Het team werd in productie ingezet met docker compose up -d op een virtuele privéserver: applicatie, worker, cache, reverse proxy. Het loopt. Zes maanden later werd door het eerste echte incident (volledige schijf op één knooppunt) alles stilgelegd: internet, wachtrijen, monitoring. Het herstelplan spreekt over "failover naar de tweede server", maar Compose is nooit geconfigureerd om twee hosts te orkestreren.
Docker Compose blinkt uit in het beschrijven van meerdere containers en hun links. Hij is geen datacenterorkestrator. Het verwarren van ‘Ik heb een werkend yaml-bestand’ met ‘Ik heb een veerkrachtige infrastructuur’ is kostbaar bij het eerste single point of fail.
What Compose doet het goed — en waar het stopt
Compose v2 beheert afhankelijkheden, gezondheidscontroles, volumes en overlay-netwerken op dezelfde Docker-engine. Ideaal om de productie lokaal te reproduceren en een samenhangende stapel te lanceren.
| nodig | Componeren | Orchestrator (Kubernetes, Nomad) |
|---|---|---|
| Multicontainer op 1 host | ✅ | ✅ (oversized) |
| Naadloos rollende update | ⚠️ handleiding/script | ✅ native |
| Multi-node / anti-single point | ❌ | ✅ |
| Horizontaal automatisch schalen | ❌ | ✅ |
| Rotatiegeheimen | ⚠️beperkt | ✅ geïntegreerd |
Op één server met een Europese host blijft Compose eerlijk als je onderhoud en backups buiten Compose op zich neemt.
Stel documenten samen met uw stapel; het maakt het niet op magische wijze beschikbaar.
Eén host, vergeten volumes en back-ups
Benoemde volumes overleven afsluitingen zonder verwijdering - handig en gevaarlijk als niemand een momentopname van de database maakt. Met een image-update wordt de applicatie bijgewerkt, maar niet wordt automatisch het PostgreSQL-volumeback-upbeleid bijgewerkt.
Controle: off-node geteste back-ups, schijfmonitoring en -waarschuwingen, gecentraliseerde logboeken - niet alleen lokale containerlogboeken. Het uitbesteden van de database verkleint het risico zonder direct over te stappen op Kubernetes.
Implementatie, onbeschikbaarheid en statuscheck
Zonder een gezondheidscontrole kan de proxy doorsturen naar een container die nog aan het opstarten is: tijdelijke serverfouten. Patroon: HTTP-controle op het eindpunt van de applicatie, proxy die alleen verkeer naar gezonde backends stuurt, implementatiescript met wachten op de status.
Naadloos updaten van meerdere exemplaren op één host blijft ambachtelijk. Dit is waar de grenzen concreet worden: je bent opnieuw aan het uitvinden wat orkestrators van nature doen.
Netwerk-, TLS- en poortblootstelling
Het publiceren van de databasepoort stelt PostgreSQL bloot aan internet als de hostfirewall laks is. Geef de voorkeur aan interne netwerknummers plus een enkele reverse proxy op een beveiligde poort.
Waarneembaarheid en nachtelijke beperkingen
Compose biedt geen clusterdashboard. Containerstatistieken gaan via een speciale agent, logt via een verzamelprogramma – moet expliciet worden toegevoegd. Documenteer wie toegang heeft tot de server, hoe u een service opnieuw kunt opstarten, waar de omgevingsbestanden zich bevinden en wie om 03.00 uur op een waarschuwing reageert.
De top: Componeer als uitgestelde schuld
Beslis en ga vooruit zonder blinde vlek
Als u Compose blijft gebruiken, behandel deze punten dan als een audit vóór het volgende incident:
- De database uitbesteden aan een beheerd aanbod of aan off-node geteste back-ups: Docker-volume alleen beschermt uw gegevens niet.
- Voeg statuscontroles toe voor elke blootgestelde service en configureer de proxy om alleen verkeer naar gezonde backends te sturen.
- Test back-ups met een getimed herstel, niet alleen de aanwezigheid van een cron-script.
- Script voor de implementatie met statusverwachting en gedocumenteerd onderhoudsvenster.
- **Implementeer gecentraliseerde schijf-, container- en logmonitoring: Compose doet dit niet standaard.
- Plan de migratiedrempel op basis van verkeer, teamgrootte en serviceniveau dat aan klanten wordt beloofd.
- Simuleer een schijfstoring: hoe lang duurt het om de service en gegevens te herstellen? Als het antwoord onduidelijk is, staat Compose nog niet voor je klaar.
Vergelijk geschikte hosts via de overzicht en de vergelijker.
Veelgestelde vragen
Staat Docker Compose gepland voor productie?
Compose richt zich primair op eenvoudige ontwikkeling en implementatie op één of enkele hosts. Bij grootschalige productie ontbreken native primitieven voor het rollend bijwerken van meerdere knooppunten, automatisch schalen en fijnmazige geheime rotatie. Dit verbiedt het niet, maar stelt de grenzen ervan.
Wanneer Compose een goede keuze blijft?
Op één server, met een klein team, een stabiele stack en tolerantie voor een kort onderhoudsvenster. Interne tools, MVP's en SaaS in een vroeg stadium vinden vaak hun plaats – zolang het single point of Failure maar wordt aangenomen en gedocumenteerd.
Hoe geheimen beheren met Compose?
Gebruik omgevingsvariabelen via een bestand zonder versiebeheer, Docker-geheimen in de zwermmodus of injectie van continue integratie naar implementatie. Leg nooit wachtwoorden vast in de repository. Draai de geheimen na eventuele verdachte lekken.
Hoe migreer je zonder big bang naar Kubernetes?
Externaliseer eerst de status (beheerde database, beheerde cache), containeriseer deze op de juiste manier en voer vervolgens service voor service uit. Compose en Kubernetes kunnen naast elkaar bestaan tijdens een transitiefase – het is niet nodig om op vrijdagavond alles om te zetten.
Componeren houdt stand zolang je het enige punt waarop je faalt kunt benoemen – en kunt uitleggen hoe je dit overleeft.