Hvis du har containeriseret din udviklingsarbejdsgang, er du enig i, at Docker er et af de bedste valg til versionskontrol. Docker Swarm er dog en af Dockers funktioner, der bruges til at orkestrere komplekse apps.
Docker Swarm-arbejdsmekanismen kan være svær at knække i starten. Men ingen bekymringer, vi vil opdele det i denne artikel. Så hvad er Docker Swarm? Hvorfor bruge det? Og hvordan virker det?
Hvad er Docker Swarm, og hvordan virker det?
Docker Swarm refererer til en gruppe Docker-værter (computere), der er netværket som en klynge for at levere specificerede opgaver. Hver Docker-vært i denne klynge er en node, også kaldet en arbejdsknude.
For at sikre en effektiv fordeling af opgaver har du brug for en ledernode. Ideelt set starter en Docker Swarm-tilstand initialisering med managerknuden, og efterfølgende noder bliver arbejdere.
Som operatør behøver du kun at interagere med managerknudepunktet, som sender instruktioner til arbejderne. Uvægerligt modtager arbejderknudepunkterne opgaveallokering fra lederknudepunktet og udfører dem i overensstemmelse hermed.
Lederknudepunktet kan dog også deltage i opgaveudførelsen (som arbejder) eller stå over for ledelsen helt. Du kan forhindre opgaveplanlægning på manageren ved at skifte dens tilstand fra aktiv til dræne. Men din beslutning om at tildele denne dobbelte funktion kan afhænge af flere faktorer. Grundlæggende vil du være sikker på, at den har nok ressourcer til at håndtere flere roller, før du gør det.
Noder fejler. Så managerknudepunktet overvåger aktivt tilstanden for hver arbejderknude og aktiverer en fejltolerant mekanisme for at omplanlægge opgaven fra en fejlknude til en anden.
Men hvad nu hvis managernoden også går ned? Interessant nok bliver sværmen ved med at løbe. Den eneste faldgrube er, at du ikke længere vil være i stand til at kommunikere med managernoden for at kontrollere klyngen.
Den almindelige fejlsikre tilgang til at forhindre dette er at tildele managerrollen til mange noder (Docker anbefaler maksimalt syv pr. klynge). Du kan derefter vælge den primære managerknude blandt dem. Når den primære leder går ned, overtager en af standby-cheferne rollen.
Du behøver dog ikke bekymre dig om rolleskift mellem noder eller tilstandsvedligeholdelse i en klynge. Raft-konsensusalgoritmen (en fejltolerant metode) indbygget i Docker SwarmKit tager sig af dette.
Hvorfor bruge Docker Swarm?
Docker Swarm er praktisk til at implementere komplekse apps med høje skalerbarhedsmuligheder. Et af dets primære brugssager er at decentralisere mikrotjenester. Hver mikrotjeneste deler derefter en lignende beholder med dem på andre arbejderknudepunkter.
En anden grund til at bruge Docker Swarm er, at flere værter kører opgaver samtidigt i en klynge. Dette er i modsætning til Docker Compose, som kun giver dig mulighed for at køre flere containere på én Docker-motor.
Denne skalerbare egenskab ved Docker Swarm gør det muligt for apps at være konsekvent tilgængelige med nul latency. Det er endda en af grundene til, at du gerne vil vælg Docker frem for andre virtualiseringsværktøjer.
Og hvad er mere? I modsætning til enkelte Docker-containere, hvor en container stopper, når den fejler, omfordeler Docker Swarm automatisk opgaver blandt de tilgængelige arbejderknudepunkter, når en fejler.
Docker Swarm holder også en sikkerhedskopi af hver stat. Så du kan altid vende nye sværmkonfigurationer tilbage til en tidligere tilstand. Sig, at managerknudepunktet på en tidligere sværm mislykkes; du kan starte en ny klynge med flere managerknudepunkter og vende den tilbage for at tilpasse konfigurationen af den forrige.
Det er også vigtigt at nævne, at interaktionen mellem lederknudepunktet og arbejderknudepunktet er sikkert.
Docker har mange alternativer, og en af de nærmeste er Kubernetes. Docker Swarm er dog nem at bruge og mere automatiseret. For eksempel, mens du muligvis skal balancere belastning manuelt i nogle andre orkestreringsværktøjer som Kubernetes, har Docker Swarm automatisk belastningsbalancering, som gør livet nemt for DevOps.
Docker Swarm Architecture
Docker Swarm-arkitekturen kredser om tjenester, noder og opgaver. Men hver har en rolle at spille i at køre stablen med succes.
Tjenester
Docker Swarm-tjenesten beskriver konfigurationen af Docker-billedet, der kører alle containere i en sværm. Den indeholder information om opgaverne i en klynge. For eksempel kan en tjeneste beskrive en Dockeriseret SQL-serveropsætning.
Når du kører en tjeneste, tvinger den managernoden til at synkronisere med dens konfigurationer. Managerknudepunktet kører derefter resten af arbejderknudepunkterne baseret på de angivne indstillinger i tjenesten.
Tjenester i Docker Swarm kan være globale eller kopierede.
Forskellen mellem dem er, at mens globale tjenester kun definerer én opgave for alle noder i en klynge, specificerer replikerede tjenester antallet af opgaver pr. node.
Noder
En node i Docker Swarm er en forekomst af hele Docker-runtiden, også kendt som Docker-motoren. Swarm noder kan være fysiske eller virtuelle maskiner. Tænk på dette som et netværk af computere, der kører lignende processer (containere).
Typisk spænder noder dog over adskillige computere og servere, der kører Docker-motoren i virkelige applikationer. Og som tidligere nævnt kan en node enten være en leder- eller arbejderknude, afhængig af rollen.
Lederknudepunktet lytter til sværmens hjerteslag og styrer arbejderknudepunkterne, som udfører opgaver, som er tildelt dem af lederknudepunktet. Som tidligere nævnt kan du have mere end én managerknude i en sværm. Men ideelt set, prøv at begrænse antallet til under syv, da tilføjelse af for mange managerknudepunkter kan reducere sværmens ydeevne.
Opgaver
En opgave definerer det arbejde, der er tildelt hver node i en Docker Swarm. I baggrunden starter opgaveplanlægning i Docker Swarm, når en orkestrator opretter opgaver og sender dem til en planlægger, som instansierer en container for hver opgave.
Managerknudepunktet bruger derefter skemalæggeren til at tildele og omtildele opgaver til noder efter behov og specificeret i Docker-tjenesten.
Docker Swarm vs. Docker Compose: Hvad er forskellene?
Folk bruger ofte Docker Compose og Docker Swarm i flæng. Selvom begge involverer at køre flere containere, er de forskellige.
Mens Docker Compose lader dig køre flere containere på en enkelt vært, distribuerer Docker Swarm dem over flere Docker-motorer i en klynge.
Du bruger Docker Compose, når du skal oprette separate containere for hver tjeneste i din app. Når en komponent går ned, forstyrrer den således ikke de andre. Men når værtsmaskinen fejler, går hele appen også ned.
Docker Swarm hjælper dig dog med at køre mange containere på klyngede noder. Så hver komponent i din app sidder på flere noder. Og når en node, der håndterer en app-komponent, går ned, allokerer sværmen sin opgave til en anden node i klyngen og omplanlægger de kørende opgaver, hvilket forhindrer nedetid.
Derfor, mens du muligvis har nedetid på Docker Compose, sikrer Docker Swarm, at din app bliver ved med at køre ved hjælp af backup-servere (arbejderknudepunkter). Docker 1.13 understøtter Docker Compose-implementering til Swarm-tilstand ved hjælp af docker stack udrulning kommando.
Docker Swarm hjælper dig med at implementere komplekse apps
Containerization har overtrumfet virtuelle maskiner i kontinuerlig integration og kontinuerlig levering (CI/CD) softwaredesign. Derfor er det en fordel at forstå Docker Swarm-mekanismen, hvis du ønsker at blive en uvurderlig DevOps-ekspert.
Du ved sikkert, hvordan du opretter en Docker-container eller endda kører en Docker Compose for flere containere i én vært. Men Docker Swarm er mere praktisk til at implementere apps med kompleks arkitektur. Det opdeler processer i enheder, forbedrer runtime-adgang og reducerer eller endda eliminerer chancerne for nedetid.