Vad är det viktigaste med någon webbaserad applikation? Det finns många, men för mig hög tillgänglighet är det viktigaste. Det är vad Docker Swarm hjälper oss att uppnå! Det hjälper till att applikationen är mycket tillgänglig.
I min föregående blogg Jag förklarade hur Docker Compose fungerar. Den här bloggen på Docker Swarm är en fortsättning på den tidigare och här har fördelarna med att använda Docker Swarm för att containerisera alla applikationer med flera containrar förklarats.
I den här bloggens fall är det bara en Angular-applikation som kommer att vara Docker Swarm'ed.
Notera : Metoden för att containerisera MEAN Stack-appen är densamma.
Så, vad är Docker Swarm?
Docker svärm är en teknik för att skapa och upprätthålla ett kluster av Docker-motorer . Docker-motorerna kan vara värd på olika noder, och dessa noder som ligger på avlägsna platser bildar en Klunga när du är ansluten i svärmläge.
Varför använda Docker Swarm?
Av redan anförda skäl! Uppnå hög tillgänglighet utan stillestånd är en prioritet för varje tjänsteleverantör där ute. Kommer hög tillgänglighet att imponera på dina kunder? De kommer inte att bli imponerade om de står stilla. Det är ingen idé.
Andra fördelar med Docker Swarm
Liksom många andra tjänster gör Docker Swarm automatiskt lastbalansering för oss. Därför finns det inget behov av DevOps-ingenjörer att dirigera behandlingsförfrågningar till andra noder när en misslyckas. Klusterens chef kommer automatiskt att utföra belastningsbalansering för oss.
Decentraliserad åtkomst är en annan fördel. Vad betyder det? Det betyder att alla noder enkelt kan nås från chefen. Chefen kommer också att uppmana noderna regelbundet och hålla reda på dess hälsa / status för att klara av driftstopp. Noder kan dock inte komma åt eller spåra de tjänster som körs i andra noder / chefer.
Du kan kontrollera nej. av containrar som körs i en nod, skala upp nejet. av containrar eller skala ner nejet. baserat på vårt krav genom att bara utföra ett enda kommando.
Även efter att en applikation har distribuerats kan vi utfärda rullande uppdateringar och se till att CI (kontinuerlig integration) uppnås. Rullande uppdateringar utfärdas till en nod efter den andra, vilket säkerställer att det inte finns någon driftstopp och belastningen fördelas mellan andra noder i klustret.
Så vad nästa? Att göra det självklara. Kom igång med Docker Swarm om du redan har arbetat med Docker eller om din organisation vill behålla en pålitlig webbtjänst.
Notera : Docker-motorer installeras på oberoende värdar / servrar eller i flera virtuella datorer i en värd.
Komma igång med svärmläge
Docker Swarm initieras av chefen, eller låt mig uttrycka det så, den instans som startar Swarm-klustret blir manager. Kommandot för att starta klustret är:
$ docker svärm init --advertise-addr ip-adress
Här används flaggan ”–advertise-addr” för att annonsera sig själv för andra noder som vill gå med i klustret. IP-adressen till chefen måste anges tillsammans med flaggan. Nedan är exempel på skärmdump.
När Swarm-klustret initieras genereras en token i chefens slut. Denna token måste användas av andra noder för att gå med i svärmklustret.
Hur är det exakt? Kopiera hela token som genereras vid chefens dockermotor, klistra in den på nodens dockermotor och kör den. Den markerade delen av skärmdumpen ovan är en symbol. När token körs i en arbetarnod ser det ut som nedanstående skärmdump.
Varje nod som går med i klustret kan senare marknadsföras till en manager. Om du vill att en dockermotor ska gå med som chef, utför du kommandot nedan i chefens slut:
$ docker-svärm-token-chef
Och vid en senare tidpunkt, om du vill att token för en nod ska gå med i klustret, kör du kommandot nedan:
$ docker-svärm-token-nod
Fortsätt och kör token vid varje nod du vill, för att gå med i klustret. När allt är klart kan du köra ett dockarkodkommandolista för att kontrollera hur många noder som har gått med i klustret tillsammans med deras status. Kommandot är:
$ docker nod ls
Skärmdumpen är nedan:
Skapa en Docker-bild för vinkelapp
Om allt går bra kan vi starta vår Swarm-tjänst, förutsatt att Docker Image är byggt. Docker-bilden kan byggas från Dockerfilen. Dockerfilen som används för att bygga applikationerna är nedan:
FRÅN nod: 6 KÖR mkdir -p / usr / src / app WORKDIR / usr / src / app KOPIERA paket.json / usr / src / app KÖR npm cache ren KÖR npm installera KOPIERA. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
Dockerfilen används för att utföra en uppsättning kommandon tillsammans för att bygga en anpassad Docker-bild från en basbild. Som du kan se är basbilden jag har använt 'Nod: 6'. NodeJS är bilden I från Docker Hub som är taggad med version 6.
åsidosätta vs överbelastning c ++
Jag skapar sedan en ny Docker-katalog inuti containern och gör den till en fungerande katalog i min container.
Jag kopierar filen 'package.json' från min lokala maskin till behållarens arbetskatalog. Jag specificerar sedan kommandona 'RUN npm cache clean' och 'RUN npm install'. npm installera kommandot laddar ner den version av beroenden som nämns i filen package.json.
Jag kopierar sedan alla projektkoder från den lokala maskinen till behållaren och exponerar portnummer 4200 för åtkomst till Angular-programmet i webbläsaren och slutligen anger jag kommandot npm start som behåller applikationen.
För att skapa Docker-bilden baserat på den här Dockerfilen, kör du kommandot nedan:
$ docker build -t vinkelbild.
Notera: Docker-bilderna måste byggas i alla noder i klustret. Utan det kan containrar inte snurras i andra Docker-motorer.
Startar Docker Swarm Service
Med tanke på att vår Docker-bild är byggd kan vi snurra en container ur den här bilden. Men vi kommer att göra något bättre: skapa en Docker Swarm-tjänst ur den. Kommandot för att skapa en svärmetjänst är:
$ docker-tjänst skapa --namn 'Angular-App-Container' -p 4200: 4200 vinkelbild
Här används 'namn' -flaggan för att ge ett namn till min tjänst och 'p' -flaggan används för att exponera containerporten för värdporten. I filen package.json har jag angett behållarporten där Angular-appen ska värd. Och 4200 i det här kommandot hjälper till att kartlägga containerns port 4200 till värdens port 4200. ”vinkelbild” är namnet på bilden jag tidigare byggde.
Kom ihåg : När vi skapar en tjänst kan den vara värd på vilken som helst dockermotor i klustret. Svärmchefen bestämmer var den kommer att vara värd. Men oavsett i vilken nod det är värd kan applikationen nås på localhost: 4200 från någon av de noder som är anslutna i klustret.
Hur är det mojligt? Eftersom Swarm internt exponerar portnumren för alla andra noder i klustret. Det betyder, port nr. 4200 på valfri nod / manager i klustret skulle göra Angular-applikationen.
Nu då? Är behållaren aktiv?
Du kan verifiera om tjänsten är containeriserad genom att köra kommandot docker-servicelista. Men det kan ta en minut innan containern distribueras. Nedan är kommandot:
$ dockerservice ls
Detta kommando listar alla tjänster som hanteras av Swarm-klustret. I vårt fall ska den visa en aktiv behållare. Titta på skärmdumpen nedan för referens.
Här anger “REPLICAS = 1/1” att det finns en enda ”tjänst” för den behållaren i klustret. Och “MODE = replicated” indikerar att tjänsten replikeras på alla noder i klustret.
För att identifiera vilken nod / chef, appen är värd, kan vi köra kommandot docker-tjänsten ps-kommando följt av behållarens namn. Kommandot är:
$ dockerservice ps Angular-App-Container
Skärmdumpen för detsamma finns nedan.
Detta nämner detaljer om den nod som applikationen är värd för tillsammans med kommandot som används för att starta tjänsten.
Kommandot 'docker ps' kastar ljus över detaljerna om den aktiva behållaren. Kommandot är:
$ docker ps
Titta på skärmdumpen nedan för referens.
Men det här kommandot fungerar bara på klusterhanteraren och noden där tjänsten faktiskt är värd.
För att kontrollera hur många noder som körs, kör du kommandot nodlista. Kommandot är:
$ docker nod ls
För att kontrollera behållarna som körs i en viss värd kör du kommandot nod ps. Kommandot är:
$ docker nod ps
Om du kommer ihåg nämnde jag tidigare att tjänsten för närvarande körs i replikerat LÄGE. Detta innebär att tjänsten replikeras över alla noder i klustren. Tror du att det finns ett alternativ?
Absolut! Det finns något som kallas Global MODE. I det här läget finns en tjänst för denna container som körs på varje enskild / manager i klustret. Kom ihåg att stoppa den aktuella tjänsten / behållaren innan du spinner en annan uppsättning containrar.
Kommandot för det är:
$ dockerservice rm Angular-App-Container
Kommandot för att snurra behållaren i globalt läge är:
$ docker-tjänst skapa --namn 'Angular-App-Container' -p 4200: 4200 --läge global vinkelbild
Detta skulle skapa 3 tjänster på de 3 noderna i vårt kluster. Du kan verifiera det genom att köra kommandot docker-servicelista. Skärmdumpen av detta är nedan.
När docker-tjänsten ps-kommando körs ser du något liknande:
Som du kan se står det att läget är replikerat och replikerna för denna behållare är 3. Nu kommer den bästa delen av den här bloggen.
För att ha två repliker av tjänsterna som körs mellan de tre behållarna kan vi använda replikflaggan. Titta på kommandot nedan:
$ docker-tjänst skapa --namn 'Angular-App-Container' -p 4200: 4200 --replicas = 2 vinkelbild
Du kommer att märka att dessa två tjänster är belastningsbalanserade mellan de tre noder i klustret. Kör kommandot dockerserviceprocess för att verifiera i vilka noder behållarna är aktiva. Titta på skärmdumpen nedan för referens. Behållarna är aktiva i en chefsnod och en arbetarnod.
Från Worker-noden kan du verifiera att behållaren körs genom att utföra kommandot 'docker ps'.
Docker Swarm för hög tillgänglighet
Nu för att faktiskt verifiera att det finns hög tillgänglighet i vårt kluster, måste vi uppleva ett scenario där en av noderna går ner och andra noder i klustret kompenserar för det. Vi kan åstadkomma detta scenario genom att manuellt stoppa behållaren från en av noderna med det här kommandot:
$ docker stop Angular-App-Container
Kör kommandot ovan på noden: Worker-1 där containern körs.Från chefen kör du kommandot:
$ dockerservice ps Angular-App-Container
Du kommer nu att märka att containern nu körs i nod: Worker-2 och Manager. Det har dock stängts av från nod: Worker-1. Detsamma syns från skärmdumpen nedan.
Detta är hur Docker hög tillgänglighet är uppnådd. JagTrots att behållaren är inaktiv i Worker-1 kan applikationen återges vid portnummer 4200 på den arbetarnoden. Det beror på att den är internt ansluten till andra noder i klustret och att den kan göra applikationen i webbläsaren.
Hög tillgänglighet efter uppskalning av tjänsterna
Vare sig det är i replikerat läge eller globalt läge, vi kan skala upp antalet tjänster som körs i vårt kluster. Och även efter uppskalning kommer vi att kunna behålla hög tillgänglighet. Fantastiskt är det inte?
Men när vi kommer tillbaka till vår punkt, låt oss se hur lätt det är att skala upp antalet tjänster i vårt kluster. Om vi antar att vi har antingen 2 eller 3 repliker i vårt kluster, låt oss skala upp tjänsterna till 5 genom att bara köra ett enda kommando. Kommandot är:
$ docker-servicevåg Angular-App-Container = 5
Skärmdumpen av detta är nedan.
Genom att köra docker-servicelistan kommandot kan du märka att antalet repliker nu är 5. Och genom att köra docker-tjänsten ps-kommandot tillsammans med tjänstnamnet kan du se hur de 5 tjänsterna är belastningsbalanserade och fördelade på de 3 noderna . Kommandon är:
$ dockerservice ls $ dockerservice ps Angular-App-Container
Och slutligen, i en Docker Swarm-installation, om du inte vill att din chef ska delta i proceduren och hålla den upptagen för att bara hantera processerna, kan vi tömma chefen från att vara värd för alla applikationer. För det är så det fungerar i världen, eller hur? Cheferna är endast för att hantera andra arbetare. Hur som helst är kommandot att göra det:
$ docker-noduppdatering - tillgänglighetsavloppshanterare-1
Du kan verifiera om chefen nu deltar i klustret genom att köra kommandot docker nodlista och docker service ps kommando:
$ docker nod ls $ docker service ps Angular-App-Container
Du kan nu märka att containertjänsterna har delats upp mellan Worker-noder och att Manager-noden faktiskt har tömts från att containerisera någon tjänst. Skärmdumpen är nedan.
Så det slutar med den här bloggen på Docker Swarm. Jag hoppas att den här bloggen förklarade hur viktigt det är att implementera Swarm-läge för att uppnå hög tillgänglighet. Håll koll på fler bloggar i denna Docker-handledningsserie.
Du kan alternativt titta på videon nedan för att förstå hur Docker Swarm fungerar. Alla begrepp som förklaras ovan har beskrivits i videon.
Docker Swarm för hög tillgänglighet | Docker-handledning | DevOps handledning
Nu när du har lärt dig om Docker, kolla in av Edureka, ett pålitligt online-lärande företag med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Den här Edureka Docker Certification Training-kursen hjälper eleverna att få expertis i att implementera Docker och behärska den.
Har du en fråga till oss? Vänligen nämna det i kommentarfältet så återkommer vi till dig.