When adopting Docker containers as a way to deploy applications and functionality in your landscape one of the tricks is to make sure you do not have to many different types of containers. Even though it is relatively simple to build a container and bake all configuration into it this might cause issues at a later stage. All container images need to be maintained and have some level of lifecycle management applied to them.
For this reason, it is better to limit the number of containers and ensure you can dynamically control the behaviour. This might cause a bit more work when developing the container image and will need to have some thinking about how to dynamically configure a container based upon a limited set of input parameters.
The reason you want to limit the number of parameters you provide a container during startup is that it is relative inflexible and will cause an additional burden on the teams responsible for ensuring the containers are always up and running in the right manner.
A better way is to store configuration data externally and have the container collect the configuration data based upon one (or max two) parameters. This can be for example the role of a container or the environment name where it will be deployed.
As an example, if we build a container for
Oracle ORDS which will connect on one side to an Oracle database and on the other side provide a REST API interface to consumers you can make use of this principle. You do want to build a ORDS Docker container only once and would like to inform the container with a parameter which configuration details it needs to gather to start in the right role and manner within the landscape.
We have been building Oracle ORDS containers based upon
Oracle Linux 7 Slim, as part of the script that starts ORDS in the container we have included parts that will ensure it will connect to a Consul Key Value store and collect the needed data to dynamically build the configuration files that are used by ORDS to start.
As an example, our ORDS container already knows it is an ORDS container, at startup we provide the input parameter that informs the container that the application name is “app0”. Based upon this knowledge the scripting will be able to fetch the needed configuration data from the
Consul REST API.
In Consul we have provided all the needed KV pairs for the script to write the ORDS configuration. If we for example want to have the database hostname where an ORDS “app0” container needs to connect to we execute the below curl command to fetch the data:
curl -s http://192.168.56.52:8500/v1/kv/ords/app0/params/db.hostname | jq '.[].Value' | tr -d '"' | base64 –decode
The reason we use jq in the above example is to help with fetching "Value" from the JSON message we get returned by Consul. If we look at the full JSON message we get returned we see we get the below returned:
[
{
"LockIndex": 0,
"Key": "ords/app0/params/db.hostname",
"Flags": 0,
"Value": "MTkyLjE2OC41Ni4xMDE=",
"CreateIndex": 8026,
"ModifyIndex": 8047
}
]
In our case we are only interested in "value", by adding
jq '.[].Value' to the command we will only get the content of "Value" returned. However, value is between double quotes and is a base64 encoded string. If we want to decode the base64 encoded string we need to feed this into the base64 command which will not work if we still have it wrapped in the double quotes. This is the reason we pipe the result first into the tr command to strip off the double quotes. The result is a clear base64 encoded string which we can decode using the base64 --decode command.
Placing Consul in the center
By placing Consul in the center of your deployment you will add a KV store which can be used in combination with your Docker containers to play a vital role in how containers are started. By ensuring you have a way of controlling how Consul is positioned per environment (think development, test, acceptance & production like environments) you can influence extremely well how containers are behaving in relation to the environment they are running in.
Building the right and useable structure in the Consul KV store is vital for building the level of flexibility you need in a dynamic landscape.
Spending the right amount of time in thinking about the KV structure which can be used in every environment and thinking about how containers will fetch data from a central Consul KV store in your landscape will require some time and effort, however, will provide you with a lot of benefits in the longer run when operating a wider container based footprint.
