Overlays

Note

This chapter covers the LXD based workflow v1.

As soon as a single edi project configuration should support multiple use cases the use of overlays will help to get rid of duplicate configuration code. When using overlays, it is a good practice to put most of the configuration code into a single yaml file. In the example configuration used throughout the previous chapters this is the file configuration/base/my-project.yml. A use case like my-project-develop.yml is then just a symbolic link to this configuration file. The differentiation between the use cases happens in the global overlay (e.g. configuration/overlay/my-project-develop.global.yml): edi will initially load the base configuration and then merge it with the global overlay. The configuration done in the global overlay takes precedence over the configuration done in the base configuration.

edi furthermore supports two additional overlays: The configuration can be further tuned per host (the overlay file shall then end with .$(hostname).yml, e.g. .buildd.yml) and per user (the overlay file shall then end with .$(id -un).yml, e.g. .johndoe.yml). The user overlay takes the highest precedence.

The following picture illustrates how yaml configuration files will get merged:

The merged configuration can be displayed using a command like:

edi lxc configure --config my-dev-container my-project-develop.yml

The usage of overlays is optional and in any case it is not necessary to specify all possible overlays.

--config

Dump the merged configuration instead of running the command.