{"id":4820,"date":"2026-06-21T22:20:33","date_gmt":"2026-06-21T16:50:33","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/"},"modified":"2026-06-21T22:20:33","modified_gmt":"2026-06-21T16:50:33","slug":"what-is-a-docker-image-a-complete-guide-for-beginners-2","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/","title":{"rendered":"What is a Docker Image? A Complete Guide for Beginners"},"content":{"rendered":"<p>[2024-05-22 03:14:22] ERROR: Failed to pull image &#8220;registry.internal\/frontend-monolith:latest&#8221;<br \/>\n[2024-05-22 03:14:22] Kubelet: FailedToPull &#8220;failed to register layer: Error processing tar file(exit status 1): write \/usr\/local\/lib\/node_modules\/very-large-useless-package: no space left on device&#8221;<br \/>\n[2024-05-22 03:15:01] CRITICAL: Node ip-10-0-42-11.ec2.internal is DiskPressure<br \/>\n[2024-05-22 03:15:10] ALERT: Production environment is down. 0\/15 pods running.<\/p>\n<p>$ docker history registry.internal\/frontend-monolith:latest<br \/>\nIMAGE          CREATED        CREATED BY                                      SIZE      COMMENT<br \/>\n<ID>           2 hours ago    \/bin\/sh -c #(nop)  CMD [&#8220;npm&#8221; &#8220;start&#8221;]          0B      <br \/>\n<ID>           2 hours ago    \/bin\/sh -c npm install &amp;&amp; npm run build         1.85GB  <br \/>\n<ID>           2 hours ago    \/bin\/sh -c #(nop) COPY dir:7a8&#8230; in \/app       850MB   <br \/>\n<ID>           2 hours ago    \/bin\/sh -c apt-get update &amp;&amp; apt-get upgrade -y 420MB   <br \/>\n<ID>           3 months ago   \/bin\/sh -c #(nop)  FROM node:20.11.1            1.1GB     <\/p>\n<p>It\u2019s 4:00 AM. My coffee is cold, my eyes feel like they\u2019ve been rubbed with sandpaper, and I\u2019ve just spent the last three days of my life cleaning up a mess that shouldn\u2019t have existed in the first place. The logs above are the autopsy of a &#8220;modern&#8221; deployment. A single <strong>docker image<\/strong>, pushed by a developer who thinks disk space is a magical, infinite resource provided by the cloud gods, managed to bring down an entire production cluster. <\/p>\n<p>The Kubelet died. The storage driver choked. The nodes went into a death spiral because someone decided that a 3.2GB container image was a reasonable way to ship a frontend application. This isn&#8217;t just a technical failure; it&#8217;s a failure of discipline. It\u2019s the result of a generation of engineers who treat the containerization process as a &#8220;black box&#8221; where they can dump their entire local development environment and hope the orchestrator figures it out. <\/p>\n<p>I\u2019m tired of it. I\u2019m tired of the &#8220;it works on my machine&#8221; mentality being packaged into a bloated tarball and shoved into a registry. Let\u2019s talk about why your <strong>docker image<\/strong> is a liability.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_80 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-6a382e24ca7c4\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-6a382e24ca7c4\"  aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#The_25GB_%E2%80%9CHello_World%E2%80%9D_and_the_Death_of_Common_Sense\" >The 2.5GB &#8220;Hello World&#8221; and the Death of Common Sense<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#Layer_Caching_How_Your_Order_of_Operations_is_Killing_the_Build_Server\" >Layer Caching: How Your Order of Operations is Killing the Build Server<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#The_%E2%80%9Cdocker_history%E2%80%9D_Audit_Finding_the_Hidden_Skeletons_in_Your_Layers\" >The &#8220;docker history&#8221; Audit: Finding the Hidden Skeletons in Your Layers<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#Multi-Stage_Builds_The_Only_Way_to_Keep_Your_Sanity_and_Your_Disk_Space\" >Multi-Stage Builds: The Only Way to Keep Your Sanity and Your Disk Space<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#Distroless_Scratch_and_the_Art_of_Minimalist_Suffering\" >Distroless, Scratch, and the Art of Minimalist Suffering<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#The_Security_Tax_of_Laziness_Why_Your_Image_is_a_CVE_Playground\" >The Security Tax of Laziness: Why Your Image is a CVE Playground<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#Related_Articles\" >Related Articles<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"The_25GB_%E2%80%9CHello_World%E2%80%9D_and_the_Death_of_Common_Sense\"><\/span>The 2.5GB &#8220;Hello World&#8221; and the Death of Common Sense<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The first thing I saw when I looked at the Dockerfile for this disaster was <code>FROM node:20.11.1<\/code>. Not the slim version. Not the Alpine version. The full-fat, Debian-based, everything-including-the-kitchen-sink image. Why? Because the developer &#8220;didn&#8217;t want to deal with missing dependencies.&#8221; <\/p>\n<p>When you pull a base image like that, you aren&#8217;t just pulling Node.js. You are pulling a full operating system distribution. You\u2019re pulling build tools, compilers, headers, and documentation for libraries you will never, ever call. You are pulling <code>gcc<\/code>, <code>make<\/code>, and <code>python3.12.2<\/code> (yes, inside a Node image) just in case some obscure native module needs to compile during <code>npm install<\/code>. <\/p>\n<p>But it gets worse. Look at that <code>apt-get upgrade -y<\/code> line in the history. That is a crime against humanity. When you run an upgrade inside a Dockerfile layer, you are effectively creating a &#8220;snowflake&#8221; image. You are saying, &#8220;I want whatever the Debian mirrors happen to have at this exact microsecond.&#8221; It breaks build idempotency. It ensures that no two builds will ever be the same. And because of how UnionFS works, that layer is now a permanent part of your <strong>docker image<\/strong>. <\/p>\n<p>UnionFS is a stackable filesystem. Every command in your Dockerfile creates a new layer. These layers are additive. If you install 400MB of updates in one layer and then try to &#8220;clean up&#8221; in the next, you haven&#8217;t saved a single byte. The 400MB is still there, buried in the lower layers, taking up space on the disk, consuming bandwidth during the pull, and slowing down the container start time. The kernel has to mount every single one of these layers using the <code>overlay2<\/code> storage driver, merging the <code>upperdir<\/code> and <code>lowerdir<\/code> into a <code>merged<\/code> view. Every layer you add increases the complexity of the filesystem lookups. Every layer is a potential performance bottleneck.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Layer_Caching_How_Your_Order_of_Operations_is_Killing_the_Build_Server\"><\/span>Layer Caching: How Your Order of Operations is Killing the Build Server<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>I watched the CI\/CD logs for this project. The build took 22 minutes. For a React app. Why? Because the developer put <code>COPY . .<\/code> at the top of the Dockerfile. <\/p>\n<pre class=\"codehilite\"><code class=\"language-dockerfile\">FROM node:20.11.1\nWORKDIR \/app\nCOPY . .\nRUN npm install\nRUN npm run build\n<\/code><\/pre>\n<p>This is the peak of inefficiency. By copying the entire source directory before running <code>npm install<\/code>, you invalidate the cache for the most expensive part of the build\u2014the dependency installation\u2014every single time a single character changes in a README file. <\/p>\n<p>The Docker daemon calculates a hash for the files being copied. If that hash changes, the cache for that layer and every subsequent layer is discarded. You are forcing the build server to reach out to the registry, download hundreds of megabytes of <code>node_modules<\/code>, and write them to disk over and over again. <\/p>\n<p>A sane person\u2014someone who actually cares about the health of the registry and the build server\u2014would do this:<\/p>\n<pre class=\"codehilite\"><code class=\"language-dockerfile\">FROM node:20.11.1-slim\nWORKDIR \/app\nCOPY package.json package-lock.json .\/\nRUN npm ci --only=production\nCOPY . .\nRUN npm run build\n<\/code><\/pre>\n<p>By copying only the manifest files first, you allow Docker to cache the <code>npm ci<\/code> layer. Unless you change your dependencies, that 1.8GB of <code>node_modules<\/code> cruft stays in the cache. But even then, why are we shipping <code>node_modules<\/code> at all? Why is the production <strong>docker image<\/strong> carrying around the source code, the test suites, the linter configurations, and the <code>node_modules<\/code> folder that contains <code>babel<\/code>, <code>webpack<\/code>, and <code>typescript<\/code>? None of those are needed at runtime. They are build-time artifacts. Shipping them to production is like shipping the scaffolding along with the finished skyscraper.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The_%E2%80%9Cdocker_history%E2%80%9D_Audit_Finding_the_Hidden_Skeletons_in_Your_Layers\"><\/span>The &#8220;docker history&#8221; Audit: Finding the Hidden Skeletons in Your Layers<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>When the cluster started screaming, I ran <code>docker history --no-trunc<\/code>. It\u2019s a horror story in plain text. I found layers that were nothing but <code>chown<\/code> commands. <\/p>\n<p>Did you know that if you run <code>RUN chown -R node:node \/app<\/code> on a directory that contains 1GB of data, you have just added another 1GB to your <strong>docker image<\/strong>? The <code>overlay2<\/code> driver doesn&#8217;t just change the metadata of the files. Because layers are immutable, it has to copy the files to the &#8220;upper&#8221; layer to apply the new ownership. You now have two copies of your data sitting on the disk. <\/p>\n<p>I also found the <code>.git<\/code> directory. 800MB of git history, hidden inside the image. The developer forgot a <code>.dockerignore<\/code> file. So, every time they built the <strong>docker image<\/strong>, the entire history of the project\u2014every deleted branch, every large binary ever accidentally committed, every secret ever pushed and then &#8220;removed&#8221;\u2014was sent to the Docker daemon as part of the build context. <\/p>\n<p>The build context is a tarball of your current directory. If you don&#8217;t have a <code>.dockerignore<\/code>, you are sending garbage over the wire. You are making the <code>COPY . .<\/code> command even more bloated than it already is. A proper <code>.dockerignore<\/code> should be the first thing you write. It should exclude <code>node_modules<\/code>, <code>.git<\/code>, <code>dist<\/code>, <code>build<\/code>, <code>*.log<\/code>, <code>.env<\/code>, and anything else that isn&#8217;t strictly necessary for the build.<\/p>\n<p>And let\u2019s talk about <code>ADD<\/code> vs <code>COPY<\/code>. I see people using <code>ADD<\/code> like it\u2019s a generic &#8220;put file here&#8221; command. It\u2019s not. <code>ADD<\/code> has &#8220;magic&#8221; behavior. It can fetch files from remote URLs. It can automatically extract tarballs. This magic is dangerous. It\u2019s non-deterministic. If you <code>ADD<\/code> a tarball from a URL, you have no guarantee that the content of that URL hasn&#8217;t changed. Use <code>COPY<\/code>. It\u2019s explicit. It\u2019s predictable. Predictability is the only thing that keeps me from losing my mind when the OOM killer starts reaping processes at 3 AM.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Multi-Stage_Builds_The_Only_Way_to_Keep_Your_Sanity_and_Your_Disk_Space\"><\/span>Multi-Stage Builds: The Only Way to Keep Your Sanity and Your Disk Space<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>If you aren&#8217;t using multi-stage builds in 2024, you shouldn&#8217;t be allowed to touch a production cluster. It is the single most effective tool we have to combat <strong>docker image<\/strong> bloat, and yet I see it ignored constantly.<\/p>\n<p>A multi-stage build allows you to use a heavy, dependency-rich image for the build phase and then copy only the resulting artifacts into a tiny, minimal image for the runtime phase. Here is what the autopsy of that 3.2GB image should have looked like:<\/p>\n<pre class=\"codehilite\"><code class=\"language-dockerfile\"># Stage 1: The Build\nFROM node:20.11.1-bookworm-slim AS builder\nWORKDIR \/app\nCOPY package.json package-lock.json .\/\nRUN npm ci\nCOPY . .\nRUN npm run build\n\n# Stage 2: The Runtime\nFROM nginx:1.25.4-alpine3.19.1\nCOPY --from=builder \/app\/dist \/usr\/share\/nginx\/html\nEXPOSE 80\nCMD [&quot;nginx&quot;, &quot;-g&quot;, &quot;daemon off;&quot;]\n<\/code><\/pre>\n<p>The difference? The first stage might be 1.5GB. The second stage\u2014the one that actually gets pushed to the registry and pulled by the Kubernetes nodes\u2014is about 30MB. <\/p>\n<p>30MB vs 3.2GB. <\/p>\n<p>Think about the implications for a second. A 30MB <strong>docker image<\/strong> pulls in seconds. It doesn&#8217;t trigger disk pressure alerts. It doesn&#8217;t saturate the network interface of the node. It doesn&#8217;t fill up the local image cache and force the Kubelet to start garbage collecting images that are actually needed. <\/p>\n<p>When you use <code>COPY --from<\/code>, you are cherry-picking the only things that matter. You are leaving behind the <code>npm<\/code> cache, the source code, the compilers, and the thousands of transient dependencies that exist only to transform your code into a static bundle. You are shipping the product, not the factory.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Distroless_Scratch_and_the_Art_of_Minimalist_Suffering\"><\/span>Distroless, Scratch, and the Art of Minimalist Suffering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>For the truly disciplined, even Alpine 3.19.1 is too much. Alpine is great\u2014it\u2019s small, it uses <code>musl<\/code> instead of <code>glibc<\/code>, and it has a decent package manager (<code>apk<\/code>). But it still has a shell. It still has a package manager. It still has a filesystem hierarchy that a motivated attacker could use once they find a vulnerability in your application.<\/p>\n<p>If you are shipping a Go binary or a statically linked Rust application, your <strong>docker image<\/strong> should start with <code>FROM scratch<\/code>. <\/p>\n<p><code>scratch<\/code> is an empty image. It has zero bytes. No shell, no <code>\/bin\/ls<\/code>, no <code>\/etc\/passwd<\/code>. You just <code>COPY<\/code> your binary in and you\u2019re done. This is the ultimate form of containerization. It\u2019s the smallest possible attack surface. It\u2019s the most efficient use of resources. <\/p>\n<p>If you\u2019re running something like Java or Python 3.12.2 and you can&#8217;t go full <code>scratch<\/code>, use &#8220;Distroless&#8221; images. These are images maintained by Google that contain only your application and its runtime dependencies. They don&#8217;t have a shell. You can&#8217;t <code>exec<\/code> into them to poke around. This makes developers cry because they can&#8217;t &#8220;debug&#8221; by running <code>ls<\/code> inside the container, but you know what? We have logs for that. We have telemetry. We have distributed tracing. You don&#8217;t need a shell in production. A shell in production is just a gift for someone who wants to turn your cluster into a crypto-miner.<\/p>\n<p>When you reduce an image to its bare essentials, you aren&#8217;t just saving space. You are reducing the cognitive load of the SRE. I don&#8217;t have to worry about whether a vulnerability in <code>libssl<\/code> or <code>ncurses<\/code> is going to trigger a P0 security alert if those libraries aren&#8217;t even in the image.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The_Security_Tax_of_Laziness_Why_Your_Image_is_a_CVE_Playground\"><\/span>The Security Tax of Laziness: Why Your Image is a CVE Playground<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Every single megabyte of &#8220;cruft&#8221; you leave in your <strong>docker image<\/strong> is a potential entry point for an exploit. That 3.2GB image I had to delete? It had 412 known vulnerabilities. 85 of them were &#8220;Critical&#8221; or &#8220;High.&#8221; <\/p>\n<p>Why? Because it was based on an old version of a full Debian image that hadn&#8217;t been patched in months. It had <code>curl<\/code>, <code>wget<\/code>, <code>git<\/code>, and a dozen other tools that are perfect for a post-exploitation scenario. If an attacker found a remote code execution (RCE) bug in the React app&#8217;s server-side rendering component, they would have a full suite of tools ready and waiting for them to start lateral movement through the network.<\/p>\n<p>When you use a bloated <strong>docker image<\/strong>, you are paying a &#8220;security tax.&#8221; You are forcing the security team to sift through thousands of false positives in the container scans. You are making it impossible to distinguish between a real threat and the background noise of a poorly maintained base image.<\/p>\n<p>And let&#8217;s talk about the OOM killer. When your container is bloated, it\u2019s not just the disk that suffers. Memory management becomes a nightmare. A bloated runtime often has a larger memory footprint. In a Kubernetes environment, we set <code>requests<\/code> and <code>limits<\/code>. If your <strong>docker image<\/strong> is so large that it takes 5 minutes to pull and another 2 minutes to initialize because it\u2019s scanning a massive filesystem, the liveness and readiness probes are going to fail. The orchestrator will kill the container and try again. This is the &#8220;CrashLoopBackOff&#8221; hell that I spent my Saturday night navigating.<\/p>\n<p>The &#8220;No space left on device&#8221; error is just the tip of the iceberg. It\u2019s the final symptom of a systemic lack of care. It\u2019s what happens when we prioritize &#8220;developer velocity&#8221; over operational stability. We\u2019ve made it so easy to build and push a <strong>docker image<\/strong> that we\u2019ve forgotten that someone actually has to run the damn thing.<\/p>\n<p>I\u2019m looking at the Prometheus dashboard now. The disk usage is back to normal. The pull times are down from minutes to seconds. The new images\u2014the ones I rebuilt using multi-stage builds and Alpine\u2014are sitting at a comfortable 45MB. The nodes are happy. The OOM killer is dormant. <\/p>\n<p>But I know it won&#8217;t last. Tomorrow, some &#8220;full stack&#8221; wizard will decide they need a new library, and instead of adding it to the <code>package.json<\/code>, they\u2019ll just <code>apt-get install<\/code> it in a new layer. They\u2019ll push a 4GB image, and the cycle will start all over again. <\/p>\n<p>If you\u2019re reading this and you\u2019re a developer: look at your <code>docker history<\/code>. If you see layers that are larger than your actual application code, you have failed. If you aren&#8217;t using a <code>.dockerignore<\/code>, you are being lazy. If you are shipping a shell to production, you are being reckless. <\/p>\n<p>Disk space isn&#8217;t infinite. Bandwidth isn&#8217;t free. And my sleep is definitely not something you should be sacrificing because you couldn&#8217;t be bothered to learn how a filesystem works. Audit your <strong>docker image<\/strong> before I have to do it for you. Because next time, I might just let the cluster stay down. <\/p>\n<p>I&#8217;m going to bed. Don&#8217;t page me unless the data center is literally on fire. And even then, check the <strong>docker image<\/strong> sizes first. It\u2019s probably just another bloated layer trying to consume the world.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Related_Articles\"><\/span>Related Articles<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Explore more insights and best practices:<\/p>\n<ul>\n<li><a href=\"https:\/\/itsupportwale.com\/blog\/10-devops-best-practices-for-faster-software-delivery-4\/\">10 Devops Best Practices For Faster Software Delivery 4<\/a><\/li>\n<li><a href=\"https:\/\/itsupportwale.com\/blog\/10-react-best-practices-for-writing-cleaner-code-in-2024\/\">10 React Best Practices For Writing Cleaner Code In 2024<\/a><\/li>\n<li><a href=\"https:\/\/itsupportwale.com\/blog\/react-best-practices-build-scalable-apps-faster\/\">React Best Practices Build Scalable Apps Faster<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>[2024-05-22 03:14:22] ERROR: Failed to pull image &#8220;registry.internal\/frontend-monolith:latest&#8221; [2024-05-22 03:14:22] Kubelet: FailedToPull &#8220;failed to register layer: Error processing tar file(exit status 1): write \/usr\/local\/lib\/node_modules\/very-large-useless-package: no space left on device&#8221; [2024-05-22 03:15:01] CRITICAL: Node ip-10-0-42-11.ec2.internal is DiskPressure [2024-05-22 03:15:10] ALERT: Production environment is down. 0\/15 pods running. $ docker history registry.internal\/frontend-monolith:latest IMAGE CREATED CREATED BY SIZE &#8230; <a title=\"What is a Docker Image? A Complete Guide for Beginners\" class=\"read-more\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\" aria-label=\"Read more  on What is a Docker Image? A Complete Guide for Beginners\">Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4820","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.0 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>What is a Docker Image? A Complete Guide for Beginners - ITSupportWale<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is a Docker Image? A Complete Guide for Beginners - ITSupportWale\" \/>\n<meta property=\"og:description\" content=\"[2024-05-22 03:14:22] ERROR: Failed to pull image &#8220;registry.internal\/frontend-monolith:latest&#8221; [2024-05-22 03:14:22] Kubelet: FailedToPull &#8220;failed to register layer: Error processing tar file(exit status 1): write \/usr\/local\/lib\/node_modules\/very-large-useless-package: no space left on device&#8221; [2024-05-22 03:15:01] CRITICAL: Node ip-10-0-42-11.ec2.internal is DiskPressure [2024-05-22 03:15:10] ALERT: Production environment is down. 0\/15 pods running. $ docker history registry.internal\/frontend-monolith:latest IMAGE CREATED CREATED BY SIZE ... Read more\" \/>\n<meta property=\"og:url\" content=\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\" \/>\n<meta property=\"og:site_name\" content=\"ITSupportWale\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/Itsupportwale-298547177495978\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-21T16:50:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2021\/05\/android-chrome-512x512-1.png\" \/>\n\t<meta property=\"og:image:width\" content=\"512\" \/>\n\t<meta property=\"og:image:height\" content=\"512\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Techie\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Techie\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\"},\"author\":{\"name\":\"Techie\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/#\/schema\/person\/8c5a2b3d36396e0a8fd91ec8242fd46d\"},\"headline\":\"What is a Docker Image? A Complete Guide for Beginners\",\"datePublished\":\"2026-06-21T16:50:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\"},\"wordCount\":2299,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/#organization\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\",\"url\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\",\"name\":\"What is a Docker Image? A Complete Guide for Beginners - ITSupportWale\",\"isPartOf\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/#website\"},\"datePublished\":\"2026-06-21T16:50:33+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/itsupportwale.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What is a Docker Image? A Complete Guide for Beginners\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/#website\",\"url\":\"https:\/\/itsupportwale.com\/blog\/\",\"name\":\"ITSupportWale\",\"description\":\"Tips, Tricks, Fixed-Errors, Tutorials &amp; Guides\",\"publisher\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/itsupportwale.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/#organization\",\"name\":\"itsupportwale\",\"url\":\"https:\/\/itsupportwale.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2023\/09\/cropped-Logo-trans-without-slogan.png\",\"contentUrl\":\"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2023\/09\/cropped-Logo-trans-without-slogan.png\",\"width\":1119,\"height\":144,\"caption\":\"itsupportwale\"},\"image\":{\"@id\":\"https:\/\/itsupportwale.com\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/Itsupportwale-298547177495978\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/itsupportwale.com\/blog\/#\/schema\/person\/8c5a2b3d36396e0a8fd91ec8242fd46d\",\"name\":\"Techie\",\"sameAs\":[\"https:\/\/itsupportwale.com\",\"iswblogadmin\"],\"url\":\"https:\/\/itsupportwale.com\/blog\/author\/iswblogadmin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What is a Docker Image? A Complete Guide for Beginners - ITSupportWale","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/","og_locale":"en_US","og_type":"article","og_title":"What is a Docker Image? A Complete Guide for Beginners - ITSupportWale","og_description":"[2024-05-22 03:14:22] ERROR: Failed to pull image &#8220;registry.internal\/frontend-monolith:latest&#8221; [2024-05-22 03:14:22] Kubelet: FailedToPull &#8220;failed to register layer: Error processing tar file(exit status 1): write \/usr\/local\/lib\/node_modules\/very-large-useless-package: no space left on device&#8221; [2024-05-22 03:15:01] CRITICAL: Node ip-10-0-42-11.ec2.internal is DiskPressure [2024-05-22 03:15:10] ALERT: Production environment is down. 0\/15 pods running. $ docker history registry.internal\/frontend-monolith:latest IMAGE CREATED CREATED BY SIZE ... Read more","og_url":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/","og_site_name":"ITSupportWale","article_publisher":"https:\/\/www.facebook.com\/Itsupportwale-298547177495978","article_published_time":"2026-06-21T16:50:33+00:00","og_image":[{"width":512,"height":512,"url":"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2021\/05\/android-chrome-512x512-1.png","type":"image\/png"}],"author":"Techie","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Techie","Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#article","isPartOf":{"@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/"},"author":{"name":"Techie","@id":"https:\/\/itsupportwale.com\/blog\/#\/schema\/person\/8c5a2b3d36396e0a8fd91ec8242fd46d"},"headline":"What is a Docker Image? A Complete Guide for Beginners","datePublished":"2026-06-21T16:50:33+00:00","mainEntityOfPage":{"@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/"},"wordCount":2299,"commentCount":0,"publisher":{"@id":"https:\/\/itsupportwale.com\/blog\/#organization"},"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/","url":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/","name":"What is a Docker Image? A Complete Guide for Beginners - ITSupportWale","isPartOf":{"@id":"https:\/\/itsupportwale.com\/blog\/#website"},"datePublished":"2026-06-21T16:50:33+00:00","breadcrumb":{"@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/itsupportwale.com\/blog\/what-is-a-docker-image-a-complete-guide-for-beginners-2\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/itsupportwale.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What is a Docker Image? A Complete Guide for Beginners"}]},{"@type":"WebSite","@id":"https:\/\/itsupportwale.com\/blog\/#website","url":"https:\/\/itsupportwale.com\/blog\/","name":"ITSupportWale","description":"Tips, Tricks, Fixed-Errors, Tutorials &amp; Guides","publisher":{"@id":"https:\/\/itsupportwale.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/itsupportwale.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/itsupportwale.com\/blog\/#organization","name":"itsupportwale","url":"https:\/\/itsupportwale.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/itsupportwale.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2023\/09\/cropped-Logo-trans-without-slogan.png","contentUrl":"https:\/\/itsupportwale.com\/blog\/wp-content\/uploads\/2023\/09\/cropped-Logo-trans-without-slogan.png","width":1119,"height":144,"caption":"itsupportwale"},"image":{"@id":"https:\/\/itsupportwale.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/Itsupportwale-298547177495978"]},{"@type":"Person","@id":"https:\/\/itsupportwale.com\/blog\/#\/schema\/person\/8c5a2b3d36396e0a8fd91ec8242fd46d","name":"Techie","sameAs":["https:\/\/itsupportwale.com","iswblogadmin"],"url":"https:\/\/itsupportwale.com\/blog\/author\/iswblogadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/posts\/4820","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/comments?post=4820"}],"version-history":[{"count":0,"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/posts\/4820\/revisions"}],"wp:attachment":[{"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/media?parent=4820"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/categories?post=4820"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/itsupportwale.com\/blog\/wp-json\/wp\/v2\/tags?post=4820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}