Hvad er det vigtigste ved enhver webbaseret applikation? Der er mange, men for mig høj tilgængelighed er det vigtigste. Det er, hvad Docker Swarm hjælper os med at opnå! Det hjælper med, at applikationen er meget tilgængelig.
I min forrige blog , Jeg forklarede, hvordan Docker Compose fungerer. Denne blog på Docker Swarm er en fortsættelse af den tidligere, og her er fordelene ved at bruge Docker Swarm til containerisering af enhver applikation med flere containere blevet forklaret.
I denne blogs tilfælde er det kun en Angular-applikation, der bliver Docker Swarm'ed.
Bemærk : Metoden til at containerisere MEAN Stack-appen er den samme.
Så hvad er Docker Swarm?
Docker sværm er en teknik til at skabe og vedligeholde en klynge af Docker-motorer . Docker-motorerne kan være hostet på forskellige noder, og disse noder, der befinder sig i fjerntliggende placeringer, udgør en Klynge når den er tilsluttet i sværmtilstand.
Hvorfor bruge Docker Swarm?
Af allerede nævnte grunde! At opnå høj tilgængelighed uden nedetid er en prioritet for hver tjenesteudbyder derude. Vil høj tilgængelighed imponere dine kunder? De vil ikke blive imponeret, hvis de står nedetid. Det er en no-brainer.
Andre fordele ved Docker Swarm
Ligesom mange andre tjenester gør Docker Swarm automatisk belastningsbalancering for os. Derfor er der ikke behov for DevOps-teknikere til at dirigere behandlingsanmodninger til andre noder, når en fejler. Klyngens manager udfører automatisk belastningsafbalancering for os.
Decentral adgang er en anden fordel. Hvad betyder det? Det betyder, at alle noder let kan tilgås fra manager. Lederen vil også bede knudepunkterne regelmæssigt og holde styr på dets helbred / status for at klare nedetid. Noder kan dog ikke få adgang til eller spore de tjenester, der kører i andre noder / administratorer.
Du kan kontrollere nej. af containere, der kører i en node, Skalere op nej af containere eller nedskalere nej baseret på vores krav ved blot at udføre en enkelt kommando.
Selv efter at en applikation er blevet implementeret, kan vi udstede rullende opdateringer og sørg for, at CI (kontinuerlig integration) opnås. Rullende opdateringer udstedes til den ene node efter den anden, hvilket sikrer, at der ikke er nogen nedetid, og belastningen fordeles mellem andre noder i klyngen.
Så hvad nu? At gøre det åbenlyse. Kom godt i gang med Docker Swarm, hvis du allerede har arbejdet med Docker, eller hvis din organisation ønsker at containerisere en pålidelig webservice.
Bemærk : Docker-motorer er installeret på uafhængige værter / servere eller i flere virtuelle computere i en vært.
Kom godt i gang med sværmetilstand
Docker Swarm initieres af manager, eller lad mig sige det på denne måde, den forekomst, der starter Swarm-klyngen, bliver manager. Kommandoen til at starte klyngen er:
$ docker sværm init --advertise-addr ip-adresse
Her bruges '–advertise-addr' flag til at annoncere sig selv for andre noder, der ønsker at deltage i klyngen. Managerens IP-adresse skal specificeres sammen med flagget. Nedenfor er eksemplet screenshot.
Når sværmklyngen startes, genereres et token i lederens afslutning. Dette token skal bruges af andre noder for at deltage i sværmklyngen.
Hvordan er det nøjagtigt? Kopier hele token genereret ved managerens dockermotor, indsæt det ved nodens dockermotor og udfør det. Den fremhævede del af skærmbilledet ovenfor er et symbol. Når tokenet udføres på en arbejdsknude, vil det se ud som nedenstående skærmbillede.
Enhver knude, der slutter sig til klyngen, kan senere promoveres til en manager. Hvis du vil have en dockermotor til at deltage som manager, skal du udføre nedenstående kommando i lederens afslutning:
$ docker sværm join-token manager
Og på et senere tidspunkt, hvis du ønsker, at token for en node skal deltage i klyngen, skal du køre kommandoen nedenfor:
$ docker sværm join-token node
Gå videre, og udfør tokenet ved hver node, du vil, for at deltage i klyngen. Når alt dette er gjort, kan du køre en docker-nodelistekommando for at kontrollere, hvor mange noder der er tilsluttet klyngen sammen med deres status. Kommandoen er:
$ docker node ls
Skærmbilledet er nedenfor:
Oprettelse af et dockerbillede til kantet app
Hvis alt er i orden, kan vi starte vores sværmetjeneste, forudsat at Docker Image er bygget. Docker-billedet kan bygges fra Dockerfilen. Dockerfilen, der bruges til at opbygge applikationerne, er nedenfor:
FRA knude: 6 KØR mkdir -p / usr / src / app WORKDIR / usr / src / app COPY-pakke.json / usr / src / app KØR npm cache ren KØR npm installer KOPIER. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
Dockerfilen bruges til at udføre et sæt kommandoer sammen til opbygning af et brugerdefineret Docker-billede fra et basisbillede. Som du kan se, er det grundbillede, jeg har brugt, 'Node: 6'. NodeJS er billedet I fra Docker Hub, der er mærket med version 6.
Jeg opretter derefter en ny Docker-mappe inde i containeren og gør den til den fungerende mappe inde i min container.
hvad er en java ide
Jeg kopierer filen 'package.json' fra min lokale maskine til containerens arbejdsmappe. Jeg specificerer derefter kommandoerne 'RUN npm cache clean' og 'RUN npm install'. npm installation kommando downloader den version af afhængigheder, der er nævnt i filen package.json.
Jeg kopierer derefter alle projektkoder fra den lokale maskine til containeren og udsætter portnummer 4200 for at få adgang til Angular-applikationen i browseren, og til sidst angiver jeg kommandoen npm start, der beholder applikationen.
Kør nedenstående kommando for at oprette Docker-billedet baseret på denne Dockerfil:
$ docker build -t vinkelbillede.
Bemærk: Docker-billederne skal bygges i alle noder i klyngen. Uden det kan containere ikke spindes i andre Docker-motorer.
Opret en kopi af objektet Java
Start af Docker Swarm Service
Da vores Docker-billede er bygget, kan vi dreje en container ud af dette billede. Men vi vil gøre noget bedre: Opret en Docker Swarm-tjeneste ud af den. Kommando til at oprette en sværmetjeneste er:
$ docker-tjeneste opretter --navn 'Angular-App-Container' -p 4200: 4200 vinkelbillede
Her bruges 'navn' flag til at give et navn til min tjeneste, og 'p' flag bruges til at udsætte containerporten for værtsporten. I filen package.json har jeg angivet containerporten, hvor Angular-appen skal være. Og 4200 i denne kommando hjælper med at kortlægge containerens port 4200 til værtens port 4200. 'kantet-billede' er navnet på det billede, jeg tidligere byggede.
Husk : Når vi opretter en tjeneste, kan den hostes på enhver dockermotor i klyngen. Administratoren af sværmen beslutter, hvor den skal hostes. Men uanset i hvilken node det er hostet, kan applikationen tilgås på localhost: 4200 fra en hvilken som helst af de noder, der er forbundet i klyngen.
Hvordan er det muligt? Fordi Swarm internt udsætter portnumrene for at være tilgængelige for alle andre knudepunkter i klyngen. Det betyder, port nr. 4200 på enhver node / manager i klyngen ville gengive Angular-applikationen.
Hvad nu? Er containeren aktiv?
Du kan kontrollere, om tjenesten er containeriseret ved at køre docker-servicelistekommandoen. Men det kan tage et minut for containeren at blive implementeret. Nedenfor er kommandoen:
$ docker service ls
Denne kommando viser alle de tjenester, der administreres af Swarm-klyngen. I vores tilfælde skal den vise en aktiv container. Se nedenstående skærmbillede til reference.
Her angiver 'REPLICAS = 1/1', at der er en enkelt 'service' af denne container i klyngen. Og 'MODE = replikeret' indikerer, at tjenesten replikeres på alle knudepunkterne i klyngen.
For at identificere, hvilken node / manager, appen er hostet, kan vi køre kommandodockertjeneste ps-kommando efterfulgt af containernavnet. Kommandoen er:
$ dockerservice ps Angular-App-Container
Skærmbilledet for det samme er nedenfor.
Dette nævner detaljer om den knude, som applikationen er hostet sammen med den kommando, der bruges til at starte tjenesten.
Kommandoen 'docker ps' kaster lys over detaljerne om den aktive container. Kommandoen er:
$ docker ps
Se nedenstående skærmbillede til reference.
Men denne kommando fungerer kun på klyngeadministratoren og den node, hvor tjenesten faktisk er hostet.
For at kontrollere, hvor mange noder der kører, skal du køre kommandoen node-liste. Kommandoen er:
$ docker node ls
For at kontrollere de containere, der kører i en bestemt vært, skal du køre kommandoen node ps. Kommandoen er:
$ docker node ps
Hvis du husker det, nævnte jeg tidligere, at tjenesten i øjeblikket kører i replikeret MODE. Dette betyder, at tjenesten replikeres på tværs af alle knudepunkter i klyngerne. Tror du, at der er et alternativ?
Absolut! Der er noget, der kaldes Global MODE. I denne tilstand er der en service af denne container, der kører på hver enkelt / manager i klyngen. Husk at stoppe den aktuelle service / container før du drejer et andet sæt containere.
Kommandoen til det er:
$ docker service rm Angular-App-Container
Kommandoen til at dreje containeren i global tilstand er:
$ docker-tjeneste opretter --navn 'Angular-App-Container' -p 4200: 4200 --tilstand globalt vinkelbillede
Dette ville skabe 3 tjenester på de 3 noder i vores klynge. Du kan bekræfte det ved at køre kommandoen til docker-servicelisten. Skærmbilledet af dette er nedenfor.
Når docker-service ps-kommandoen udføres, vil du se noget som dette:
Som du kan se, står der, at tilstanden er replikeret, og kopierne af denne container er 3. Nu kommer den bedste del af denne blog.
For at have to replikaer af tjenesterne, der kører mellem de tre containere, kan vi bruge replikaflagget. Se på kommandoen nedenfor:
$ docker service oprette --navn 'Angular-App-Container' -p 4200: 4200 --replicas = 2 vinkelbillede
hvordan man indstiller classpath i linux
Du vil bemærke, at disse 2 tjenester er belastningsafbalanceret mellem de tre noder i klyngen. Kør dockerserviceproceskommandoen for at kontrollere, i hvilke noder containerne er aktive. Se nedenstående skærmbillede til reference. Containerne er aktive i en managerknude og en arbejdsknudepunkt.
Fra Worker-noden kan du kontrollere, at containeren kører ved at udføre kommandoen 'docker ps'.
Docker-sværm til høj tilgængelighed
Nu for faktisk at kontrollere, at der er høj tilgængelighed i vores klynge, skal vi opleve et scenarie, hvor en af noderne går ned, og andre noder i klyngen kompenserer for det. Vi kan skabe dette scenario ved manuelt at stoppe containeren fra en af noderne ved hjælp af denne kommando:
$ docker stop Angular-App-Container
Kør ovenstående kommando på noden: Worker-1, hvor containeren kører.Fra lederen skal du køre kommandoen:
$ dockerservice ps Angular-App-Container
Du vil nu bemærke, at containeren nu kører i node: Worker-2 og Manager. Det er dog blevet lukket ned fra node: Worker-1. Det samme kan ses fra nedenstående skærmbillede.
Sådan her Docker høj tilgængelighed er opnået. jegPå trods af at containeren er inaktiv i Worker-1, kan applikationen gengives ved portnummer 4200 på den pågældende arbejdsknude. Dette skyldes, at det er internt forbundet til andre noder i klyngen, og det er i stand til at gengive applikationen i browseren.
Høj tilgængelighed efter opskalering af tjenesterne
Det være sig i replikeret tilstand eller global tilstand, vi kan skalere antallet af tjenester, der kører i vores klynge. Og selv efter opskalering vil vi være i stand til at bevare den høje tilgængelighed. Fantastisk er det ikke?
Men når vi kommer tilbage til vores pointe, lad os se, hvor let det er at skalere antallet af tjenester i vores klynge. Forudsat at vi enten har 2 eller 3 replikaer i vores klynge, lad os skalere tjenesterne op til 5 ved blot at køre en enkelt kommando. Kommandoen er:
$ docker servicevægt Angular-App-Container = 5
Skærmbilledet af dette er nedenfor.
Ved at køre docker-servicelistekommandoen kan du bemærke, at antallet af replikaer nu er 5. Og ved at køre docker-tjenesten ps-kommandoen sammen med servicenavnet kan du se, hvordan de 5 tjenester er belastningsafbalanceret og distribueret på de 3 noder . Kommandoer er:
$ docker service ls $ docker service ps Angular-App-Container
Og endelig i en Docker Swarm-opsætning, hvis du ikke vil have din manager til at deltage i proceduren og holde den optaget for kun at styre processerne, så kan vi dræne manager fra at være vært for enhver applikation. Fordi det er sådan, det fungerer i verden, er det ikke? Lederne er kun til at styre andre arbejdere. Under alle omstændigheder er kommandoen til at gøre det:
$ docker node opdatering --tilgængelighed afløb Manager-1
Du kan kontrollere, om administratoren nu deltager i klyngen ved at køre kommandoen til docker-nodelisten og kommandoen til docker-service ps:
$ docker node ls $ docker service ps Angular-App-Container
Du kan nu bemærke, at containertjenesterne er blevet opdelt mellem Worker-noder, og at Manager-noden faktisk er drænet fra containerisering af enhver tjeneste. Skærmbilledet er nedenfor.
Så det bringer en stopper for denne blog på Docker Swarm. Jeg håber, at denne blog forklarede, hvor vigtigt det er at implementere Swarm-tilstand for at opnå høj tilgængelighed. Hold øje med flere blogs i denne Docker-tutorial-serie.
Du kan alternativt se videoen nedenfor for at forstå, hvordan Docker Swarm fungerer. Alle de begreber, der er forklaret ovenfor, er blevet dækket i videoen.
Docker-sværm til høj tilgængelighed | Docker-vejledning | DevOps-vejledning
Nu hvor du har lært om Docker, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Dette Edureka Docker-certificeringskursus hjælper eleverne med at få ekspertise i implementering af Docker og mestring af det.
Har du et spørgsmål til os? Nævn det i kommentarfeltet, og vi vender tilbage til dig.