10 Essential Docker Do‑Not‑Do Rules for Reliable Deployments

When you finally embrace containers, you discover they solve many problems and offer numerous advantages:

They are immutable – OS, library versions, configurations, directories and applications are identical. Using the same QA‑tested image ensures consistent product behavior.

They are lightweight – containers consume very little memory, only the memory for the main process plus a few dozen MB.

They are fast – starting a container is as quick as launching a single process, taking seconds rather than minutes.

However, many users still treat containers like traditional VMs, forgetting that containers are also disposable.

Container principle: “Containers are temporary.”

This characteristic forces users to change how they use and manage containers. Below are practices to avoid in order to maximize container benefits.

1) Do not store data inside containers – Containers may be stopped, destroyed, or replaced. Store persistent data in volumes and ensure applications are designed to write to shared storage.

2) Do not publish your application twice – Do not manually deploy the app inside a running container; instead, bake the app into the image so the container remains immutable.

3) Do not create oversized images – Keep images small by including only files and libraries required to run the application; avoid unnecessary packages or running updates during build.

4) Do not use a single‑layer image – Use a layered filesystem: base OS layer, security/user layer, library layer, configuration layer, and application layer to simplify rebuilding and distribution.

5) Do not create images from running containers – Avoid “docker commit”; use Dockerfiles or other reproducible S2I methods to build images.

6) Do not rely solely on the “latest” tag – Tag images explicitly; the “latest” tag behaves like a Maven snapshot and can lead to unexpected incompatibilities.

7) Do not run more than one process in a single container – Containers are designed for a single main process; multiple processes complicate logging and updates.

8) Do not store credentials in images – Use environment variables to inject secrets from outside the container.

9) Do not run processes as root – Use the USER directive to run containers with a non‑root user for better security.

10) Do not depend on container IP addresses – Use service names or environment variables for inter‑container communication, as IPs may change.

Source: https://www.cnblogs.com/zuxing/articles/9554093.html