Met de container zijn ‘revolutie’ apps veel meer gegroeid dan alleen een database en een frontend. Applicaties zijn opgesplitst in verschillende microservices en ze communiceren meestal met elkaar via een REST API (meestal JSON-geformatteerde payloads via HTTP). Docker-containers zijn ideaal voor dit soort architectuur. U kunt uw frontend 'microservice' in een Docker-container verpakken, de database gaat in een andere, enzovoort, enzovoort. Elke service praat met een andere via een vooraf gedefinieerde REST API in plaats van een monoliet te zijn die als een enkel stuk software is geschreven.
Als u een nieuwe functionaliteit of functie moet implementeren, bijvoorbeeld een analyse-engine, kunt u daar eenvoudig een nieuwe microservice voor schrijven en deze zou gegevens verbruiken via de REST API die wordt weergegeven door de verschillende microservices van uw web-app. En naarmate uw functionaliteit in de loop van de tijd groeit, groeit deze lijst met microservices ook mee.
U wilt niet elke afzonderlijke container implementeren, deze configureren en vervolgens al het andere configureren om er ook mee te praten. Dat wordt al vervelend met zelfs drie containers. Met Docker-Compose kunt u de implementatie van meerdere containers automatiseren.
Docker-Compose is een van de eenvoudigste tools waarmee u het abstracte idee van microservices kunt omzetten in een functionele set Docker-containers.
Gedistribueerde systemen
Nu we de web-app hebben opgesplitst in meerdere containers, heeft het weinig zin om ze allemaal op één server te houden (erger nog op één virtuele machine!) Dat is waar services zoals Docker Swarm en Kubernetes in het spel komen.
Met Docker Swarm kunt u meerdere replica's van uw toepassing op meerdere servers uitvoeren. Als uw microservice zo is geschreven dat deze 'horizontaal' kan worden geschaald, kunt u Docker Swarm gebruiken om uw web-app in meerdere datacenters en meerdere regio's te implementeren. Dit biedt weerstand tegen het uitvallen van een of meerdere datacenters of netwerkkoppelingen. Dit wordt meestal gedaan met behulp van een subopdracht in Docker, dat wil zeggen Docker Stack.
De Docker-stack subcommand gedraagt zich veel meer als het Docker-Compose-commando en dat kan leiden tot misvattingen bij iemand die een van de technologieën gebruikt.
Bron van verwarring
Qua gebruik en workflow werken beide technologieën erg op elkaar en dit zorgt voor verwarring. De manier waarop u uw app implementeert met Docker Swarm of Docker-Compose, lijkt sterk op elkaar. U definieert uw toepassing in een YAML-bestand. Dit bestand bevat de afbeeldingsnaam, de configuratie voor elke afbeelding en ook de schaal (aantal replica's) waaraan elke microservice moet voldoen tijdens de implementatie.
Het verschil zit vooral in de backend, waar docker-compose de container op een enkele Docker-host implementeert, Docker Swarm deze op meerdere knooppunten implementeert. Losjes gesproken kan het nog steeds de meeste dingen doen die docker-compose kan, maar het schaalt het over meerdere Docker-hosts.
overeenkomsten
Zowel Docker Swarm als Docker-Compose hebben de volgende overeenkomsten:
- Ze nemen beide YAML-geformatteerde definities van uw toepassingsstack.
- Ze zijn beide bedoeld voor toepassingen met meerdere containers (microservices)
- Ze hebben allebei een schaalparameter waarmee u meerdere containers van dezelfde afbeelding kunt uitvoeren, zodat uw microservice horizontaal kan worden geschaald.
- Ze worden beide onderhouden door hetzelfde bedrijf, d.w.z. Docker, Inc.
Verschillen
De paar verschillen tussen Docker Swarm en Docker-Compose:
- Docker Swarm wordt gebruikt om uw web-app over een of meer servers te schalen. Waar als Docker-compose uw web-app eenvoudig op een enkele Docker-host zal draaien.
- Uw web-app schalen Docker Swarm biedt een serieuze hoge beschikbaarheid en fouttolerantie. Het schalen van uw web-app met Docker-Compose op één host is alleen nuttig voor testen en ontwikkelen.
- Docker Swarm en gerelateerde subcommando's zoals Docker Swarm en Docker Stack zijn ingebouwd in de Docker CLI zelf. Ze maken allemaal deel uit van het Docker-binaire bestand dat u via uw terminal aanroept. Docker-Compose is een op zichzelf staand binair bestand.
Een use-case voor Docker-Compose
Zoals hierboven beschreven, zijn het beide totaal verschillende tools en elk lost een heel ander probleem op, dus het is niet alsof het een een alternatief is voor het ander. Om nieuwkomers echter een idee te geven van waar ik het over heb, is hier een use-case voor Docker Compose.
Stel dat u zelf een WordPress-blog wilt hosten op een enkele server. Het instellen of onderhouden ervan is niet iets dat u handmatig wilt doen, dus wat u in plaats daarvan zou doen, is Docker en Docker-compose op uw VPS installeren, een eenvoudig YAML-bestand maken dat alle verschillende aspecten van uw WordPress-stack definieert, zoals hieronder, :
Opmerking: als je het onderstaande gebruikt om een WordPress-site te implementeren, verander dan alle wachtwoorden in iets veiligs. Beter nog, gebruik Docker Secrets om gevoelige gegevens zoals wachtwoorden op te slaan, in plaats van deze in een gewoon tekstbestand te hebben.
versie:'3'Diensten:
db:
afbeelding: mysql:5.7
volumes:
- db_data:/waar/lib/mysql
herstart: altijd
omgeving:
MYSQL_ROOT_PASSWORD: een of andere wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
hangt af van:
- db
afbeelding: wordpress:laatste
poorten:
-'8000: 80'
herstart: altijd
omgeving:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpressWachtwoord
WORDPRESS_DB_NAME: wordpress
volumes:
db_data:{}
Nadat het bestand is gemaakt en zowel Docker als Docker-compose zijn geïnstalleerd, hoeft u alleen maar het volgende uit te voeren:
$docker-compose up-NSEn je site is in de lucht. Als er een update is, voer dan uit:
$docker-compose downGooi vervolgens de oude Docker-afbeeldingen weg en voer de opdracht docker-compose up -d uit en nieuwe afbeeldingen worden automatisch binnengehaald. Aangezien u de permanente gegevens hebt opgeslagen in een Docker-volume, gaat de inhoud van uw website niet verloren.
Wanneer Docker Swarm gebruiken?
Terwijl Docker-compose meer een automatiseringstool is, is Docker Swarm bedoeld voor meer veeleisende toepassingen. Web-apps met honderden of duizenden gebruikers of werklast die parallel moet worden geschaald. Bedrijven met een groot aantal gebruikers en strenge SLA-vereisten zouden een gedistribueerd systeem zoals Docker Swarm willen gebruiken. Als uw app op meerdere servers en meerdere datacenters draait, wordt de kans op downtime als gevolg van een getroffen DC- of netwerkverbinding aanzienlijk verminderd.
Dat gezegd hebbende, aarzel ik om Docker Swarm aan te bevelen voor productietoepassingen, omdat concurrerende technologieën zoals Kubernetes aantoonbaar beter geschikt zijn voor deze taak. Kubernetes wordt standaard ondersteund door veel cloudproviders en het werkt redelijk goed met Docker Containers, dus je hoeft je app niet eens opnieuw te bouwen om te profiteren van Kubernetes.
Conclusie
Ik hoop dat dit geklets over Docker en zijn satellietprojecten informatief was en dat je beter voorbereid bent op het docker-ecosysteem.