<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Containers on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/containers/</link><description>Recent content in Containers on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 23 Jun 2023 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/containers/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker and Containers (8): Beyond Docker — Kubernetes, Swarm, and What Comes Next</title><link>https://www.chenk.top/en/docker-containers/08-orchestration-preview/</link><pubDate>Fri, 23 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/08-orchestration-preview/</guid><description>&lt;p>So far, this series has focused on single-host Docker: one machine running containers. This setup works well for development, small projects, and applications with modest traffic. However, when you need your service to survive server failures, handle traffic spikes, or deploy updates without downtime, single-host Docker falls short. Container orchestration addresses these issues, and Kubernetes has become the go-to solution.&lt;/p>
&lt;hr>
&lt;h2 id="why-single-host-docker-isnt-enough" class="heading-anchor">Why Single-Host Docker Isn&amp;rsquo;t Enough&lt;a href="#why-single-host-docker-isnt-enough" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Consider what happens when your Docker host fails:&lt;/p></description></item><item><title>Docker and Containers (7): Security — Running Containers Without Giving Away the Keys</title><link>https://www.chenk.top/en/docker-containers/07-security-and-best-practices/</link><pubDate>Thu, 22 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/07-security-and-best-practices/</guid><description>&lt;p>Docker&amp;rsquo;s default configuration prioritizes convenience over security. Containers run as root, have access to a broad set of Linux capabilities, and can write to their entire filesystem. This is fine for development but dangerous for production. A container escape vulnerability in a root-privileged container means an attacker can take over the host. Let&amp;rsquo;s fix that.&lt;/p>
&lt;hr>
&lt;h2 id="the-threat-model" class="heading-anchor">The Threat Model&lt;a href="#the-threat-model" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Before securing your setup, understand what you&amp;rsquo;re defending against:&lt;/p></description></item><item><title>Docker and Containers (6): Debugging and Logging — When Things Go Wrong Inside a Box</title><link>https://www.chenk.top/en/docker-containers/06-debugging-and-logging/</link><pubDate>Wed, 21 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/06-debugging-and-logging/</guid><description>&lt;p>A container that works is invisible. A container that doesn&amp;rsquo;t work is a black box. The entire point of containerization is isolation — but that same isolation makes debugging harder. You can&amp;rsquo;t just &lt;code>ssh&lt;/code> into a container or browse its filesystem from the host. Docker provides a specific set of tools for inspecting, diagnosing, and understanding what happens inside running (and crashed) containers.&lt;/p>
&lt;hr>
&lt;h2 id="reading-container-logs" class="heading-anchor">Reading Container Logs&lt;a href="#reading-container-logs" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Logs are your first line of investigation. Docker captures everything a container writes to stdout and stderr.&lt;/p></description></item><item><title>Docker and Containers (5): Docker Compose — Multi-Container Applications</title><link>https://www.chenk.top/en/docker-containers/05-docker-compose/</link><pubDate>Tue, 20 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/05-docker-compose/</guid><description>&lt;p>The previous articles taught you how to run containers with &lt;code>docker run&lt;/code>, pass port mappings with &lt;code>-p&lt;/code>, create networks with &lt;code>docker network create&lt;/code>, and mount volumes with &lt;code>-v&lt;/code>. Now imagine doing that for a web server, an API backend, a database, a cache, and a task queue — every time you start your development environment. Docker Compose replaces those 20+ commands with a single file and a single command: &lt;code>docker compose up&lt;/code>.&lt;/p></description></item><item><title>Docker and Containers (4): Networking and Volumes — How Containers Talk and Persist</title><link>https://www.chenk.top/en/docker-containers/04-networking-and-volumes/</link><pubDate>Mon, 19 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/04-networking-and-volumes/</guid><description>&lt;p>Containers are deliberately isolated. That&amp;rsquo;s the point. But useful applications need to accept connections from the outside world, talk to databases, and store data that survives container restarts. Docker provides two mechanisms for this: networks (for communication) and volumes (for persistent storage). Getting these right makes the difference between a demo and a deployment.&lt;/p>
&lt;hr>
&lt;h2 id="docker-networking" class="heading-anchor">Docker Networking&lt;a href="#docker-networking" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>When Docker starts, it creates a virtual network infrastructure on the host. Each container gets its own network namespace (with its own IP address, routing table, and network interfaces), and Docker manages the traffic flow between containers and the outside world.&lt;/p></description></item><item><title>Docker and Containers (3): Dockerfile Patterns — From Naive to Production</title><link>https://www.chenk.top/en/docker-containers/03-dockerfile-patterns/</link><pubDate>Sun, 18 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/03-dockerfile-patterns/</guid><description>&lt;p>Most tutorials show you a 5-line Dockerfile and move on. When you deploy to production, you might find your image is 1.2 GB, builds take 8 minutes even for a one-line code change, and your security team flags vulnerabilities in packages you didn&amp;rsquo;t know were installed. Writing a good Dockerfile is a skill that pays off every time your CI pipeline runs.&lt;/p>
&lt;hr>
&lt;h2 id="every-dockerfile-instruction" class="heading-anchor">Every Dockerfile Instruction&lt;a href="#every-dockerfile-instruction" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Let&amp;rsquo;s go through every instruction you&amp;rsquo;ll use, with concrete examples.&lt;/p></description></item><item><title>Docker and Containers (2): Images and Layers — What docker pull Actually Downloads</title><link>https://www.chenk.top/en/docker-containers/02-images-and-layers/</link><pubDate>Sat, 17 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/02-images-and-layers/</guid><description>&lt;p>The first time I ran &lt;code>docker pull ubuntu&lt;/code> I expected to download an entire operating system. Instead, it finished in seconds and was only 77 MB. That seemed impossibly small for a Linux distribution. The secret is layers — and understanding how they work changes the way you think about building and shipping containers.&lt;/p>
&lt;hr>
&lt;h2 id="image-vs-container" class="heading-anchor">Image vs Container&lt;a href="#image-vs-container" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Before diving into layers, let&amp;rsquo;s clarify a fundamental distinction that trips up many beginners.&lt;/p></description></item><item><title>Docker and Containers (1): Why Containers — The Problem VMs Didn't Solve</title><link>https://www.chenk.top/en/docker-containers/01-why-containers/</link><pubDate>Fri, 16 Jun 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/docker-containers/01-why-containers/</guid><description>&lt;p>Every developer has heard the phrase &amp;ldquo;it works on my machine.&amp;rdquo; Virtual machines were supposed to fix that, and they did — at the cost of gigabytes of RAM, minutes of boot time, and an entire duplicate operating system per application. Containers asked a different question: what if we could isolate applications without duplicating the kernel?&lt;/p>
&lt;hr>
&lt;h2 id="the-actual-problem" class="heading-anchor">The Actual Problem&lt;a href="#the-actual-problem" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Consider deploying a Python web application. You need Python 3.11, specific pip packages, a particular version of libssl, and some system-level configuration. Your colleague&amp;rsquo;s app needs Python 3.9 and a conflicting libssl version. The staging server runs Ubuntu 20.04 while production runs Amazon Linux 2.&lt;/p></description></item></channel></rss>