Denne opplæringen introduserer Java-utviklere for Docker Swarm. Du lærer hvorfor så mange bedriftsbutikker har tatt i bruk containeradministrert utvikling via Docker, og hvorfor klynging er en viktig teknikk for å jobbe med Docker-containere. Du vil også finne ut hvordan to populære Docker-klyngeteknologier - Amazon ECS og Docker Swarm - sammenligner, og få en rask guide til å velge riktig løsning for butikken eller prosjektet. Opplæringen avsluttes med en praktisk demonstrasjon av å bruke Docker Swarm til å utvikle og administrere en to-node bedriftsklynge.
Les nå: Containerstyrt utvikling med Docker
Det er en god ide å være kjent med containeradministrert utvikling og Docker-grunnleggende før du dykker ned i Docker Swarm. Det er en oversikt nedenfor, men se min introduksjon til Docker for en mer grundig diskusjon. Utviklere som er kjent med disse grunnleggende, bør hoppe til neste avsnitt.
Hva er avtalen med Docker?
Docker er en åpen plattform for å bygge, sende og kjøre distribuerte applikasjoner. Dockeriserte applikasjoner kan kjøres lokalt på en utviklers maskin, og de kan distribueres til produksjon på tvers av en skybasert infrastruktur. Docker egner seg til rask utvikling og muliggjør kontinuerlig integrering og kontinuerlig distribusjon som nesten ingen annen teknologi gjør. På grunn av disse funksjonene er det en plattform som alle utviklere bør vite hvordan de skal bruke.
Det er viktig å forstå at Docker er et containerisering teknologi, ikke en virtualisering teknologi. Mens en virtuell maskin inneholder et komplett operativsystem og administreres av en tungvektsprosess kalt hypervisor, er en container designet for å være veldig lett og selvstendig. Hver server kjører en demonprosess kalt en Docker-motor som kjører containere og oversetter operativsystemanrop inne i containeren til innfødte anrop på vertsoperativsystemet. En container, som er analog med en virtuell maskin, bare mye mindre, er vert for applikasjonen, kjøretidsmiljøet og et barebones-operativsystem. Beholdere kjører vanligvis på virtuelle maskiner. Mens en virtuell maskin kan ta minutter å starte, kan en container gjøre det på få sekunder.
Figur 1 illustrerer forskjellen mellom en container og en virtuell maskin.
Docker-containere er selvstendige, noe som betyr at de inkluderer alt de trenger for å kjøre applikasjonen din. For eksempel, for et webapplikasjon som kjører i Tomcat, vil containeren inneholde:
- En krigsfil
- Tomcat
- JVM
- Basisoperativsystemet
Figur 2 viser arkitekturen til en webapp i en Docker-container.
Når det gjelder Docker, kjører hver virtuelle maskin en demoneprosess kalt Docker-motor. Du bygger applikasjonen din, for eksempel WAR-filen, og oppretter deretter en tilsvarende Dockerfil. En Dockerfile er en tekstfil som beskriver hvordan du bygger en Docker-bilde, som er en binær fil som inneholder alt som trengs for å kjøre applikasjonen. Som et eksempel kan du bygge en Dockerfile fra et Tomcat-basebilde som inneholder et base Linux OS, Java runtime og Tomcat. Etter å ha bedt Docker om å kopiere en WAR-fil til Tomcats webapps-katalog, vil Dockerfile bli samlet til et Docker-bilde som består av base OS, JVM, Tomcat og WAR-filen. Du kan kjøre Docker-bildet lokalt, men du vil til slutt publisere det til en Docker-depot, som DockerHub.
Mens et Docker-bilde er en binær versjon av beholderen din, kalles en kjøretidsforekomst av et Docker-bilde a Docker-container. Docker-containere drives av din Docker-motor. Maskinen som kjører Docker-motoren din kalles Docker vert; dette kan være din lokale bærbare datamaskin eller en skyplattform, avhengig av omfanget av applikasjonen din.
Grunnleggende i denne delen gir grunnlag for å forstå hvorfor klynging er et viktig tillegg til Docker-verktøysettet. Se introduksjonen min til Docker for mer.
Clustering Docker
De fleste utviklere som kommer i gang med Docker, vil bygge en Dockerfil og kjøre den lokalt på en bærbar datamaskin. Men det er mer med containeradministrert utvikling enn å kjøre individuelle Docker-containere lokalt. Dockers supermakt er dens evne til å dynamisk skalere containere opp eller ned. I produksjon betyr dette å kjøre Docker i en klynge på tvers av en rekke maskiner eller virtuelle maskiner.
Ulike Docker-klyngeteknologier er tilgjengelige, men de to mest populære er Amazon EC2 Container Service (ECS) og Docker Swarm.
Amazon ECS
Amazons Docker-klyngeteknologi utnytter Amazon Web Services (AWS) for å lage en klynge av virtuelle maskiner som kan kjøre Docker-containere. En ECS-klynge består av administrert ECS-forekomster, som er EC2-forekomster med en Docker-motor og en ECS-agent. ECS bruker en autoskaleringsgruppe for å utvide og trekke inn antall forekomster basert på CloudWatch-policy. For eksempel når den gjennomsnittlige CPU-bruken av ECS-forekomster er for høy, kan du be ECS om å starte flere forekomster, opp til det maksimale antallet forekomster som er definert i autoskalingsgruppen.
Docker-containere administreres av en ECS-tjeneste og konfigurert av mengden beregningskapasitet (CPU) og RAM som beholderen trenger å kjøre. ECS-tjenesten har en tilknyttet Elastic Load Balancer (ELB). Når det starter og stopper Docker-containere, registrerer og avregistrerer ECS-tjenesten disse containerne hos ELB. Når du har satt opp reglene for klyngen din, sørger Amazon ECS for at du har ønsket antall containere som kjører, og disse containerne er tilgjengelige via ELB. Figur 3 viser en oversikt på høyt nivå av Amazon ECS.
Det er viktig å skille mellom ECS tilfeller og oppgaver. ECS-klyngen administrerer ECS-forekomster, som er spesielle EC2-forekomster som kjører i en autoskalingsgruppe. ECS-tjenesten administrerer oppgavene, som kan inneholde en eller flere Docker-containere, og som kjører på klyngen. En ELB sitter foran ECS-forekomster som kjører Docker-containere og distribuerer last til Docker-containere. Forholdet mellom ECS-oppgaver og Docker-containere er at en oppgavedefinisjon forteller ECS-tjenesten hvilke Docker-containere som skal kjøres og konfigurasjonen av disse containerne. ECS-tjenesten kjører oppgaven som starter Docker-containerne.
Se introduksjonen min til Amazon ECS på VMTurbo.com.
Docker sverm
Docker's innfødte klyngeteknologi, Docker Swarm, lar deg kjøre flere Docker-containere over en klynge virtuelle maskiner. Docker Swarm definerer en sjef container som kjører på en virtuell maskin som administrerer miljøet, distribuerer containere til de forskjellige agentene og rapporterer containerstatus og distribusjonsinformasjon for klyngen.
Når du kjører en Docker Swarm, er lederen det primære grensesnittet i Docker. Agenter er "dockermaskiner" som kjører på virtuelle maskiner som registrerer seg hos manager og kjører Docker-containere. Når klienten sender en forespørsel til lederen om å starte en container, finner lederen en tilgjengelig agent for å kjøre den. Den bruker en minst utnyttet algoritme for å sikre at agenten som kjører minst antall containere, vil kjøre den nylig etterspurte containeren. Figur 4 viser en eksempelkonfigurasjon av Docker Swarm, som du vil utvikle i neste avsnitt.
Lederprosessen kjenner til alle aktive agenter og containere som kjører på disse agentene. Når agentens virtuelle maskiner starter, registrerer de seg hos manager og er deretter tilgjengelige for å kjøre Docker-containere. Eksemplet i figur 4 har to agenter (Agent1 og Agent2) som er registrert hos manager. Hver agent kjører to Nginx-containere.
Docker Swarm vs Amazon ECS
Denne artikkelen inneholder Docker Swarm, men det er nyttig å sammenligne containerteknologier. Mens Amazon ECS tilbyr en godt utviklet nøkkelferdig løsning, gir Docker Swarm deg friheten til å konfigurere mer av din egen infrastruktur. Som et eksempel administrerer Amazon ECS både containere og lastbalansere, mens du i Docker Swarm konfigurerer en lastbalanseringsløsning som Cisco LocalDirector, F5 BigIp eller en Apache- eller Nginx-programvareprosess.
Hvis du allerede kjører appen din i AWS, gjør ECS det mye enklere å kjøre og administrere Docker-containere enn en ekstern løsning. Som AWS-utvikler bruker du sannsynligvis allerede autoskaleringsgrupper, ELB-er, virtuelle private skyer (VPC), identitets- og tilgangsstyringsroller (IAM), roller og policyer, og så videre. ECS integreres godt med dem alle, så det er veien å gå. Men hvis du ikke kjører i AWS, gjør Docker Swarms tette integrasjon med Docker-verktøyene det til et godt valg.
AWS og Docker Swarm i hybridskyen
Amazon Web Services kan konfigureres for svært høy tilgjengelighet, skalerbarhet og ytelse, og det er sannsynligvis grunnen til at den betjener 25% av all internettrafikk, inkludert den massivt skalerte Netflix-infrastrukturen. Nylig har det imidlertid vært et skyv mot hybrid sky-miljøer. EN hybrid sky er en sky der en del av applikasjonen, eller noen ganger en full kopi av den, kjører i en offentlig sky som AWS, og en del av den kjører i en privat sky. Et populært alternativ i dette tilfellet er å kjøre OpenStack i et privat datasenter.
En hybridsky er en trygg strategi for et selskap som flytter noen eller alle operasjoner til skyen, men må gå sakte og få tillit til offentlige skyer. Når du velger et hybrid sky-alternativ, må du opprette et abstraksjonslag på toppen av de underliggende skyteknologiene, noe som betyr at du like enkelt kan distribuere til Docker Swarm som kjører på OpenStack i ditt eget datasenter som du kan til ECS som kjører på AWS . Verktøy som Chef og Puppet kan hjelpe ved å la deg definere miljøene dine abstrakt, delegere til dem for å håndtere mange av forskjellene mellom de forskjellige miljøene.
Komme i gang med Docker Swarm
I forrige avsnitt så du en eksempelarkitektur for en to-node Docker Swarm-klynge. Nå skal du utvikle den klyngen ved hjelp av to Nginx Docker-containerforekomster. Nginx er en populær webserver, offentlig tilgjengelig som et Docker-bilde på DockerHub. Fordi denne artikkelen er fokusert på Docker Swarm, ønsket jeg å bruke en Docker-container som den er rask og enkel å starte og grei å teste. Du kan bruke hvilken som helst Docker-container du ønsker, men for illustrasjonsformål valgte jeg Nginx for dette eksemplet.
Min introduksjon til Docker inkluderer en guide for å sette opp Docker i utviklingsmiljøet ditt. Hvis du har installert og konfigurert Docker Toolbox, inneholder den alt du trenger for å kjøre Docker Swarm. Se Dockers offisielle dokumentasjon for ytterligere installasjonsinstruksjoner.
Docker Swarm på kommandolinjen
Hvis du tidligere har brukt Docker, er du kjent med å bruke docker kommandolinje for å starte og stoppe containere. Når du bruker Docker Swarm, handler du docker til docker-maskin. Docker Machine er definert som følger i Docker-dokumentasjonen:
Hvis du har installert Docker, inkluderer installasjonen din allerede Docker Machine. For å komme i gang med Docker Swarm, start Docker og åpne en terminal på datamaskinen din. Utfør følgende docker-maskin ls kommando for å liste alle virtuelle maskiner på din lokale maskin:
$ docker-maskin lS NAVN AKTIV DRIVERSTAT URL URL SVARM standard * virtualbox Kjører tcp: //192.168.99.100: 2376 Hvis du bare har kjørt Docker fra din lokale maskin, bør du ha standard virtuell Docker-maskin som kjører med en IP-adresse 192.168.99.100. For å spare ressurser på din lokale maskin, kan du stoppe denne virtuelle maskinen ved å utføre: docker-maskin stopper standard.
Lag en sverm
En Docker-sverm består av to eller virtuelle maskiner som kjører Docker-forekomster. For denne demoen oppretter vi tre nye virtuelle maskiner: manager, agent1 og agent2. Lag dine virtuelle maskiner ved hjelp av docker-maskin lage kommando:
$ docker-maskin oppretter -d virtualbox manager $ docker-maskin oppretter -d virtualbox agent1 $ docker-maskin oppretter -d virtualbox agent2 De docker-maskin lage kommandoen oppretter en ny "maskin". Passerer den -d argument kan du spesifisere driveren som skal brukes til å lage maskinen. Kjører lokalt, det burde det være virtualbox. Den første maskinen som er opprettet er sjef, som er vert for lederprosessen. De to siste maskinene, agent1 og agent2, er agentmaskinene som er vert for agentprosessene.
På dette punktet har du opprettet de virtuelle maskinene, men du har ikke opprettet den faktiske svermansvarlig eller agenter. For å se de virtuelle maskinene og deres tilstand, kjør docker-maskin ls kommando:
$ docker-maskin ls NAVN AKTIV DRIVERSTAT URL URL SVARM DOCKER FEIL agent1 - virtualbox Kjører tcp: //192.168.99.101: 2376 v1.11.1 agent2 - virtualbox Kjører tcp: //192.168.99.102: 2376 v1.11.1 standard - virtualbox Stoppet ukjent manager * virtualbox Kjører tcp: //192.168.99.100: 2376 v1.11.1 
