Cloud, Docker & DevOps — snelle en betrouwbare deployments
We zetten alle applicaties in containers met Docker, orkestreren ze met Docker Compose (of Kubernetes bij enterpriseprojecten), richten Caddy in als reverse proxy met automatische SSL en automatiseren de volledige deploymentcyclus via GitHub Actions — van commit tot productie in één geautomatiseerde pipeline.
Containerisatie met Docker en Docker Compose
Elke dienst heeft zijn eigen multi-stage Dockerfile: een buildfase die afhankelijkheden installeert en compileert, en een minimale eindfase (distroless of Alpine) die alleen de noodzakelijke artefacten bevat. Een typische Next.js-image blijft onder 150 MB, een FastAPI-image onder 80 MB. De images worden bij elke merge naar main opnieuw gebouwd en semantisch getagd (`v1.2.3` + `latest`).
Docker Compose beschrijft de volledige stack: frontend, API, database, Redis en workers. Gevoelige variabelen (databasewachtwoord, API-sleutels, Stripe-secret) staan in een `.env` die buiten Git blijft — nooit vast in de image. Health checks in Compose zorgen ervoor dat afhankelijkheden klaar zijn voordat er wordt gestart (database klaar → API start → frontend start).
- Buildcache met `--mount=type=cache` — afhankelijkheden worden niet bij elke build opnieuw gedownload
- Geoptimaliseerde volgorde van layers: stabiele afhankelijkheden eerst, daarna de broncode
- Secrets-beheer met Docker Secrets of HashiCorp Vault bij enterpriseprojecten
- `restart: unless-stopped` + `docker compose up --no-deps` voor atomaire deployments
Caddy — moderne reverse proxy met automatische SSL
Caddy 2.8 regelt SSL/TLS automatisch via ACME (Let's Encrypt of ZeroSSL) — certificaten worden zonder handmatige configuratie aangevraagd en vernieuwd. HTTP/2 en HTTP/3 (QUIC) staan standaard aan. Beveiligingsheaders (HSTS, X-Frame-Options, CSP) stellen we globaal in via herbruikbare snippets. De declaratieve Caddyfile-configuratie laat zich diffen en staat onder versiebeheer in Git.
Rate limiting, gzip- en brotli-compressie en gestructureerde JSON-logging activeren we via native Caddy-directives — zonder nginx-modules of omslachtige Apache-configuratie. Verzoeken naar gevoelige paden (`/admin`, `.env`, `.git`) beantwoordt een globaal beveiligingssnippet met 444 (geen antwoord).
- Moderne TLS-configuratie vanaf dag één — uitsluitend TLS 1.3 met moderne cipher suites
- On-demand TLS voor multi-tenant-SaaS met dynamische subdomeinen
- Herladen zonder actieve verbindingen te verbreken — `caddy reload`
- Caddy-logs → Loki → Grafana — verkeersanalyse en meldingen bij afwijkingen
CI/CD met GitHub Actions en monitoring
De CI-pipeline draait bij elke PR: lint, typecontrole, unittests, bouwen van de Docker-image en een scan op kwetsbaarheden (Trivy). Slagen alle stappen, dan wordt de image naar de registry gepusht en automatisch uitgerold naar staging. Een merge naar main betekent automatische deployment naar productie, gevolgd door een health check. Mislukt die binnen 60 seconden, dan volgt een automatische rollback.
Voor monitoring gebruiken we Grafana en Prometheus voor applicatiemetrieken (latency, foutpercentage, queuegrootte) en Loki voor logaggregatie. Meldingen lopen via Slack of e-mail: foutpercentage boven 1 %, P95-latency boven 500 ms, schijf boven 85 % bezetting. De externe uptimemonitoring verzorgt Better Uptime — een openbaar SLA-dashboard leveren we op verzoek.
- Trivy-scan op kwetsbaarheden in de images — kritieke CVE's blokkeren de deployment
- Dependabot met auto-merge voor patch-updates (vereist een groene CI)
- Automatische databaseback-up naar S3-compatibele opslag (nachtelijk, 30 dagen bewaartermijn)
Voordelen en beperkingen
Voordelen
- Deployment met automatische rollback bij een mislukte health check.
- Automatische SSL/TLS via Caddy — certificaten worden zonder handmatige stap vernieuwd.
- Reproduceerbare omgeving: dezelfde Docker-image in ontwikkeling, staging en productie.
- Monitoring en meldingen (Grafana, Loki) — problemen worden zichtbaar vóór de gebruikers ze merken.
Beperkingen
- Docker Compose schaalt bij multi-node-enterprisesetups niet zoals Kubernetes.
- De initiële CI/CD-inrichting kost tijd en vraagt DevOps-ervaring.
- Images en logs nemen schijfruimte in — regelmatig opruimen is nodig.
- Volledige monitoring (Prometheus + Grafana) brengt extra diensten mee die je moet onderhouden.
Kort oordeel
Docker, Caddy en GitHub Actions vormen de ideale combinatie voor betrouwbare deployments op een VPS of een paar nodes. Bij tientallen nodes met agressieve auto-scaling leidt de weg naar Kubernetes.
Specificatietabel
| Mogelijkheid | Grens / drempel | Typisch gebruik | |
|---|---|---|---|
| Orkestratie | Docker Compose, volledige stack | Eén node; meerdere nodes vragen om Swarm of K8s | VPS, kleine tot middelgrote projecten |
| Reverse proxy | Caddy 2.8, HTTP/3, automatische SSL | Zeer complexe regels vragen om een uitvoerige configuratie | Meerdere domeinen, multi-tenant |
| CI/CD | GitHub Actions, geautomatiseerde deployment | CI-minuten worden buiten de free tier afgerekend | Automatisch van commit tot in productie |
| Typische kosten | VPS vanaf ongeveer 5 €/maand | Monitoring en back-ups brengen extra kosten mee | Van één enkele website tot multi-brandbeheer |
Docker Compose vergeleken met Kubernetes
| Criterium | Docker Compose | Kubernetes |
|---|---|---|
| Inspanning bij de inrichting | Laag | Hoog |
| Multi-node-schaling / auto-scaling | Beperkt (één node) | Uitstekend |
| Geschikt voor | VPS, kleine tot middelgrote projecten | Grote vloten, enterprise |
Veelgestelde vragen
Waarom Caddy en niet nginx?
Caddy regelt SSL/TLS automatisch via ACME, zet HTTP/2 en HTTP/3 standaard aan en heeft genoeg aan een korte, declaratieve configuratie. nginx heeft voor hetzelfde resultaat Certbot nodig en aanzienlijk meer handmatige configuratie.
Heb ik Kubernetes nodig?
Voor de meeste websites niet. Docker Compose op een VPS draait een website of een handvol diensten betrouwbaar. Kubernetes wordt pas interessant bij tientallen nodes met agressieve auto-scaling.
Hoe verloopt een deployment?
GitHub Actions bouwt een nieuwe image, start die naast de oude, voert een health check uit en leidt daarna het verkeer om. Mislukt de health check binnen 60 seconden, dan wordt automatisch teruggerold naar de vorige versie.
Welke monitoring raden jullie aan?
Grafana en Prometheus voor metrieken (latency, foutpercentage) en Loki voor geaggregeerde logs, met meldingen via Slack of e-mail. Voor de externe beschikbaarheidscontrole komt daar een onafhankelijke dienst als Better Uptime bij.