For mange valg: hvordan man vælger det rigtige værktøj til at styre dine Docker-klynger

Der er alle mulige måder at spille Docker-spillet på, og naturligvis vil ingen af ​​dem være rigtige for enhver brugssag. Så hvad jeg skal gøre her, er at give dig et kort funktionelt overblik over hver af de mest åbenlyse ledelsesmuligheder på en måde, der kan hjælpe dig med at vælge selv og spare dig for en masse tid og frustration i processen. På den måde ser du smart ud, og ingen behøver at vide, at det hele tiden var mig.

Først er her dog den sætning, som hver artikel om ethvert emne, selv fjernbetjent relateret til Docker, skal begynde: I løbet af de sidste n år (hvor n <6) er containerteknologier og især Docker blevet dominerende værktøjer i applikationsleverandørverdenen .

Store. Med det ude af vejen kan vi komme i gang. Så du overvejer at levere din app eller netværkstjeneste gennem Docker-containere ... eller i det mindste give dem et godt udseende. Jeg vil bestemt ikke diskutere med dig: det er sandsynligvis et godt valg.

Nu formentlig ved du allerede, at Docker Engine er det open source-softwaremiljø, der lader dig virtualisere bits og stykker af et værtshardwaresystem, indtil de ser ud og fungerer ligesom ægte servere. Docker er nu tilgængelig i enten sin gratis (Community Edition) af kommercielt understøttede (Enterprise Edition) versioner.

Uden tvivl ved du også, at påkalde Docker Engine fra din kommandolinje ved hjælp af ting som:

$ docker ps$ docker images

og:

$ docker network inspect

... får ting gjort. Ikke så behagelig med alt det? Der er noget intro-niveau materiale, du måske kan lide, der er inkluderet i mine Docker-orienterede kurser på Pluralsight.

Alt det fungerer fint, mens du bare lærer dig rundt. Men når du er klar til at begynde at planlægge en robust og meget skalerbar implementering - komplet med komplekse konfigurationer, der kan omfatte mikrotjenester og netværksbroer - ændres landskabet hurtigt. Spørgsmålet er ikke så meget "hvordan", men "hvor og hvilket": Har du beregnings- og netværksressourcer til at køre din app lokalt, eller skal du finde en vært? Skal du gøre det selv eller vælge en administreret tjeneste på en offentlig sky som AWS's Elastic Beasntalk?

Og hvad så med administrationen? Er du en praktisk type, eller foretrækker du at stå et lag eller to tilbage og lade styringsværktøjer som Kubernetes eller Docker sværmtilstand gøre noget af det tunge løft for dig? Eller hvad med to eller tre lag tilbage og går med Ansible eller Puppet?

Lad os dele ting i tre kategorier: repository værktøjer til opbevaring og håndtering af Docker billeder, administration rammer til at definere, lancering, og styring af Docker containere gennem deres livscyklus, og derefter nogle kommandolinjeflag og konfiguration automatisering styringsværktøjer .

1. Billedregistreringer

Docker Hub

For de fleste er det åbenlyse første sted at lede efter Docker-billeder - pakkerne, der indeholder operativsystemer og software, der bruges til at køre containere - Docker Hub. Leveret af Docker selv, besidder Docker Hub en stor samling af billeder, der kommer forudindlæst til at understøtte alle slags applikationsprojekter. Du kan finde og undersøge billeder på webstedet hub.docker.com og derefter trække dem direkte ind i dit eget Docker Engine-miljø.

$ docker pull ubuntu

Når du først har oprettet dine egne billeder, kan du sikkert gemme så mange af dem, som du vil, i offentlige arkiver på Docker Hub. Derudover giver de dig en privat repo gratis og mere med en hastighed på ca. en dollar pr. Repo. Måske er den bedste ting ved Docker Hub den måde, den fungerer problemfrit på næsten alt andet, der er forbundet med Docker, herunder offentlige cloud-udbydere som AWS og infrastrukturadministrationstjenester som Docker Cloud.

Den separate Docker Store-tjeneste giver dig mulighed for at offentliggøre forcertificerede billeder og plugins for at tilfredsstille efterspørgslen efter adgang til pålidelige ressourcer.

EC2 Container Registry (ECR)

Amazons AWS ved alt om kraften og potentialet i Docker og ønsker at komme ind i spillet. Som en del af deres bestræbelser på at åbne deres skyøkosystem for så meget Docker-forretning som muligt, har de opbygget deres eget register til at gå med deres EC2 Container Service-platform: ECR. Billeder kan skubbes, trækkes og administreres via AWS GUI eller CLI-værktøjet. Tilladelsespolitikker kan kun kontrollere billedadgang til de personer, du vælger.

Begrænsningen? ECR er naturligvis designet til at fungere bedst med infrastruktur, der kører på AWS-baserede tjenester som ECS og Elastic Beanstalk.

Docker-registreringsdatabasen

Hvis du har brug for at vedligeholde dine billeder lidt tættere på hjemmet - enten af ​​sikkerhedsmæssige eller praktiske årsager - vil du gerne vide om Dockers frit tilgængelige Docker Registry. Du udpeger en registry-server med adgang til og fra dine andre netværksaktiver, installerer og aktiverer derefter docker-registry-pakken, tagger billeder, så de peges på dit lokale register, og du har fået dig en ægte, live privat repo.

$ dpkg -i docker-registry_2.4.1~ds1-2_amd64.deb$ systemctl enable docker-registry$ docker tag hello-world localhost:5000/hello-world:latest

Selve billederne er gemt dybt inde i filsystemet på din server, men de er tilgængelige via de samme CLI-værktøjer som dem på Docker Hub. Bekymret for at sikre dine billeder? Docker Registry giver dig mulighed for at anvende SSL / TLS-certifikater og kontrollere adgang ved at håndhæve login-godkendelse til dit websted.

Docker Trusted Registry er Dockers kommercielle version af Docker Registry. Til gengæld for månedlige eller årlige afgifter får du ekstra klokker og fløjter inklusive support, en browserbaseret GUI og LDAP / AD-integration.

2. Administrationsrammer

Selv når du først er gået ud over scenen, der bare ser-hvordan-ting-fungerer, vil du muligvis stadig have en aktiv Docker-implementering lokalt: Måske er dine kunder alle lokale, eller din forventede arbejdsbyrde er ikke så tung. Eller måske er du bare paranoid om sikkerhed. Og med "paranoid om sikkerhed" mener jeg selvfølgelig "godt informeret om den aktuelle tilstand af netværkssårbarheder".

En måde at ”forblive lokalt på” er bare at fortsætte med det, du har gjort indtil nu. Så længe du tager hensyn til ressource sikkerhed og kapacitet, er der ingen grund til at opgive den gode gamle Community Edition Docker Engine, du allerede har installeret.

Men hvis det kompleksitetsniveau, du tror, ​​du vil stå over for, får dig til at føle dig lidt tabt, vil du måske overveje at opgradere til et kommercielt miljø, der sammen med løbende support kan tilbyde browserbaserede admin-konsoller. Uanset hvad skal du dog give dit eget hostingmiljø, hvor dine containere kører. Det kan være dine lokale servere eller virtuelle maskiner, der kører i en offentlig sky som AWS eller Azure.

Docker Datacenter

Du opretter Datacenter (nu markedsført som en del af Docker Enterprise Edition) ved at downloade og installere den almindelige Docker Engine på din lokale server sammen med en anden pakke kaldet Docker Universal Control Plane (UCP). UCP giver en browsergrænseflade, der tillader central styring af alle de billeder, apps og netværk, der udgør din infrastruktur. Sikkerhed håndteres også via grænsefladen.

Docker Cloud

Ligesom Docker Datacenter (som også er et officielt Docker-produkt) tilbyder Docker Cloud en GUI-browserbaseret konsol til styring af alle aspekter af dine Docker-implementeringer. Dette inkluderer administration til dine værtsnoder, der kører i offentlige skyer. Den store forskel er, at i modsætning til Datacenter hostes Docker Cloud-administrationstjenesten fra cloud.docker.com-webstedet: der er ingen serversoftware, der kan installeres på dit eget udstyr.

Det fungerer ved at indtaste godkendelsesoplysninger til dine cloud-udbyderkonti (som AWS) eller ved at installere Docker Cloud Agent på enhver Linux- eller Windows-maskine, der kører hvor som helst, hvor der er netværksforbindelse. Ved at klikke på knappen "Bring din egen node" i Node Clusters-vinduet vises en Linux-kommando til download og installation af agenten, der muligvis ser sådan ud:

$ curl -Ls //get.cloud.docker.com/ | sudo -H sh -s 90b501cb04e344bfbf76890a09362c39

Docker Cloud organiserer ressourcer i node-klynger, som er grupper af individuelle noder, der administreres som en del af en enkelt tjeneste, alle dedikeret til et samlet implementeringsmål.

Jeg tror, ​​at en del af grunden til, at Docker fortsætter med at promovere to lignende tjenester (Datacenter og Cloud) går et par år tilbage til, da Docker købte et firma ved navn Tutum og omdøbte deres webbaserede produkt Docker Cloud. Tutum havde allerede en glad kundebase og en ret succesrig forretningsmodel, så der var ingen grund til at lukke den ned. Under alle omstændigheder fungerer begge dele, så vælg bare den, der ringer til din klokke.

AWS EC2 Container Service (ECS)

Udover ECR-billedregistret har AWS skabt sin egen fulde infrastruktur til både hosting og administration af Docker-containerklynger. ECS fungerer ved at klargøre en specialbygget EC2-forekomst med både Docker Engine og en ECS-agent installeret. Ved hjælp af enten ECS-konsollen eller AWS CLI kan du definere, starte og administrere containere på den EC2-forekomst.

$ aws ecs describe-clusters

For at være ærlig kan det være en hård opgave at finde ud af, hvordan alle de mange ECS-stykker passer sammen. Mit “Brug af Docker på Amazon Web Services” -kursus om Pluralsight bruger lidt tid på at forklare, hvordan delene fungerer. Her er den korte version:

  • Opgaver : metadata, der definerer et program og dets netværk, opbevaring og sikkerhedsmiljø
  • Services : software, der starter, overvåger og styrer dine containere
  • Containere : definitioner for de maskiner, der kører en opgave
  • Klynger : organisering af strukturer til opgaver og tjenester

AWS elastisk bønnestængel

Elastic Beanstalk sidder effektivt oven på ECS, så du kan distribuere din applikation på tværs af alle AWS-ressourcer, der normalt bruges af ECS, men med stort set al logistik pænt abstraheret væk. Effektivt er alt hvad du behøver for at starte et fuldt skalerbart, komplekst mikrotjenestemiljø et deklarativt JSON-formateret script i en fil, der hedder Dockerrun.aws.json. Du kan enten uploade dit script til GUI'en eller fra en initialiseret lokal mappe ved hjælp af AWS Beanstalk kommandolinjegrænseflade, køre det ved hjælp af:

$ eb run

Og det er det. Nej virkelig.

Jeg skal nævne, at Dockerrun.aws.json-filer findes i to varianter: V1 til implementering af enkelt containere og V2 til flere containere. Det er også værd at bemærke, at en stor fordel ved at bruge CLI over browserversionen er, hvor meget lettere det kan gøre fjern SSH-login til EC2-værts- og administrationsopgaver.

Her er noget andet at sige om: De første sytten kapitler i min bog "Lær Amazon Web Services i en måned med frokost" spores, trin for trin, opførelsen af ​​et meget tilgængeligt, skalerbart og sikkert WordPress-websted. Til kapitel 19 - bare for hurtigt at illustrere, hvordan det fungerer - oprettede jeg en 20-linjers Dockerrun.aws.json-fil, der gjorde stort set nøjagtig den samme ting ... men på bare fem minutter.

Nu er det ikke at sige, at bogens første 17 kapitler var spild af tid! Uden at forstå, hvordan hver enkelt AWS-tjeneste fungerer, ville du faktisk ikke helt forstå, hvad det var, som Beanstalk faktisk opnåede. Og du vil helt sikkert gå glip af al slags funktionalitet, der kan tage dig langt ud over de ting, som Beanstalk kan levere. Men det siger bestemt noget om styrken ved scriptede implementeringer, ikke sandt?

3. Ledelsesværktøjer

Docker Swarm Mode

Selvom det nu er en del af Docker Engine lige ud af kassen, måske fordi den stadig er under konstant ændring, har Docker-sværmtilstand på en eller anden måde smagen af ​​et enkeltstående produkt. Ideen er, at du kan udpege en af ​​dine servere (kendt som en node) som en manager:

$ docker swarm init

... og andre servere som klienter:

$ docker swarm join

Derefter opretter og administrerer klynger af Docker-containere som tjenester ved hjælp af "dockerservice" -kommandoer fra manageren og distribueres automatisk og effektivt containerne mellem alle dine tilgængelige servere, uanset hvor de måtte bo. Du bør prøve det selv for spændingen ved at køre en simpel "serviceskala" -kommando og se den rigtige mængde containere magisk og øjeblikkeligt vises på tværs af dit netværk.

$ docker service create -p 80:80 --name webserver nginx$ docker service scale webserver=5

Jeg dedikerede en del af mit Pluralsight “Brug af Docker med AWS Elastic Beanstalk” kursus til at demonstrere Docker Swarm i aktion. Se, hvis du er interesseret.

Kubernetes

Ligesom Swarm er Googles Kubernetes også meget god til effektivt at styre store containerklynger. Og at sige, at Kubernetes er populær, er som at sige regn er våd. Duh.

Kubernetes organiserer ressourcer i bælg, som i sig selv består af sammenkoblede beholdere, der kører individuelle mikrotjenester. Du bør tænke på en bælg som fuldstændig engangsbrug, dens funktion kan straks udskiftes af andre, der afventer deres chance for at komme ind i denne verden.

Faktisk oprettes og ødelægges bælg i henhold til de behov, der er defineret på masternoden af ​​ting som planlægning og replikeringskontrollere, som alle igen kan styres af kubectl-programmet. Bælter - og deres containere - kører på servere, der er kendt som medarbejdernoder, der kører deres egne forekomster af Docker Engine.

Jeg ved ikke om dig, men jeg finder det både forvirrende og irriterende, at hver enkelt it-platform vælger at henvise til de bestanddele ved forskellige - men ofte kun lidt forskellige - navne. Der burde være en lov.

Implementeringsautomatiseringsværktøjer

Jeg kan ikke gå væk fra en gennemgangsartikel som denne uden i det mindste at nævne, hvordan du kan bruge næsten ethvert af de populære implementerings orkestreringsværktøjer som Ansible, Jenkins og Puppet til at automatisere dine Docker-miljøer. At dykke ned i de fine detaljer ville tage mig langt ud over min oprindelige plan for denne artikel, så vælg bare dit yndlingsværktøj og dokumentér.

Var det nyttigt? Tjek min Bootstrap IT-webside for masser af lignende Docker-, Linux- og AWS-godheder.