Containerisatie lost een van de hardnekkigste problemen in software-uitrol op: het verschil tussen de omgeving waarin software wordt ontwikkeld en de omgeving waarin die in productie draait. Een container verpakt de applicatie samen met alles wat die nodig heeft, zodat hij overal hetzelfde draait: op de laptop van de ontwikkelaar, in de testpipeline en op de productieserver.
Docker is de meest gebruikte containerruntime en buildtool. Een Dockerfile beschrijft hoe het image wordt gebouwd; het image is het onveranderlijke pakket dat overal wordt uitgerold. In de meeste projecten die wij bouwen, is containerisatie een vast onderdeel: de ontwikkelomgeving draait in containers, de pipeline bouwt en test in containers, en productie draait hetzelfde image dat getest is. Ook bestaande applicaties containeriseren wij, voor consistentie, draagbaarheid of uitrol op containerplatforms.
Wat containerisatie omvat
Dockerfile-ontwerp. Multi-stage builds die bouwtools scheiden van de runtime, zodat productie-images klein en veilig zijn. Een volgorde van instructies die de buildcache optimaal benut, minimale en regelmatig bijgewerkte base images, processen die niet als root draaien, en een .dockerignore die de buildcontext schoon houdt.
Docker Compose voor ontwikkeling. De applicatie, database, message broker en cache als één reproduceerbare omgeving, met health checks en afhankelijkheden in de juiste volgorde, volume mounts voor live herladen en omgevingsvariabelen uit .env-bestanden, gedocumenteerd met een .env.example.
Container registries. Images die de pipeline naar een registry pusht en de uitrol daar weer ophaalt, getagd met de commit-hash voor onveranderlijke verwijzingen, en opruimregels zodat oude images zich niet eindeloos opstapelen.
Netwerken en limieten. Eigen netwerken waarin containers elkaar op naam vinden, alleen de poorten openzetten die nodig zijn, resourcelimieten voor CPU en geheugen, en health checks zodat een vastgelopen container wordt herkend.
Kubernetes voor productie op schaal
Moeten meerdere replica's draaien voor beschikbaarheid, is uitrollen zonder downtime nodig, of moet het platform automatisch schalen bij wisselende belasting, dan zetten wij Kubernetes in: deployments met rolling updates of blue-green, automatisch schalen op CPU, geheugen of eigen metrics, persistente opslag voor wat herstarts moet overleven, en ingress met automatisch beheerde TLS-certificaten. Manifests per omgeving beheren wij met Kustomize of Helm.
Gebruikte technologieën
Docker, Docker Compose, Kubernetes, Helm en Kustomize, GitHub Container Registry en AWS ECR, cert-manager, Nginx, systemd voor containers op een VPS, en GitHub Actions of GitLab CI voor bouwen en pushen.
Dezelfde container, van ontwikkeling tot productie
Het doel van containerisatie is één artefact dat in elke omgeving hetzelfde draait. Dat betaalt zich vanaf de eerste uitrol terug: wat getest is, is wat live gaat, nieuwe ontwikkelaars zijn sneller op gang, en problemen zijn reproduceerbaar in plaats van gebonden aan één server. Zie ook CI/CD-pipelines.
Veelgestelde vragen over Docker
Kunnen jullie onze bestaande applicatie containeriseren?
Meestal wel. Wij schrijven een Dockerfile die de huidige runtime nabootst, verplaatsen configuratie naar omgevingsvariabelen, en testen de container naast de bestaande opzet voordat we overstappen.
Hebben wij Kubernetes nodig om Docker te gebruiken?
Nee. Veel applicaties draaien prima als containers op één server met Docker Compose of systemd. Kubernetes loont pas op een schaal waarop u de orchestratiefuncties nodig heeft.
Hoe houden jullie images veilig?
Minimale, regelmatig bijgewerkte base images, processen die niet als root draaien, geen secrets in images, en scans op kwetsbaarheden in de buildpipeline.
Zijn de code en configuratie van ons?
Dat kan. Het eigendom van de broncode en infrastructuurconfiguratie wordt contractueel vastgelegd, en kan volledig van u zijn, inclusief documentatie.
Bekijk alle technologieën waarmee wij werken of onze software op maat.