Settings and Secrets Volume
Provisioning settings directory
Many applications require custom configurations, secrets, SSL certificates and various other settings stored in files outside a container image. A typical approach to providing the required files for processes in a container is to mount a local directory or a file to a container. A cluster of distributed hosts does not have such a local directory equally available for all the hosts unless you opt into some sort of network file system.
Overnode takes simpler approach. It uploads the content of a current working project directory to all the nodes, when the up command is invoked. The down command reverts the action. The uploaded files and subdirectories can be universally mounted to containers using OVERNODE_ETC environment variable.
For example, let's create a file for the echo service, which we played with before:
And now mount it to the echo server container to the /settings
path as read-only:
Once the configuration is reapplied:
The echo server can serve the provisioned file:
Excluding files / directories
By default, the Overnode uploads all the files from the working project directory. You can exclude some files or directories by enumerating them in the .overnodeignore file. The minimal recommended content for the file is the following:
Recreating containers on settings change
When supportive settings or secret files are updated and re-uploaded again with the up command, some processes within containers may detect the updates in files and take the required actions automatically. But some other may require a restart, which you can trigger with help of the restart command. Alternatively, we can implement the strategy to re-create affected containers after the upload automatically.
Let's say we would like to re-create the container for the above configured echo
service, when the hello-world.txt
file is changed.
First, we instruct the Overnode to md5 hash the content of the required file or directory automatically before every upload by placing md5env file with a corresponding name and location. For example:
And secondly, we instruct the underlying Docker Compose engine to use the hash value as an environment variable via the env_file
property. The change in the environment variable value will force recreation of a container:
Finally, the up command will always trigger re-creation for containers, which project the updated md5env file:
We can also check the hash environment variable value echoed by the server: