Docker Swarm for å oppnå høy tilgjengelighet



Denne bloggen på Docker Swarm forklarer kraften i å sette opp en klynge med Docker-motorer via konfigurert Docker Swarm for å oppnå høy tilgjengelighet.

Hva er den viktigste funksjonen i ethvert nettbasert program? Det er mange, men for meg høy tilgjengelighet er det viktigste. Det er det Docker Swarm hjelper oss med å oppnå! Det hjelper i at applikasjonen er veldig tilgjengelig.

I min forrige blogg , Jeg forklarte hvordan Docker Compose fungerer. Denne bloggen på Docker Swarm er en fortsettelse av den tidligere, og her er fordelene ved å bruke Docker Swarm for containerisering av applikasjoner med flere containere blitt forklart.





I tilfellet til denne bloggen er det bare en Angular-applikasjon som vil bli Docker Swarm’ed.
Merk : Metoden for å containerisere MEAN Stack-appen er den samme.

Så, hva er Docker Swarm?

Docker sverm er en teknikk for å skape og opprettholde en klynge av Docker-motorer . Docker-motorene kan være vert på forskjellige noder, og disse noder som er på avsidesliggende steder danner en Klynge når du er koblet til i svermmodus.



Hvorfor bruke Docker Swarm?

Av allerede nevnte grunner! Å oppnå høy tilgjengelighet uten nedetid er en prioritet for alle tjenesteleverandører der ute. Vil høy tilgjengelighet imponere kundene dine? De vil ikke bli imponert hvis de møter nedetid. Det er en no-brainer.

Andre fordeler med Docker Swarm

Som mange andre tjenester, gjør Docker Swarm automatisk lastbalansering for oss. Derfor er det ikke behov for DevOps-ingeniører å rutebehandle forespørsler til andre noder når en mislykkes. Klyngens leder utfører automatisk lastbalansering for oss.

Desentralisert tilgang er en annen fordel. Hva betyr det? Det betyr at alle noder er lett tilgjengelige fra lederen. Lederen vil også be nodene regelmessig og holde oversikt over helsen / statusen for å takle nedetid. Imidlertid kan noder ikke få tilgang til eller spore tjenestene som kjører i andre noder / ledere.



Du kan sjekke nei. av containere som kjører i en node, oppskalering nei. av containere eller nedskalere nei. basert på vårt krav, ved å bare utføre en enkelt kommando.

Selv etter at en applikasjon er distribuert, kan vi utstede rullende oppdateringer og sørg for at CI (kontinuerlig integrasjon) oppnås. Rullende oppdateringer utstedes til den ene noden etter den andre, og sørger dermed for at det ikke er nedetid og belastningen fordeles mellom andre noder i klyngen.

Så hva neste? Å gjøre det åpenbare. Kom i gang med Docker Swarm hvis du allerede har jobbet med Docker eller hvis organisasjonen din ønsker å containerisere en pålitelig webtjeneste.

Merk : Docker-motorer er installert på uavhengige verter / servere eller i flere virtuelle maskiner i en vert.

Linux-systemadministratorroller og ansvar

Komme i gang med svermmodus

Docker Swarm er initiert av lederen, eller la meg si det slik, forekomsten som starter Swarm-klyngen blir manager. Kommandoen for å starte klyngen er:

$ docker sverm init --advertise-addr ip-adresse

Her brukes flagget ‘–advertise-addr’ for å annonsere seg selv for andre noder som vil bli med i klyngen. IP-adressen til manager må spesifiseres sammen med flagget. Nedenfor er eksemplet på skjermbildet.

docker init kommando - docker sverm - edureka

Når svermeklyngen er startet, genereres et token ved lederens slutt. Dette tokenet må brukes av andre noder for å bli med i svermeklyngen.

Hvordan er det akkurat? Kopier hele tokenet som genereres ved managerens dockermotor, lim det inn i nodeens dockermotor og kjør det. Den fremhevede delen av skjermbildet ovenfor er et token. Når tokenet kjøres på en arbeiderknute, vil det se ut som skjermbildet nedenfor.

Enhver node som blir med i klyngen kan senere promoteres til en manager. Hvis du vil at en dockermotor skal bli med som leder, utfører du kommandoen nedenfor på lederens slutt:

$ docker sverm-token-manager

Og på et senere tidspunkt, hvis du vil at token for en node skal bli med i klyngen, kjører du kommandoen nedenfor:

$ docker sverm-token-node

Gå videre, og kjør tokenet på hver node du vil, for å bli med i klyngen. Når alt dette er gjort, kan du kjøre en docker-nodeliste-kommando for å sjekke hvor mange noder som har blitt med i klyngen sammen med statusen. Kommandoen er:

$ docker node ls

Skjermbildet er nedenfor:

Opprette et Docker-bilde for vinkelapp

Hvis alt er bra, kan vi starte Swarm-tjenesten vår, forutsatt at Docker Image er bygget. Docker-bildet kan bygges fra Dockerfile. Dockerfilen som ble brukt til å bygge applikasjonene er nedenfor:

FRA node: 6 KJØR mkdir -p / usr / src / app WORKDIR / usr / src / app KOPIER pakke.json / usr / src / app KJØR npm cache ren KJØR npm installer KOPIER. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']

Dockerfilen brukes til å utføre et sett med kommandoer sammen for å bygge et tilpasset Docker-bilde fra et basisbilde. Som du kan se, er grunnbildet jeg har brukt ‘Node: 6’. NodeJS er bildet jeg fra Docker Hub som er merket med versjon 6.

Jeg oppretter da en ny Docker-katalog inne i containeren og gjør den til arbeidskatalogen i containeren min.

Jeg kopierer filen ‘package.json’ fra min lokale maskin til containerens arbeidskatalog. Jeg spesifiserer deretter kommandoene 'RUN npm cache clean' og 'RUN npm install'. npm installere kommandoen laster ned versjonen av avhengigheter som er nevnt i filen package.json.

Jeg kopierer deretter alle prosjektkodene fra den lokale maskinen til containeren, og eksponerer portnummer 4200 for tilgang til Angular-applikasjonen i nettleseren, og til slutt spesifiserer jeg kommandoen npm start som beholder applikasjonen.

For å opprette Docker-bildet basert på denne Dockerfilen, kjør kommandoen nedenfor:

$ docker build -t vinkelbilde.

Merk: Docker-bildene må bygges i alle nodene i klyngen. Uten den kan ikke containere spinnes i andre Docker-motorer.

Starter Docker Swarm Service

Gitt at Docker Image vårt er bygget, kan vi spinne en container ut av dette bildet. Men vi vil gjøre noe bedre: lage en Docker Swarm-tjeneste ut av den. Kommandoen for å opprette en svermetjeneste er:

$ docker-tjeneste oppretter --navn 'Angular-App-Container' -p 4200: 4200 vinkelbilde

Her brukes ‘navn’ -flagget til å gi et navn til tjenesten min og ‘p’ -flagget brukes til å eksponere containerporten for vertsporten. I package.json-filen har jeg spesifisert containerporten som Angular-appen skal være vert for. Og 4200 i denne kommandoen hjelper til med å kartlegge containerens port 4200 til vertsport 4200. ‘vinkelbilde’ er navnet på bildet jeg tidligere bygde.

Huske : Når vi oppretter en tjeneste, kan den være vert på hvilken som helst dockermotor i klyngen. Lederen for svermen vil bestemme hvor den skal være vert. Men uansett i hvilken node det er vert, kan du få tilgang til applikasjonen på localhost: 4200 fra hvilken som helst av nodene som er koblet til i klyngen.

Hvordan er det mulig? Fordi Swarm internt utsetter portnumrene for å være tilgjengelig for alle andre noder i klyngen. Det betyr at port nr. 4200 på en hvilken som helst node / manager i klyngen ville gjengi Angular-applikasjonen.

Hva nå? Er beholderen aktiv?

Du kan bekrefte om tjenesten er containerisert ved å kjøre docker-tjenestelistekommandoen. Men det kan ta et minutt før containeren blir utplassert. Nedenfor er kommandoen:

$ docker-tjeneste ls

Denne kommandoen vil liste opp alle tjenestene som administreres av Swarm-klyngen. I vårt tilfelle skal den vise en aktiv container. Se på skjermbildet nedenfor for referanse.

Her indikerer “REPLICAS = 1/1” at det er en enkelt ‘tjeneste’ av den containeren, i klyngen. Og “MODE = replikert” indikerer at tjenesten replikeres på alle nodene i klyngen.

Nå, for å identifisere hvilken node / manager, appen er vert, kan vi kjøre kommandodokkertjeneste ps-kommando etterfulgt av containernavnet. Kommandoen er:

$ docker-tjeneste ps Angular-App-Container

Skjermbildet for det samme er nedenfor.

Dette nevner detaljer om noden applikasjonen er vert for sammen med kommandoen som ble brukt til å starte tjenesten.

Kommandoen ‘docker ps’ kaster lys over detaljene om den aktive beholderen. Kommandoen er:

$ docker ps

Se på skjermbildet nedenfor for referanse.

Men denne kommandoen fungerer bare på klyngebehandleren og noden der tjenesten faktisk er vert.

For å sjekke hvor mange noder som kjører, kjør kommandoen nodeliste. Kommandoen er:

$ docker node ls

For å sjekke beholderne som kjører i en bestemt vert, kjør kommandoen node ps. Kommandoen er:

$ docker node ps

Hvis du husker det, nevnte jeg tidligere at tjenesten for tiden kjører i replikert MODE. Dette betyr at tjenesten replikeres på tvers av alle noder i klyngene. Tror du det er et alternativ?

Absolutt! Det er noe som kalles Global MODE. I denne modusen er det en tjeneste for denne containeren som kjører på hver enkelt / manager i klyngen. Husk å stoppe den nåværende tjenesten / beholderen før du spinner et annet sett med containere.

Kommandoen for det er:

$ docker service rm Angular-App-Container

Kommandoen for å spinne beholderen i global modus er:

$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --modus globalt vinkelbilde

Dette vil skape 3 tjenester på de 3 nodene i klyngen vår. Du kan bekrefte det ved å kjøre docker-tjenestelistekommandoen. Skjermbildet av dette er nedenfor.

Når kommandoen for docker-tjenesten ps kjøres, ser du noe sånt som dette:

Som du kan se, står det at modusen er replikert og kopiene til denne beholderen er 3. Nå kommer den beste delen av denne bloggen.

For å ha to kopier av tjenestene som kjører mellom de tre containerne, kan vi bruke replikaflagget. Se på kommandoen nedenfor:

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

Du vil merke at disse to tjenestene er lastbalansert mellom de tre nodene i klyngen. Kjør docker-serviceprosesskommandoen for å bekrefte i hvilke noder containerne er aktive. Se på skjermbildet nedenfor for referanse. Containerne er aktive i en ledernode og en arbeiderknute.

Fra Worker-noden kan du bekrefte at containeren kjører ved å utføre kommandoen ‘docker ps’.

Docker Swarm for høy tilgjengelighet

Nå for å faktisk verifisere at det er høy tilgjengelighet i klyngen vår, må vi oppleve et scenario der en av nodene går ned og andre noder i klyngen gjør opp for det. Vi kan få til dette scenariet ved å stoppe beholderen manuelt fra en av nodene ved hjelp av denne kommandoen:

$ docker stopp Angular-App-Container

Kjør kommandoen ovenfor på noden: Arbeider-1 der containeren kjører.Kjør kommandoen fra lederen:

$ docker-tjeneste ps Angular-App-Container

Du vil nå legge merke til at containeren nå kjører i node: Worker-2 og Manager. Imidlertid har den blitt stengt fra node: Worker-1. Det samme er synlig fra skjermbildet nedenfor.

Dette er hvordan Docker høy tilgjengelighet er oppnådd. JegTil tross for at beholderen er inaktiv i Worker-1, kan applikasjonen gjengis ved portnummer 4200 på den arbeidernoden. Dette er fordi den er koblet internt til andre noder i klyngen, og den kan gjengi applikasjonen i nettleseren.

Høy tilgjengelighet etter oppskalering av tjenestene

Det være seg i replikert modus eller global modus, vi kan skalere opp antall tjenester som kjører i klyngen vår. Og selv etter oppskalering vil vi kunne beholde høy tilgjengelighet. Fantastisk er det ikke?

ruby on rails webapplikasjon

Men når vi kommer tilbake til poenget vårt, la oss se hvor enkelt det er å skalere opp antallet tjenester i klyngen vår. Forutsatt at vi har enten 2 eller 3 kopier i klyngen, la oss skalere opp tjenestene til 5 ved å bare kjøre en enkelt kommando. Kommandoen er:

$ docker serviceskala Angular-App-Container = 5

Skjermbildet av dette er nedenfor.

Ved å kjøre docker-tjenestelistekommandoen, kan du merke at antall replikaer nå er 5. Og ved å kjøre docker-tjenesten ps-kommandoen sammen med tjenestenavnet, kan du se hvordan de 5 tjenestene er lastbalansert og distribuert på de 3 nodene . Kommandoer er:

$ dockertjeneste ls $ dockertjeneste ps Angular-App-Container

Og til slutt, i et Docker Swarm-oppsett, hvis du ikke vil at lederen din skal delta i prosedyrene og holde den opptatt for bare å administrere prosessene, kan vi tømme lederen fra å være vert for ethvert program. For det er slik det fungerer i verden, ikke sant? Lederne er bare for å administrere andre arbeidere. Uansett er kommandoen for å gjøre det:

$ docker node oppdatering - tilgjengelighetsavløp Manager-1

Du kan bekrefte om lederen nå deltar i klyngen ved å kjøre docker-nodelistekommandoen og docker-tjenesten ps-kommando:

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

Du kan nå legge merke til at containertjenestene er delt mellom arbeidernoder og at Manager-noden faktisk har blitt tømt for å containerisere enhver tjeneste. Skjermbildet er nedenfor.

Så det slutter med denne bloggen på Docker Swarm. Jeg håper denne bloggen forklarte hvor viktig det er å implementere svermmodus for å oppnå høy tilgjengelighet. Følg med for flere blogger i denne Docker-opplæringsserien.

Du kan alternativt se videoen nedenfor for å forstå hvordan Docker Swarm fungerer. Alle konseptene som er forklart ovenfor er dekket i videoen.

Docker Swarm for høy tilgjengelighet | Docker-veiledning | DevOps-veiledning

Nå som du har lært om Docker, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Dette Edureka Docker-sertifiseringskurset hjelper elever å få ekspertise i å implementere Docker og mestre det.

Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.