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.