{"id":4482,"date":"2026-01-26T21:08:31","date_gmt":"2026-01-26T15:38:31","guid":{"rendered":"https:\/\/www.itsupportwale.com\/blog\/10-docker-best-practices-to-optimize-your-containers\/"},"modified":"2026-02-17T15:57:18","modified_gmt":"2026-02-17T10:27:18","slug":"10-docker-best-practices-to-optimize-your-containers","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/10-docker-best-practices-to-optimize-your-containers\/","title":{"rendered":"10 Docker Best Practices to Optimize Your Containers"},"content":{"rendered":"

text
\n[2024-05-22 03:14:02] INFO: Deployment triggered by ‘Rockstar_Dev_69’
\n[2024-05-22 03:15:44] ERROR: Failed to pull image “registry.internal\/awesome-app:latest”
\n[2024-05-22 03:15:44] ERROR: RPC error: code = Unknown desc = failed to register layer: Error processing tar file(exit status 1): write \/usr\/src\/app\/node_modules\/huge-useless-library\/dist\/bundle.js: no space left on device
\n[2024-05-22 03:16:10] CRITICAL: Node ip-10-0-42-12.ec2.internal is DiskPressure
\n[2024-05-22 03:16:15] CRITICAL: Kubelet stopped posting node status.
\n[2024-05-22 03:17:00] FATAL: Production cluster is unresponsive. PagerDuty initiated.<\/p>\n

I am currently staring at a cold cup of coffee and a terminal screen that is bleeding red. It is 4:00 AM. I have been awake for 72 hours because you decided that the "docker best" way to deploy a simple Node.js microservice was to wrap it in a 3GB container image and push it directly to our production registry using the `latest` tag. \n\nOur nodes didn't just fail; they choked. They tried to pull your bloated monstrosity, ran out of disk space on the root partition, and the Kubelet died in a fit of rage. I had to manually prune the build cache on twelve different workers just to get the control plane to talk to me again. \n\nSit down. We are going to talk about why your "it works on my machine" mentality is a cancer on this infrastructure.\n\n## Stop Using 'Latest' Like a Gambler\n\nYou tagged your image as `latest`. Do you know what `latest` means in Docker Engine 24.0.7? It means absolutely nothing. It is a default label, not a pointer to the most recent stable build. When you pushed that 3GB image, every single node in the cluster that had an `imagePullPolicy: Always` setting tried to pull it simultaneously. \n\nBecause you didn't version your image, I couldn't roll back. I couldn't just tell Kubernetes to go back to `v1.2.3` because you\u2019ve been overwriting `latest` for the last three weeks. We had to dig through the registry API to find the SHA256 hash of the previous working image while the CEO was screaming in the Slack bridge.\n\nIn a real environment, you pin your versions. You use semantic versioning. You use the git commit hash. You do anything except use that godforsaken tag. If I see another deployment manifest with `image: awesome-app:latest`, I am revoking your registry write permissions and making you deploy via carrier pigeon.\n\n## Your Layers are Bloated and You Should Feel Bad\n\nI ran a `docker history` on your image. It was like performing an autopsy on a man who died from eating too much lead. Here is what I saw:\n\n```bash\nIMAGE          CREATED        CREATED BY                                      SIZE      COMMENT\n<missing>      2 hours ago    \/bin\/sh -c #(nop)  CMD ["npm" "start"]          0B        \n<missing>      2 hours ago    \/bin\/sh -c npm install                          1.8GB     \n<missing>      2 hours ago    \/bin\/sh -c #(nop) COPY dir:7e3... in \/app       1.1GB     \n<missing>      2 hours ago    \/bin\/sh -c apt-get update && apt-get install\u2026   450MB     \n<missing>      3 weeks ago    \/bin\/sh -c #(nop)  WORKDIR \/app                 0B        \n<missing>      3 weeks ago    \/bin\/sh -c #(nop)  FROM node:bookworm           850MB     \n<\/code><\/pre>\n
Three gigabytes. For a Hello World API. <\/p>\n
You used node:bookworm<\/code> (Debian Bookworm) as your base image. Why? Do you need a full suite of build tools, man pages, and a C compiler in production? No. You don’t. You included the .git<\/code> directory. You included the tests<\/code> folder. You included the node_modules<\/code> from your local macOS environment which, newsflash, doesn’t work on Linux when you have native C++ bindings.<\/p>\n
You need to understand OverlayFS2. Every RUN<\/code>, COPY<\/code>, and ADD<\/code> instruction in your Dockerfile creates a new layer. These layers are stacked. If you COPY<\/code> 1GB of data in one layer and then RUN rm -rf<\/code> that data in the next, your image is still 1GB larger. The data is still there, hidden in the lowerdir, haunting the filesystem like a vengeful ghost. To keep things “docker best” compliant, you must clean up in the same layer where the mess was made.<\/p>\n
\n
Table of Contents<\/p>\n