Extend flavour system with config files?

[hny-gd]

Dear cooks,

I would like to start a discussion regarding a potential best practice regarding using the flavour system for creating more complex container images.

Background

As you probably know, I have set up Potluck a few weeks ago (https://potluck.honeyguide.net and https://github.com/hny-gd/potluck) which aims to create a repository of preconfigured but nonetheless adaptable pot images/flavours. The long term aim is to have something like Dockerhub for Pot.

These images can be used as stand alone jails but also via the nomad-pot-driver (or potentially any other orchestration platform in the future that chooses to support pot).

The high-level approach that I chose to create new containers that remain somewhat configurable after creation looks like this:

• Create flavour scripts and shell scripts that are run when preparing the image (stock pot functionality)
• These flavour scripts create a script within the jail (/usr/local/bin/cook) that is set up to be started automatically when the jail is started
• When a user fetches the pot image, he can parametrize it for his environment with pot set-env - each container has a certain set of environment variables that can be set (e.g. to define hostnames, certain options etc)
• When the fetched image is started for the first time with these environment variables, the cook script uses the variables to create the various config files necessary to run the packages within the jail
• After that, the configuration is finished and from now on on each run the services are started within the jail

A more detailed explanation including the current template for pot images can be found here: https://potluck.honeyguide.net/howto/

Challenge

Beside all the issues with this approach that I don't see (any kind of feedback is welcome), the main problem that I do see is that this mixes code & configuration in one huge and very unwieldy shell script: Each cook script contains all the configuration files in the form

echo "
configfile content line 1
configfile \$PARAMETERVARIABLE
...
" > /usr/local/etc/myparametrisedconfig.conf

...because it needs to read $PARAMETERVARIABLE on the first run and set it in the config file. And this cook script in turn is saved within the flavour shell script so that it gets created when pot creates the image so that it can be run when the jail starts the first time.

Proposal

Therefore I have the following suggestion:

Extend the flavour system with a directory of files that are copied into the jail when the flavour is processed by pot. E.g. when there are the files <flavour> and <flavour>.sh, add the directory <flavour>.d that contains files that are copied into the jail before executing the <flavour>.sh file. Copy details (e.g. target directory) could be set in the <flavour> file.

These files could be template files that in the potluck case are now within the cook script (like e.g. saltstack has them) or any other kind of scripts that could then be processed by a script like the cook script to set variable values.

This probably would be a bit similar to a dockerfile ADD.

Why not pot copy-in?

Of course there is pot copy-in, but (according to my understanding) this is either a manual call and thus not part of the flavour definition or as part of a flavour not suitable if one wants to have it executed only once on pot create and then never again.

What are your thoughts? Do you have better ideas?

[pizzamig]

Hi. copy-in can be used in a flavor. The limitations are:

• the file/directory is copied during creation only, not at start, because the flavor is used at create time.
• there is no support for templates

The first limitation can be somehow fixed with pre-start hook: you can can overwrite a configuration file copying it from the host to the jail.

What you are doing with cook is the template stanza in nomad. However, pot doesn't provide this kind of feature outside the nomad plugin.

Rendering a configuration file from a template could be an additional feature, tho.

[hny-gd]

Thanks a lot, @pizzamig, then I misunderstood the copy-in within a flavour (I thought that it would be set as configuration parameter that is executed each time).

Will test it with the next flavour I am working on right now.

Regarding configuration file templates: I could imagine it would really add value to pot outside of the nomad/consul context. I have not yet thought about how this could look like to fit well into the pot logic/philosophy though.