Containers zijn een Unix-concept waarmee applicaties met al hun vereiste afhankelijkheden kunnen worden verpakt in één eenvoudig uit te voeren image. Dit heeft enorme voordelen voor een DevOps-workflow, maar is het de extra moeite waard?
Containers synchroniseren Dev- en Prod-omgevingen
Bij containers is het hele idee dat ze alles verpakken wat je nodig hebt om je code uit te voeren in een gemakkelijk te distribueren afbeelding. Dit betekent dat u alleen de afbeelding hoeft te downloaden en
docker run. uit te voeren.
De tijd van "het werkt niet op mijn machine" is voorbij. Met containers - op voorwaarde dat iedereen Docker correct heeft geïnstalleerd en weet hoe het te gebruiken - zou de container op jouw computer ongeveer hetzelfde moeten werken als alle anderen.
Bovendien geldt dit ook voor uw productieomgeving. U kunt een paar dev-functies inschakelen in ontwikkelingsbuilds, maar voor het grootste deel kunnen containers ongewijzigd naar uw productieservers worden verzonden. U zult niet veel problemen ondervinden met het hosten van containers.
Containers maken efficiënt schalen mogelijk
Omdat het zo gemakkelijk is om een container te runnen, zijn er tal van services die ze voor u kunnen uitvoeren. Deze worden meestal aangeduid als orkestratietools-tools die het uitvoeren van meerdere instanties van containers op veel servers beheren.
AWS heeft hun Elastic Container Service, die het beheer van uw containers op een vloot van EC2-instanties of op hun eigen Fargate-service beheert. Kubernetes is open source en veel cloudproviders bieden integraties die het gebruiken.
Elke orkestratieservice kan de status van uw instanties volgen en nieuwe opstarten wanneer er veel verkeer is. Dit maakt efficiënt schalen mogelijk, waardoor u veel geld kunt besparen op hostingkosten (tot 90% op AWS met Auto Scaling en Spot Instances), en u hoeft zich niet al te veel zorgen te maken over het ontgroeien van uw infrastructuur.
Bovendien ervaren containers niet dezelfde prestatievermindering als het draaien van virtuele machines, omdat het niet voor elke app een gast-besturingssysteem hoeft te draaien. Dit maakt containerhosting over het algemeen goedkoper en veel efficiënter.
En dit alles is mogelijk gemaakt vanwege de aard van containers, zonder dat er extra werk nodig is. Je kunt hetzelfde doen op AWS met behulp van aangepaste AMI's, maar ze zijn veel moeilijker te beheren dan containers, en je zult sowieso veel van hetzelfde werk doen.
Containers Versiebeheer Uw SysAdmin
Misschien is het coolste gevolg van containers dat ze al je serverconfiguratie uit het hoofd van je SysAdmin halen en naar
git brengen, waar het kan worden beheerd en gevolgd. Omdat elk nieuw pakket, configuratiebestand, installatiescript en afhankelijkheid zich in de buildmap voor de container bevindt, is het triviaal om het aan te sluiten op bronbeheer.
Containers integreren bijzonder goed met de operationele kant van een DevOps-workflow. Hiermee kunt u dezelfde versiebeheer- en testsystemen gebruiken die u heeft om uw serverarchitectuur te beheren. En omdat iedereen synchroon loopt en dezelfde omgeving gebruikt om te ontwikkelen, bouwen en testen, zou het heel soepel moeten verlopen.
Plus, Docker werkt goed met continue integratiesystemen. Docker-builds zijn eenvoudig te automatiseren, vooral als u Azure Pipelines gebruikt. Het pushen van een Docker-image naar uw serverpark is net zo eenvoudig als het bijwerken van de image in de repository. U kunt zelfs een nieuwe container op een subset van servers implementeren om de status ervan te controleren voordat u deze in de hele vloot implementeert, iets dat zonder containers niet triviaal zou zijn om te implementeren.
Het nadeel: de hoofdpijn is echt
Let's be real-containers zijn zeker de elegantere oplossing, maar ze zijn veel moeilijker in te stellen en mee te werken, vergeleken met gewoon een nieuwe Linux-box opstarten en een uur besteden aan het installeren van software. Iedereen heeft het laatste gedaan, maar het eerste kost over het algemeen veel meer tijdsinvestering. (Hoewel, als je een heleboel servers gebruikt, Docker maar één keer hoeft te worden geconfigureerd.)
Als uw taak niet bijzonder ingewikkeld is, of als er niet veel vraag naar is, kan de implementatie met containers overkill zijn. Er is geen echte reden om
nginx
en
node in een container te plaatsen als je het maar op één instantie uitvoert.
En hoewel containers het gemakkelijker maken om alle afhankelijkheden te beheren die gepaard kunnen gaan met het uitvoeren van uw app, is het ook veel lastiger om Docker uit te voeren en poorten te binden wanneer u uw app wilt testen, vergeleken met alleennpm start
of iets dergelijks in uw projectdirectory. Dit kan zeker worden verholpen met opstartscripts, maar als u macOS of Windows gebruikt, draait u nog steeds een hele VM om uw web-app te laden.
Uiteindelijk, als je een fan bent van Docker en zijn concepten, weerhoudt niets je ervan om het voor je persoonlijke projecten te gebruiken. Maar de voordelen van Docker beginnen pas echt op te wegen tegen de hoofdpijn als je eenmaal in een groter team werkt. In een teamomgeving zorgt het samenbrengen van alles rondom uw app in uw versiebeheersystemen en DevOps-workflow ervoor dat de productie soepel verloopt.
