标签：#Containers

A container's writable layer feels like a filesystem, and that's exactly the trap. Write a database into it, remove the container, and the data is gone — no warning, no recovery. If you want anything to survive docker rm , it has to live outside the container, and Docker gives you three ways to do that: named volumes, bind mounts, and tmpfs. Knowing which one to reach for is most of the battle. Why the writable layer betrays you Every running container gets a thin read-write layer stacked on top of its image layers. It looks persistent because you can docker exec in and see your files. But that layer is bound to the container's lifecycle. docker run --name scratch alpine sh -c 'echo hello > /data.txt; cat /data.txt' # hello docker rm scratch # the layer — and /data.txt — no longer exists There's no "oops." The writable layer is discarded with the container. Persistence is not a default you get; it's a decision you make. That decision is a volume, a bind mount, or tmpfs. Named volumes: the default for state A named volume is storage that Docker creates and manages for you. You give it a name, Docker keeps the actual bytes under its own directory, and you never have to care where that is. docker volume create pgdata docker run -d --name db \ --mount type = volume,source = pgdata,target = /var/lib/postgresql/data \ postgres:16 The container writes to /var/lib/postgresql/data , but those bytes land in a Docker-managed location on the host. Remove and recreate the container against the same volume and the data is still there. docker rm -f db docker run -d --name db \ --mount type = volume,source = pgdata,target = /var/lib/postgresql/data \ postgres:16 # same data, new container Where do the bytes actually live? Under Docker's data root, typically /var/lib/docker/volumes/<name>/_data : docker volume inspect pgdata --format '{{ .Mountpoint }}' # /var/lib/docker/volumes/pgdata/_data The point is that you're not supposed to reach into that path directly — Docker owns it. You

"Works on my machine" is one of the oldest jokes in software, and it stopped being funny the first time it cost me a weekend. The code was fine. The environment wasn't. A library version on the build box didn't match production, and nobody could see it because "the environment" was a fuzzy, undocumented thing that lived partly in a config management tool, partly in someone's .bashrc , and partly in tribal memory. Containerization is the boring, durable fix for that whole class of problem. Not because containers are magic, but because they force you to turn a fuzzy environment into a single, inspectable, reproducible artifact. That shift — from "a machine we hope is configured right" to "an image we can point at" — is the actual win. Let me walk through what that means operationally, with a minimal example. What containerization actually solves Strip away the tooling and a container image is one thing: your application plus everything it needs to run, packaged together and frozen. The OS libraries, the runtime, the dependencies, your code — all captured at build time into one immutable blob with a content-addressable identity. That has three consequences that matter when you're the one on call: The environment stops being a variable. If it runs from image myapp:1.4.2 in staging, the same image runs in production. You're no longer debugging the difference between two machines. The artifact is immutable. You don't patch a running container in place and hope. You build a new image, tag it, and roll it out. The old one still exists, unchanged, if you need to go back. Rollback becomes trivial. "Roll back" means "run the previous image tag." That's it. No reinstalling packages, no un-applying config drift. After enough years in operations, you learn that most 3 a.m. incidents aren't exotic. They're some version of "this box isn't like the other boxes." Containers don't make you smarter, but they take that entire category off the table. Images vs. containers, briefly These

AWS launched Lambda MicroVMs, a new serverless compute primitive that runs each user session or AI agent in its own Firecracker virtual machine with hardware-level isolation, snapshot-based rapid launch, and state preservation for up to eight hours. Reddit community analysis found the minimum setup costs $3.03/day, roughly 9x Fargate spot pricing. By Steef-Jan Wiggers

AWS made Graviton5-powered EC2 M9g and M9gd instances generally available with 192 ARM cores, formally verified VM isolation via the Nitro Isolation Engine, and DDR5-8800 memory. ClickHouse reported 36% better performance with zero code changes. Meta committed tens of millions of cores. On-demand pricing is 9% above Graviton4, translating to roughly 15% better price-performance. By Steef-Jan Wiggers

The scary part of an agent-driven container escape is not the container escape. That sounds wrong, so let me be precise. The primitives in Sysdig's latest threat research are not new magic. A mounted Docker socket has been a bad idea for years. Over-permissioned Kubernetes service accounts have been a bad idea for years. Privileged containers are dangerous. Host namespace tricks are dangerous. Secrets reachable from application pods are dangerous. None of this should surprise anyone who has had to review production Kubernetes setups with a straight face. The new part is the operator. Sysdig observed what it describes as an LLM-harness-driven attacker exploiting a vulnerable marimo notebook, enumerating the container and host environment, using the Docker socket as an escape path, creating privileged containers, reading host credentials, and replaying a Kubernetes service-account token to dump Secrets. That is the part worth sitting with. Not because the agent invented a new class of exploit. Because it made the old mistakes compose faster. the attack surface was already there Most security incidents are not movie plots. They are boring edges left open long enough for someone to connect them. In this case, the edges are familiar. An internet-reachable application had a vulnerability. The workload had access to a Docker socket. The container environment exposed enough information to enumerate possible escape paths. A Kubernetes service-account token was available. The token had enough RBAC to read Secrets. Secrets contained useful downstream credentials. That is not one bug. That is a chain of assumptions. The application team may have thought about the notebook vulnerability. The platform team may have thought about the Docker socket as a convenience for one workflow. The Kubernetes team may have thought the service account was scoped "only" to a namespace. The security team may have had runtime alerts somewhere in the backlog. Each decision can look locally tolerabl

The etcd Endpoint Trap A cluster migration just took your whole control plane offline. In the next few minutes you'll find out why, and fix it the way the CKA exam expects. This is a CKA Troubleshooting walkthrough. Every command below is real output from a live cluster, and you can reproduce the whole thing yourself (scripts at the end). The scenario A single-node kubeadm cluster was migrated to a new machine. The control plane won't come up. Your task: identify the broken component, find the root cause, fix the config, restart, and verify. Single-node kubeadm cluster, freshly migrated Control plane will not start Find the broken component Root-cause it, fix it, verify How the control plane actually starts The kubelet runs the control plane as static pods from /etc/kubernetes/manifests . The kube-apiserver cannot start unless it can reach etcd. Give it the wrong etcd address and the apiserver crashes, so the whole cluster looks dead. The kube-apiserver runs as a static pod : the kubelet reads its manifest from /etc/kubernetes/manifests/ and keeps it running. The apiserver cannot start unless it can reach etcd, so a wrong --etcd-servers endpoint takes the whole API down, and with it, everything you'd normally use to debug. Step 1 — Reproduce the symptom First, reproduce the symptom. kubectl get nodes is refused. A refused connection on the API port means the API server is down: a control-plane problem, not a workload problem. $ kubectl get nodes The connection to the server cka-scenario1-control-plane:6443 was refused - did you specify the right host or port? A refused connection on the API port is a control-plane problem, not a workload problem. Step 2 — Investigate from the node kubectl can't help us now, so drop to the node. The kubelet itself is active. But follow its log and you'll see it stuck in a loop, restarting the apiserver over and over. The kubelet is fine; the static pod it manages is the problem. $ systemctl is-active kubelet active $ journalctl -u ku

Cybersecurity firm Chainguard has announced the launch of Athena, an industry coalition to use artificial intelligence to find and fix vulnerabilities in widely-used open-source software before attackers can exploit them. The coalition focuses on libraries, containers and other components that underpin web browsers, data centres, smartphones and payment systems. By Matt Saunders

When a platform started with total developer autonomy, teams felt overwhelmed and ended up solving the same problems in completely different ways. The company shifted to enablement over support, working together with teams intensively, and helping teams feel confident and capable, turning the right way into being the easiest way. By Ben Linders

Introduction One of the common tasks performed by DevOps Engineers is upgrade of their organization's Kubernetes Cluster at least once every 3 months as Kubernetes release newer version while maintaining on the last 3 released versions. For instance, if the newest version is v1.34, the supported versions would be v1.34, v1.33 & v1.32. Hence, the need to understand how this upgrade process can be achieved with zero downtime. Prerequisites: Cordon your Nodes: This simply means making your nodes unschedulable. No new deployments would be scheduled on the node. Review and understand the change logs in the release notes - Ensure that the change logs or updated components won't affect your production environment. Kubernetes upgrade are irreversible - You can't downgrade your cluster after an upgrade. A fresh installation would be required in the event of an issue with the upgraded version. Hence Lower Level Environment Test (Unit, Staging or Pre-Production) - Given that Kubernetes upgrades are irreversible, always test the newer version and allow monitoring for about 2-weeks before production cluster upgrade. Control Plane & Nodes should be on the same versions. Cluster Auto-Scaler: If you are using this feature within your Kubernetes environment, ensure that it is on the same or compatible version with your control plane to avoid issues during the cluster upgrade. IP Addresses: Make available at least 5 IP addresses within the cluster subnet. Kubelet: This component should also match the version of your control plane before the upgrade. What are the actual upgrade processes Control Plane Upgrade: If using the Managed Kubernetes Cluster (EKS, AKS, GKS), the Cloud Company will take care of managing the control plane. However, upgrade of the cluster doesn't happen automatically. Hence, you will be required to action this via the CLI, UI or EKSCLI etc. Node Group or Data Plane Upgrade: Managed Node Groups - This is easier because you can use the rollout deployment approach,

1. Introduction to Docker One of the biggest historical challenges in software engineering has been environment inconsistency , the frustrating situation where an application works perfectly on one machine but unexpectedly fails elsewhere. And this is precisely the problem Docker was designed to solve. Docker is a containerization platform that packages applications and their dependencies into isolated environments called containers . Its goal is simple: Run applications consistently everywhere. Instead of configuring every machine manually, Docker packages everything an application needs to run. 1.1 What is Docker? Docker is a platform used to build, package, and run applications inside containers. A container includes: Application code Dependencies Runtime Libraries Configuration Simple mental model: Code + Dependencies + Runtime = Container This ensures applications behave the same way across development, testing, and production environments. 1.2 VMs vs Containers VMs (Virtual Machines) package: Application Dependencies Full Operating System Containers package only: Application Dependencies Runtime Containers share the host operating system kernel, making them much lighter and faster. Feature Virtual Machine Docker Container Includes OS Yes No Startup Speed Slow Fast Resource Usage Heavy Lightweight Size Large Small Simple analogy: Virtual Machine = Full House Container = Apartment in a Building 1.3 Docker Ecosystem Overview Docker includes multiple tools: Docker Engine The core service that runs containers. Docker Desktop A local GUI and development environment. Docker Hub A cloud registry for storing and sharing Docker images. Docker Compose A tool for running multiple containers together. Example: docker compose up Can start an entire application stack: Backend API Database Redis Frontend with a single command. 2. Docker Architecture & Fundamentals To use Docker effectively, it is important to understand how its core components work together. Docker follows a

Just released an open-source bash checker for CIFSwitch (CVE-2026-46243) — the 19-year-old Linux kernel LPE disclosed last week that lets any unprivileged local user get root by abusing the CIFS/SPNEGO upcall path. The script runs on bare-metal, VMs, and inside containers, and is CI/CD-friendly with JSON output and clean exit codes. It checks: ✅ Kernel version against patched thresholds (6.18.22 / 6.19.12 / 7.0+) ✅ cifs-utils presence and exploitable version ✅ CIFS kernel module load state and blacklist status ✅ Unprivileged user namespace sysctl (the pivot point for the exploit) ✅ Active request-key cifs.spnego rules ✅ SELinux / AppArmor enforcement ✅ Container capabilities (CAP_SYS_ADMIN) ✅ Kernel symbol verification for the fix commit Outputs human-readable or JSON for SIEM ingestion. Exit 0 = safe, exit 1 = action needed — drop it straight into a pipeline. CIFSwitch is the fourth Linux LPE in under six weeks (after Copy Fail, Dirty Frag, and Fragnesia). If you're running multi-tenant Linux, CI runners, or container build farms, now is a good time to audit. I have also updated the cve_checks.conf in my my K8s-container_escape_audit toolkit to detect this issue.

Microsoft announced Azure Linux 4.0 and Azure Container Linux at Open Source Summit. Azure Linux 4.0 is a Fedora-based general-purpose server distribution for Azure VMs, the first time Microsoft has offered a supported Linux beyond container hosting. Azure Container Linux is an immutable container-optimized host built on Flatcar. By Steef-Jan Wiggers

I've been running AI workloads on Azure Container Apps for over a year. Every time I spin up a new agent backend, the ritual is the same: create an environment, configure networking, set scaling rules, wire up health probes, then deploy the actual container. For a prototype agent that might live for a week, that's too much ceremony for what you get. ACA Express, which hit public preview in May 2026, kills most of that ceremony. And a separate but related announcement, Docker Compose for Agents, brings MCP gateways and model serving to standard ACA environments. They solve different problems and run on different infrastructure, but together they cover the full spectrum of agent deployment on Azure. Let me break down both. ACA Express: What It Actually Is Express is a new environment tier within Azure Container Apps. You bring a container image. Express handles provisioning, HTTPS, scaling (including scale-from-zero with subsecond cold starts), and resource allocation. No environment to manually provision through the portal. No networking to configure. No scaling rules to write. Under the hood, Express is built on ACA Sandboxes, a platform primitive that uses prewarmed pools to deliver that subsecond startup. This isn't the standard ACA cold-start experience with a fresh coat of paint. It's a different architecture. The tradeoffs are real. Express is HTTP workloads only, consumption CPU only. No GPU. No VNet integration. No Dapr. No service discovery between apps. No managed identity at runtime. No health probes. If you need any of those, standard ACA environments are still there. But for stateless HTTP agent backends, Express is dramatically faster to deploy and cheaper to run. Here's what it takes to get a container running: # Create an express environment az containerapp env create \ --name my-express-env \ --resource-group rg-my-agents \ --environment-mode express \ --logs-destination none # Deploy your app az containerapp create \ --name my-agent-api \ --resource