Recommended approach for custom extensions

[jngrb]

Using cloud-init, we want to provide specialized cloud instances with a pre-configured software component (user application). This software component comprises of several (.deb) packages and a specific configuration (rather complex, across multiple configuration files).

Cloud-init should not only pre-install the required additional packages (can easily be done with the package-update-upgrade-install module), but also allow to inject parts of the configuration in an easy fashion.

What's the recommended approach for injection such configuration details for application packages?

With full file injection and script inject, too much complexity is put into the cloud-init data. We rather want a solution tailored to the needs and avoiding complexity.

So would a custom configuration module the best way forward?

• Are there already reference implementations or good examples using such a custom module?
• Given the currently shown schema warnings, what's the best way to inform cloud-init about the schema modifications in a way that is easy to maintain?
• Where to maintain such an extension? Is there space in this repository for third-party / community extensions? What's the recommended approach to maintain a custom module in a third-party repository?
• Is there any "easier" solution? For instance, when configuring application containers for Docker or Kubernetes, often configuration is injected via environment variables. Could there be a way how this can used for cloud-init as well? E.g. a mechanism that will inject cloud-init variables into environment files for generic systemd services?

[yudin-s]

For the shape you describe, I would separate two layers:

1. Bake the large, stable application payload into an image or package: .deb dependencies, default templates, systemd units, validation scripts, and documentation.
2. Use cloud-init only for the small per-instance contract: customer/site values, feature toggles, endpoints, secrets references, or a path to a config bundle.

If those per-instance keys are application-specific and need validation/rendering across several files, a custom module is the right cloud-init-native boundary. The documented out-of-tree route is:

• create a Python module named cc_<name>.py;
• put it beside the other cloud-init config modules, such as /usr/lib/python3/dist-packages/cloudinit/config/ on Ubuntu;
• add the module name to cloud_init_modules, cloud_config_modules, or cloud_final_modules in /etc/cloud/cloud.cfg or a cloud.cfg.d file, depending on when it must run.

For an app package, I would usually ship the module in your own .deb plus a small /etc/cloud/cloud.cfg.d/<app>.cfg snippet that enables it. That keeps user-data small and lets you version the renderer/tests with the application. The module can then render /etc/default/<app>, drop files under /etc/<app>/, run package-specific validation, and restart/enable services only when appropriate.

The awkward part is schema. The cloud-init module creation docs say upstream modules should provide meta and schema documentation, but the custom-module reference also warns that out-of-tree modules introduce unknown cloud-config keys and there is not currently an easy way for those modules to register their schema with cloud-init validation. So:

• if you need first-class schema validation with no warnings, the clean path is upstreaming or carrying an image/package patch that extends the installed cloud-init schema;
• if this is private/product-specific, accept that cloud-init schema validation may warn on your custom key and do your stricter validation inside cc_<app>;
• keep the external cloud-config schema small enough that warnings are understandable, for example one top-level key like my_app:.

There is not a generic cloud-init feature that turns arbitrary cloud-config variables into systemd environment files for every application. You can approximate it with write_files plus packages/runcmd for simple cases, but once the configuration spans many files and needs app-aware validation, that becomes harder to maintain than a small custom module.

So my recommendation would be: package the application defaults, expose a narrow my_app: cloud-config API, implement an out-of-tree cc_my_app module in your product image/package, and only seek upstream cloud-init inclusion if the module is generally useful beyond your application.

If this gives you a workable extension boundary, please mark the answer as solved.

[rjhornsby]

I think @yudin-s is correct that trying to bake all of the things into cloud-init is probably too much.

In addition to his suggestions, and possibly as an alternative to baking everything into an image, you may want to look at a post cloud-init configuration management tool like chef/puppet/ansible. These are much more suited to the kinds of complex operations you're trying to execute. If you wish, you can get cloud-init to kick off an initial chef/puppet/ansible run.