{"id":4735,"date":"2026-03-15T21:07:29","date_gmt":"2026-03-15T15:37:29","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/docker-image-guide-how-to-build-run-and-manage-images\/"},"modified":"2026-03-15T21:07:29","modified_gmt":"2026-03-15T15:37:29","slug":"docker-image-guide-how-to-build-run-and-manage-images","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/docker-image-guide-how-to-build-run-and-manage-images\/","title":{"rendered":"Docker Image Guide: How to Build, Run, and Manage Images"},"content":{"rendered":"

text
\n[root@prod-node-04 ~]# docker pull registry.internal.corp\/analytics\/data-cruncher:latest
\nlatest: Pulling from analytics\/data-cruncher
\nd5a1f291072d: Already exists
\nf23a467d5e21: Pull complete
\n4f4fb5514a3d: Pull complete
\n7d23456789ab: Extracting [==================================================>] 2.1GB\/2.1GB
\n8e34567890cd: Extracting [========================> ] 1.2GB\/2.4GB
\nfailed to register layer: Error processing tar file(exit status 1): write \/usr\/lib\/x86_64-linux-gnu\/libLLVM-15.so.1: no space left on device
\n[root@prod-node-04 ~]# df -h \/var\/lib\/docker
\nFilesystem Size Used Avail Use% Mounted on
\n\/dev\/nvme0n1p3 100G 96G 0 100% \/var\/lib\/docker
\n[root@prod-node-04 ~]# date
\nSun Oct 20 03:14:22 UTC 2024<\/p>\n

The smell of a data center at 3:00 AM is a specific cocktail of ionized air, floor wax, and the metallic tang of overheating copper. I\u2019m sitting on a cold raised-floor tile in Row 4, my laptop balanced on a crash cart, staring at the terminal output above. This is the "modern" infrastructure we were promised. This is the "efficiency" of the container revolution. \n\nA junior developer, likely someone who thinks a "socket" is something you plug a lamp into, pushed a 4.5GB image to the registry. They didn't bother to check the base image. They didn't bother to clean up the build dependencies. They just kept stacking layers like a toddler playing with sticky blocks until the underlying filesystem\u2014a perfectly tuned XFS partition on a high-speed NVMe\u2014choked to death on the sheer volume of redundant garbage.\n\nWe used to ship binaries. We used to ship 15MB ELF files that did one thing and did it well. Now, we ship entire operating systems, half-baked Python environments, and three different versions of the LLVM compiler just to run a microservice that calculates a sales tax. It is a disgrace.\n\n## The Bloat is the Point\n\nThe "docker image" is not a revolutionary technology. It is a glorified tarball with an identity crisis. At its core, it is a collection of filesystem changes wrapped in a JSON manifest that tells the Docker Engine (currently v25.0.3 in this godforsaken cluster) how to stack them using a union filesystem. \n\nThe industry has moved away from the discipline of the "bare metal" era, where every byte of RAM was a precious resource, toward a culture of "storage is cheap, so let's be lazy." But storage isn't cheap when you're paying for the IOPS to pull a 4GB image across a saturated 10GbE link every time a pod restarts.\n\nWhen you pull `debian:bookworm`, you aren't just getting the tools you need. You're getting a whole graveyard of legacy utilities, man pages, and shared libraries that your application will never touch. But that\u2019s just the start. Developers treat these images like virtual machines. They `apt-get install` everything from `vim` to `net-tools` "just in case" they need to debug. \n\nThe result? A bloated, sluggish monster. The "image" becomes a black box. Because it\u2019s so easy to just `docker build`, nobody asks what\u2019s actually inside. They don't see the 400MB of `.pyc` files or the `.git` directory accidentally copied into the image because someone forgot a `.dockerignore` file. The bloat isn't an accident; it's the inevitable outcome of a system that rewards convenience over competence.\n\n## Layer Caching: The False Promise of Speed\n\nDocker's marketing team loves to talk about layer caching. They tell you that if you don't change a layer, you don't have to rebuild it or pull it. It sounds like magic. In reality, it\u2019s a leaky abstraction that creates more problems than it solves.\n\nDocker uses the `Overlay2` storage driver. It works by creating a series of directories on the host\u2014usually under `\/var\/lib\/docker\/overlay2`\u2014and merging them into a single unified view using the kernel's union mount capabilities. When you run a command in a Dockerfile, Docker creates a new layer. If you delete a file in that layer, it isn't actually gone. It\u2019s just hidden by a "whiteout" file in the upper layer.\n\nLook at this `docker history` output from the failed image:\n\n```bash\n[root@prod-node-04 ~]# docker history --no-trunc analytics\/data-cruncher:latest\nIMAGE          CREATED        CREATED BY                                                                                          SIZE      COMMENT\n<missing>      2 hours ago    RUN \/bin\/sh -c apt-get update && apt-get install -y build-essential python3-dev libllvm15 && rm -rf \/var\/lib\/apt\/lists\/* # buildkit   1.85GB    \n<missing>      2 hours ago    COPY . \/app # buildkit                                                                              2.1GB     \n<missing>      3 hours ago    RUN \/bin\/sh -c pip install -r requirements.txt # buildkit                                           450MB     \n<missing>      4 hours ago    FROM debian:bookworm                                                                                117MB     \n<\/code><\/pre>\n
Notice the 2.1GB COPY . \/app<\/code> layer? The developer copied their entire local environment, including a venv<\/code> folder and several large CSV test files, into the image. Then, in the next layer, they installed build-essential<\/code>. Even if they had tried to clean up the build tools in a later RUN<\/code> command, the 1.85GB of compilers and headers would still exist in the previous layer, forever haunting the disk space of every node in the cluster.<\/p>\n
The “cache” is only as good as the developer’s understanding of the build order. Change one line at the top of your Dockerfile, and every subsequent layer is invalidated. You’re back to pulling gigabytes of data. It\u2019s a fragile system that encourages “clever” Dockerfile hacks rather than actual optimization.<\/p>\n
\n
Table of Contents<\/p>\n