Best Practices for Docker Container deployments

Container technology like Docker leads to faster testing and deployments of software applications. The following is a list of some best practices to consider when using containers. The key objectives are :
Repeatability
Reliability
Resiliency

To achieve this :

1. Have a single code base, tracked in git with many deploys

• Docker containers should be immutable
• Use the environment variables to change anything inside the container
• Do not build separate images for staging and production

2. Explicitly declare and isolate any dependencies

• Do not use latest in images. Instead define the exact version e.g. ubuntu:latest vs ubuntu:16.04
• Its useful to build run times (e.g. Java run time) based on specific images
• Process -> Base OS -> Run Time (e.g. Java run time) -> Add app

3. Store configuration in the environment

• Do not have a config.yml or properties.xml
• Always use environmental variables

4. Treat backing services as attached resources

• Never use local disk
• Data will always disappear
• Connect to network services using connection info from the environment e.g. DB_URL

5. Strictly separate build and run stages

• Build immutable images and then run them
• Never install anything on deployments
• Respect the life cycle : build, run, destroy

6. Execute the application as 1 or more stateless processes

• Schedule long running processes by distributing them across a cluster of physical hardware

7. Export services via port binding

• Define ports from environment variables
• A PID cannot guarantee the port in the container

8. Scale out via process model

• Horizontally scale by adding instances

9. Maximize robustness with fast start-up and graceful shutdown

• Quickly scale up when there is a load spike
• For a data intensive app its tempting to load data into memory as a hot cache. Issue is that this stops having a fast start-up (as need to load data into memory). Could use Redis or memcache as an alternative

10. Keep development, staging and production as simple as possible

• Run containers in development e.g. DB, caching

11. Treat logs as event streams

• Log to standard output (stdout) and standard error (stderr)
• Use something like the ELK stack to collect all the logs
• Should never need to ssh to check logs
• There should not be random log files in the container

12. Run admin/management tasks as one off processes

• Do not use customer containers as one off tasks
• Reuse app images with specific entry points for tasks