Posted onSep 27, 2022 • Originally published athackmamba.io

Best Practices when using Docker Compose

#docker #devops #cloud

This article was originally posted onHackmamba.

Container technology has streamlined how you’d build, test, and deploy software from local environments, to on-premise data centers, or the cloud. But while using container technology, a new problem of manually starting and stopping each container arose, making it tedious to build multi-container applications.

To solve this problem, Docker Inc createdDocker Compose. You can use Docker Compose to simplify the running of multi-container applications with as little as two commands;docker-compose up anddocker-compose down. But as with every software tool, there are best practices to use it efficiently.

This article will discuss 4 best practices you should consider when using Docker Compose to orchestrate multi-container Docker applications. The best practices are:

Substitute environment variables in Docker Compose files
If possible, avoid multiple Compose files for different environments
Use YAML templates to avoid repetition
Usedocker-compose up flags where necessary

Substitute Environment Variables in Docker Compose Files

Ideally, when defining a Compose file, you would have environment variables with secrets you wouldn’t want to push to any source code management platform like GitHub.

It is best to configure those environmental variables in the machine's shell, where you will deploy the multi-container application, so there are no secret leaks. And then populate the environment variables inside the Docker Compose file by substituting as seen below.

mongoDB:    environment:      - MONGO_INITDB_ROOT_USERNAME=${MONGO_INITDB_ROOT_USERNAME}      - MONGO_INITDB_ROOT_PASSWORD=${MONGO_INITDB_ROOT_PASSWORD}

With the above configuration in your Docker Compose file, when you rundocker-compose up, Docker Compose will look for theMONGO_INITDB_ROOT_USERNAME andMONGO_INITDB_ROOT_PASSWORD environment variables in the shell and then substitute their values in the file.

How toAddEnvironmentVariables to yourShell
Ideally, to add to a shell, you would useexport VARIABLE=<variable_value>. But with that method, if the host machine reboots, those environment variables will be lost.

To add environment variables that would persist through reboots, create an environment file with:

$ vi .env

And in that file, store your environment variables like in the image below and save the file.

Then in the root directory of your production machine, run$ ls -la, which should show you a.profile as shown in the image below.

Open up the profile file with$ vi .profile and at the end of the file, add this configuration:

set -o allexport; source /<path_to_the_directory_of_.env_file>/.env; set +o allexport

The above configuration will loop through all the environment variables you set and add them to your machine.

And to ensure the configuration takes effect, log out of your shell session, log back in, and then run:

$ printenv

You should see your environment variables, as shown in the image below.

Check out thisdocumentation to learn more about best practices using environment variables in Docker Compose.

If Possible, Avoid Multiple Compose Files for Different Environments

AlthoughDocker suggests defining an additional Compose file for a specific environment, e.g.,docker-compose-prod.yaml for your production environment. This approach can cause issues as it is manual and error-prone when reapplying all modifications from one environment to another. Also, it increases the complexity of your development process when you consider CI, staging, or QA environments.

As a rule, you should always try to keep only a single Docker Compose file for all environments. But in cases where you might want to usenodemon to monitor changes in your node application during development. Or perhaps you would use a managed MongoDB database in production but run MongoDB locally in a container for development.

For these cases, you can use thedocker-compose.override.yml file. As its name implies, the override file will contain configuration overrides for existing or entirely new services in yourdocker-compose.yaml file.

To run your project with the override file, you still run the defaultdocker-compose up command. Then Docker Compose will automatically merge thedocker-compose.yml anddocker-compose.override.yml files into one. Suppose you defined a service in both files; Docker Compose merges the configurations using the rules described inAdding and overriding configuration.

You can add the override file to your.gitignore file, so it won't be there when you push code to production. After doing this, if you still see the need to create more Compose files, then go ahead but keep in mind the complexity.

Use YAML Templates to Avoid Repetition

When a service has options that will repeat in other services, you can create a template from the initial service to reuse in the other services instead of continuously repeating yourself.

The following illustrates Docker Compose YAML templating:

version: '3.9'services:  web: &service_default    image: .    init: true    restart: always   backend:    <<: *service_default # inheriting the service defaults definitions    image: <image_name>    env_file: .env    environment:      XDEBUG_CONFIG: "remote_host=${DOCKER_HOST_NAME_OR_IP}"

In the above YAML configuration, the first service definesrestart: always, which will restart the container automatically if it crashes. Instead of addingrestart: always and other recurring configs you might have to all your services, you can replicate them with<<: *service_default.

Check out thisarticle to learn more about YAML templating capabilities for Docker Compose.

Use`docker-compose up` Flags Where Necessary

To make your development process a lot easier when creating and starting up containers withdocker-compose up, you could use the features provided bydocker-compose up flags.

To see these flags, you can run the command below in your terminal:
$ docker-compose up --help

Also, you can see them in thecompose up command line reference, but viewing them on your terminal is easier during development.

Conclusion

This article discussed 4 best practices you should consider when using Docker Compose to orchestrate multi-container Docker applications. There are other best practices you can consider; to learn more about them, check out the following resources: