<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker on Commentary of Takao</title><link>https://takao.blog/en/categories/docker/</link><description>Recent content in Docker on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/categories/docker/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing Reusable Docker Compose Configs for Dev and Prod</title><link>https://takao.blog/en/web/docker-compose-production-best-practice/</link><pubDate>Mon, 20 Apr 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-compose-production-best-practice/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Designing Reusable Docker Compose Configs for Dev and Prod" /&gt;&lt;h2 id="designing-reusable-docker-compose-configs-for-dev-and-prod"&gt;Designing Reusable Docker Compose Configs for Dev and Prod
&lt;/h2&gt;&lt;p&gt;Docker Compose is the standard tool for defining and running multi-container applications. But many teams fall into the trap of maintaining separate &lt;code&gt;docker-compose.yml&lt;/code&gt; files for development, staging, and production — leading to duplication, drift, and configuration bugs.&lt;/p&gt;
&lt;p&gt;A better approach uses &lt;strong&gt;compose file overlays&lt;/strong&gt;, &lt;strong&gt;profiles&lt;/strong&gt;, and &lt;strong&gt;environment variables&lt;/strong&gt; to keep a single source of truth that adapts to each environment.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-base-composeyml-pattern"&gt;The Base &lt;code&gt;compose.yml&lt;/code&gt; Pattern
&lt;/h2&gt;&lt;p&gt;Start with a single &lt;code&gt;compose.yml&lt;/code&gt; that defines the shared service definitions — the image, command, ports, and environment that remain the same across environments.&lt;/p&gt;</description></item><item><title>Maximizing Docker Build Cache for Faster Deployment Pipelines</title><link>https://takao.blog/en/web/docker-build-caches-speedup/</link><pubDate>Sat, 20 Sep 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-build-caches-speedup/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Maximizing Docker Build Cache for Faster Deployment Pipelines" /&gt;&lt;p&gt;Whether you are trying to speed up local iterative container runs or aiming to shave minutes off your CI/CD pipelines, optimizing your &lt;strong&gt;Docker image build speeds&lt;/strong&gt; is a crucial aspect of engineering productivity. Long build wait times disrupt developer focus and drive up cloud computing costs.&lt;/p&gt;
&lt;p&gt;One of the most powerful and easiest ways to optimize build speeds is by configuring Docker files to maximize the use of the &lt;strong&gt;Docker Build Cache&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Reducing Docker Image Sizes with Multi-Stage Builds</title><link>https://takao.blog/en/web/docker-multi-stage-build-reduction/</link><pubDate>Thu, 20 Mar 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-multi-stage-build-reduction/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Reducing Docker Image Sizes with Multi-Stage Builds" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Keeping Docker image footprints small is critical for accelerating deployment cycles, lowering storage costs, and tightening security by shrinking the container&amp;rsquo;s attack surface.&lt;/p&gt;
&lt;p&gt;However, a naive Dockerfile construction often bundles compile-time dependencies (like gcc, headers, build caches) and testing tools directly into the final runtime image. This inflates the image size from a few megabytes to hundreds or gigabytes.&lt;/p&gt;
&lt;p&gt;To solve this, Docker introduced &lt;strong&gt;Multi-Stage Builds&lt;/strong&gt;. This article reviews the core practices of multi-stage architectures, demonstrating image footprint optimization using a TypeScript Node.js project.&lt;/p&gt;</description></item><item><title>Docker Compose for Production: Deployment Best Practices</title><link>https://takao.blog/en/web/docker-compose-production/</link><pubDate>Tue, 12 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-compose-production/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Docker Compose for Production: Deployment Best Practices" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Docker Compose is often relegated to local development, but it is increasingly used for single-host production deployments of small-to-medium applications. The common criticism that &amp;ldquo;Compose is not for production&amp;rdquo; overlooks a key point: for many workloads, a well-configured Compose stack on a single VM provides the right balance of simplicity and reliability.&lt;/p&gt;
&lt;p&gt;This guide covers production-grade Compose practices — treating your compose files as infrastructure-as-code with proper version control, CI/CD integration, and production-specific hardening.&lt;/p&gt;</description></item><item><title>Docker Networking: From Bridge to Overlay Networks</title><link>https://takao.blog/en/web/docker-networking/</link><pubDate>Tue, 27 Aug 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-networking/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Docker Networking: From Bridge to Overlay Networks" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Docker containers are designed to be portable and isolated, but they rarely run in isolation. Containers need to communicate with each other, with the host system, and with external services. Understanding Docker&amp;rsquo;s networking model is essential for building reliable, secure, and performant containerized applications.&lt;/p&gt;
&lt;p&gt;Docker provides several built-in network drivers — bridge, host, overlay, macvlan, ipvlan, and none — each suited to different use cases. This guide covers each driver in depth, along with DNS resolution, port mapping, security isolation, and Docker Compose networking patterns.&lt;/p&gt;</description></item><item><title>Container Security Scanning: Protecting Your Supply Chain</title><link>https://takao.blog/en/web/container-security/</link><pubDate>Tue, 16 Jul 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/container-security/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Container Security Scanning: Protecting Your Supply Chain" /&gt;&lt;p&gt;Container security is no longer optional. With supply chain attacks on the rise, securing container images from build to runtime is a fundamental requirement for any organization running containerized workloads. Runtime security alone is insufficient; supply chain security must start at the image build stage.&lt;/p&gt;
&lt;h2 id="the-container-supply-chain-threat-landscape"&gt;The Container Supply Chain Threat Landscape
&lt;/h2&gt;&lt;p&gt;Attack vectors in the container supply chain include compromised base images, vulnerable dependencies, leaked secrets, and malicious packages. Real-world incidents such as the Codecov breach exposing credentials, dependency confusion attacks, and cryptominers found in public images highlight the severity of these threats. The shared responsibility model means that while platforms like Docker provide base infrastructure, the security of your built images is your responsibility.&lt;/p&gt;</description></item><item><title>Docker Health Checks and Container Monitoring Best Practices</title><link>https://takao.blog/en/web/docker-health-checks/</link><pubDate>Mon, 25 Dec 2023 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-health-checks/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Docker Health Checks and Container Monitoring Best Practices" /&gt;&lt;p&gt;Docker health checks are essential for building self-healing container infrastructure. They enable automatic detection of application failures and trigger container restarts, ensuring your services remain available. This guide covers everything from basic &lt;code&gt;HEALTHCHECK&lt;/code&gt; implementation to advanced production patterns.&lt;/p&gt;
&lt;h2 id="the-healthcheck-instruction"&gt;The HEALTHCHECK Instruction
&lt;/h2&gt;&lt;p&gt;The &lt;code&gt;HEALTHCHECK&lt;/code&gt; instruction in a Dockerfile tells Docker how to test whether a container is still working correctly:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-dockerfile" data-lang="dockerfile"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;HEALTHCHECK&lt;/span&gt; --interval&lt;span style="color:#f92672"&gt;=&lt;/span&gt;30s --timeout&lt;span style="color:#f92672"&gt;=&lt;/span&gt;3s --start-period&lt;span style="color:#f92672"&gt;=&lt;/span&gt;40s --retries&lt;span style="color:#f92672"&gt;=&lt;/span&gt;&lt;span style="color:#ae81ff"&gt;3&lt;/span&gt; &lt;span style="color:#ae81ff"&gt;\
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; CMD curl -f http://localhost:3000/health &lt;span style="color:#f92672"&gt;||&lt;/span&gt; exit &lt;span style="color:#ae81ff"&gt;1&lt;/span&gt;&lt;span style="color:#960050;background-color:#1e0010"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Docker tracks three states: &lt;code&gt;starting&lt;/code&gt; (during the start period), &lt;code&gt;healthy&lt;/code&gt; (checks pass), and &lt;code&gt;unhealthy&lt;/code&gt; (checks fail after retries). The &lt;code&gt;--start-period&lt;/code&gt; is critical for applications with slow startup times &amp;ndash; it suppresses failures during initialization.&lt;/p&gt;</description></item></channel></rss>