Denne vejledning introducerer Java-udviklere til Docker Swarm. Du lærer, hvorfor så mange virksomhedsbutikker har vedtaget containeradministreret udvikling via Docker, og hvorfor klyngedannelse er en vigtig teknik til at arbejde med Docker-containere. Du finder også ud af, hvordan to populære Docker-klyngeteknologier - Amazon ECS og Docker Swarm - sammenligner, og få en hurtig guide til at vælge den rigtige løsning til din butik eller dit projekt. Selvstudiet afsluttes med en praktisk demonstration af, hvordan du bruger Docker Swarm til at udvikle og administrere en to-node-virksomhedsklynge.
Læs nu: Containerstyret udvikling med Docker
Det er en god ide at være fortrolig med containeradministreret udvikling og Docker-grundlæggende, inden du dykker ned i Docker Swarm. Der er en oversigt nedenfor, men se min introduktion til Docker for en mere dybtgående diskussion. Udviklere, der er fortrolige med disse grundlæggende, skal springe til næste afsnit.
Hvad er aftalen med Docker?
Docker er en åben platform til bygning, forsendelse og kørsel af distribuerede applikationer. Dockeriserede applikationer kan køre lokalt på en udviklers maskine, og de kan distribueres til produktion på tværs af en skybaseret infrastruktur. Docker egner sig til hurtig udvikling og muliggør kontinuerlig integration og kontinuerlig implementering som næsten ingen anden teknologi gør. På grund af disse funktioner er det en platform, som enhver udvikler skal vide, hvordan man bruger.
Det er vigtigt at forstå, at Docker er en containerisering teknologi, ikke en virtualisering teknologi. Mens en virtuel maskine indeholder et komplet operativsystem og styres af en tungvægtsproces kaldet en hypervisor, er en container designet til at være meget let og selvstændig. Hver server kører en dæmonproces kaldet en Docker-motor, der kører containere og oversætter operativsystemopkald inde i containeren til native-opkald på værtsoperativsystemet. En container, der er analog med en virtuel maskine, kun meget mindre, er vært for din applikation, runtime-miljø og et barebones-operativsystem. Containere kører typisk på virtuelle maskiner. Mens en virtuel maskine kan tage minutter at starte, kan en container gøre det på få sekunder.
Figur 1 illustrerer forskellen mellem en container og en virtuel maskine.
Docker-containere er selvstændige, hvilket betyder, at de inkluderer alt, hvad de har brug for til at køre din applikation. For eksempel for en webapplikation, der kører i Tomcat, vil containeren omfatte:
- En krigsfil
- Tomcat
- JVM
- Basisoperativsystemet
Figur 2 viser arkitekturen for en webapp inde i en Docker-container.
I tilfælde af Docker kører hver virtuel maskine en dæmonproces kaldet Docker-motor. Du bygger din applikation, såsom din WAR-fil, og opretter derefter en tilsvarende Dockerfil. En Dockerfile er en tekstfil, der beskriver, hvordan man bygger en Docker-billede, som er en binær fil, der indeholder alt, hvad der er nødvendigt for at køre applikationen. Som et eksempel kan du oprette en Dockerfile fra et Tomcat-basisbillede, der indeholder et base Linux OS, Java runtime og Tomcat. Efter at have bedt Docker om at kopiere en WAR-fil til Tomcats webapps-mappe, ville Dockerfile blive samlet til et Docker-billede bestående af base OS, JVM, Tomcat og din WAR-fil. Du kan køre Docker-billedet lokalt, men du vil i sidste ende offentliggøre det til en Docker-lager, ligesom DockerHub.
Mens et Docker-billede er en binær version af din container, kaldes en runtime-forekomst af et Docker-billede en Docker-container. Docker-containere drives af din Docker-motor. Maskinen, der kører din Docker-motor, kaldes Docker vært; dette kan være din lokale bærbare computer eller en skyplatform, afhængigt af omfanget af din applikation.
Grundlæggende i dette afsnit giver et fundament for at forstå, hvorfor klyngedannelse er en vigtig tilføjelse til dit Docker-værktøjssæt. Se min introduktion til Docker for mere.
Clustering Docker
De fleste udviklere, der kommer i gang med Docker, bygger en Dockerfil og kører den lokalt på en bærbar computer. Men der er mere ved containeradministreret udvikling end at køre individuelle Docker-containere lokalt. Dockers supermagt er dens evne til dynamisk at skalere containere op eller ned. I produktion betyder det at køre Docker i en klynge på tværs af en række maskiner eller virtuelle maskiner.
Forskellige Docker-klyngeteknologier er tilgængelige, men de to mest populære er Amazon EC2 Container Service (ECS) og Docker Swarm.
Amazon ECS
Amazons Docker-klyngeteknologi udnytter Amazon Web Services (AWS) til at oprette en klynge af virtuelle maskiner, der kan køre Docker-containere. En ECS-klynge består af managed ECS-forekomster, som er EC2-forekomster med en Docker-motor og en ECS-agent. ECS bruger en autoskaleringsgruppe til at udvide og indgå antallet af forekomster baseret på CloudWatch-politikker. For eksempel, når den gennemsnitlige CPU-brug af ECS-forekomsterne er for høj, kan du bede ECS om at starte flere forekomster op til det maksimale antal forekomster, der er defineret i gruppen til automatisk skalering.
Docker-containere administreres af en ECS-tjeneste og konfigureret af mængden af computerkapacitet (CPU) og RAM, som containeren har brug for at køre. ECS-tjenesten har en tilknyttet Elastic Load Balancer (ELB). Da det starter og stopper Docker-containere, registrerer og afregistrerer ECS-tjenesten disse containere hos ELB. Når du har oprettet reglerne for din klynge, sikrer Amazon ECS, at du har det ønskede antal containere, der kører, og at disse containere alle er tilgængelige via ELB. Figur 3 viser et højt billede af Amazon ECS.
Det er vigtigt at skelne mellem ECS tilfælde og opgaver. ECS-klyngen administrerer dine ECS-forekomster, som er specielle EC2-forekomster, der kører i en automatisk skaleringsgruppe. ECS-tjenesten administrerer opgaverne, som kan indeholde en eller flere Docker-containere, og som kører på klyngen. En ELB sidder foran ECS-forekomsterne, der kører dine Docker-containere og distribuerer belastning til dine Docker-containere. Forholdet mellem ECS-opgaver og Docker-containere er, at en opgavedefinition fortæller ECS-tjenesten, hvilke Docker-containere der skal køres, og konfigurationen af disse containere. ECS-tjenesten kører opgaven, som starter Docker-containerne.
Se min introduktion til Amazon ECS på VMTurbo.com.
Docker sværm
Dockers oprindelige klyngeteknologi, Docker Swarm, giver dig mulighed for at køre flere Docker-containere på tværs af en klynge af virtuelle maskiner. Docker Swarm definerer en Manager container, der kører på en virtuel maskine, der administrerer miljøet, distribuerer containere til de forskellige agenter og rapporterer containerstatus og implementeringsoplysninger til klyngen.
Når du kører en Docker-sværm, er manager den primære grænseflade til Docker. Agenter er "dockermaskiner", der kører på virtuelle maskiner, der registrerer sig hos manager og kører Docker-containere. Når klienten sender en anmodning til manager om at starte en container, finder manager en tilgængelig agent til at køre den. Det bruger en mindst anvendt algoritme for at sikre, at den agent, der kører det mindste antal containere, kører den nyligt anmodede container. Figur 4 viser en eksempel på en Docker Swarm-konfiguration, som du vil udvikle i næste afsnit.
Manager-processen kender til alle de aktive agenter og containerne, der kører på disse agenter. Når agentens virtuelle maskiner starter, registrerer de sig hos manager og er derefter tilgængelige til at køre Docker-containere. Eksemplet i figur 4 har to agenter (Agent1 og Agent2), der er registreret hos manager. Hver agent kører to Nginx-containere.
Docker Swarm vs Amazon ECS
Denne artikel indeholder Docker Swarm, men det er nyttigt at sammenligne containerteknologier. Mens Amazon ECS tilbyder en veludviklet nøglefærdig løsning, giver Docker Swarm dig friheden til at konfigurere mere af din egen infrastruktur. Som et eksempel administrerer Amazon ECS både containere og load balancers, mens du i Docker Swarm konfigurerer en load balancing-løsning såsom Cisco LocalDirector, F5 BigIp eller en Apache- eller Nginx-softwareproces.
Hvis du allerede kører din app i AWS, gør ECS det meget nemmere at køre og administrere Docker-containere end en ekstern løsning ville. Som AWS-udvikler udnytter du sandsynligvis allerede autoskalering af grupper, ELB'er, virtuelle private skyer (VPC), identitets- og adgangsstyringsroller (IAM) og politikker osv. ECS integreres godt med dem alle, så det er vejen at gå. Men hvis du ikke kører i AWS, gør Docker Swarms stramme integration med Docker-værktøjerne det til et godt valg.
AWS og Docker Swarm i hybridskyen
Amazon Web Services kan konfigureres til meget høj tilgængelighed, skalerbarhed og ydeevne, hvilket sandsynligvis er grunden til, at det servicerer 25% af al internettrafik, inklusive den massivt skalerede Netflix-tjenesterinfrastruktur. For nylig har der imidlertid været et skub mod hybrid cloud-miljøer. EN hybrid sky er en sky, hvor en del af applikationen eller undertiden en fuld kopi af den kører i en offentlig sky som AWS, og en del af den kører i en privat sky. En populær mulighed i dette tilfælde er at køre OpenStack i et privat datacenter.
En hybrid sky er en sikker strategi for et firma, der flytter nogle eller alle operationer til skyen, men har brug for at gå langsomt og få tillid til offentlige skyer. Når du vælger en hybrid cloud-mulighed, skal du oprette et abstraktionslag oven på de underliggende skyteknologier, hvilket betyder, at du lige så let kan implementere til Docker Swarm, der kører på OpenStack i dit eget datacenter, som du kan til ECS, der kører på AWS . Værktøjer som Chef og Puppet kan hjælpe ved at lade dig definere dine miljøer abstrakt og delegere til dem for at håndtere mange af forskellene mellem de forskellige miljøer.
Kom godt i gang med Docker Swarm
I det foregående afsnit så du en eksempelarkitektur til en to-node Docker Swarm-klynge. Nu udvikler du denne klynge ved hjælp af to Nginx Docker-containerforekomster. Nginx er en populær webserver, offentligt tilgængelig som et Docker-billede på DockerHub. Fordi denne artikel er fokuseret på Docker Swarm, ville jeg bruge en Docker-container, som den er hurtig og nem at starte og ligetil at teste. Du er fri til at bruge enhver Docker-container, du ønsker, men til illustrative formål valgte jeg Nginx til dette eksempel.
Min introduktion til Docker inkluderer en guide til opsætning af Docker i dit udviklingsmiljø. Hvis du har installeret og konfigureret Docker Toolbox, indeholder den alt, hvad du har brug for til at køre Docker Swarm. Se Dockers officielle dokumentation for yderligere installationsinstruktioner.
Docker Swarm på kommandolinjen
Hvis du tidligere har brugt Docker, er du fortrolig med at bruge docker kommandolinje til start og stop af containere. Når du bruger Docker Swarm, handler du docker til docker-maskine. Docker-maskine er defineret som følger i Docker-dokumentationen:
Hvis du har installeret Docker, inkluderer din installation allerede Docker Machine. For at komme i gang med Docker Swarm skal du starte Docker og åbne en terminal på din computer. Udfør følgende docker-maskine ls kommando til at liste alle virtuelle computere på din lokale maskine:
$ docker-maskine ls NAVN AKTIV DRIVERSTAT URL URL SWARM standard * virtualbox Kører tcp: //192.168.99.100: 2376 Hvis du kun har kørt Docker fra din lokale maskine, skal du have standard Docker virtuel maskine, der kører med en IP-adresse på 192.168.99.100. For at spare ressourcer på din lokale maskine kan du stoppe denne virtuelle maskine ved at udføre: docker-maskine stop standard.
Opret en sværm
En Docker-sværm består af to eller virtuelle maskiner, der kører Docker-forekomster. Til denne demo opretter vi tre nye virtuelle maskiner: manager, agent1 og agent2. Opret dine virtuelle maskiner ved hjælp af docker-maskine oprette kommando:
$ docker-maskine opretter -d virtualbox manager $ docker-maskine opretter -d virtualbox agent1 $ docker-maskine opretter -d virtualbox agent2 Det docker-maskine oprette kommando opretter en ny "maskine". At give det -d argument giver dig mulighed for at specificere driveren, der skal bruges til at oprette maskinen. Kører lokalt, det burde det være virtualbox. Den første maskine, der oprettes, er Manager, som er vært for managerprocessen. De sidste to maskiner, agent1 og agent2, er de agentmaskiner, der er vært for agentprocesserne.
På dette tidspunkt har du oprettet de virtuelle maskiner, men du har ikke oprettet den egentlige sværmadministrator eller agenter. For at se de virtuelle maskiner og deres tilstand udføre docker-maskine ls kommando:
$ docker-maskine ls NAVN AKTIV DRIVERSTAT URL URL SWARM DOCKER FEJL agent1 - virtualbox Kører tcp: //192.168.99.101: 2376 v1.11.1 agent2 - virtualbox Kører tcp: //192.168.99.102: 2376 v1.11.1 standard - virtualbox stoppet Ukendt manager * virtualbox Kører tcp: //192.168.99.100: 2376 v1.11.1 
