Docker-arkitekturen under huven

Docker bygger på en klient-server-modell med tre centrala komponenter:

Docker Engine (daemon)

dockerd är bakgrundsprocessen som hanterar bygge, körning och distribution av containrar. Den exponerar ett REST-API som Docker CLI (docker) och andra verktyg kommunicerar med. Sedan 2024 använder Docker som standard containerd som container-runtime, samma runtime som Kubernetes förlitar sig på – vilket gör övergången mellan verktygen smidigare.

Images och lager

En Docker-image är en skrivskyddad mall som definieras i en Dockerfile. Varje instruktion (FROM, RUN, COPY) skapar ett nytt lager (layer) som cachas. Det innebär att en ändring i applikationskoden bara bygger om de lager som påverkats – inte hela imagen.

```dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]

```

Tips från vår driftverksamhet: Lägg sällan ändrade lager (basimage, systempaket) överst i Dockerfilen och applikationskoden sist. Det maximerar cache-träffar och snabbar upp CI/CD-pipelines avsevärt.

Docker Hub och privata registries

Docker Hub erbjuder hundratusentals publika images. Men i produktion rekommenderar vi alltid en privat registry – Amazon ECR, Azure Container Registry eller Harbor – av tre skäl:

1. Säkerhet: Du kontrollerar vad som körs i dina kluster.

2. Nätverkslatens: Närmare registry = snabbare pulls, särskilt vid autoskalning.

3. Compliance: NIS2-direktivet och GDPR kräver spårbarhet i leveranskedjan – en publik image utan verifierat ursprung uppfyller sällan det kravet.

---

Från Compose till Kubernetes: orkestrering i praktiken

Att köra en enstaka container är trivialt. Utmaningen börjar när applikationen består av tjugo mikrotjänster, tre databaser och en meddelandekö – och allt ska skalas, uppdateras och övervakas utan avbrott.

Docker Compose: startpunkten

Docker Compose definierar multi-container-applikationer i en enda YAML-fil. Det är perfekt för:

• Lokal utveckling
• Integrationstester i CI/CD
• Mindre produktionsmiljöer utan krav på automatisk skalning

```yaml

services:

api:

build: ./api

ports:

- "8000:8000"

depends_on:

- db

db:

image: postgres:16

volumes:

- pgdata:/var/lib/postgresql/data

environment:

POSTGRES_PASSWORD_FILE: /run/secrets/db_password

secrets:

- db_password

volumes:

pgdata:

secrets:

db_password:

file: ./secrets/db_password.txt

```

Kubernetes: produktionsstandarden

Enligt CNCFs årliga undersökning har Kubernetes etablerats som den dominerande plattformen för containerorkestrering i produktion. De tre stora molnleverantörerna erbjuder managerade varianter – EKS (AWS), AKS (Azure) och GKE (Google Cloud) – som hanterar kontrollplanet åt dig.

Kubernetes löser problem som Compose inte adresserar:

• Automatisk skalning (HPA/VPA) baserad på CPU, minne eller anpassade mätvärden
• Self-healing: Crashade pods startas om automatiskt
• Rolling deployments: Noll nedtid vid uppdateringar
• Service discovery och lastbalansering inbyggt
• Deklarativ konfiguration versionshanterad i Git (GitOps)

Opsios rekommendation: Gå inte till Kubernetes för tidigt. Om din applikation har färre än fem tjänster och inga krav på automatisk skalning är Compose eller ECS Fargate ofta enklare att driva och billigare att köra. Managerad DevOps

---

Säkerhet i containeriserade miljöer

Containrar introducerar en ny attackyta som kräver specifik säkerhetspraxis. Traditionella perimeterlösningar räcker inte – varje image, varje konfiguration och varje runtime-beteende måste granskas.

Image-säkerhet: skanна innan du skeppar

• Minimala basbilder: Använd alpine, distroless eller scratch istället för fullständiga ubuntu-images. Mindre image = färre paket = mindre attackyta.
• Automatisk skannings: Integrera Trivy, Snyk eller Aqua Security i CI/CD-pipelinen. Ingen image med kritiska CVE:er bör nå produktion.
• Signerade images: Använd Docker Content Trust (DCT) eller Cosign/Sigstore för att verifiera att imagen kommer från en betrodd källa.

Runtime-säkerhet

• Kör aldrig som root: Lägg till USER nonroot i Dockerfilen. Det begränsar skadan vid en container escape.
• Read-only filesystem: Sätt --read-only på containrar som inte behöver skriva till disk.
• Seccomp och AppArmor: Begränsa vilka systemanrop containern får göra. Standardprofilerna blockerar de farligaste anropen, men anpassade profiler ger starkare skydd.
• Nätverkspolicyer: I Kubernetes, använd NetworkPolicies för att begränsa trafik mellan pods. Zero-trust-principer gäller även inuti klustret.

Compliance-aspekter för svenska organisationer

NIS2-direktivet, som trädde i kraft 2024, ställer krav på supply chain-säkerhet – och containerimages är en del av den kedjan. GDPR kräver att personuppgifter skyddas oavsett var de behandlas, vilket påverkar var du kör dina containrar och hur secrets hanteras.

Konkret: lagra aldrig lösenord eller API-nycklar i Dockerfilen eller image-lager. Använd Kubernetes Secrets (krypterade med KMS), HashiCorp Vault eller AWS Secrets Manager. Molnsäkerhet

---

FinOps och containerkostnader

Containerisering kan sänka infrastrukturkostnader – men det sker inte automatiskt. Utan styrning skapar organisationer istället överprovisioning på containernivå.

Tre vanliga kostnadsmisstag

1. Inga resource requests/limits: Pods utan definierade gränser äter upp nod-resurser okontrollerat. Sätt alltid requests (det schedulern reserverar) och limits (det hårda taket).

2. Överdimensionerade nodpooler: Kör inte c5.4xlarge-instanser om dina containrar behöver 256 MB RAM. Använd Karpenter (AWS) eller NAP (GKE) för automatisk nodprovisionering.

3. Ingen spot/preemptible-strategi: Stateless containrar – webb-frontends, API-gateways, batch-jobb – är idealiska för spot-instanser som kostar en bråkdel av on-demand-priset.

Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den största utmaningen för organisationer som kör arbetsbelastningar i molnet. Containerisering ger bättre verktyg för att adressera problemet, men bara om man faktiskt använder dem.

Cloud FinOps

---

Praktisk migrering: från VM-baserad drift till containrar

Att containerisera en befintlig applikation kräver mer än att skriva en Dockerfile. Här är den arbetsordning vi använder vid Molnmigrering:

Steg 1: Inventera och prioritera

Kartlägg alla applikationer och kategorisera dem:

• Containeriserings-mogna: Stateless tjänster, REST-APIer, frontend-applikationer
• Kräver anpassning: Stateful tjänster som behöver persistent storage-strategi
• Lämna som VM: Äldre applikationer med kernel-beroenden, licensmodeller kopplade till fysisk hårdvara

Steg 2: Bygg CI/CD-pipeline först

Innan du containeriserar en enda tjänst, etablera:

• Git-repo med Dockerfile och Kubernetes-manifester (eller Helm charts)
• Automatiserad image-build och skanering
• Deployment till staging via GitOps (ArgoCD eller Flux)
• Observability: loggar (Fluent Bit → OpenSearch), mätvärden (Prometheus/Grafana), traces (OpenTelemetry)

Steg 3: Migrera inkrementellt

Strangler fig-mönstret fungerar: låt den nya containeriserade tjänsten köra parallellt med den gamla VM-baserade, dirigera trafik gradvis, och stäng av den gamla först när den nya bevisligen fungerar i produktion.

---

Observability: det containrar inte löser åt dig

Containrar gör deployment snabbare. Men de gör inte felsökning enklare – snarare tvärtom. Istället för tre monoliter att övervaka har du nu femtio mikrotjänster som kommunicerar via nätverk.

Tre pelare krävs:

Enligt Datadogs State of Cloud-rapport har organisationer som kör containrar i produktion i genomsnitt betydligt fler tjänster att övervaka än VM-baserade miljöer. Utan strukturerad observability blir incidenthantering ett gissningsspel.

Det är här ett 24/7 SOC/NOC tillför verkligt värde. Opsios team i Karlstad och Bangalore övervakar containeriserade miljöer dygnet runt med automatiserade larm och runbooks som triggas innan slutanvändare påverkas. Managerade molntjänster

---

Vanliga frågor

Vad är skillnaden mellan en container och en virtuell maskin?

En container delar värdoperativsystemets kärna och paketerar enbart applikationen med dess beroenden. En virtuell maskin kör ett helt eget operativsystem ovanpå en hypervisor. Det gör containrar snabbare att starta, mer resurseffektiva och enklare att flytta mellan miljöer – men de ger svagare isolering på kärnnivå.

Behöver jag Kubernetes om jag kör Docker?

Inte nödvändigtvis. Docker Compose räcker för enklare applikationer och utvecklingsmiljöer. Men så snart du behöver automatisk skalning, self-healing och rolling deployments i produktion – då är Kubernetes eller en managerad orkestrering som EKS, AKS eller GKE rätt steg.

Hur säkrar jag Docker-containrar i produktion?

Använd minimala basbilder (Alpine, distroless), skanna images med verktyg som Trivy eller Snyk, kör aldrig processer som root inuti containern, begränsa capabilities med seccomp och AppArmor, och övervaka runtime-beteende. Integrera skanningen i CI/CD-pipelinen så att sårbara images aldrig når produktion.

Är Docker gratis att använda?

Docker Engine och CLI är öppen källkod under Apache 2.0. Docker Desktop kräver sedan 2022 en betald prenumeration för organisationer med fler än 250 anställda eller över 10 miljoner USD i årsomsättning. Alternativ som Podman och Rancher Desktop erbjuder likvärdig funktionalitet utan licensavgift.

Hur hänger containerisering ihop med molnkostnader?

Containrar gör det möjligt att packa fler arbetsbelastningar per nod, vilket minskar överprovisioning. Med FinOps-metodik – requests/limits-styrning, autoskalning och spot-instanser – kan en containeriserad miljö kosta betydligt mindre än motsvarande VM-baserad infrastruktur. Flexeras State of the Cloud har konsekvent visat att kostnadshantering är organisationers främsta molnutmaning.