Vilka är de bästa Docker-verktygen? En översikt

Det om­fat­tan­de Docker- eko­sy­ste­met erbjuder ut­veck­la­re en rad möj­lig­he­ter att dis­tri­bu­e­ra ap­pli­ka­tio­ner, samordna con­tain­rar och mycket mer. Vi går igenom de vik­ti­gas­te Docker-verktygen och ger dig en översikt över de mest populära tred­je­parts­pro­jek­ten som utvecklar öppen käll­kods­verk­tyg för Docker.

Vilka är de vik­ti­gas­te Docker-verktygen/kom­po­nen­ter­na?

Idag är Docker mycket mer än bara en so­fisti­ke­rad plattform för hantering av pro­gram­va­ru­kon­tain­rar. Ut­veck­la­re har skapat en rad olika Docker-verktyg för att göra dis­tri­bu­tio­nen av ap­pli­ka­tio­ner via dis­tri­bu­e­rad in­fra­struk­tur och moln­mil­jö­er enklare, snabbare och mer flexibel. Förutom verktyg för klustring och or­kest­re­ring finns det också en central app­mark­nads­plats och ett verktyg för hantering av moln­re­sur­ser.

Docker-motor

När ut­veck­la­re säger ”Docker” menar de van­ligt­vis denöppen käll­kods­ba­se­ra­de klient-ser­ve­rap­pli­ka­tio­nen somutgör grunden för con­tai­ner­platt­for­men. Denna ap­pli­ka­tion kallas Docker Engine. Centrala kom­po­nen­ter i Docker Engine är Docker-daemonen, ett REST API och ett CLI (kom­man­do­rads­gräns­snitt) som fungerar som an­vän­dar­gräns­snitt.

Med denna design kan du kom­mu­ni­ce­ra med Docker Engine via kom­man­do­rads­kom­man­don och hantera Docker-bilder, Docker-filer och Docker-con­tain­rar bekvämt från ter­mi­na­len.

Du hittar en de­tal­je­rad be­skriv­ning av Docker Engine i vår Docker-hand­led­ning för nybörjare Docker-hand­led­ning: in­stal­la­tion och första stegen.

Docker Hub

Docker Hub till­han­da­hål­ler an­vän­dar­na ett moln­ba­se­rat register som gör det möjligt att ladda ner Docker-bilder, hantera dem centralt och dela dem med andra Docker-användare. Re­gi­stre­ra­de användare kan lagra Docker-bilder of­fent­ligt eller i privata arkiv. För att ladda ner en offentlig bild (kallas för att hämta i Docker-ter­mi­no­lo­gi) krävs inget an­vän­dar­kon­to. En in­te­gre­rad tagg­me­ka­nism möjliggör ver­sions­han­te­ring av bilder.

Förutom andra Docker-an­vän­da­res of­fent­li­ga arkiv finns det också många resurser från Docker-ut­veck­lings­tea­met och välkända open source-projekt som finns i de of­fi­ci­el­la arkiven i Docker Hub. De mest populära Docker-bilderna in­klu­de­rar NGINX-webb­ser­vern, Redis-databasen i minnet, BusyBox Unix-verk­tygs­sat­sen och Ubuntu Linux-dis­tri­bu­tio­nen.

Or­ga­ni­sa­tio­ner är en annan viktig funktion i Docker Hub, som gör det möjligt för Docker-användare att skapa privata arkiv som endast är till­gäng­li­ga för en utvald grupp av personer. Åt­komsträt­tig­he­ter hanteras inom en or­ga­ni­sa­tion med hjälp av team och grupp­med­lem­skap.

Docker Swarm

Docker Engine in­ne­hål­ler en inbyggd funktion som gör det möjligt för an­vän­dar­na att hantera Docker-värdar i kluster som kallas swarms. De klus­ter­han­te­rings- och or­kest­re­rings­funk­tio­ner som är inbyggda i Docker Engine baseras på verk­tygs­lå­dan Swarmkit. Om du använder en äldre version av con­tai­ner­platt­for­men finns Docker-verktyget till­gäng­ligt som en fri­ståen­de ap­pli­ka­tion.

Som ett inbyggt Docker-klus­ter­verk­tyg samlar Swarm en pool av Docker-värdar i en enda virtuell värd och betjänar Docker REST API. Alla Docker-verktyg som är kopplade till Docker-daemonen kan komma åt Swarm och skalas över valfritt antal Docker-värdar. Med Docker Engine CLI kan användare skapa svärmar, dis­tri­bu­e­ra ap­pli­ka­tio­ner i klustret och hantera svär­mar­nas beteende utan att behöva använda yt­ter­li­ga­re or­kest­re­rings­pro­gram­va­ra.

Docker-motorer som har kom­bi­ne­rats till kluster körs i swarm-läge. Välj detta om du vill skapa ett nytt kluster eller lägga till en Docker-värd till en befintlig swarm. Enskilda Docker-värdar i ett kluster kallas för ”noder”. Noderna i ett kluster kan köras som virtuella värdar på samma lokala system, men oftare används en moln­ba­se­rad design, där de enskilda noderna i Docker-swarm dis­tri­bue­ras över olika system och in­fra­struk­tu­rer.

Pro­gram­va­ran är baserad på en master-worker-ar­ki­tek­tur. När uppgifter ska fördelas i svärmen överför an­vän­dar­na en tjänst till manager-noden. Managern ansvarar sedan för sche­malägg­ning­en av con­tain­rar i klustret och fungerar som ett primärt an­vän­dar­gräns­snitt för åtkomst till svärm­re­sur­ser.

Manager-noden skickar enskilda enheter, så kallade uppgifter, till ar­be­tar­no­der­na.

• Tjänster: Tjänster är centrala struk­tu­rer i Docker-kluster. En tjänst de­fi­ni­e­rar en uppgift som ska utföras i ett Docker-kluster. En tjänst avser en grupp con­tain­rar som baseras på samma bild. När en tjänst skapas anger an­vän­da­ren vilken bild och vilka kommandon som ska användas. Dessutom erbjuder tjäns­ter­na möjlighet att skala ap­pli­ka­tio­ner. Användare av Docker-platt­for­men de­fi­ni­e­rar helt enkelt hur många con­tain­rar som ska startas för en tjänst.
• Uppgifter: för att dis­tri­bu­e­ra tjänster i klustret delas de upp i enskilda ar­bet­sen­he­ter (uppgifter) av han­te­rings­no­den. Varje uppgift in­ne­hål­ler en Docker-container samt de kommandon som exekveras i den.

Förutom hantering av klus­ter­kon­troll och sam­ord­ning av con­tain­rar kan manager-noder som standard även utföra worker-nod­funk­tio­ner – såvida du inte strikt begränsar dessa noders uppgifter till hantering.

Ett agent­pro­gram körs på varje ar­be­tar­nod. Detta ac­cep­te­rar uppgifter och till­han­da­hål­ler re­spek­ti­ve hu­vud­nod­sta­tus­rap­por­ter om fram­ste­gen för den överförda uppgiften. Följande bild visar en sche­ma­tisk re­pre­sen­ta­tion av en Docker Swarm:

När man im­ple­men­te­rar en Docker Swarm förlitar sig an­vän­dar­na i allmänhet på Docker-maskinen.

Docker Compose

Docker Compose gör det möjligt att slå samman flera con­tain­rar och köra dem med ett enda kommando. Grun­de­le­men­tet i Compose är den centrala kon­troll­fi­len som baseras på det pris­be­lön­ta språket YAML. Syntaxen i denna compose-fil liknar den i den öppna käll­kods­pro­gram­va­ran Vagrant, som används vid skapande och pro­vi­sio­ne­ring av virtuella maskiner.

I filen docker-compose.yml kan du definiera valfritt antal pro­gram­va­ru­kon­tain­rar, inklusive alla beroenden, samt deras re­la­tio­ner till varandra. Sådana ap­pli­ka­tio­ner med flera kon­tain­rar styrs enligt samma mönster som enskilda pro­gram­va­ru­kon­tain­rar. Använd kommandotdocker-compose i kom­bi­na­tion med önskat un­der­kom­man­do för att hantera hela ap­pli­ka­tio­nens livscykel.

Detta Docker-verktyg kan enkelt in­te­gre­ras i ett kluster baserat på Swarm. På så sätt kan du köra mul­ti­con­tai­ner-ap­pli­ka­tio­ner skapade med Compose på dis­tri­bu­e­ra­de system lika enkelt som på en enskild Docker-värd.

En annan funktion i Docker Compose är en in­te­gre­rad skal­nings­me­ka­nism. Med or­kest­re­rings­verk­ty­get kan du enkelt använda kom­man­do­rads­pro­gram­met för att definiera hur många con­tain­rar du vill starta för en viss tjänst.

Vilka tred­je­parts­verk­tyg för Docker finns det?

Förutom den interna ut­veck­ling­en från Docker Inc. finns det olika pro­gram­va­ru­verk­tyg och platt­for­mar från externa le­ve­ran­tö­rer som till­han­da­hål­ler gräns­snitt för Docker Engine eller som har ut­veck­lats speciellt för den populära con­tai­ner­platt­for­men. Inom Docker-eko­sy­ste­met är de mest populära open source-projekten or­kest­re­rings­verk­ty­get Ku­ber­ne­tes, klus­ter­han­te­rings­verk­ty­get Shipyard, lösningen för transport av flera con­tain­rar Panamax, platt­for­men för kon­ti­nu­er­lig in­teg­ra­tion Drone, det moln­ba­se­ra­de ope­ra­tiv­sy­ste­met OpenStack och da­ta­cen­te­ro­pe­ra­tiv­sy­ste­met D2iQ DC/OS, som baseras på klus­ter­han­te­ra­ren Mesos.

Ku­ber­ne­tes

Det är inte alltid möjligt för Docker att ta fram egna or­kest­re­rings­verk­tyg som Swarm och Compose. Av denna anledning har olika företag under flera år in­ve­ste­rat i egen ut­veck­ling för att skapa skräd­dar­syd­da verktyg som un­der­lät­tar driften av con­tai­ner­platt­for­men i stora, dis­tri­bu­e­ra­de in­fra­struk­tu­rer. En av de mest populära lös­ning­ar­na av detta slag är open source-projektet Ku­ber­ne­tes.

Ku­ber­ne­tes är en klus­ter­han­te­ra­re för con­tai­ner­ba­se­ra­de ap­pli­ka­tio­ner. Målet med Ku­ber­ne­tes är att au­to­ma­ti­se­ra ap­pli­ka­tio­ner i ett kluster. För att göra detta använder or­kest­re­rings­verk­ty­get ett REST-API, ett kom­man­do­rads­pro­gram och ett grafiskt webb­gräns­snitt som kon­troll­gräns­snitt. Med dessa gräns­snitt kan au­to­ma­ti­se­ring­ar initieras och sta­tus­rap­por­ter begäras. Du kan använda Ku­ber­ne­tes för att:

• köra con­tai­ner­ba­se­ra­de foton på ett kluster,
• in­stal­le­ra och hantera ap­pli­ka­tio­ner i dis­tri­bu­e­ra­de system,
• skalera ap­pli­ka­tio­ner och
• använda hårdvara på bästa möjliga sätt.

För detta ändamål kom­bi­ne­rar Ku­ber­ne­tes con­tain­rar till logiska delar, som kallas pods. Pods re­pre­sen­te­rar klus­ter­han­te­ra­rens grund­läg­gan­de enheter, som kan dis­tri­bue­ras i klustret genom sche­malägg­ning.

Precis som Docker Swarm är även Ku­ber­ne­tes baserat på en master-worker-ar­ki­tek­tur. Ett kluster består av en Ku­ber­ne­tes-master och en rad arbetare, som också kallas Ku­ber­ne­tes-noder (eller minions). Ku­ber­ne­tes-mastern fungerar som en central kon­troll­plan i klustret och består av fyra grund­läg­gan­de kom­po­nen­ter, vilket möjliggör direkt kom­mu­ni­ka­tion i klustret och upp­gifts­för­del­ning. En Ku­ber­ne­tes-master består av en API-server, kon­fi­gu­ra­tions­min­net etcd, en sche­maläg­ga­re och en kon­troll­han­te­ra­re.

• API-server: alla au­to­ma­ti­se­ring­ar i Ku­ber­ne­tes-klustret initieras med REST-API via en API-server. Denna fungerar som det centrala ad­mi­nist­ra­tions­gräns­snit­tet i klustret.
• etcd: du kan tänka dig det öppna käll­kods­ba­se­ra­de kon­fi­gu­ra­tions­min­net etcd som Ku­ber­ne­tes-klustrets minne. Key Value Store, som CoreOS utvecklat speciellt för dis­tri­bu­e­ra­de system, lagrar kon­fi­gu­ra­tions­da­ta och gör den till­gäng­lig för varje nod i klustret. Klustrets aktuella tillstånd kan hanteras när som helst via etcd.
• Scheduler: Sche­du­lern ansvarar för att dis­tri­bu­e­ra con­tai­ner­grup­per (pods) i klustret. Den bestämmer re­surs­be­ho­vet för en pod och matchar sedan detta med de till­gäng­li­ga re­sur­ser­na för de enskilda noderna i klustret.
• Con­trol­ler manager: con­trol­ler manager är en tjänst i Ku­ber­ne­tes master och styr or­kest­re­ring­en genom att reglera klustrets tillstånd och utföra ru­tin­upp­gif­ter. Con­trol­ler manager har som hu­vud­upp­gift att se till att klustrets tillstånd motsvarar det de­fi­ni­e­ra­de mål­till­stån­det.

De över­gri­pan­de kom­po­nen­ter­na i Ku­ber­ne­tes-mastern kan placeras på samma värd eller dis­tri­bue­ras över flera mas­ter­vär­dar inom ett kluster med hög till­gäng­lig­het.

Medan Ku­ber­ne­tes-mastern ansvarar för or­kest­re­ring­en, körs podarna som dis­tri­bue­ras i klustret på värdar, Ku­ber­ne­tes-noder, som är un­der­ord­na­de mastern. För att göra detta måste en con­tai­ner­mo­tor köras på varje Ku­ber­ne­tes-nod. Även om Docker är de facto-stan­dar­den, behöver Ku­ber­ne­tes inte använda en specifik con­tai­ner­mo­tor.

Förutom con­tai­ner­mo­torn omfattar Ku­ber­ne­tes-noderna följande kom­po­nen­ter:

• kubelet: kubelet är en agent som körs på varje Ku­ber­ne­tes-nod och används för att styra och hantera noden. Som central kon­takt­punkt för varje nod är kubelet ansluten till Ku­ber­ne­tes-mastern och sä­ker­stäl­ler att in­for­ma­tion vi­da­re­be­fordras till och tas emot från kon­troll­pla­net.
• kube-proxy: dessutom körs prox­y­tjäns­ten kube-proxy på varje Ku­ber­ne­tes-nod. Detta sä­ker­stäl­ler att för­fråg­ning­ar från utsidan vi­da­re­be­fordras till re­spek­ti­ve con­tain­rar och till­han­da­hål­ler tjänster till användare av con­tai­ner­ba­se­ra­de ap­pli­ka­tio­ner. Kube-proxy erbjuder också ru­di­men­tär last­ba­lan­se­ring.

Följande bild visar en sche­ma­tisk re­pre­sen­ta­tion av master-no­dar­ki­tek­tu­ren som or­kest­re­rings­platt­for­men Ku­ber­ne­tes baseras på:

Förutom kärn­pro­jek­tet Ku­ber­ne­tes finns det också ett flertal verktyg och tillägg som gör det möjligt att lägga till yt­ter­li­ga­re funk­tio­na­li­tet till or­kest­re­rings­platt­for­men. De mest populära är över­vak­nings- och fel­di­a­gnos­verk­ty­gen Pro­met­heus, Weave Scope och sysdig, samt pa­ket­han­te­ra­ren Helm. Det finns även plugins för Apache Maven och Gradle, samt ett Java-API som gör det möjligt att fjärr­sty­ra Ku­ber­ne­tes.

Varv

Shipyard är en ge­men­skaps­ut­veck­lad han­te­rings­lös­ning baserad på Swarm som gör det möjligt för användare att un­der­hål­la Docker-resurser som con­tain­rar, bilder, värdar och privata register via ett grafiskt an­vän­dar­gräns­snitt. Den är till­gäng­lig som en web­bap­pli­ka­tion via webb­lä­sa­ren. Förutom klus­ter­han­te­rings­funk­tio­ner­na som kan nås via ett centralt webb­gräns­snitt erbjuder Shipyard även an­vän­da­rau­ten­ti­se­ring och roll­ba­se­rad åt­komst­kon­troll.

Pro­gram­va­ran är 100 % kom­pa­ti­bel med Docker Remote API och använder den öppna käll­kods­da­ta­ba­sen RethinkDB för att lagra data för an­vän­dar­kon­ton, adresser och händelser. Pro­gram­va­ran baseras på klus­ter­han­te­rings­verk­ty­get Citadel och består av tre hu­vud­kom­po­nen­ter: styrenhet, API och an­vän­dar­gräns­snitt.

• Shipyard-kon­trol­ler: kon­trol­lern är kärn­kom­po­nen­ten i han­te­rings­verk­ty­get Shipyard. Shipyard-kon­trol­lern in­te­ra­ge­rar med RethinkDB för att lagra data och gör det möjligt att adressera enskilda värdar i ett Docker-kluster och styra händelser.
• Shipyard API: Shipyard API är baserat på REST. Alla funk­tio­ner i han­te­rings­verk­ty­get styrs via Shipyard API.
• Shipyard-an­vän­dar­gräns­snitt (UI): Shipyard-an­vän­dar­gräns­snit­tet är en AngularJS-app som ger an­vän­dar­na ett grafiskt an­vän­dar­gräns­snitt för hantering av Docker-kluster i webb­lä­sa­ren. Alla in­ter­ak­tio­ner i an­vän­dar­gräns­snit­tet sker via Shipyard API.

Mer in­for­ma­tion om open source-projektet finns på Shipyards of­fi­ci­el­la webbplats.

Panamax

Ut­veck­lar­na av det öppna käll­kods­pro­jek­tet Panamax har som mål att förenkla dis­tri­bu­tio­nen av appar med flera con­tain­rar. Det kost­nads­fria verktyget erbjuder an­vän­dar­na ett grafiskt gräns­snitt som gör det möjligt att enkelt utveckla, dis­tri­bu­e­ra och sprida komplexa ap­pli­ka­tio­ner baserade på Docker-con­tain­rar med hjälp av dra-och-släpp-funk­tio­ner.

Panamax gör det möjligt att spara komplexa ap­pli­ka­tio­ner med flera con­tain­rar som ap­pli­ka­tions­mal­lar och dis­tri­bu­e­ra dem i klu­s­te­rar­ki­tek­tu­rer med bara ett klick. Med hjälp av en in­te­gre­rad app­mark­nads­plats som finns på GitHub kan mallar för själv­ska­pa­de ap­pli­ka­tio­ner lagras i Git-arkiv och göras till­gäng­li­ga för andra användare.

De grund­läg­gan­de kom­po­nen­ter­na i Panamax-ar­ki­tek­tu­ren kan delas in i två grupper: Panamax Local Client och ett obe­grän­sat antal fjärr­dis­tri­bu­tions­mål.

Den lokala Panamax-klienten är kärn­kom­po­nen­ten i detta Docker-verktyg. Den körs på det lokala systemet och gör det möjligt att skapa komplexa con­tai­ner­ba­se­ra­de ap­pli­ka­tio­ner. Den lokala klienten består av följande kom­po­nen­ter:

• CoreOS: in­stal­la­tion av den lokala Panamax-klienten kräver Linux-dis­tri­bu­tio­nen CoreOS som värd­sy­stem, vilket har utformats speciellt för pro­gram­va­ru­kon­tain­rar. Panamax-klienten körs sedan som en Docker-container i CoreOS. Utöver Docker-funk­tio­ner­na har an­vän­dar­na tillgång till olika CoreOS-funk­tio­ner. Dessa in­klu­de­rar bland annat Fleet och Jour­nalctl:
• Fleet: istället för att in­te­gre­ras direkt med Docker använder Panamax-klienten klus­ter­han­te­ra­ren Fleet för att ko­or­di­ne­ra sina con­tain­rar. Fleet är en klus­ter­han­te­ra­re som styr Linux-daemonen systemd i da­torklus­ter.
• Jour­nalctl: Panamax-klienten använder Jour­nalctl för att begära logg­med­de­lan­den från Linux-system­han­te­ra­ren systemd från journalen.
• Lokalt kli­en­tin­stal­la­tions­pro­gram: det lokala kli­en­tin­stal­la­tions­pro­gram­met in­ne­hål­ler alla kom­po­nen­ter som behövs för att in­stal­le­ra Panamax-klienten på ett lokalt system.
• Panamax lokal agent: den centrala kom­po­nen­ten i den lokala klienten är den lokala agenten. Denna är länkad till olika andra kom­po­nen­ter och beroenden via Panamax API. Dessa in­klu­de­rar den lokala Docker-värden, Panamax UI, externa register och fjär­ra­gen­ter­na för dis­tri­bu­tions­må­len i klustret. Den lokala agenten in­te­ra­ge­rar med följande pro­gram­gräns­snitt på det lokala systemet via Panamax API för att utbyta in­for­ma­tion om körande ap­pli­ka­tio­ner:
• Docker Remote API: Panamax söker efter bilder på det lokala systemet via Docker Remote API och hämtar in­for­ma­tion om körande con­tain­rar.
• etcd API: filer överförs till CoreOS Fleet-daemon via etcd API.
• systemd-journal-gatewayd.services: Panamax hämtar jour­nalut­da­ta från körda tjänster via systemd-journal-gatewayd.services.

Dessutom möjliggör Panamax API även in­ter­ak­tio­ner med olika externa API:er.

• Docker-re­gist­rets API: Panamax hämtar bild­tag­gar från Docker-registret via Docker-re­gist­rets API.
• GitHub API: Panamax laddar mallar från GitHub-arkivet med hjälp av GitHub API.
• Kiss­Metrics API: Kiss­Metrics API samlar in data om mallar som an­vän­dar­na kör.
• Panamax UI: Panamax UI fungerar som ett an­vän­dar­gräns­snitt på det lokala systemet och gör det möjligt för användare att styra Docker-verktyget via ett grafiskt gräns­snitt. An­vän­da­rin­mat­ning vi­da­re­be­fordras direkt till den lokala agenten via Panamax API. Panamax UI är baserat på CTL Base UI Kit, ett bibliotek med UI-kom­po­nen­ter för webb­pro­jekt från Cen­tu­ry­Link.

I Panamax-ter­mi­no­lo­gi kallas varje nod i ett Docker-kluster utan för­valt­nings­upp­gif­ter för ett fjärr­dis­tri­bu­tions­mål. Dis­tri­bu­tions­mål består av en Docker-värd som är kon­fi­gu­re­rad för att dis­tri­bu­e­ra Panamax-mallar med hjälp av följande kom­po­nen­ter:

• In­stal­la­tions­pro­gram för dis­tri­bu­tions­mål: in­stal­la­tions­pro­gram­met för dis­tri­bu­tions­mål startar en Docker-värd, komplett med en Panamax-fjär­ra­gent och en or­kest­re­rings­ad­ap­ter.
• Panamax fjär­ra­gent: om en Panamax fjär­ra­gent är in­stal­le­rad kan ap­pli­ka­tio­ner dis­tri­bue­ras via den lokala Panamax-klienten till valfri slutpunkt i klustret. Panamax fjär­ra­gen­ten körs som en Docker-container på varje dis­tri­bu­tions­mål i klustret.
• Panamax-or­kest­re­rings­ad­ap­ter: I or­kest­re­rings­ad­ap­tern till­han­da­hålls pro­gram­lo­gi­ken för varje or­kest­re­rings­verk­tyg som är till­gäng­ligt för Panamax i ett oberoende ad­ap­ter­la­ger. Tack vare detta har an­vän­dar­na alltid möjlighet att välja exakt den or­kest­re­rings teknik som stöds av deras målmiljö. För­kon­fi­gu­re­ra­de adaptrar in­klu­de­rar Ku­ber­ne­tes och Fleet:
• Panamax Ku­ber­ne­tes-adapter: i kom­bi­na­tion med Panamax fjär­ra­gent möjliggör Panamax Ku­ber­ne­tes-adaptern dis­tri­bu­tion av Panamax-mallar i Ku­ber­ne­tes-kluster.
• Panamax Fleet-adapter: i kom­bi­na­tion med Panamax fjär­ra­gent möjliggör Panamax Fleet-adaptern dis­tri­bu­tion av Panamax-mallar i kluster som styrs med hjälp av Fleet-klus­ter­han­te­ra­ren.

Följande bild visar samspelet mellan de enskilda Panamax-kom­po­nen­ter­na i ett Docker-kluster:

Det CoreOS-baserade con­tai­ner­han­te­rings­verk­ty­get Panamax ger an­vän­dar­na tillgång till en rad olika stan­dard­tek­ni­ker för con­tai­ne­ror­kest­re­ring via ett grafiskt an­vän­dar­gräns­snitt, samt möj­lig­he­ten att enkelt hantera komplexa ap­pli­ka­tio­ner med flera con­tain­rar i klu­s­te­rar­ki­tek­tu­rer med valfritt system (t.ex. din egen bärbara dator).

Med Panamax of­fent­li­ga mallarkiv har Panamax-användare tillgång till ett of­fent­ligt mall­bib­li­o­tek med olika resurser via GitHub.

Drönare

Drone är en smidig plattform för kon­ti­nu­er­lig in­teg­ra­tion med minimala krav. Med detta Docker-verktyg kan du au­to­ma­tiskt ladda din senaste build från ett Git-re­po­si­to­ry som GitHub och testa den i isolerade Docker-con­tain­rar. Du kan köra valfri testsuite och skicka rapporter och sta­tus­med­de­lan­den via e-post. För varje mjuk­varu­te­st skapas en ny container baserad på bilder från det of­fent­li­ga Docker-registret. Det innebär att alla of­fent­ligt till­gäng­li­ga Docker-bilder kan användas som miljö för att testa koden.

Drone är in­te­gre­rat i Docker och stöds av olika pro­gram­me­rings­språk, såsom PHP, Node.js, Ruby, Go och Python. Con­tai­ner­platt­for­men är den enda verkliga beroendet. Du kan skapa din egen per­son­li­ga plattform för kon­ti­nu­er­lig in­teg­ra­tion med Drone på alla system där Docker kan in­stal­le­ras. Drone stöder olika ver­sions­kon­troll­för­var, och du hittar en guide för stan­dardin­stal­la­tion med GitHub-in­teg­ra­tion på open source-pro­jek­tets webbplats under readme.drone.io.

Han­te­ring­en av platt­for­men för kon­ti­nu­er­lig in­teg­ra­tion sker via ett webb­gräns­snitt. Här kan du ladda pro­gram­va­ru­ver­sio­ner från valfritt Git-arkiv, slå samman dem till ap­pli­ka­tio­ner och köra re­sul­ta­tet i en för­de­fi­ni­e­rad testmiljö. För att göra detta de­fi­nie­ras en .drone.yml-fil som anger hur ap­pli­ka­tio­nen ska skapas och köras för varje pro­gram­varu­te­st.

Drone-användare får tillgång till en öppen käll­kods­ba­se­rad CI-lösning som kom­bi­ne­rar styrkorna hos al­ter­na­ti­va produkter som Travis och Jenkins i en an­vän­dar­vän­lig ap­pli­ka­tion.

OpenStack

När det gäller att bygga och driva moln­struk­tu­rer med öppen källkod är det öppna mol­no­pe­ra­tiv­sy­ste­met OpenStack den själv­kla­ra mjuk­va­ru­lös­ning­en.

Med OpenStack kan du hantera dator-, lagrings- och nät­verks­re­sur­ser från en central kon­troll­pa­nel och göra dem till­gäng­li­ga för slu­tan­vän­da­re via ett webb­gräns­snitt.

Mol­no­pe­ra­tiv­sy­ste­met är baserat på en modulär ar­ki­tek­tur som består av flera kom­po­nen­ter:

• Zun (con­tai­ner­tjänst): Zun är Open­Stacks con­tai­ner­tjänst och möjliggör enkel dis­tri­bu­tion och hantering av con­tai­ne­ri­se­ra­de ap­pli­ka­tio­ner i OpenStack-molnet. Syftet med Zun är att låta användare hantera con­tain­rar via ett REST API utan att behöva hantera servrar eller kluster. För att kunna använda Zun behöver du tre andra OpenStack-tjänster, nämligen Keystone, Neutorn och kryr-lib­network. Zuns funk­tio­na­li­tet kan också utökas med yt­ter­li­ga­re OpenStack-tjänster som Cinder och Glance.
• Neutron (nät­verks­kom­po­nent): Neutron (tidigare Quantum) är en portabel, skalbar API-stödd system­kom­po­nent som används för nät­verks­kon­troll. Modulen till­han­da­hål­ler ett gräns­snitt för komplexa nät­verk­sto­po­lo­gi­er och stöder olika plugins genom vilka utökade nät­verks­funk­tio­ner kan in­te­gre­ras.
• kuryr-lib­network (Docker-drivrutin): kuryr-lib­network är en drivrutin som fungerar som ett gräns­snitt mellan Docker och Neutron.
• Cinder (block­lag­ring): Cinder är smek­nam­net på en komponent i OpenStack-ar­ki­tek­tu­ren som till­han­da­hål­ler permanent block­lag­ring för drift av virtuella maskiner. Modulen till­han­da­hål­ler virtuell lagring via ett själv­be­tjä­nings-API. Genom detta kan slu­tan­vän­da­re utnyttja lag­rings­re­sur­ser utan att vara medvetna om vilken enhet som till­han­da­hål­ler lagringen.
• Keystone (iden­ti­tets­tjänst): Keystone till­han­da­hål­ler OpenStack-användare en central iden­ti­tets­tjänst. Modulen fungerar som ett au­ten­ti­se­rings- och be­hö­rig­hets­sy­stem mellan de enskilda OpenStack-kom­po­nen­ter­na. Åtkomst till projekt i molnet regleras av hy­res­gäs­ter. Varje hyresgäst re­pre­sen­te­rar en användare, och flera an­vän­daråt­koms­ter med olika rät­tig­he­ter kan de­fi­nie­ras.
• Glance (bild­tjänst): Med Glance-modulen till­han­da­hål­ler OpenStack en tjänst som gör det möjligt att lagra och hämta bilder av virtuella maskiner.

Du hittar mer in­for­ma­tion om OpenStack-kom­po­nen­ter och -tjänster i vår artikel om OpenStack.

Utöver de kom­po­nen­ter som nämns ovan kan OpenStack-ar­ki­tek­tu­ren utökas med hjälp av olika moduler. Du kan läsa om de olika valfria modulerna på OpenStack-webb­plat­sen.

D2iQ DC/OS

DC/OS (Dis­tri­bu­ted Cloud Operating System) är en öppen käll­kods­pro­gram­va­ra för drift av dis­tri­bu­e­ra­de system som ut­veck­lats av D2iQ Inc. (tidigare Mesosphe­re). Projektet baseras på den öppna käll­kodsklus­ter­han­te­ra­ren Apache Mesos och är ett ope­ra­tiv­sy­stem för da­ta­cen­ter. Källkoden är till­gäng­lig för användare under Apache-licensen version 2 i DC/OS-arkiven på GitHub. En fö­re­tags­ver­sion av pro­gram­va­ran finns också till­gäng­lig på d2iq.com. Om­fat­tan­de pro­jekt­do­ku­men­ta­tion finns på dcos.io.

Du kan tänka på DC/OS som en Mesos-dis­tri­bu­tion som ger dig alla funk­tio­ner i klus­ter­han­te­ra­ren (via ett centralt an­vän­dar­gräns­snitt) och utökar Mesos avsevärt.

DC/OS använder den dis­tri­bu­e­ra­de system­kär­nan i Mesos-platt­for­men. Detta gör det möjligt att samla re­sur­ser­na i ett helt da­ta­cen­ter och hantera dem i form av ett ag­gre­ge­rat system som en enda logisk server. På så sätt kan du styra hela kluster av fysiska eller virtuella maskiner med samma enkelhet som du skulle använda en enda dator.

Pro­gram­va­ran förenklar in­stal­la­tio­nen och han­te­ring­en av dis­tri­bu­e­ra­de ap­pli­ka­tio­ner och au­to­ma­ti­se­rar uppgifter som re­surs­han­te­ring, sche­malägg­ning och in­ter­pro­cess­kom­mu­ni­ka­tion. Han­te­ring­en av ett kluster baserat på D2iQ DC/OS, samt dess in­klu­de­ra­de tjänster, sker via ett centralt kom­man­do­rads­pro­gram (CLI) eller webb­gräns­snitt (GUI).

DC/OS isolerar klustrets resurser och till­han­da­hål­ler delade tjänster, såsom tjäns­te­upp­täckt eller pa­ket­han­te­ring. Pro­gram­va­rans kärn­kom­po­nen­ter körs i ett skyddat område – kärn­kär­nan. Detta in­klu­de­rar Mesos-platt­for­mens master- och agent­pro­gram, som ansvarar för re­sur­sal­lo­ke­ring, pro­ces­si­so­le­ring och sä­ker­hets­funk­tio­ner.

• Mesos master: Mesos master är en mas­ter­pro­cess som körs på en masternod. Syftet med Mesos master är att kon­trol­le­ra re­surs­han­te­ring­en och samordna uppgifter (abstrakta ar­bet­sen­he­ter) som utförs på en agentnod. För att göra detta fördelar Mesos master resurser till re­gi­stre­ra­de DC/OS-tjänster och tar emot re­surs­rap­por­ter från Mesos-agenter.
• Mesos-agenter: Mesos-agenter är processer som körs på agent­kon­ton och ansvarar för att utföra de uppgifter som dis­tri­bue­ras av mastern. Mesos-agenter levererar re­gel­bund­na rapporter om till­gäng­li­ga resurser i klustret till Mesos-mastern. Dessa vi­da­re­be­fordras av Mesos-mastern till en sche­maläg­ga­re (dvs. Marathon, Chronos eller Cassandra). Denna bestämmer vilken uppgift som ska köras på vilken nod. Upp­gif­ter­na utförs sedan i en container på ett isolerat sätt.

Alla andra system­kom­po­nen­ter samt ap­pli­ka­tio­ner som körs av Mesos-agenterna via executor körs i an­vän­darut­rym­met. De grund­läg­gan­de kom­po­nen­ter­na i en stan­dardin­stal­la­tion av DC/OS är ad­min­rou­tern, Mesos DNS, en dis­tri­bu­e­rad DNS-proxy, last­ba­lan­se­ra­ren Minuteman, sche­maläg­ga­ren Marathon, Apache ZooKeeper och Exhibitor.

• Admin router: Admin router är en spe­ci­al­kon­fi­gu­re­rad webb­ser­ver baserad på NGINX som till­han­da­hål­ler DC/OS-tjänster samt central au­ten­ti­se­ring och prox­y­funk­tio­ner.
• Mesos DNS: System­kom­po­nen­ten Mesos DNS till­han­da­hål­ler tjäns­te­upp­täckts­funk­tio­ner som gör det möjligt för enskilda tjänster och ap­pli­ka­tio­ner i klustret att iden­ti­fi­e­ra varandra via ett centralt do­män­namns­sy­stem (DNS).
• Dis­tri­bu­e­rad DNS-proxy: den dis­tri­bu­e­ra­de DNS-proxyn är en intern DNS-dis­pat­cher.
• Minuteman: System­kom­po­nen­ten Minuteman fungerar som en intern last­ba­lan­se­ra­re som arbetar på trans­port­lag­ret (lager 4) i OSI-re­fe­rensmo­del­len.
• DC/OS Marathon: Marathon är en central komponent i Mesos-platt­for­men som fungerar i D2iQ DC/OS som ett init-system (liknande systemd). Marathon startar och övervakar DC/OS-tjänster och ap­pli­ka­tio­ner i klus­termil­jö­er. Dessutom till­han­da­hål­ler pro­gram­va­ran funk­tio­ner för hög till­gäng­lig­het, tjäns­te­upp­täckt, last­ba­lan­se­ring, häl­so­kon­trol­ler och ett grafiskt webb­gräns­snitt.
• Apache ZooKeeper: Apache ZooKeeper är en öppen käll­kods­kom­po­nent som till­han­da­hål­ler sam­ord­nings­funk­tio­ner för drift och styrning av ap­pli­ka­tio­ner i dis­tri­bu­e­ra­de system. ZooKeeper används i D2iQ DC/OS för sam­ord­ning av alla in­stal­le­ra­de system­tjäns­ter.
• Exhibitor: Exhibitor är en system­kom­po­nent som au­to­ma­tiskt in­stal­le­ras och kon­fi­gu­re­ras med ZooKeeper på varje masternod. Exhibitor till­han­da­hål­ler också ett grafiskt an­vän­dar­gräns­snitt för ZooKeeper-användare.

Olika ar­bets­be­last­ning­ar kan utföras samtidigt på klus­ter­re­sur­ser som ag­gre­ge­ras via DC/OS. Detta möjliggör till exempel parallell drift på klus­te­ro­pe­ra­tiv­sy­ste­met för big data-system, mikro­tjäns­ter eller con­tai­ner­platt­for­mar som Hadoop, Spark och Docker.

Inom D2iQ Universe finns en offentlig app­ka­ta­log till­gäng­lig för DC/OS. Med denna kan du in­stal­le­ra ap­pli­ka­tio­ner som Spark, Cassandra, Chronos, Jenkins eller Kafka genom att helt enkelt klicka på det grafiska an­vän­dar­gräns­snit­tet.

Vilka Docker-verktyg finns för säkerhet?

Även om inkaps­la­de processer som körs i con­tain­rar delar samma kärna, använder Docker ett antal tekniker för att isolera dem från varandra. Kärn­funk­tio­ner i Linux-kärnan, såsom Cgroups och Na­me­spa­ces, används van­ligt­vis för detta.

Con­tain­rar erbjuder dock fort­fa­ran­de inte samma grad av isolering som kan uppnås med virtuella maskiner. Trots an­vänd­ning­en av iso­le­rings­tek­ni­ker kan viktiga kärn­sub­sy­stem som Cgroups samt kärn­gräns­snitt i ka­ta­lo­ger­na /sys och /proc nås via con­tain­rar.

Docker-ut­veck­lings­tea­met har erkänt att dessa sä­ker­hets­pro­blem är ett hinder för eta­ble­ring­en av con­tai­ner­tek­no­lo­gi i pro­duk­tions­sy­stem. Utöver de grund­läg­gan­de iso­le­rings­tek­ni­ker­na i Linux-kärnan stöder nyare versioner av Docker Engine även ramverken AppArmor, SELinux och Seccomp, som fungerar som en slags brandvägg för kärn­re­sur­ser.

• AppArmor: Med AppArmor regleras be­hål­lar­nas åt­komsträt­tig­he­ter till fil­sy­ste­men.
• SELinux: SELinux till­han­da­hål­ler ett komplext re­gle­rings­sy­stem där åt­komst­kon­troll till kärn­re­sur­ser kan im­ple­men­te­ras.
• Seccomp: Seccomp (Secure Computing Mode) övervakar anrop av sys­te­man­rop.

Utöver dessa Docker-verktyg använder Docker även Linux-funk­tio­ner för att begränsa root-be­hö­rig­he­ter­na, som Docker Engine startar con­tain­rar med.

Det finns även andra sä­ker­hets­ris­ker kopplade till sår­bar­he­ter i pro­gram­va­ran inom ap­pli­ka­tions­kom­po­nen­ter som dis­tri­bue­ras av Docker-registret. Eftersom i princip vem som helst kan skapa Docker-bilder och göra dem till­gäng­li­ga för all­män­he­ten i Docker Hub, finns det en risk att skadlig kod in­tro­du­ce­ras i ditt system när du laddar ner en bild. Innan en ap­pli­ka­tion dis­tri­bue­ras bör Docker-användare se till att all kod som till­han­da­hålls i en bild för körning av con­tain­rar kommer från en pålitlig källa.

Docker erbjuder ett ve­ri­fi­e­rings­pro­gram som pro­gram­va­ru­le­ve­ran­tö­rer kan använda för att kon­trol­le­ra och verifiera sina Docker-bilder. Med detta ve­ri­fi­e­rings­pro­gram vill Docker göra det enklare för ut­veck­la­re att bygga säkra pro­gram­va­ru­för­sörj­nings­ked­jor för sina projekt. Förutom att öka sä­ker­he­ten för an­vän­dar­na syftar pro­gram­met till att erbjuda pro­gram­va­ru­ut­veck­la­re ett sätt att dif­fe­ren­ti­e­ra sina projekt från den mängd andra resurser som finns till­gäng­li­ga. Ve­ri­fi­e­ra­de bilder markeras med en Verified Publisher-märkning och får, förutom andra fördelar, en högre ranking i Docker Hubs sökre­sul­tat.