Hvad er de bedste Docker-værktøjer? Et overblik

Det om­fat­ten­de Docker-økosystem giver udviklere en række mu­lig­he­der for at im­ple­men­te­re ap­pli­ka­tio­ner, ko­or­di­ne­re con­tai­ne­re og meget mere. Vi gennemgår de vigtigste Docker-værktøjer og giver dig et overblik over de mest populære tred­je­part­s­pro­jek­ter, der udvikler open source-værktøjer til Docker.

Hvilke værktøjer og kom­po­nen­ter er uund­vær­li­ge i Docker?

I dag er Docker langt mere end blot en avanceret platform til styring af softwa­recon­tai­ne­re. Udviklere har skabt en række for­skel­li­ge Docker-værktøjer, der gør im­ple­men­te­rin­gen af ap­pli­ka­tio­ner via di­stri­bu­e­ret in­fra­struk­tur og cloud-miljøer nemmere, hurtigere og mere fleksibel. Ud over værktøjer til cluste­ring og or­ke­stre­ring findes der også en central app-mar­keds­plads og et værktøj til styring af cloud-res­sour­cer.

Docker Engine

Når udviklere taler om »Docker«, henviser de som regel til den open source-baserede klient-server-ap­pli­ka­tion, derdanner grund­la­get for con­tai­ner­p­lat­for­men. Denne ap­pli­ka­tion kaldes Docker Engine. De centrale kom­po­nen­ter i Docker Engine er Docker-daemonen, et REST-API og et CLI (kom­man­do­linje­græn­se­fla­de), der fungerer som bru­ger­græn­se­fla­de.

Med denne løsning kan du kom­mu­ni­ke­re med Docker Engine via kom­man­do­linje­kom­man­do­er og nemt ad­mi­ni­stre­re Docker-billeder, Docker-filer og Docker-con­tai­ne­re fra ter­mi­na­len.

Du kan finde en de­tal­je­ret be­skri­vel­se af Docker Engine i vores Docker-vej­led­ning for begyndere : Docker-vej­led­ning: in­stal­la­tion og de første skridt.

Docker Hub

Docker Hub tilbyder brugerne et cloud­ba­se­ret register, hvor Docker-billeder kan down­lo­a­des, ad­mi­ni­stre­res centralt og deles med andre Docker-brugere. Re­gi­stre­re­de brugere kan gemme Docker-billeder of­fent­ligt eller i private repo­si­to­ri­er. Det kræver ikke en bru­ger­kon­to at downloade et of­fent­ligt billede (i Docker-ter­mi­no­lo­gi kaldet »pulling« ). En in­te­gre­ret tag-mekanisme gør det muligt at ver­sio­ne­re bil­le­der­ne.

Ud over de of­fent­li­ge repo­si­to­ri­er fra andre Docker-brugere findes der også mange res­sour­cer fra Docker-ud­vik­ler­tea­met og kendte open source-projekter i de of­fi­ci­el­le repo­si­to­ri­er på Docker Hub. Blandt de mest populære Docker-images er NGINX-web­ser­ve­ren, Redis-databasen, der kører i hukom­mel­sen, BusyBox-værk­tøjs­sæt­tet til Unix samt Ubuntu-Linux-di­stri­bu­tio­nen.

Or­ga­ni­sa­tio­ner er en anden vigtig funktion i Docker Hub, som giver Docker-brugere mulighed for at oprette private repo­si­to­ri­er, der ude­luk­ken­de er til­gæn­ge­li­ge for en udvalgt gruppe af personer. Ad­gangs­ret­tig­he­der­ne ad­mi­ni­stre­res inden for en or­ga­ni­sa­tion ved hjælp af teams og grup­pe­med­lem­ska­ber.

Docker Swarm

Docker Engine in­de­hol­der en indbygget funktion, der giver brugerne mulighed for at ad­mi­ni­stre­re Docker-værter i klynger, der kaldes swarms. De klyn­ge­ad­mi­ni­stra­tions- og or­ke­stre­rings­funk­tio­ner, der er indbygget i Docker Engine, er baseret på Swarmkit-værk­tøjskas­sen. Hvis man bruger en ældre version af con­tai­ner­p­lat­for­men, er Docker-værktøjet til­gæn­ge­ligt som et selv­stæn­digt program.

Som et indbygget Docker-klyn­ge­værk­tøj samler Swarm en pulje af Docker-værter i en enkelt virtuel vært og stiller Docker REST API til rådighed. Ethvert Docker-værktøj, der er til­knyt­tet Docker-daemonen, kan få adgang til Swarm og skalere på tværs af et vil­kår­ligt antal Docker-værter. Med Docker Engine CLI kan brugerne oprette swarms, di­stri­bu­e­re ap­pli­ka­tio­ner i klyngen og styre swarmens adfærd uden at skulle bruge yder­li­ge­re or­ke­stre­rings­softwa­re.

Docker-motorer, der er samlet i klynger, kører i swarm-tilstand. Vælg denne indstil­ling, hvis du vil oprette en ny klynge eller tilføje en Docker-vært til en ek­si­ste­ren­de swarm. De enkelte Docker-værter i en klynge kaldes »noder«. Noderne i en klynge kan køre som virtuelle værter på det samme lokale system, men oftere anvendes en cloud­ba­se­ret løsning, hvor de enkelte noder i Docker-swarm’en er fordelt på for­skel­li­ge systemer og in­fra­struk­tu­rer.

Softwaren er baseret på en master-worker-ar­ki­tek­tur. Når opgaver skal fordeles i swarm-klyngen, sender brugerne en tjeneste til manager-noden. Manageren har derefter ansvaret for at planlægge con­tai­ne­re i klyngen og fungerer som den primære bru­ger­græn­se­fla­de til adgang til swarm-res­sour­cer­ne.

Le­der­no­den sender enkelte enheder, kaldet opgaver, til ar­bejds­knu­de­punk­ter­ne.

• Tjenester: Tjenester er centrale struk­tu­rer i Docker-klynger. En tjeneste definerer en opgave, der skal udføres i en Docker-klynge. En tjeneste omfatter en gruppe af con­tai­ne­re, der er baseret på det samme billede. Når man opretter en tjeneste, angiver brugeren, hvilket billede og hvilke kom­man­do­er der skal bruges. Derudover giver tjenester mulighed for at skalere ap­pli­ka­tio­ner. Brugere af Docker-plat­for­men skal blot definere, hvor mange con­tai­ne­re der skal startes for en tjeneste.
• Opgaver: For at di­stri­bu­e­re tjenester i klyngen opdeles de i in­di­vi­du­el­le ar­bejd­s­en­he­der (opgaver) af manager-noden. Hver opgave omfatter en Docker-container samt de kom­man­do­er, der udføres i den.

Ud over at varetage styringen af klyngen og ko­or­di­ne­rin­gen af con­tai­ne­re kan manager-noder som standard også udføre worker-node-funk­tio­ner – medmindre du nøje begrænser disse noders opgaver til kun at omfatte styring.

Der kører et agent­pro­gram på hver ar­bejds­knu­de­punkt. Dette modtager opgaver og sender sta­tus­rap­por­ter til det respek­ti­ve ho­ved­knu­de­punkt om frem­skrid­tet i den overførte opgave. Følgende figur viser en skematisk frem­stil­ling af en Docker Swarm:

Når man im­ple­men­te­rer en Docker Swarm, benytter man sig som regel af Docker-maskinen.

Docker Compose

Docker Compose gør det muligt at samle flere con­tai­ne­re og køre dem med en enkelt kommando. Det centrale element i Compose er den centrale kon­trol­fil, der er baseret på det pris­be­løn­ne­de sprog YAML. Syntaksen i denne Compose-fil ligner den i open source-pro­gram­met Vagrant, som bruges til at oprette og kon­fi­gu­re­re virtuelle maskiner.

I filen docker-compose.yml* kan du definere et vil­kår­ligt antal softwa­recon­tai­ne­re, herunder alle af­hæn­gig­he­der, samt deres indbyrdes re­la­tio­ner. Sådanne ap­pli­ka­tio­ner med flere con­tai­ne­re styres efter samme mønster som in­di­vi­du­el­le softwa­recon­tai­ne­re. Brug kom­man­do­endocker-compose* sammen med den ønskede un­der­kom­man­do til at ad­mi­ni­stre­re hele ap­pli­ka­tio­nens livs­cy­klus.

Dette Docker-værktøj kan nemt in­te­gre­res i en Swarm-baseret klynge. På den måde kan du køre ap­pli­ka­tio­ner med flere con­tai­ne­re, der er oprettet med Compose, på di­stri­bu­e­re­de systemer lige så nemt, som du ville gøre det på en enkelt Docker-vært.

En anden funktion i Docker Compose er en in­te­gre­ret ska­le­rings­me­ka­nis­me. Med dette or­ke­stre­rings­værk­tøj kan du nemt bruge kom­man­do­linje­pro­gram­met til at definere, hvor mange con­tai­ne­re du ønsker at starte for en bestemt tjeneste.

Hvilke tred­je­part­s­værk­tø­jer til Docker findes der?

Ud over den interne udvikling fra Docker Inc. findes der for­skel­li­ge softwa­re­værk­tø­jer og platforme fra eksterne udbydere, som tilbyder græn­se­fla­der til Docker Engine eller er udviklet specielt til den populære con­tai­ner­p­lat­form. Inden for Docker-øko­sy­ste­met omfatter de mest populære open source-projekter or­ke­stre­rings­værk­tø­jet Ku­ber­ne­tes, klyn­ge­sty­rings­værk­tø­jet Shipyard, multi-container-shipping-løsningen Panamax, den kon­ti­nu­er­li­ge in­te­gra­tions­plat­form Drone, det cloud­ba­se­re­de ope­ra­tiv­sy­stem OpenStack og D2iQ DC/OS-da­ta­cen­te­ro­pe­ra­tiv­sy­ste­met, som er baseret på klyn­ge­sty­rings­værk­tø­jet Mesos.

Ku­ber­ne­tes

Det er ikke altid muligt for Docker at udvikle sine egne or­ke­stre­rings­værk­tø­jer som Swarm og Compose. Af den grund har for­skel­li­ge virk­som­he­der i årevis in­ve­ste­ret i deres eget ud­vik­lings­ar­bej­de med at skabe skræd­der­sy­e­de værktøjer, der skal lette driften af con­tai­ner­p­lat­for­men i store, di­stri­bu­e­re­de in­fra­struk­tu­rer. Blandt de mest populære løsninger af denne type er open source-projektet Ku­ber­ne­tes.

Ku­ber­ne­tes er en klyn­ge­sty­ring til con­tai­ner­ba­se­re­de ap­pli­ka­tio­ner. Formålet med Ku­ber­ne­tes er at au­to­ma­ti­se­re ap­pli­ka­tio­ner i en klynge. Til dette formål anvender or­ke­stre­rings­værk­tø­jet en REST-API, et kom­man­do­linje­pro­gram og en grafisk web­græn­se­fla­de som sty­rings­græn­se­fla­der. Via disse græn­se­fla­der kan man igang­sæt­te au­to­ma­ti­se­rin­ger og anmode om sta­tus­rap­por­ter. Du kan bruge Ku­ber­ne­tes til at:

• køre con­tai­ner­ba­se­re­de ap­pli­ka­tio­ner på et cluster,
• in­stal­le­re og ad­mi­ni­stre­re ap­pli­ka­tio­ner i di­stri­bu­e­re­de systemer,
• skalere ap­pli­ka­tio­ner og
• udnytte hardware bedst muligt.

Med dette formål for øje samler Ku­ber­ne­tes con­tai­ne­re i logiske enheder, der kaldes pods. Pods udgør klyn­ge­sty­rin­gens grund­læg­gen­de enheder, som kan fordeles i klyngen ved hjælp af plan­læg­ning.

Ligesom Dockers Swarm er Ku­ber­ne­tes også baseret på en master-worker-ar­ki­tek­tur. En klynge består af en Ku­ber­ne­tes-master og en række arbejdere, der også kaldes Ku­ber­ne­tes-noder (eller minions). Ku­ber­ne­tes-masteren fungerer som et centralt kon­trol­plan i klyngen og består af fire grund­læg­gen­de kom­po­nen­ter, der muliggør direkte kom­mu­ni­ka­tion i klyngen og fordeling af opgaver. En Ku­ber­ne­tes-master består af en API-server, kon­fi­gu­ra­tions­hukom­mel­sen etcd, en scheduler og en con­trol­ler manager.

• API-server: Alle au­to­ma­ti­se­rin­ger i Ku­ber­ne­tes-klyngen igang­sæt­tes via REST-API gennem en API-server. Denne fungerer som den centrale ad­mi­ni­stra­tions­græn­se­fla­de i klyngen.
• etcd: Man kan betragte open source-kon­fi­gu­ra­tions­hukom­mel­sen etcd som hukom­mel­sen i et Ku­ber­ne­tes-cluster. Key Value Store, som CoreOS har udviklet specifikt til di­stri­bu­e­re­de systemer, gemmer kon­fi­gu­ra­tions­da­ta og gør dem til­gæn­ge­li­ge for alle noder i clusteret. Den aktuelle tilstand i et cluster kan til enhver tid ad­mi­ni­stre­res via etcd.
• Scheduler: Sche­du­le­ren er ansvarlig for at fordele con­tai­ner­grup­per (pods) i klyngen. Den fast­læg­ger en pods res­sour­ce­be­hov og matcher dette derefter med de til­gæn­ge­li­ge res­sour­cer på de enkelte noder i klyngen.
• Con­trol­ler manager: Con­trol­ler manager er en tjeneste i Ku­ber­ne­tes-masteren og styrer or­ke­stre­rin­gen ved at regulere klyngens tilstand og udføre ru­ti­ne­op­ga­ver. Con­trol­ler ma­na­ge­rens ho­ved­op­ga­ve er at sikre, at klyngens tilstand svarer til den de­fi­ne­re­de må­l­til­stand.

Ku­ber­ne­tes-masterens over­ord­ne­de kom­po­nen­ter kan være placeret på samme vært eller fordelt på flere master-værter inden for et højtil­gæn­ge­lig­heds­klu­ster.

Mens Ku­ber­ne­tes-masteren står for or­ke­stre­rin­gen, kører de pods, der er fordelt i klyngen, på værter, dvs. Ku­ber­ne­tes-noder, som er un­der­ord­net masteren. For at dette kan fungere, skal der køre en container-engine på hver Ku­ber­ne­tes-node. Selvom Docker er de facto-stan­dar­den, er Ku­ber­ne­tes ikke bundet til at bruge en bestemt container-engine.

Ud over container-motoren omfatter Ku­ber­ne­tes-noder følgende kom­po­nen­ter:

• kubelet: kubelet er en agent, der kører på hver enkelt Ku­ber­ne­tes-node og bruges til at styre og ad­mi­ni­stre­re noden. Som den centrale kon­takt­punkt for hver node er kubelet forbundet med Ku­ber­ne­tes-masteren og sikrer, at in­for­ma­tion vi­de­re­gi­ves til og modtages fra kon­trol­pla­net.
• kube-proxy: Derudover kører proxytje­ne­sten kube-proxy på hver Ku­ber­ne­tes-node. Dette sikrer, at an­mod­nin­ger udefra vi­de­re­sen­des til de respek­ti­ve con­tai­ne­re og leverer tjenester til brugere af con­tai­ner­ba­se­re­de ap­pli­ka­tio­ner. Kube-proxy tilbyder også ru­di­men­tær be­last­nings­ba­lan­ce­ring.

Følgende figur viser en skematisk frem­stil­ling af den master-node-ar­ki­tek­tur, som or­ke­stre­rings­plat­for­men Ku­ber­ne­tes bygger på:

Ud over selve Ku­ber­ne­tes-projektet findes der også en lang række værktøjer og ud­vi­del­ser, der gør det muligt at tilføje yder­li­ge­re funk­tio­na­li­tet til or­ke­stre­rings­plat­for­men. De mest populære er over­våg­nings- og fejl­di­ag­nos­ti­ce­rings­værk­tø­jer­ne Pro­met­heus, Weave Scope og sysdig samt pak­ke­hånd­te­rings­værk­tø­jet Helm. Der findes desuden plugins til Apache Maven og Gradle samt et Java-API, der giver mulighed for at fjernsty­re Ku­ber­ne­tes.

Skibsværft

Shipyard er en bru­ger­ud­vik­let ad­mi­ni­stra­tions­løs­ning baseret på Swarm, der giver brugerne mulighed for at ad­mi­ni­stre­re Docker-res­sour­cer som con­tai­ne­re, billeder, værter og private registre via et grafisk bru­ger­græn­se­fla­de. Det er til­gæn­ge­ligt som en we­bap­pli­ka­tion via browseren. Ud over de klyn­ge­ad­mi­ni­stra­tions­funk­tio­ner, der kan tilgås via et centralt web­græn­se­fla­de, tilbyder Shipyard også bru­ger­god­ken­del­se og rol­le­ba­se­ret ad­gangs­kon­trol.

Softwaren er 100 % kom­pa­ti­bel med Docker Remote API og bruger open source-NoSQL-databasen RethinkDB til at gemme data for bru­ger­kon­ti, adresser og be­gi­ven­he­der. Softwaren er baseret på klyn­ge­sty­rings­værk­tø­jet Citadel og består af tre ho­ved­kom­po­nen­ter: con­trol­ler, API og bru­ger­græn­se­fla­de.

• Shipyard-con­trol­ler: Con­trol­le­ren er kernen i ad­mi­ni­stra­tions­værk­tø­jet Shipyard. Shipyard-con­trol­le­ren kom­mu­ni­ke­rer med RethinkDB for at gemme data og gør det muligt at henvende sig til in­di­vi­du­el­le værter i et Docker-klynge samt at styre be­gi­ven­he­der.
• Shipyard API: Shipyard API er baseret på REST. Alle funk­tio­ner i ad­mi­ni­stra­tions­værk­tø­jet styres via Shipyard API.
• Shipyard-bru­ger­græn­se­fla­de (UI): Shipyard-bru­ger­græn­se­fla­den er en AngularJS-app, der giver brugerne en grafisk bru­ger­græn­se­fla­de til styring af Docker-klynger i web­brow­se­ren. Alle in­ter­ak­tio­ner i bru­ger­græn­se­fla­den foregår via Shipyard API.

Yder­li­ge­re op­lys­nin­ger om open source-projektet findes på Shipyards of­fi­ci­el­le hjem­mesi­de.

Panamax

Ud­vik­ler­ne bag open source-projektet Panamax har sat sig for at forenkle im­ple­men­te­rin­gen af apps, der består af flere con­tai­ne­re. Det gratis værktøj tilbyder brugerne en grafisk bru­ger­græn­se­fla­de, der gør det muligt at udvikle, im­ple­men­te­re og di­stri­bu­e­re komplekse ap­pli­ka­tio­ner baseret på Docker-con­tai­ne­re på en nem måde ved hjælp af træk-og-slip.

Panamax gør det muligt at gemme komplekse ap­pli­ka­tio­ner med flere con­tai­ne­re som ap­pli­ka­tions­ska­be­lo­ner og di­stri­bu­e­re dem i klyn­gear­ki­tek­tu­rer med et enkelt klik. Via en in­te­gre­ret app-mar­keds­plads, der hostes på GitHub, kan ska­be­lo­ner til bru­ger­de­fi­ne­re­de ap­pli­ka­tio­ner gemmes i Git-repo­si­to­ri­er og gøres til­gæn­ge­li­ge for andre brugere.

De grund­læg­gen­de kom­po­nen­ter i Panamax-ar­ki­tek­tu­ren kan inddeles i to grupper: Panamax Local Client og et vil­kår­ligt antal eksterne im­ple­men­te­rings­mål.

Den lokale Panamax-klient er kernen i dette Docker-værktøj. Den kører på det lokale system og gør det muligt at oprette komplekse con­tai­ner­ba­se­re­de ap­pli­ka­tio­ner. Den lokale klient består af følgende kom­po­nen­ter:

• CoreOS: In­stal­la­tion af den lokale Panamax-klient kræver Linux-di­stri­bu­tio­nen CoreOS som vært­sy­stem, som er specielt udviklet til softwa­recon­tai­ne­re. Panamax-klienten kører derefter som en Docker-container i CoreOS. Ud over Docker-funk­tio­ner­ne har brugerne adgang til for­skel­li­ge CoreOS-funk­tio­ner. Disse omfatter blandt andet Fleet og Jour­nalctl:
• Fleet: I stedet for at integrere direkte med Docker bruger Panamax-klienten clus­ter­ma­na­ge­ren Fleet til at or­ke­stre­re sine con­tai­ne­re. Fleet er en clus­ter­ma­na­ger, der styrer Linux-daemonen systemd i com­pu­ter­klyn­ger.
• Jour­nalctl: Panamax-klienten bruger Jour­nalctl til at anmode om log­med­del­el­ser fra Linux-sy­stemad­mi­ni­stra­to­ren systemd fra journalen.
• Lokal kli­en­tin­stal­la­tions­pro­gram: Det lokale kli­en­tin­stal­la­tions­pro­gram in­de­hol­der alle kom­po­nen­ter, der er nød­ven­di­ge for at in­stal­le­re Panamax-klienten på et lokalt system.
• Panamax lokal agent: den centrale komponent i den lokale klient er den lokale agent. Denne er forbundet med for­skel­li­ge andre kom­po­nen­ter og af­hæn­gig­he­der via Panamax API. Disse omfatter den lokale Docker-host, Panamax UI, eksterne registre og fjer­na­gen­ter­ne for im­ple­men­te­rings­må­le­ne i klyngen. Den lokale agent in­ter­a­ge­rer med følgende pro­gram­græn­se­fla­der på det lokale system via Panamax API for at udveksle op­lys­nin­ger om kørende ap­pli­ka­tio­ner:
• Docker-fjern-API: Panamax søger efter billeder på det lokale system via Docker-fjern-API’en og indhenter op­lys­nin­ger om kørende con­tai­ne­re.
• etcd API: filer overføres til CoreOS Fleet-daemonen via etcd API.
• systemd-journal-gatewayd.services: Panamax henter jour­na­lud­skrif­ten for kørende tjenester via systemd-journal-gatewayd.services.

Desuden muliggør Panamax API også in­te­gra­tion med for­skel­li­ge eksterne API’er.

• Docker Registry API: Panamax henter bil­led­tags fra Docker Registry via Docker Registry API.
• GitHub-API: Panamax indlæser ska­be­lo­ner fra GitHub-repo­si­to­ri­et ved hjælp af GitHub-API’en.
• Kis­sMe­tri­cs API: Kis­sMe­tri­cs API indsamler data om ska­be­lo­ner, som brugerne kører.
• Panamax UI: Panamax UI fungerer som en bru­ger­græn­se­fla­de på det lokale system og giver brugerne mulighed for at styre Docker-værktøjet via en grafisk græn­se­fla­de. Bru­ger­ind­tast­nin­ger vi­de­re­sen­des direkte til den lokale agent via Panamax API. Panamax UI er baseret på CTL Base UI Kit, et bibliotek med UI-kom­po­nen­ter til webpro­jek­ter fra Cen­tury­Link.

I Panamax-ter­mi­no­lo­gi­en betegnes hver node i et Docker-klynge uden ad­mi­ni­stra­tions­op­ga­ver som et eksternt im­ple­men­te­rings­mål. Im­ple­men­te­rings­mål består af en Docker-vært, der er kon­fi­gu­re­ret til at im­ple­men­te­re Panamax-ska­be­lo­ner ved hjælp af følgende kom­po­nen­ter:

• In­stal­la­tions­pro­gram til im­ple­men­te­rings­mål: In­stal­la­tions­pro­gram­met til im­ple­men­te­rings­mål starter en Docker-vært, komplet med en Panamax-fjer­na­gent og en or­ke­stre­rings­a­dap­ter.
• Panamax-fjer­na­gent: Hvis der er in­stal­le­ret en Panamax-fjer­na­gent, kan ap­pli­ka­tio­ner di­stri­bu­e­res via den lokale Panamax-klient til ethvert ønsket slutpunkt i klyngen. Panamax-fjer­na­gen­ten kører som en Docker-container på hvert im­ple­men­te­rings­mål i klyngen.
• Panamax-or­ke­stre­rings­a­dap­ter: I or­ke­stre­rings­a­dap­te­ren leveres pro­gram­lo­gik­ken for hvert or­ke­stre­rings­værk­tøj, der er til­gæn­ge­ligt for Panamax, i et uaf­hæn­gigt adap­ter­lag. På grund af dette har brugerne mulighed for altid at vælge den nøjagtige or­ke­stre­rings­tek­no­lo­gi, der skal un­der­støt­tes af deres målmiljø. For­ud­kon­fi­gu­re­re­de adaptere in­klu­de­rer Ku­ber­ne­tes og Fleet:
• Panamax Ku­ber­ne­tes-adapter: I kom­bi­na­tion med Panamax-fjer­na­gen­ten muliggør Panamax Ku­ber­ne­tes-adapteren di­stri­bu­tion af Panamax-ska­be­lo­ner i Ku­ber­ne­tes-klynger.
• Panamax Fleet-adapter: I kom­bi­na­tion med Panamax-fjer­na­gen­ten muliggør Panamax Fleet-adapteren di­stri­bu­tion af Panamax-ska­be­lo­ner i klynger, der styres ved hjælp af Fleet-klyn­ge­ma­na­ge­ren.

Følgende figur viser sam­spil­let mellem de enkelte Panamax-kom­po­nen­ter i et Docker-cluster:

Det CoreOS-baserede con­tai­ne­rad­mi­ni­stra­tions­værk­tøj Panamax giver brugerne adgang til en række stan­dard­tek­no­lo­gi­er til con­tai­ner­or­ke­stre­ring via en grafisk bru­ger­græn­se­fla­de samt mu­lig­he­den for nemt at ad­mi­ni­stre­re komplekse ap­pli­ka­tio­ner med flere con­tai­ne­re i klyn­gear­ki­tek­tu­rer fra ethvert system (f.eks. din egen bærbare computer).

Med Panamax’ of­fent­li­ge ska­be­lo­nar­kiv har Panamax-brugere adgang til et of­fent­ligt ska­be­lon­bi­bli­o­tek med for­skel­li­ge res­sour­cer via GitHub.

Drone

Drone er en strøm­li­net platform til kon­ti­nu­er­lig in­te­gra­tion med minimale krav. Med dette Docker-værktøj kan du au­to­ma­tisk hente din nyeste build fra et Git-repo­si­tory som f.eks. GitHub og teste den i isolerede Docker-con­tai­ne­re. Du kan køre enhver testsuite og sende rapporter og sta­tus­med­del­el­ser via e-mail. For hver softwa­re­test oprettes der en ny container baseret på billeder fra det of­fent­li­ge Docker-register. Det betyder, at ethvert of­fent­ligt til­gæn­ge­ligt Docker-billede kan bruges som miljø til at teste koden.

Drone er in­te­gre­ret i Docker og un­der­støt­tes af for­skel­li­ge pro­gram­me­rings­sprog, såsom PHP, Node.js, Ruby, Go og Python. Con­tai­ner­p­lat­for­men er den eneste egentlige for­ud­sæt­ning. Du kan oprette din egen per­son­li­ge platform til kon­ti­nu­er­lig in­te­gra­tion med Drone på ethvert system, hvor Docker kan in­stal­le­res. Drone un­der­støt­ter for­skel­li­ge ver­sions­sty­rings­repo­si­to­ri­er, og du kan finde en vej­led­ning til stan­dar­din­stal­la­tio­nen med GitHub-in­te­gra­tion på open source-pro­jek­tets hjem­mesi­de under readme.drone.io.

Ad­mi­ni­stra­tio­nen af plat­for­men til kon­ti­nu­er­lig in­te­gra­tion foregår via en web­græn­se­fla­de. Her kan du hente software-builds fra ethvert Git-repo­si­tory, flette dem sammen til ap­pli­ka­tio­ner og køre re­sul­ta­tet i et for­ud­de­fi­ne­ret testmiljø. Til dette formål oprettes der en .drone.yml-fil, der angiver, hvordan ap­pli­ka­tio­nen skal oprettes og køres for hver enkelt softwa­re­test.

Drone-brugere får en open source-CI-løsning, der forener styrkerne ved al­ter­na­ti­ve produkter som Travis og Jenkins i et bru­ger­ven­ligt program.

OpenStack

Når det drejer sig om at opbygge og drive open source-clo­ud­løs­nin­ger, er open source-cloudo­pe­ra­tiv­sy­ste­met OpenStack den fo­re­truk­ne softwa­re­løs­ning.

Med OpenStack kan du ad­mi­ni­stre­re computer-, lager- og net­værks­res­sour­cer fra et centralt kon­trol­pa­nel og gøre dem til­gæn­ge­li­ge for slut­bru­ger­ne via en web­græn­se­fla­de.

Cloud-ope­ra­tiv­sy­ste­met er baseret på en modulær ar­ki­tek­tur, der består af flere kom­po­nen­ter:

• Zun (con­tai­nertje­ne­ste): Zun er Open­Sta­cks con­tai­nertje­ne­ste og gør det nemt at im­ple­men­te­re og ad­mi­ni­stre­re con­tai­ner­ba­se­re­de ap­pli­ka­tio­ner i OpenStack-skyen. Formålet med Zun er at give brugerne mulighed for at ad­mi­ni­stre­re con­tai­ne­re via et REST API uden at skulle ad­mi­ni­stre­re servere eller klynger. For at kunne bruge Zun skal du have tre andre OpenStack-tjenester, nemlig Keystone, Neutron og kryr-lib­network. Zuns funk­tio­na­li­tet kan også udvides gennem yder­li­ge­re OpenStack-tjenester såsom Cinder og Glance.
• Neutron (net­værks­kom­po­nent): Neutron (tidligere Quantum) er en bærbar, skalerbar API-un­der­støt­tet sy­stem­kom­po­nent, der bruges til net­værks­sty­ring. Modulet giver en græn­se­fla­de til komplekse net­værk­stopo­lo­gi­er og un­der­støt­ter for­skel­li­ge plugins, hvori­gen­nem udvidede net­værks­funk­tio­ner kan in­te­gre­res.
• kuryr-lib­network (Docker-driver): kuryr-lib­network er en driver, der fungerer som en græn­se­fla­de mellem Docker og Neutron.
• Cinder (bloklager): Cinder er kæ­le­nav­net for en komponent i OpenStack-ar­ki­tek­tu­ren, der leverer ved­va­ren­de bloklager til drift af VM’er. Modulet leverer virtuelt lager via en selv­be­tje­nings-API. Gennem dette kan slut­bru­ge­re gøre brug af la­gerre­s­sour­cer uden at være klar over, hvilken enhed der leverer lageret.
• Keystone (iden­ti­tet­stje­ne­ste): Keystone leverer en central iden­ti­tet­stje­ne­ste til OpenStack-brugere. Modulet fungerer som et god­ken­del­ses- og til­la­del­ses­sy­stem mellem de enkelte OpenStack-kom­po­nen­ter. Adgangen til projekter i skyen reguleres af lejere. Hver lejer re­præ­sen­te­rer en bruger, og der kan defineres flere bru­ge­r­ad­gan­ge med for­skel­li­ge ret­tig­he­der.
• Glance (bil­ledtje­ne­ste): Med Glance-modulet leverer OpenStack en tjeneste, der gør det muligt at gemme og hente billeder af virtuelle maskiner.

Du kan finde mere in­for­ma­tion om OpenStack-kom­po­nen­ter og -tjenester i vores artikel om OpenStack.

Ud over de oven­nævn­te kom­po­nen­ter kan OpenStack-ar­ki­tek­tu­ren udvides ved hjælp af for­skel­li­ge moduler. Du kan læse mere om de for­skel­li­ge valgfrie moduler på Open­Sta­cks hjem­mesi­de.

D2iQ DC/OS

DC/OS (Di­stri­bu­ted Cloud Operating System) er et open source-program til drift af di­stri­bu­e­re­de systemer, udviklet af D2iQ Inc. (tidligere Mesosp­he­re). Projektet er baseret på den open source-baserede clus­ter­ma­na­ger Apache Mesos og er et ope­ra­tiv­sy­stem til da­ta­cen­tre. Kil­de­ko­den er til­gæn­ge­lig for brugere under Apache-licens version 2 i DC/OS-repo­si­to­ri­er­ne på GitHub. En en­ter­pri­se-version af softwaren er også til­gæn­ge­lig på d2iq.com. Om­fat­ten­de pro­jek­t­do­ku­men­ta­tion kan findes på dcos.io.

Man kan betragte DC/OS som en Mesos-di­stri­bu­tion, der giver dig adgang til alle clus­ter­ma­na­ge­rens funk­tio­ner (via en central bru­ger­græn­se­fla­de) og udvider Mesos be­ty­de­ligt.

DC/OS bygger på Mesos-plat­for­mens kerne til di­stri­bu­e­re­de systemer. Dette gør det muligt at samle res­sour­cer­ne i et helt da­ta­cen­ter og ad­mi­ni­stre­re dem som et samlet system, ligesom en enkelt logisk server. På den måde kan du styre hele klynger af fysiske eller virtuelle maskiner lige så nemt, som du ville betjene en enkelt computer.

Softwaren forenkler in­stal­la­tion og ad­mi­ni­stra­tion af di­stri­bu­e­re­de ap­pli­ka­tio­ner og au­to­ma­ti­se­rer opgaver såsom res­sour­ce­ad­mi­ni­stra­tion, plan­læg­ning og kom­mu­ni­ka­tion mellem processer. Ad­mi­ni­stra­tio­nen af et cluster baseret på D2iQ DC/OS samt de med­føl­gen­de tjenester foregår via et centralt kom­man­do­linje­pro­gram (CLI) eller en web­græn­se­fla­de (GUI).

DC/OS isolerer klyngens res­sour­cer og leverer fælles tjenester, såsom tje­ne­ste­o­p­da­gel­se og pak­ke­hånd­te­ring. Softwa­rens ker­ne­kom­po­nen­ter kører i et beskyttet område – ker­nel­ker­nen. Dette omfatter master- og agent­pro­gram­mer­ne i Mesos-plat­for­men, som varetager res­sour­ce­al­lo­ke­ring, pro­ce­si­so­le­ring og sik­ker­heds­funk­tio­ner.

• Mesos-master: Mesos-masteren er en ma­ster­pro­ces, der kører på en master-node. Formålet med Mesos-masteren er at styre res­sour­ce­hånd­te­rin­gen og ko­or­di­ne­re opgaver (abstrakte ar­bejd­s­en­he­der), der udføres på en agent-node. Til dette formål fordeler Mesos-masteren res­sour­cer til re­gi­stre­re­de DC/OS-tjenester og modtager res­sour­ce­rap­por­ter fra Mesos-agenter.
• Mesos-agenter: Mesos-agenter er processer, der kører på agent­kon­ti og er an­svar­li­ge for at udføre de opgaver, der fordeles af masteren. Mesos-agenter leverer re­gel­mæs­si­ge rapporter om de til­gæn­ge­li­ge res­sour­cer i klyngen til Mesos-masteren. Disse vi­de­re­sen­des af Mesos-masteren til en scheduler (dvs. Marathon, Chronos eller Cassandra). Denne beslutter, hvilken opgave der skal køres på hvilken node. Opgaverne udføres derefter i en container på en isoleret måde.

Alle øvrige sy­stem­kom­po­nen­ter samt ap­pli­ka­tio­ner, der køres af Mesos-agenterne via executor, kører i bru­ger­rum­met. De grund­læg­gen­de kom­po­nen­ter i en stan­dar­din­stal­la­tion af DC/OS er admin-routeren, Mesos DNS, en di­stri­bu­e­ret DNS-proxy, load ba­lan­ce­ren Minuteman, sche­du­le­ren Marathon, Apache ZooKeeper og Exhibitor.

• Admin-router: Admin-routeren er en specielt kon­fi­gu­re­ret webserver baseret på NGINX, der leverer DC/OS-tjenester samt centrale god­ken­del­ses- og proxy­funk­tio­ner.
• Mesos DNS: Sy­stem­kom­po­nen­ten Mesos DNS leverer ser­vi­ce­op­da­gel­ses­funk­tio­ner, der gør det muligt for in­di­vi­du­el­le tjenester og ap­pli­ka­tio­ner i klyngen at iden­ti­fi­ce­re hinanden via et centralt do­mæ­ne­nav­ne­sy­stem (DNS).
• Di­stri­bu­e­ret DNS-proxy: Den di­stri­bu­e­re­de DNS-proxy er en intern DNS-dis­pat­cher.
• Minuteman: Sy­stem­kom­po­nen­ten Minuteman fungerer som en intern load balancer, der arbejder på trans­port­la­get (Layer 4) i OSI-re­fe­ren­ce­mo­del­len.
• DC/OS Marathon: Marathon er en central komponent i Mesos-plat­for­men, der fungerer i D2iQ DC/OS som et init-system (svarende til systemd). Marathon starter og overvåger DC/OS-tjenester og -ap­pli­ka­tio­ner i klyn­ge­mil­jø­er. Derudover leverer softwaren højtil­gæn­ge­lig­heds­funk­tio­ner, ser­vi­ce­op­da­gel­se, be­last­nings­ba­lan­ce­ring, sund­hed­s­tjek og en grafisk web­græn­se­fla­de.
• Apache ZooKeeper: Apache ZooKeeper er en open source-softwa­re­kom­po­nent, der leverer ko­or­di­ne­rings­funk­tio­ner til drift og styring af ap­pli­ka­tio­ner i di­stri­bu­e­re­de systemer. ZooKeeper bruges i D2iQ DC/OS til ko­or­di­ne­ring af alle in­stal­le­re­de sy­stemtje­ne­ster.
• Exhibitor: Exhibitor er en sy­stem­kom­po­nent, der au­to­ma­tisk in­stal­le­res og kon­fi­gu­re­res sammen med ZooKeeper på hver master-node. Exhibitor leverer også en grafisk bru­ger­græn­se­fla­de til ZooKeeper-brugere.

For­skel­li­ge ar­bejds­op­ga­ver kan udføres samtidigt på klyn­geres­sour­cer, der samles via DC/OS. Dette muliggør for eksempel parallel drift på klyn­ge­o­pe­ra­tiv­sy­ste­met af big data-systemer, mi­kro­tje­ne­ster eller con­tai­ner­p­lat­for­me som Hadoop, Spark og Docker.

I D2iQ Universe findes der et of­fent­ligt app-katalog til DC/OS. Her kan du in­stal­le­re ap­pli­ka­tio­ner som Spark, Cassandra, Chronos, Jenkins eller Kafka ved blot at klikke i den grafiske bru­ger­græn­se­fla­de.

Hvilke Docker-værktøjer findes der til sikkerhed?

Selvom ind­kaps­le­de processer, der kører i con­tai­ne­re, deler den samme kerne, bruger Docker en række teknikker til at isolere dem fra hinanden. Til dette formål anvendes der typisk centrale funk­tio­ner i Linux-kernen, såsom Cgroups og Na­mes­pa­ces.

Con­tai­ne­re tilbyder dog stadig ikke samme grad af isolation, som man kan opnå med virtuelle maskiner. På trods af brugen af iso­le­rings­tek­nik­ker kan vigtige ker­nesub­sy­ste­mer som f.eks. Cgroups samt ker­ne­græn­se­fla­der i mapperne /sys og /proc nås via con­tai­ne­re.

Docker-ud­vik­ler­tea­met har erkendt, at disse sik­ker­heds­pro­ble­mer udgør en hindring for ind­fø­rel­sen af con­tai­ner­tek­no­lo­gi i pro­duk­tions­sy­ste­mer. Ud over de grund­læg­gen­de iso­le­rings­tek­nik­ker i Linux-kernen un­der­støt­ter nyere versioner af Docker Engine også ram­me­vær­ker­ne AppArmor, SELinux og Seccomp, som fungerer som en slags firewall for centrale res­sour­cer.

• AppArmor: Med AppArmor reguleres con­tai­ner­nes ad­gangs­ret­tig­he­der til fil­sy­ste­mer­ne.
• SELinux: SELinux tilbyder et komplekst re­gu­le­rings­sy­stem, hvor ad­gangs­kon­trol til centrale res­sour­cer kan im­ple­men­te­res.
• Seccomp: Seccomp (Secure Computing Mode) overvåger ud­fø­rel­sen af sy­stem­kald.

Ud over disse Docker-værktøjer benytter Docker sig også af Linux-funk­tio­ner til at begrænse de root-ret­tig­he­der, som Docker Engine starter con­tai­ne­re med.

Der er også andre sik­ker­heds­mæs­si­ge be­kym­rin­ger ved­rø­ren­de sår­bar­he­der i software inden for ap­pli­ka­tions­kom­po­nen­ter, der di­stri­bu­e­res via Docker-registret. Da stort set alle kan oprette Docker-billeder og gøre dem of­fent­ligt til­gæn­ge­li­ge for fæl­les­ska­bet på Docker Hub, er der en risiko for, at der indføres ondsindet kode i dit system, når du down­lo­a­der et billede. Inden en ap­pli­ka­tion tages i brug, bør Docker-brugere sikre sig, at al kode i et billede, der bruges til at køre con­tai­ne­re, stammer fra en pålidelig kilde.

Docker tilbyder et ve­ri­fi­ka­tions­pro­gram, som softwa­reud­by­de­re kan benytte til at få deres Docker-images kon­trol­le­ret og ve­ri­fi­ce­ret. Med dette ve­ri­fi­ka­tions­pro­gram ønsker Docker at gøre det lettere for udviklere at opbygge sikre softwa­re­le­ve­ran­dør­kæ­der til deres projekter. Ud over at øge sik­ker­he­den for brugerne har pro­gram­met til formål at give softwa­re­ud­vik­le­re en mulighed for at dif­fe­ren­ti­e­re deres projekter fra de mange andre res­sour­cer, der findes på markedet. Ve­ri­fi­ce­re­de billeder er markeret med et “Verified Publisher “-badge og får, ud over andre fordele, en højere placering i sø­ge­re­sul­ta­ter­ne på Docker Hub.