Run Consistent Dev, Stage & Prod Docker Environments

Mark Shust
InstructorMark Shust

Share this video with your friends

Send Tweet
Published 4 years ago
Updated 3 years ago

Docker makes it easy to have near-full environment parity between dev, stage and prod. In this lesson we’ll go over a typical setup within Docker Compose, and how to manage backing services between dev, stage and prod.

Instructor: [00:00] We define the app surfaces we want to use within our Docker Compose YAML file. Docker makes it easy to run consistent environments between dev, stage, and prod.

[00:10] Because the images and versions we define in this YAML file are the exact images and versions we use on staging and production, we can ensure we have 100 percent parity between environments, and that differences between environments will never exist.

[00:25] Third-party backing services are typically configured with environment variables. This allows the use of the exact same code base between environments, and requests are directed to that appropriate backing service depending on the value of the environment variables.

[00:40] Let's take an example of Google Analytics. Say you want to test the functionality of your analytics code in a local environment, but don't want it to affect prod. You would simply create a new Google Analytics account, and use the ID of that test account within an environment variable.

[00:56] Then you define the environment variable within your .env file. Take the code snippet supplied from your Google Analytics account, then substitute where it calls a reference to your Analytics account number with a reference to your environment variable.

[01:11] When you start your Docker container, your environment variables will be set from your .env file, meaning that the test Analytics ID will be applied. When you deploy code through staging and production, you can use your different related Analytics IDs that are defined within each specific environment's .env file.

[01:29] Since .env files should not be committed to version control systems, you should most likely create the process of adding and changing environment variables to your deployment process. This way, you could be assured that the correct environment variables are set upon deployments to the related environment.

5f8dcf43-90be-44f5-adb2-112adaaf6f9e@anonymous.zalando.com
5f8dcf43-90be-44f5-adb2-112adaaf6f9e@anonymous.zalando.com
~ 4 years ago

Hi. One question, env variables shouldn't be store in the VCS. Where should they be stored then? It is a mystery part of the 12 factors App :) Thanks

Alan Plum
Alan Plum
~ 4 years ago

Hi. One question, env variables shouldn't be store in the VCS. Where should they be stored then? It is a mystery part of the 12 factors App :)

Yupp, that seems to be an "exercise left to the reader" but if you can't think of any place other than the VCS, you can store them in the VCS as long as you encrypt them with a strong cipher. This means they're "hidden in plain sight" and as long as the unencrypted file never touches the VCS you get the best of both worlds. Of course that only moves the problem from "how does the env file end up on the server" to "how does the decryption key end up on the server" but that seems easier to solve.

Mark Shust
Mark Shustinstructor
~ 4 years ago

I'd recommend to not put them on VCS. Just keep them on the filesystem? :) Just don't version them.

If you need backups of env vars, just make backups and keep them outside of the VCS. The generation of env var files can also be included in the build process if desired. Really depends on the application/need.

Michael
Michael
~ 4 years ago

How to share environment variable files with other developers? If a developer adds an environment variable for a new feature, all other developers must set this environment variable as soon as the feature is merged into the develop branch. How to document and communicate change of environment variables? If you switch between (feature-) branches, you might need different environment variables. How to manage them if they are not tracked by the VCS? How to detect conflicts, if the same environment variable name is used in another feature branch that is merged into develop branch? You might not get a git merge conflict.