Docker Best Practices - BKJackson/BKJackson_Wiki GitHub Wiki

Articles

Dockerfile Best Practices - Docker docs
Best Practices for Operating Containers
Best practices for building containers
6 Docker Basics You Should Completely Grasp When Getting Started - July 13, 2017
Overcoming Docker's Mutable Image Tags
A New, Better Way to Automatically Update Docker Containers - Oct 21, 2018, 4 min read
Intro Guide to Dockerfile Best Practices - Docker blog

Docker workflows

Automate Your Dev Workflow with Docker - Covers importance of consistent environments.
Automate Your Docker Deployments

Notes from Best practices for building containers - Article from Google Cloud site

• Package a single app per container
  When you start working with containers, it's a common mistake to treat them as virtual machines that can run many different things simultaneously. A container can work this way, but doing so reduces most of the advantages of the container model. For example, take a classic Apache/MySQL/PHP stack: you might be tempted to run all the components in a single container. However, the best practice is to use two or three different containers: one for Apache, one for MySQL, and potentially one for PHP if you are running PHP-FPM.

• On using bash scripts
  A bad practice: Using a bash script as an entrypoint in a container and making it spawn several apps as background jobs. For the proper use of bash scripts in containers, see Properly handle PID 1, signal handling, and zombie processes.

• Properly handle process identifiers (PIDs) 1, signal handling, and zombie processes Process identifiers (PIDs) are unique identifiers that the Linux kernel gives to each process. PIDs are namespaced, meaning that a container has its own set of PIDs that are mapped to PIDs on the host system. The first process launched when starting a Linux kernel has the PID 1. The first process launched in a container gets PID 1. Docker and Kubernetes use signals to communicate with the processes inside containers, most notably to terminate them. Both Docker and Kubernetes can only send signals to the process that has PID 1 inside a container.

Linux signals are the main way to control the lifecycle of processes inside a container. In line with the previous best practice, in order to tightly link the lifecycle of your app to the container it's in, ensure that your app properly handles Linux signals. The most important Linux signal is SIGTERM because it terminates a process. Your app might also receive a SIGKILL signal, which is used to kill the process non-gracefully, or a SIGINT signal, which is sent when you type Ctrl+C and is usually treated like SIGTERM.