标签：#docker

A few weeks ago I published corridor-lab — a Docker lab that proved a triage mismatch: a service that stores nothing sensitive can become high-priority because of where it sits in the path to a sensitive downstream system. The lab proved the premise. The next question was whether a tool could identify those nodes automatically — without manual path declaration, without value labels, from graph position alone. So I built corridor-id. You point it at a Docker Compose file. It discovers the topology, computes depth from exposed surfaces, and identifies which nodes expand forward reach into deeper parts of the environment. No asset-value labels. No sensitivity ratings. No human classification. Reach and graph position only. Then I pointed it at four architecturally different Docker environments. Two had corridor nodes. Two had none. Both answers were useful. But the zero-corridor results taught me more than the positive ones. What corridor-id does The tool reads a Docker Compose file and builds a reachability graph from service definitions, network memberships, and port mappings. It then orients that graph from exposed surfaces using BFS and identifies nodes that provide forward reach — access to strictly deeper nodes that the exposed surface cannot reach directly. The output is a ranked list with two metrics: exposure distance (how close to the surface) and forward reach gain (how many deeper nodes become reachable through this node). One command: python corridor-id.py docker-compose.yml No manual path declaration. No value labels. No configuration. From graph position alone. The four tests corridor-lab — segmented, depth 3 My own lab, five services across five segmented networks. The tool independently identified status-api as a corridor node — the same finding the lab was built to prove. Corridor nodes found: 3 → status-api Exposure distance: 1 Forward reach gain: 1 → log-monitor Exposure distance: 1 Forward reach gain: 1 → internal-admin-api Exposure distance: 2 For

The Quest Begins (The "Why") Picture this: I’m hunched over my laptop at 2 a.m., surrounded by empty coffee mugs, trying to get a simple Node.js API to run on a friend’s Windows machine. I’ve got the code, I’ve got the dependencies, but every time I hit npm start on his box I’m greeted with “Cannot find module ‘left-pad’” (yeah, I know, that’s a meme, but it felt real). It was like trying to cast a spell in Harry Potter while forgetting the wand‑movement — nothing happened, and I felt like a Muggle in a wizard’s duel. That night I realized the real dragon wasn’t the buggy code; it was the “it works on my machine” curse. I needed a way to package everything — the runtime, the libraries, the environment variables — into a single, portable chest that any teammate (or future‑me) could open and instantly get the same result. Enter Docker, the holy grail of reproducibility. If The Matrix taught us anything, it’s that once you see the underlying code, you can bend reality. Docker lets you see the container code and then bend your deployment reality to your will. The Revelation (The Insight) The big “aha!” came when I stopped thinking of Docker as just another VM and started seeing it as a lightweight, immutable snapshot of my app’s filesystem. Unlike a full VM that boots an entire OS, a Docker container shares the host kernel but isolates everything else — think of it as the Inception dream‑within‑a‑dream, but each layer is a read‑only snapshot you can stack like LEGO bricks. Here’s the secret sauce in three lines: Dockerfile – a recipe that tells Docker how to build the image. Image – the built, immutable artifact (the “DVD” of your app). Container – a running instance of that image (the “movie playing” from the DVD). When you docker build , Docker reads the Dockerfile line‑by‑line, creates intermediate layers, caches them, and finally spits out an image you can tag, push to a registry, and run anywhere. No more “it works on my machine” because the machine inside the cont

If you've ever heard the phrase "it works on my machine", you already understand the exact problem Docker was built to solve. Before Docker existed, deploying software was painful. Developers would spend hours — sometimes days — configuring servers, managing dependencies, and debugging environment-specific issues. Docker changed all of that by packaging applications and their dependencies into lightweight, portable units called containers. What Exactly Is a Container? Think of a container like a shipping container in the real world. No matter what's inside — electronics, furniture, food — it fits on any ship, truck, or train. In software, a Docker container holds your application code, runtime, libraries, and configuration, all bundled together so it runs identically anywhere: your laptop, a staging server, or a cloud provider. This is fundamentally different from virtual machines (VMs). While VMs emulate an entire operating system — making them heavy and slow to start — containers share the host OS kernel and start in milliseconds. They use far less memory and disk space, making them ideal for modern microservices architectures. The Core Docker Concepts You Need to Know Image : A read-only template used to create containers. Think of it as a recipe. You define it in a Dockerfile, and Docker builds it into an image. Container : A running instance of an image. You can run multiple containers from the same image simultaneously. Dockerfile : A plain text file with instructions for building a Docker image. Every command in the file adds a new layer to the image. Docker Hub : A cloud registry where you can find and share Docker images. It's like GitHub, but for container images. Docker Compose : A tool for defining and running multi-container applications using a YAML file. Your First Docker Commands Getting started with Docker is simpler than most developers expect. After installing Docker Desktop on your machine, you can run your first container with a single command:

Nếu bạn vừa nhận một chiếc laptop từ danh sách ReviewLaptop để vừa học kiến trúc vừa làm dev, việc tối ưu hóa máy là cực kỳ quan trọng. Các phần mềm như Revit hay AutoCAD vốn đã ngốn tài nguyên rất lớn, vì vậy bạn cần một môi trường lập trình 'nhẹ' và ổn định. Tối ưu hóa WSL2 và Docker cho máy Workstation Với các dòng máy như Dell Precision hay Lenovo LOQ, việc chạy WSL2 với cấu hình mặc định có thể chiếm dụng quá nhiều RAM, làm ảnh hưởng đến các ứng dụng kiến trúc đang mở. Bạn nên giới hạn tài nguyên cho WSL2 bằng file .wslconfig . Truy cập vào đường dẫn %USERPROFILE%_\.wslconfig (hoặc tạo mới) và cấu hình như sau: [wsl2] # Giới hạn RAM để dành cho Revit/AutoCAD memory = 8GB # Giới hạn số lượng nhân CPU processors = 4 # Tự động giải phóng bộ nhớ khi không sử dụng autoMemoryReclaim = true # Thiết lập swap nếu cần swap = 4GB Nếu bạn có GPU rời (như trên dòng Lenovo LOQ hay Alienware), hãy đảm bảo đã cài đặt NVIDIA Container Toolkit để thực hiện Docker GPU passthrough . Điều này giúp bạn chạy các container xử lý AI hoặc render mà không làm treo hệ điều hành chính. Quản lý nhiệt độ và giới hạn phần cứng Một giới hạn thực tế quan trọng khi dùng laptop workstation là VRAM ceiling . Các dòng máy tầm trung thường có VRAM hạn chế, nếu bạn chạy Docker image nặng hoặc render cùng lúc, máy sẽ bị giật lag do tràn bộ nhớ đồ họa. Lời khuyên về Thermal Mode: Khi Code/Làm việc nhẹ: Hãy để ở chế độ Balanced hoặc Quiet . Việc này giúp giảm tiếng ồn của quạt (fan noise) và kéo dài tuổi thọ linh kiện. Khi Build Project/Render: Chuyển sang chế độ Performance hoặc Turbo . Lúc này, ưu tiên là đẩy hết nhiệt lượng ra ngoài để duy trì xung nhịp CPU cao nhất có thể. Việc cân bằng giữa sức mạnh phần cứng cho đồ án kiến trúc và sự ổn định cho môi trường dev sẽ giúp bạn làm việc hiệu quả hơn rất nhiều.

Docker is a game-changer for developers—making it easier to package, ship, and run applications. But with great power comes great responsibility. Whether you're running containers in development or production, security should never be an afterthought . In this post, I'll walk you through beginner-friendly Docker security practices that will help you build safer containers from the start. No enterprise jargon—just practical, actionable tips. Why Care About Docker Security? Containers may feel isolated, but they share the host OS kernel. This means: A compromised container could lead to host compromise. Vulnerabilities in container images can be exploited. Misconfigured containers can unintentionally expose sensitive data or ports. Docker Security Best Practices for Beginners This post is a follow-up to my previous article, Docker Like a Pro: Essential Commands and Tips , where we explored fundamental Docker commands and tips. Building upon that foundation, this guide focuses on essential security practices to help you build safer containers from the start. Docker has revolutionized the way developers build, ship, and run applications. However, with great power comes great responsibility. Whether you're running containers in development or production, security should never be an afterthought. In this post, I'll walk you through beginner-friendly Docker security practices that will help you build safer containers from the start. No enterprise jargon—just practical, actionable tips. Why Care About Docker Security? Containers may feel isolated, but they share the host OS kernel. This means: A compromised container could lead to host compromise. Vulnerabilities in container images can be exploited. Misconfigured containers can unintentionally expose sensitive data or ports. 1. Use Official Images When Possible Start by pulling images from Docker Hub’s verified publishers or official repositories. Use this: docker pull node:18 Not this (could be outdated or malicious): doc

Last week I couldn't shake an idea: what if I had an AI that knew everything I know ? Not ChatGPT — something on my hardware, holding my knowledge, answering to no one's API bill. Yesterday I built it. Here's the honest breakdown. What it does NEXUS runs on a regular Windows laptop — aging i7, 16GB RAM, no GPU. It: Remembers everything. Drop any file in a folder; 60 seconds later it's searchable memory. Answers from MY knowledge. "Which of my projects were formally closed and why?" — it answers from my actual records. Watches the live web. Every 2 hours it pulls Hacker News and news feeds, learns what's trending, pings my Telegram. Reports to my phone. 7 AM daily briefing: what it learned, what's running, what needs me. The stack — all free, all open source Ollama runs the models (Llama 3.2, Mistral 7B). Open WebUI is my private ChatGPT. Qdrant stores memory. n8n automates. SearXNG searches privately. PostgreSQL, Redis, and MinIO handle data. Commercial equivalent: $300–500/month . My cost: electricity. The memory trick nobody explains simply Parse — extract text from any file Chunk — split into ~300-word pieces Embed — each chunk becomes 768 numbers representing its meaning Store — a database that searches by similarity Your question becomes 768 numbers too, and the database finds memories with similar meaning — not matching keywords. I asked "how do I get clients cheaper" and it found my notes on "reducing customer acquisition cost." Different words. Same meaning. That's the magic. What surprised me A 2GB model is genuinely useful. Llama 3.2 3B answers from my knowledge in seconds, on CPU. The automation matters more than the AI. The watched folder + Telegram bot turned a cool demo into a system I actually use. Windows is fine. Docker Desktop + WSL2 ran all nine services without drama. The bill, honestly Hardware: $0 (laptop I own) Software: $0 (open source) APIs: $0 (all local) Time: one focused day The only future cost is a cloud GPU server (~$65/mo) when I outg

I have been building Lunarr , a self-hosted web media server for people who want to scan, organize, and watch their own movie and TV libraries in the browser. It is still early, but the core idea is simple: Add local or SFTP media libraries, scan them, match metadata, and play them through a clean web UI. Lunarr is not trying to replace Plex or Jellyfin overnight. Those projects are mature and cover a huge surface area. Lunarr is currently focused on being small, direct, and practical for self-hosted setups where media may live on the same machine or on remote SFTP storage. What Lunarr does today Lunarr currently supports: Local movie and TV libraries SFTP movie and TV libraries TMDb metadata matching Movie, show, season, and episode organization Browser playback Direct streaming when the browser can play the file Temporary HLS remux/transcode when needed Seekable request-driven HLS playback Sidecar .vtt subtitle detection Admin/user accounts Library sharing controls Manual scans, scheduled scans, and local file watching Docker deployment The SFTP support is one of the important parts for me. A lot of self-hosted setups do not keep media on the same machine as the web app. Lunarr can scan remote folders and, when possible, play seekable remote media without first copying the whole file locally. Playback model Lunarr tries direct playback first when the browser can handle the file. When direct playback is not suitable, Lunarr uses temporary HLS playback. Instead of transcoding an entire movie up front, it generates segments around what the player is actually requesting. For example, if you jump from 55 minutes to 13 minutes and then to 80 minutes, Lunarr does not transcode everything between those points. It repositions FFmpeg, generates the requested segment, and prepares a small lookahead window so playback can continue. That keeps CPU and disk usage more proportional to what the viewer is actually watching. Quick start with Docker docker run -d \ --name lunarr \ -

Há alguns meses, pagando $7/mês por um servidor de 512MB no Render pra hospedar uma API de um projeto da escola, decidi entender como esse tipo de infraestrutura funciona por baixo — e construir a minha própria versão. O resultado é o Arctis Deploy : uma plataforma de deploy contínuo via Git, com Docker isolado por projeto. Esse post é sobre como ela funciona por dentro. Arquitetura geral Frontend (Next.js) │ ▼ Backend (Go + Fiber) — Clean Architecture │ ├──► Deploy-Agent (roda em cada servidor) → Docker └──► Database-Agent (provisiona MySQL/Postgres) em desenvolvimento, ainda não disponível para usuários Cada servidor de produção roda um deploy-agent próprio. O backend central envia comandos via HTTPs autenticado e o agent executa o que for necessário — clone, build, container, métricas. O pipeline de deploy Todo deploy passa por 5 etapas sequenciais: clone — git clone --depth 1 , otimizado pra trazer só o necessário analyze — detecta o framework automaticamente lendo package.json , requirements.txt , go.mod , etc. build — gera um Dockerfile multi-stage específico pro framework detectado (timeout: 15min) deploy — sobe o container na porta alocada, com limites de CPU/RAM aplicados health check — faz requisições até o container responder, com rollback automático em caso de falha Cada etapa emite logs estruturados ( info / warn / error ), transmitidos via WebSocket em tempo real pro frontend. Detecção automática de framework Next.js, React, Vue, Node.js, e sites estáticos. A detecção é baseada nos arquivos do repositório — o usuário só conecta o Git e dá push. Outros detalhes Pool de recursos : cada plano define um total de Projetos/CPU/RAM/disco que o usuário distribui livremente entre seus projetos Auto-sleep : no free, containers sem tráfego são pausados ( docker pause ) — não destruídos — e despertam automaticamente na próxima requisição Domínios : subdomínio automático ou domínio próprio, com SSL via Cloudflare Pagamentos : MercadoPago integrado, planos em real V

After containerizing an application with Docker, the next logical step is deploying it on Kubernetes. Kubernetes helps automate application deployment, scaling, networking, and management of containerized workloads. Instead of manually running containers, Kubernetes ensures your application remains available and can easily scale when needed. In this guide, we'll deploy a Docker image of a Node.js application on Kubernetes using a Deployment and a Service. Prerequisites Before starting, make sure you have: Docker installed Kubernetes cluster running (Docker Desktop Kubernetes, Minikube, Kind, EKS, etc.) kubectl configured A Docker image pushed to Docker Hub In my case, the image was: madhavnaks/node-app:latest Why Kubernetes? Running a container using Docker is straightforward: docker run -p 3000:3000 madhavnaks/node-app:latest However, in production environments we need much more than simply running a container. Kubernetes provides: High availability Self-healing containers Load balancing Service discovery Horizontal scaling Rolling updates This makes it the industry standard for container orchestration. Understanding the Kubernetes Architecture for This Deployment For this deployment, we'll use two Kubernetes resources: Deployment A Deployment is responsible for: Creating Pods Maintaining desired replica count Recreating failed Pods automatically Managing updates and rollbacks Service A Service provides a stable network endpoint for Pods. Since Pod IPs change frequently, Services allow applications and users to communicate reliably with Pods. Deployment and Service Manifest Create a file named: app.yaml Add the following configuration: apiVersion : apps/v1 kind : Deployment metadata : name : node-app spec : replicas : 2 selector : matchLabels : app : node-app template : metadata : labels : app : node-app spec : containers : - name : node-app image : madhavnaks/node-app:latest ports : - containerPort : 3000 --- apiVersion : v1 kind : Service metadata : name : node-a

TL;DR: Create React App builds bake environment variables at build time. ConfigMaps let you inject runtime configs into your container. Here’s how to bridge them so the same Docker image works across dev, staging, and production. The Problem You’ve built a React app with Create React App (CRA), Vite, or Next.js. You use .env files: js // api.js const API_URL = process.env.REACT_APP_API_URL; You build your Docker image: dockerfile FROM node:18 AS builder COPY . . RUN npm run build # REACT_APP_API_URL gets baked here FROM nginx:alpine COPY --from=builder /build /usr/share/nginx/html Then you deploy to Kubernetes. But now you want different API URLs for staging vs production. You could rebuild the image for each environment (bad – slow, wasteful). Or you could use a ConfigMap to inject values at runtime. ConfigMap to the Rescue A ConfigMap stores key-value pairs. Kubernetes can mount it as a file inside your pod. But React runs in the browser, not in the container’s filesystem. So how does the browser read a file from a ConfigMap? Simple: You serve a dynamic env-config.js file from your web server. Step-by-Step Solution Create a ConfigMap with your environment variables yaml # configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: react-env-config data: env-config.js: | window.__env = { REACT_APP_API_URL: " https://api.production.com ", REACT_APP_FEATURE_FLAG: "true" }; Apply it: bash kubectl apply -f configmap.yaml Modify your React app to read from window.__env Instead of reading process.env directly, use a runtime config: js // config.js export function getEnvVar(name) { // Runtime injection from window. env (provided by ConfigMap) if (window. env && window. env[name] !== undefined) { return window. env[name]; } // Fallback to build-time env vars (for local dev) return process.env[name]; } Use it in your components: js // api.js import { getEnvVar } from './config'; const API_URL = getEnvVar('REACT_APP_API_URL'); Serve the ConfigMap file via your web server U

A pattern keeps repeating itself in AI projects. The model works. The demo works. The proof of...

Every time I started a side project, I rebuilt the same five things before I wrote a single line of the actual idea: auth, a database, file uploads, a deploy pipeline, and TLS. Different domain, same plumbing. By the third project I was copy-pasting my own docker-compose.yml from a folder two repos over and renaming things until they stopped erroring. So I stopped. I froze that plumbing into one boilerplate — PocketBase + Next.js + Caddy on a single cheap VPS — and now I ship every side project on it. Same shape every time: clone, rename, write the part that's actually new, push. The thing I care about most isn't the speed, though. It's that I stopped paying for it. A handful of real projects now run on this setup for a few euros a month, total — not a stack of per-service SaaS bills that each want $25 here and $20 there before you've shipped anything. No Vercel seat, no managed Postgres, no Auth-as-a-Service, no object-storage line item. Here's the whole thing. Why this stack The trick that makes the cost collapse is PocketBase . It's a single Go binary that gives you, in one process: Auth — email/password, OAuth, the works, with a real users collection A database — SQLite, with a schema you manage from an admin UI Realtime — subscribe to collection changes over SSE File storage — uploads handled, with on-the-fly thumbnails An admin dashboard — at /_/ , for free That's four or five separate SaaS products collapsed into one binary that runs anywhere and stores everything in a folder. Compared to wiring up Supabase or Firebase, the mental model is tiny: it's one process and one data directory. Back up the directory and you've backed up the entire app — database, uploaded files, auth tokens, all of it. For the front I use Next.js (App Router, React Server Components) because that's where I'm fastest, and Caddy as the reverse proxy because it gets you automatic HTTPS with zero config — it provisions and renews Let's Encrypt certificates on its own. And it all lives on

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

My Previous Deployment Choices Since I mostly do web development using Ruby on Rails, these were my go-to options for deployment: PaaS like Heroku, Render, or Railway Serverless setups (Cloud Run + NeonDB) Honestly, I didn’t have any major complaints. PaaS costs a bit more, but in return, you get a clean UI and dead-simple workflows like GitHub integration. If the cost bothered me, I’d just go serverless. For my personal servers—where huge traffic isn't exactly a concern—going serverless meant the app would just sleep when inactive, allowing me to run services for around 50 yen a month. Compared to the headache of clicking through complex AWS or GCP dashboards to piece things together based on architecture diagrams, it was a walk in the park. I was perfectly content. Seriously. Kamal Became the Default in Rails 8 Everything changed when Rails 8 dropped. I heard they adopted Kamal as the official deployment tool. Kamal — Deploy web apps anywhere From bare metal to cloud VMs using Docker, deploy web apps anywhere with zero downtime. kamal-deploy.org Kamal? Is deploying really going to get any easier? I mean, I’m doing completely fine right now, though... That’s what I thought. But once I gave it a shot, it felt like being struck by lightning. This is an absolute game-changer. All you have to do is run rails new , throw your server's IP address into deploy.yml , and run kamal setup . That’s it—your app is deployed. For every release after that, it's just kamal deploy . I couldn't believe how simple the deployment workflow was. # deploy.yml service : my-app image : my-user/my-app servers : web : - 192.0.2.1 # Just swap in your VPS IP address here proxy : ssl : true host : app.example.com # Set up your domain here Sure, you have to bring your own server, but Kamal prides itself on being able to deploy absolutely anywhere. I rented a couple of VPS instances from Hetzner for about $10 a month each to host SuperRails and LazyCafe . From what I looked into, you can't really

📌 This article was originally published on Sherdil E-Learning . I'm republishing it here so the dev.to community can benefit too. The Kubernetes vs Docker question is one of the most common sources of confusion for developers entering DevOps. People hear both names constantly, see them used together in job listings, and assume they must be competitors. They are not. Docker and Kubernetes do different jobs, and most modern infrastructure uses both. This guide explains what each tool actually does, how they fit together in a real deployment, the practical difference between Docker Compose and Kubernetes, and which one you should learn first. Docker: the container creator Docker is a tool for building, running, and managing containers . A container is a lightweight, portable package that contains an application together with its dependencies, runtime, system libraries, environment variables, and configuration files. The same container runs the same way on a laptop, a CI runner, a production server, or a cloud platform. In a typical Docker workflow you: Write a Dockerfile that describes how to build the image Run docker build to produce the image Run docker run to launch a container from it For multiple containers (a web app plus a database, for example), you use Docker Compose to define the whole set in a docker-compose.yml file and start them with one command. Docker is excellent for individual containers and small multi-container applications. The limitation is scale. What happens when you need a hundred containers across a dozen servers? When one container crashes at 3 a.m.? When you need to roll out a new version without downtime? Docker alone does not solve those problems. For the official reference, see docs.docker.com . Kubernetes: the orchestration layer above Docker Kubernetes (often shortened to K8s ) is an open-source platform that runs containers across many machines as a single coordinated system . It was originally built at Google, based on their internal

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

The Setup I run a Proxmox 9 homelab (pve-manager/9.0.5, kernel 6.14.8-2-pve) and I needed to run Docker inside an LXC container — not a VM — to test a customer-style "bring-your-own-VPS" deployment path for a PaaS I'm building. The container had to act like a standard Ubuntu cloud VM: Docker, systemd, the works. LXC over a full VM gets me near-bare-metal performance, a fraction of the RAM overhead, and instant boots. The catch: the "Docker on LXC" recipes you'll find on most blog posts and Proxmox forum threads are out of date . They assume kernel 5.x and runc 1.1.x. On a modern Proxmox (kernel 6.14 + runc 1.2+ shipped with Docker 29) those recipes fail in two new and confusing ways before you even reach the workarounds we used to know about. This article walks through exactly what fails, why it fails, and the config that actually works in 2026 — plus an honest look at the security tradeoffs, because spoiler: the working config is privileged , and that matters. The Goal A Proxmox LXC container that can: Run docker run hello-world cleanly Pull and build complex images (multi-stage builds, overlay2 storage driver) Run nested containers with their own systemd Use systemd --user for per-service lingering processes Attempt 1: Unprivileged LXC (the path you "should" take) Conventional wisdom says: use unprivileged LXC. The container's root is mapped to an unprivileged UID on the host (typically 100000 ), so even a full container compromise can't escape to host root. Modern Proxmox makes this the default and recommended mode. I started with an unprivileged Ubuntu 25.04 container, added the now-standard features: pct set <vmid> -features nesting = 1,keyctl = 1,fuse = 1 Then inside the container, installed Docker from the official download.docker.com repo and ran: docker run --rm hello-world Here's what happened: docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start

You buy a NAS for silent, always-on storage. It sits in a corner, humming quietly, doing its thing. Then you install Docker. Then Syncthing. Then a few containers. Suddenly the HDDs never stop. Seeking, spinning, clicking. Not occasionally - constantly. At 2am you can hear it from the next room. This is what happened, why it happens, and how to make it stop. What's Actually Causing the Noise Mechanical HDDs make noise when the read/write head moves. The more random the I/O - small reads and writes scattered across the disk - the more seeking, the more noise. Sequential writes to a single file are quiet. Random I/O across thousands of small files is loud. Docker and Syncthing are both pathological for HDDs in different ways. Docker overlay2 Docker's default storage driver is overlay2. Every container runs on top of layered filesystems - the image layers are stacked, and a thin writable layer sits on top for each running container. Every file operation inside a container that touches a file from a lower layer triggers a copy-on-write : the entire file gets copied up to the writable layer before the write happens. On an SSD this is fast and silent. On spinning HDDs with mechanical heads, every copy-on-write is a seek, a read, and a write - often scattered across the disk. And it's not just copy-on-write. Docker's overlay2 metadata lives in small files across a deep directory tree. Container startup reads dozens of these. Log rotation writes to them. Health checks touch them. Any container doing anything at all generates constant scattered I/O. Syncthing's 60-Second Heartbeat Syncthing uses BoltDB as its internal database - it stores file indexes, sync state, and peer information there. BoltDB flushes to disk every 60 seconds regardless of whether anything changed. On a busy sync folder with thousands of files, this flush isn't a single sequential write. It rewrites pages across the B-tree structure, which means multiple seeks across the database file. Quiet when it's a

We've all been there. You're 45 minutes into a Docker tutorial, feeling great about yourself, and then someone casually drops: "Just pull the image and spin up a container." And you think: "...wait, aren't those the same thing?" First - this has happened to a good number of us if we are to be honest. Even almost every single DevOps engineer, cloud architect, and platform wizard you admire has typed the wrong term in a sentence at least once in their career. It's practically a rite of initiation. There should be a badge for it if you ask me. Why Does This Trip Everyone Up? Here's the sneaky truth: Docker commands blur the line constantly. You type docker run nginx and something called a "container" starts — but wait, didn't you just use an "image" called nginx ? Where did one end and the other begin? The confusion lives in the fact that they are deeply related — one literally gives birth to the other. But they are fundamentally, completely different things. Getting this distinction straight is your official rite of passage into DevOps. Once it clicks, the rest of Docker feels like cheating. Basically, A Docker Image is the blueprint : a frozen, static snapshot of everything your app needs - the OS layer, the dependencies, the config files, your actual code. It just sits there on disk, completely inert. You can't run a blueprint. A Docker Container is the house : the live, running instance that was built from that blueprint. It has processes running, files potentially being written, network ports being listened on. It's alive. And now, just like one blueprint can produce 10 identical houses on different streets - one Image can launch 10 identical Containers simultaneously; and that's where Docker's scaling magic comes from. # The image just sits here, unchanging docker pull nginx # Now we BUILD a house (container) from the blueprint docker run nginx # Build THREE houses from the same single blueprint docker run nginx docker run nginx docker run nginx Here is an exampl

There's a question that keeps surfacing across engineering teams — sometimes in architecture reviews,...