<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Devops on Commentary of Takao</title><link>https://takao.blog/en/tags/devops/</link><description>Recent content in Devops 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/tags/devops/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>Accelerating GitHub Actions Workflows via actions/cache</title><link>https://takao.blog/en/web/github-actions-caching-setup/</link><pubDate>Thu, 20 Nov 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/github-actions-caching-setup/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Accelerating GitHub Actions Workflows via actions/cache" /&gt;&lt;p&gt;Automated CI/CD pipelines (like GitHub Actions) are a cornerstone of modern software quality control. However, if your workflows fetch external packages, boot container environments, and rebuild entire applications from scratch on every pull request, execution times can quickly balloon to several minutes.&lt;/p&gt;
&lt;p&gt;Long feedback loops slow developer productivity and lead to higher billing costs.&lt;/p&gt;
&lt;p&gt;In this article, we&amp;rsquo;ll demonstrate how to utilize GitHub&amp;rsquo;s official caching mechanisms to speed up your workflows from minutes to seconds.&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 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>GitHub Actions Advanced: Workflows Beyond CI/CD Basics</title><link>https://takao.blog/en/web/github-actions-advanced/</link><pubDate>Tue, 16 Apr 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/github-actions-advanced/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post GitHub Actions Advanced: Workflows Beyond CI/CD Basics" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;GitHub Actions has evolved from a simple CI/CD tool into a comprehensive automation platform. While basic workflows are well-documented, the platform&amp;rsquo;s advanced features—reusable workflows, composite actions, matrix strategies, and deployment patterns—enable sophisticated automation pipelines. This article explores these advanced capabilities for teams building complex CI/CD systems.&lt;/p&gt;
&lt;h2 id="reusable-workflows"&gt;Reusable Workflows
&lt;/h2&gt;&lt;p&gt;Reusable workflows allow you to define a workflow in one repository and call it from others, following the DRY principle. They are triggered with &lt;code&gt;workflow_call&lt;/code&gt; and accept inputs and secrets.&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>