Docker Swarm voor het bereiken van hoge beschikbaarheid



Deze blog over Docker Swarm legt de kracht uit van het opzetten van een cluster van Docker-engines via geconfigureerde Docker Swarm om High Availability te bereiken.

Wat is het belangrijkste kenmerk van een webgebaseerde applicatie? Er zijn er veel, maar voor mij hoge beschikbaarheid is het belangrijkste. Dat is wat Docker Swarm ons helpt te bereiken! Het helpt bij het feit dat de applicatie zeer beschikbaar is.

In mijn vorige blog , Legde ik uit hoe Docker Compose werkt. Deze blog over Docker Swarm is een voortzetting van de vorige en hier zijn de voordelen van het gebruik van Docker Swarm voor het containeriseren van een multi-container-applicatie uitgelegd.





In het geval van deze blog is het alleen een Angular-applicatie die Docker Swarm -ed zal zijn.
Opmerking : De methode om de MEAN Stack-app in een container te plaatsen is hetzelfde.

Dus, wat is Docker Swarm?

Docker Swarm is een techniek om een ​​cluster van Docker-motoren . De Docker-engines kunnen op verschillende knooppunten worden gehost en deze knooppunten die zich op afgelegen locaties bevinden, vormen een TROS wanneer verbonden in Swarm-modus.



Waarom Docker Swarm gebruiken?

Om reeds genoemde redenen! Bereiken hoge beschikbaarheid zonder enige downtime is een prioriteit voor elke serviceprovider die er is. Zal hoge beschikbaarheid indruk maken op uw klanten? Ze zullen niet onder de indruk zijn als ze te maken krijgen met downtime. Dat is een no-brainer.

Andere voordelen van Docker Swarm

Net als veel andere services, doet Docker Swarm automatisch taakverdeling voor ons. Daarom is het voor DevOps-technici niet nodig om verwerkingsverzoeken naar andere knooppunten te routeren wanneer er een mislukt. De clusterbeheerder voert automatisch taakverdeling voor ons uit.

Gedecentraliseerde toegang is een ander voordeel. Wat betekent dat? Het betekent dat alle knooppunten gemakkelijk toegankelijk zijn vanuit de manager. De manager zal de knooppunten ook regelmatig vragen en de gezondheid / status ervan bijhouden om met downtime om te gaan. Knooppunten hebben echter geen toegang tot of kunnen de services die in andere knooppunten / managers worden uitgevoerd, niet volgen.



U kunt het nr. van containers die in een knooppunt draaien, vergroot de nee. van containers of verkleinen de nee. op basis van onze vereisten, door slechts een enkele opdracht uit te voeren.

Zelfs nadat een applicatie is geïmplementeerd, kunnen we uitgeven rollende updates en zorg ervoor dat CI (Continuous Integration) wordt bereikt. Rollende updates worden naar het ene knooppunt na het andere verzonden, zodat er geen downtime is en de belasting wordt verdeeld over andere knooppunten in het cluster.

Dus wat is het volgende? Om het voor de hand liggende te doen. Ga aan de slag met Docker Swarm als je al aan Docker hebt gewerkt of als je organisatie een betrouwbare webservice in containers wil opnemen.

Opmerking : Docker-engines worden geïnstalleerd op onafhankelijke hosts / servers of in meerdere VM's in een host.

Aan de slag met de zwermmodus

Docker Swarm wordt geïnitieerd door de manager, of laat ik het zo zeggen, de instantie die het Swarm-cluster start, wordt de manager. De opdracht om het cluster te starten is:

$ docker swarm init --advertise-addr ip-adres

Hier wordt de vlag ‘–advertise-addr’ gebruikt om zichzelf te adverteren voor andere knooppunten die lid willen worden van het cluster. Het IP-adres van de manager moet samen met de vlag worden opgegeven. Hieronder ziet u het voorbeeldscherm.

docker init-opdracht - docker-zwerm - edureka

Wanneer het zwermcluster wordt gestart, wordt een token gegenereerd aan het einde van de manager. Dit token moet door andere knooppunten worden gebruikt om zich bij het zwermcluster aan te sluiten.

Hoe is het precies? Kopieer het volledige token dat is gegenereerd in de docker-engine van de manager, plak het in de docker-engine van het knooppunt en voer het uit. Het gemarkeerde gedeelte van de bovenstaande schermafbeelding is een token. Wanneer het token wordt uitgevoerd op een werkknooppunt, ziet het eruit als in de onderstaande schermafbeelding.

Elk knooppunt dat zich bij het cluster voegt, kan later worden gepromoveerd tot manager. Als je wilt dat een docker-engine meedoet als manager, voer je de onderstaande opdracht uit aan het einde van de manager:

$ docker zwerm join-token manager

waar wordt data science voor gebruikt

En op een later tijdstip, als u wilt dat het token voor een knooppunt lid wordt van het cluster, voert u de onderstaande opdracht uit:

$ docker swarm join-token node

Ga je gang en voer het token uit op elk knooppunt dat je wilt, om lid te worden van het cluster. Als dat allemaal is gebeurd, kunt u een docker-knooppuntlijstopdracht uitvoeren om te controleren hoeveel knooppunten zich bij het cluster hebben aangesloten, samen met hun status. De opdracht is:

$ docker-knooppunt ls

De screenshot is hieronder:

Een Docker-afbeelding maken voor de Angular-app

Als alles goed is, kunnen we onze Swarm-service starten, op voorwaarde dat de Docker Image is gebouwd. De Docker-afbeelding kan worden gebouwd vanuit de Dockerfile. Het Dockerfile dat is gebruikt om de applicaties te bouwen, staat hieronder:

FROM node: 6 RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm cache clean RUN npm install COPY. / usr / src / app 4200 CMD EXPOSEREN ['npm', 'start']

De Dockerfile wordt gebruikt om een ​​reeks opdrachten samen uit te voeren voor het bouwen van een aangepaste Docker-image op basis van een basisimage. Zoals je kunt zien, is de basisafbeelding die ik heb gebruikt ‘Node: 6’. NodeJS is de afbeelding I van Docker Hub die is getagd met versie 6.

Ik maak dan een nieuwe Docker-map in de container en maak er de werkmap in mijn container van.

Ik kopieer het ‘package.json’ -bestand van mijn lokale computer naar de werkmap van de container. Ik specificeer dan de ‘RUN npm cache clean’ en ‘RUN npm install’ opdrachten. npm installeren commando downloadt de versie van afhankelijkheden die worden genoemd in het package.json-bestand.

Ik kopieer dan alle projectcodes van de lokale machine naar de container, waarbij poortnummer 4200 wordt weergegeven voor toegang tot de Angular-applicatie in de browser en tot slot specificeer ik de opdracht npm start die de applicatie in een container plaatst.

Om nu de Docker-image te maken op basis van dit Dockerfile, voert u de onderstaande opdracht uit:

$ docker build -t angular-image.

Opmerking: De Docker-installatiekopieën moeten in alle knooppunten in het cluster worden gebouwd. Zonder dit kunnen containers niet worden rondgedraaid in andere Docker-engines.

fibonacci iteratieve c ++

De Docker Swarm-service starten

Aangezien onze Docker-afbeelding is gebouwd, kunnen we een container uit deze afbeelding draaien. Maar we zullen iets beters doen: er een Docker Swarm-service van maken. Commando om een ​​zwermdienst te creëren is:

$ docker service create --naam 'Angular-App-Container' -p 4200: 4200 angular-image

Hier wordt de vlag ‘naam’ gebruikt om een ​​naam aan mijn service te geven en wordt de vlag ‘p’ gebruikt om de containerpoort aan de hostpoort bloot te stellen. In het package.json-bestand heb ik de containerpoort gespecificeerd waarop de Angular-app moet worden gehost. En de 4200 in deze opdracht helpt de poort 4200 van de container in kaart te brengen met poort 4200 van de host. ‘Angular-image’ is de naam van de afbeelding die ik eerder heb gemaakt.

Onthouden : Wanneer we een service maken, kan deze worden gehost op elke docker-engine in het cluster. De manager van de zwerm zal beslissen waar het zal worden gehost. Maar ongeacht in welk knooppunt het wordt gehost, de applicatie is toegankelijk op localhost: 4200 vanaf elk van de knooppunten die in het cluster zijn verbonden.

Hoe is dat mogelijk? Omdat Swarm de poortnummers intern blootstelt om toegankelijk te zijn voor elk ander knooppunt in het cluster. Dat betekent dat poort nr. 4200 op elk knooppunt / manager in het cluster zou de Angular-toepassing weergeven.

Wat nu? Is de container actief?

U kunt controleren of de service een container bevat door de opdracht docker-servicelijst uit te voeren. Maar het kan een minuut duren voordat de container is ingezet. Hieronder staat het commando:

$ docker-service ls

Met deze opdracht worden alle services weergegeven die worden beheerd door het Swarm-cluster. In ons geval zou het één actieve container moeten weergeven. Bekijk de onderstaande schermafbeelding ter referentie.

Hier geeft ‘REPLICAS = 1/1’ aan dat er één enkele ‘service’ van die container in het cluster is. En 'MODE = gerepliceerd' geeft aan dat de service wordt gerepliceerd op alle knooppunten in het cluster.

Om nu te identificeren op welke node / manager de app wordt gehost, kunnen we de opdracht docker service ps uitvoeren, gevolgd door de containernaam. De opdracht is:

$ docker-service ps Angular-App-Container

De screenshot voor hetzelfde is hieronder.

Dit vermeldt details over het knooppunt waarop de applicatie wordt gehost, samen met de opdracht die wordt gebruikt om met de service te starten.

De opdracht ‘docker ps’ werpt licht op de details van de actieve container. De opdracht is:

$ docker ps

Bekijk de onderstaande schermafbeelding ter referentie.

Maar deze opdracht werkt alleen op de clustermanager en het knooppunt waar de service daadwerkelijk wordt gehost.

Voer de opdracht knooppuntlijst uit om te controleren hoeveel knooppunten actief zijn. Commando is:

$ docker-knooppunt ls

Voer de opdracht node ps uit om de containers die op een bepaalde host draaien te controleren. Commando is:

$ docker-knooppunt ps

Als je het je herinnert, heb ik eerder gezegd dat de service momenteel wordt uitgevoerd in de gerepliceerde MODUS. Dit betekent dat de service wordt gerepliceerd over alle knooppunten in de clusters. Denk je dat er een alternatief is?

Absoluut! Er is zoiets als Global MODE. In deze modus is er een service van deze container die wordt uitgevoerd op elke afzonderlijke manager in het cluster. Vergeet niet om de huidige service / container te stoppen voordat u een andere set containers laat draaien.

Het commando daarvoor is:

$ docker-service rm Angular-App-Container

Het commando om de container te draaien in de globale modus is:

$ docker service create --naam 'Angular-App-Container' -p 4200: 4200 --mode globale angular-image

Dit zou 3 services creëren op de 3 knooppunten in ons cluster. U kunt het verifiëren door de opdracht docker-servicelijst uit te voeren. De screenshot hiervan is hieronder.

Wanneer de docker service ps-opdracht wordt uitgevoerd, ziet u zoiets als dit:

Zoals je kunt zien, staat er dat de modus wordt gerepliceerd en dat de replica's van deze container 3 zijn. Nu komt het beste deel van deze blog.

Om 2 replica's van de services tussen de drie containers te laten draaien, kunnen we de vlag replica's gebruiken. Kijk naar de onderstaande opdracht:

$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 angular-image

U zult opmerken dat deze 2 services zijn verdeeld over de drie knooppunten in het cluster. Voer de docker-serviceprocesopdracht uit om te controleren in welke knooppunten de containers actief zijn. Bekijk de onderstaande schermafbeelding ter referentie. De containers zijn actief in één beheerknooppunt en één werkknooppunt.

Vanuit het Worker-knooppunt kunt u controleren of de container wordt uitgevoerd door de opdracht ‘docker ps’ uit te voeren.

Docker Swarm voor hoge beschikbaarheid

Om nu daadwerkelijk te verifiëren dat er een hoge beschikbaarheid in ons cluster is, moeten we een scenario ervaren waarin een van de knooppunten uitvalt en andere knooppunten in het cluster dit goedmaken. We kunnen dat scenario bewerkstelligen door de container handmatig te stoppen vanaf een van de knooppunten met behulp van deze opdracht:

$ docker stop Angular-App-Container

Voer de bovenstaande opdracht uit op het knooppunt: Worker-1 waarop de container wordt uitgevoerd.Voer vanuit de manager de opdracht uit:

$ docker-service ps Angular-App-Container

Je zult nu merken dat de container nu draait in node: Worker-2 en Manager. Het is echter afgesloten vanaf knooppunt: Worker-1. Hetzelfde is zichtbaar in de onderstaande schermafbeelding.

Dit is hoe Docker hoge beschikbaarheid is bereikt. ikOndanks dat de container in Worker-1 inactief is, kan de applicatie worden weergegeven op poortnummer 4200 op dat worker-knooppunt. Dit komt doordat het intern is verbonden met andere knooppunten in het cluster en het de toepassing in de browser kan weergeven.

Hoge beschikbaarheid na opschaling van de services

Of het nu in gerepliceerde modus of globale modus is, we kunnen het aantal services dat in ons cluster wordt uitgevoerd, opschalen. En ook na schaalvergroting kunnen we hoge beschikbaarheid behouden. Geweldig is het niet?

Maar om terug te komen op ons punt, laten we eens kijken hoe gemakkelijk het is om het aantal services in ons cluster op te schalen. Ervan uitgaande dat we 2 of 3 replica's in ons cluster hebben, laten we de services opschalen naar 5 door slechts een enkele opdracht uit te voeren. De opdracht is:

$ docker-serviceschaal Angular-App-Container = 5

De screenshot hiervan is hieronder.

fibonacci in c ++

Door de docker-servicelijstopdracht uit te voeren, kunt u zien dat het aantal replica's nu 5 is. En door de docker service ps-opdracht samen met de servicenaam uit te voeren, kunt u zien hoe de 5 services worden verdeeld en verdeeld over de 3 knooppunten. . Commando's zijn:

$ docker-service ls $ docker-service ps Angular-App-Container

En tot slot, als u in een Docker Swarm-opstelling niet wilt dat uw manager deelneemt aan de procedure en hem alleen bezig houdt met het beheren van de processen, dan kunnen we de manager ontslaan van het hosten van een applicatie. Want zo werkt het in de wereld, nietwaar? De managers zijn alleen voor het beheren van andere werknemers. Hoe dan ook, het commando om dat te doen is:

$ docker node update - beschikbaarheid drain Manager-1

U kunt controleren of de manager nu deelneemt aan het cluster door de opdracht docker node list en docker service ps uit te voeren:

$ docker-knooppunt ls $ docker-service ps Angular-App-Container

U kunt nu zien dat de containerservices zijn verdeeld over Worker-knooppunten en dat het Manager-knooppunt feitelijk is afgevoerd van het containeriseren van een service. De screenshot is hieronder.

Daarmee komt dus een einde aan deze blog over Docker Swarm. Ik hoop dat deze blog heeft uitgelegd hoe belangrijk het is om de Swarm-modus te implementeren om een ​​hoge beschikbaarheid te bereiken. Blijf op de hoogte voor meer blogs in deze Docker-tutorialserie.

Je kunt ook de onderstaande video bekijken om te begrijpen hoe Docker Swarm werkt. Alle hierboven toegelichte concepten zijn in de video behandeld.

Docker Swarm voor hoge beschikbaarheid | Docker-zelfstudie | DevOps-zelfstudie

Nu je meer over Docker hebt gehoord, kun je het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. Deze Edureka Docker-certificeringstraining helpt cursisten expertise op te doen in het implementeren en beheersen van Docker.

Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte en we nemen contact met u op.