Run Consistent Dev, Stage & Prod Docker Environments
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.