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

Det omfattande Docker- ekosystemet erbjuder utvecklare en rad möjligheter att distribuera applikationer, samordna containrar och mycket mer. Vi går igenom de viktigaste Docker-verktygen och ger dig en översikt över de mest populära tredjepartsprojekten som utvecklar öppen källkodsverktyg för Docker.

Vilka är de viktigaste Docker-verktygen/komponenterna?

Idag är Docker mycket mer än bara en sofistikerad plattform för hantering av programvarukontainrar. Utvecklare har skapat en rad olika Docker-verktyg för att göra distributionen av applikationer via distribuerad infrastruktur och molnmiljöer enklare, snabbare och mer flexibel. Förutom verktyg för klustring och orkestrering finns det också en central appmarknadsplats och ett verktyg för hantering av molnresurser.

Docker-motor

När utvecklare säger ”Docker” menar de vanligtvis denöppen källkodsbaserade klient-serverapplikationen somutgör grunden för containerplattformen. Denna applikation kallas Docker Engine. Centrala komponenter i Docker Engine är Docker-daemonen, ett REST API och ett CLI (kommandoradsgränssnitt) som fungerar som användargränssnitt.

Med denna design kan du kommunicera med Docker Engine via kommandoradskommandon och hantera Docker-bilder, Docker-filer och Docker-containrar bekvämt från terminalen.

Du hittar en detaljerad beskrivning av Docker Engine i vår Docker-handledning för nybörjare Docker-handledning: installation och första stegen.

Docker Hub

Docker Hub tillhandahåller användarna ett molnbaserat register som gör det möjligt att ladda ner Docker-bilder, hantera dem centralt och dela dem med andra Docker-användare. Registrerade användare kan lagra Docker-bilder offentligt eller i privata arkiv. För att ladda ner en offentlig bild (kallas för att hämta i Docker-terminologi) krävs inget användarkonto. En integrerad taggmekanism möjliggör versionshantering av bilder.

Förutom andra Docker-användares offentliga arkiv finns det också många resurser från Docker-utvecklingsteamet och välkända open source-projekt som finns i de officiella arkiven i Docker Hub. De mest populära Docker-bilderna inkluderar NGINX-webbservern, Redis-databasen i minnet, BusyBox Unix-verktygssatsen och Ubuntu Linux-distributionen.

Organisationer ä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 tillgängliga för en utvald grupp av personer. Åtkomsträttigheter hanteras inom en organisation med hjälp av team och gruppmedlemskap.

Docker Swarm

Docker Engine innehåller en inbyggd funktion som gör det möjligt för användarna att hantera Docker-värdar i kluster som kallas swarms. De klusterhanterings- och orkestreringsfunktioner som är inbyggda i Docker Engine baseras på verktygslådan Swarmkit. Om du använder en äldre version av containerplattformen finns Docker-verktyget tillgängligt som en fristående applikation.

Som ett inbyggt Docker-klusterverktyg 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, distribuera applikationer i klustret och hantera svärmarnas beteende utan att behöva använda ytterligare orkestreringsprogramvara.

Docker-motorer som har kombinerats 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 molnbaserad design, där de enskilda noderna i Docker-swarm distribueras över olika system och infrastrukturer.

Programvaran är baserad på en master-worker-arkitektur. När uppgifter ska fördelas i svärmen överför användarna en tjänst till manager-noden. Managern ansvarar sedan för schemaläggningen av containrar i klustret och fungerar som ett primärt användargränssnitt för åtkomst till svärmresurser.

Manager-noden skickar enskilda enheter, så kallade uppgifter, till arbetarnoderna.

• Tjänster: Tjänster är centrala strukturer i Docker-kluster. En tjänst definierar en uppgift som ska utföras i ett Docker-kluster. En tjänst avser en grupp containrar som baseras på samma bild. När en tjänst skapas anger användaren vilken bild och vilka kommandon som ska användas. Dessutom erbjuder tjänsterna möjlighet att skala applikationer. Användare av Docker-plattformen definierar helt enkelt hur många containrar som ska startas för en tjänst.
• Uppgifter: för att distribuera tjänster i klustret delas de upp i enskilda arbetsenheter (uppgifter) av hanteringsnoden. Varje uppgift innehåller en Docker-container samt de kommandon som exekveras i den.

Förutom hantering av klusterkontroll och samordning av containrar kan manager-noder som standard även utföra worker-nodfunktioner – såvida du inte strikt begränsar dessa noders uppgifter till hantering.

Ett agentprogram körs på varje arbetarnod. Detta accepterar uppgifter och tillhandahåller respektive huvudnodstatusrapporter om framstegen för den överförda uppgiften. Följande bild visar en schematisk representation av en Docker Swarm:

När man implementerar en Docker Swarm förlitar sig användarna i allmänhet på Docker-maskinen.

Docker Compose

Docker Compose gör det möjligt att slå samman flera containrar och köra dem med ett enda kommando. Grundelementet i Compose är den centrala kontrollfilen som baseras på det prisbelönta språket YAML. Syntaxen i denna compose-fil liknar den i den öppna källkodsprogramvaran Vagrant, som används vid skapande och provisionering av virtuella maskiner.

I filen docker-compose.yml kan du definiera valfritt antal programvarukontainrar, inklusive alla beroenden, samt deras relationer till varandra. Sådana applikationer med flera kontainrar styrs enligt samma mönster som enskilda programvarukontainrar. Använd kommandotdocker-compose i kombination med önskat underkommando för att hantera hela applikationens livscykel.

Detta Docker-verktyg kan enkelt integreras i ett kluster baserat på Swarm. På så sätt kan du köra multicontainer-applikationer skapade med Compose på distribuerade system lika enkelt som på en enskild Docker-värd.

En annan funktion i Docker Compose är en integrerad skalningsmekanism. Med orkestreringsverktyget kan du enkelt använda kommandoradsprogrammet för att definiera hur många containrar du vill starta för en viss tjänst.

Vilka tredjepartsverktyg för Docker finns det?

Förutom den interna utvecklingen från Docker Inc. finns det olika programvaruverktyg och plattformar från externa leverantörer som tillhandahåller gränssnitt för Docker Engine eller som har utvecklats speciellt för den populära containerplattformen. Inom Docker-ekosystemet är de mest populära open source-projekten orkestreringsverktyget Kubernetes, klusterhanteringsverktyget Shipyard, lösningen för transport av flera containrar Panamax, plattformen för kontinuerlig integration Drone, det molnbaserade operativsystemet OpenStack och datacenteroperativsystemet D2iQ DC/OS, som baseras på klusterhanteraren Mesos.

Kubernetes

Det är inte alltid möjligt för Docker att ta fram egna orkestreringsverktyg som Swarm och Compose. Av denna anledning har olika företag under flera år investerat i egen utveckling för att skapa skräddarsydda verktyg som underlättar driften av containerplattformen i stora, distribuerade infrastrukturer. En av de mest populära lösningarna av detta slag är open source-projektet Kubernetes.

Kubernetes är en klusterhanterare för containerbaserade applikationer. Målet med Kubernetes är att automatisera applikationer i ett kluster. För att göra detta använder orkestreringsverktyget ett REST-API, ett kommandoradsprogram och ett grafiskt webbgränssnitt som kontrollgränssnitt. Med dessa gränssnitt kan automatiseringar initieras och statusrapporter begäras. Du kan använda Kubernetes för att:

• köra containerbaserade foton på ett kluster,
• installera och hantera applikationer i distribuerade system,
• skalera applikationer och
• använda hårdvara på bästa möjliga sätt.

För detta ändamål kombinerar Kubernetes containrar till logiska delar, som kallas pods. Pods representerar klusterhanterarens grundläggande enheter, som kan distribueras i klustret genom schemaläggning.

Precis som Docker Swarm är även Kubernetes baserat på en master-worker-arkitektur. Ett kluster består av en Kubernetes-master och en rad arbetare, som också kallas Kubernetes-noder (eller minions). Kubernetes-mastern fungerar som en central kontrollplan i klustret och består av fyra grundläggande komponenter, vilket möjliggör direkt kommunikation i klustret och uppgiftsfördelning. En Kubernetes-master består av en API-server, konfigurationsminnet etcd, en schemaläggare och en kontrollhanterare.

• API-server: alla automatiseringar i Kubernetes-klustret initieras med REST-API via en API-server. Denna fungerar som det centrala administrationsgränssnittet i klustret.
• etcd: du kan tänka dig det öppna källkodsbaserade konfigurationsminnet etcd som Kubernetes-klustrets minne. Key Value Store, som CoreOS utvecklat speciellt för distribuerade system, lagrar konfigurationsdata och gör den tillgänglig för varje nod i klustret. Klustrets aktuella tillstånd kan hanteras när som helst via etcd.
• Scheduler: Schedulern ansvarar för att distribuera containergrupper (pods) i klustret. Den bestämmer resursbehovet för en pod och matchar sedan detta med de tillgängliga resurserna för de enskilda noderna i klustret.
• Controller manager: controller manager är en tjänst i Kubernetes master och styr orkestreringen genom att reglera klustrets tillstånd och utföra rutinuppgifter. Controller manager har som huvuduppgift att se till att klustrets tillstånd motsvarar det definierade måltillståndet.

De övergripande komponenterna i Kubernetes-mastern kan placeras på samma värd eller distribueras över flera mastervärdar inom ett kluster med hög tillgänglighet.

Medan Kubernetes-mastern ansvarar för orkestreringen, körs podarna som distribueras i klustret på värdar, Kubernetes-noder, som är underordnade mastern. För att göra detta måste en containermotor köras på varje Kubernetes-nod. Även om Docker är de facto-standarden, behöver Kubernetes inte använda en specifik containermotor.

Förutom containermotorn omfattar Kubernetes-noderna följande komponenter:

• kubelet: kubelet är en agent som körs på varje Kubernetes-nod och används för att styra och hantera noden. Som central kontaktpunkt för varje nod är kubelet ansluten till Kubernetes-mastern och säkerställer att information vidarebefordras till och tas emot från kontrollplanet.
• kube-proxy: dessutom körs proxytjänsten kube-proxy på varje Kubernetes-nod. Detta säkerställer att förfrågningar från utsidan vidarebefordras till respektive containrar och tillhandahåller tjänster till användare av containerbaserade applikationer. Kube-proxy erbjuder också rudimentär lastbalansering.

Följande bild visar en schematisk representation av master-nodarkitekturen som orkestreringsplattformen Kubernetes baseras på:

Förutom kärnprojektet Kubernetes finns det också ett flertal verktyg och tillägg som gör det möjligt att lägga till ytterligare funktionalitet till orkestreringsplattformen. De mest populära är övervaknings- och feldiagnosverktygen Prometheus, Weave Scope och sysdig, samt pakethanteraren Helm. Det finns även plugins för Apache Maven och Gradle, samt ett Java-API som gör det möjligt att fjärrstyra Kubernetes.

Varv

Shipyard är en gemenskapsutvecklad hanteringslösning baserad på Swarm som gör det möjligt för användare att underhålla Docker-resurser som containrar, bilder, värdar och privata register via ett grafiskt användargränssnitt. Den är tillgänglig som en webbapplikation via webbläsaren. Förutom klusterhanteringsfunktionerna som kan nås via ett centralt webbgränssnitt erbjuder Shipyard även användarautentisering och rollbaserad åtkomstkontroll.

Programvaran är 100 % kompatibel med Docker Remote API och använder den öppna källkodsdatabasen RethinkDB för att lagra data för användarkonton, adresser och händelser. Programvaran baseras på klusterhanteringsverktyget Citadel och består av tre huvudkomponenter: styrenhet, API och användargränssnitt.

• Shipyard-kontroller: kontrollern är kärnkomponenten i hanteringsverktyget Shipyard. Shipyard-kontrollern interagerar 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 funktioner i hanteringsverktyget styrs via Shipyard API.
• Shipyard-användargränssnitt (UI): Shipyard-användargränssnittet är en AngularJS-app som ger användarna ett grafiskt användargränssnitt för hantering av Docker-kluster i webbläsaren. Alla interaktioner i användargränssnittet sker via Shipyard API.

Mer information om open source-projektet finns på Shipyards officiella webbplats.

Panamax

Utvecklarna av det öppna källkodsprojektet Panamax har som mål att förenkla distributionen av appar med flera containrar. Det kostnadsfria verktyget erbjuder användarna ett grafiskt gränssnitt som gör det möjligt att enkelt utveckla, distribuera och sprida komplexa applikationer baserade på Docker-containrar med hjälp av dra-och-släpp-funktioner.

Panamax gör det möjligt att spara komplexa applikationer med flera containrar som applikationsmallar och distribuera dem i klusterarkitekturer med bara ett klick. Med hjälp av en integrerad appmarknadsplats som finns på GitHub kan mallar för självskapade applikationer lagras i Git-arkiv och göras tillgängliga för andra användare.

De grundläggande komponenterna i Panamax-arkitekturen kan delas in i två grupper: Panamax Local Client och ett obegränsat antal fjärrdistributionsmål.

Den lokala Panamax-klienten är kärnkomponenten i detta Docker-verktyg. Den körs på det lokala systemet och gör det möjligt att skapa komplexa containerbaserade applikationer. Den lokala klienten består av följande komponenter:

• CoreOS: installation av den lokala Panamax-klienten kräver Linux-distributionen CoreOS som värdsystem, vilket har utformats speciellt för programvarukontainrar. Panamax-klienten körs sedan som en Docker-container i CoreOS. Utöver Docker-funktionerna har användarna tillgång till olika CoreOS-funktioner. Dessa inkluderar bland annat Fleet och Journalctl:
• Fleet: istället för att integreras direkt med Docker använder Panamax-klienten klusterhanteraren Fleet för att koordinera sina containrar. Fleet är en klusterhanterare som styr Linux-daemonen systemd i datorkluster.
• Journalctl: Panamax-klienten använder Journalctl för att begära loggmeddelanden från Linux-systemhanteraren systemd från journalen.
• Lokalt klientinstallationsprogram: det lokala klientinstallationsprogrammet innehåller alla komponenter som behövs för att installera Panamax-klienten på ett lokalt system.
• Panamax lokal agent: den centrala komponenten i den lokala klienten är den lokala agenten. Denna är länkad till olika andra komponenter och beroenden via Panamax API. Dessa inkluderar den lokala Docker-värden, Panamax UI, externa register och fjärragenterna för distributionsmålen i klustret. Den lokala agenten interagerar med följande programgränssnitt på det lokala systemet via Panamax API för att utbyta information om körande applikationer:
• Docker Remote API: Panamax söker efter bilder på det lokala systemet via Docker Remote API och hämtar information om körande containrar.
• etcd API: filer överförs till CoreOS Fleet-daemon via etcd API.
• systemd-journal-gatewayd.services: Panamax hämtar journalutdata från körda tjänster via systemd-journal-gatewayd.services.

Dessutom möjliggör Panamax API även interaktioner med olika externa API:er.

• Docker-registrets API: Panamax hämtar bildtaggar från Docker-registret via Docker-registrets API.
• GitHub API: Panamax laddar mallar från GitHub-arkivet med hjälp av GitHub API.
• KissMetrics API: KissMetrics API samlar in data om mallar som användarna kör.
• Panamax UI: Panamax UI fungerar som ett användargränssnitt på det lokala systemet och gör det möjligt för användare att styra Docker-verktyget via ett grafiskt gränssnitt. Användarinmatning vidarebefordras direkt till den lokala agenten via Panamax API. Panamax UI är baserat på CTL Base UI Kit, ett bibliotek med UI-komponenter för webbprojekt från CenturyLink.

I Panamax-terminologi kallas varje nod i ett Docker-kluster utan förvaltningsuppgifter för ett fjärrdistributionsmål. Distributionsmål består av en Docker-värd som är konfigurerad för att distribuera Panamax-mallar med hjälp av följande komponenter:

• Installationsprogram för distributionsmål: installationsprogrammet för distributionsmål startar en Docker-värd, komplett med en Panamax-fjärragent och en orkestreringsadapter.
• Panamax fjärragent: om en Panamax fjärragent är installerad kan applikationer distribueras via den lokala Panamax-klienten till valfri slutpunkt i klustret. Panamax fjärragenten körs som en Docker-container på varje distributionsmål i klustret.
• Panamax-orkestreringsadapter: I orkestreringsadaptern tillhandahålls programlogiken för varje orkestreringsverktyg som är tillgängligt för Panamax i ett oberoende adapterlager. Tack vare detta har användarna alltid möjlighet att välja exakt den orkestrerings teknik som stöds av deras målmiljö. Förkonfigurerade adaptrar inkluderar Kubernetes och Fleet:
• Panamax Kubernetes-adapter: i kombination med Panamax fjärragent möjliggör Panamax Kubernetes-adaptern distribution av Panamax-mallar i Kubernetes-kluster.
• Panamax Fleet-adapter: i kombination med Panamax fjärragent möjliggör Panamax Fleet-adaptern distribution av Panamax-mallar i kluster som styrs med hjälp av Fleet-klusterhanteraren.

Följande bild visar samspelet mellan de enskilda Panamax-komponenterna i ett Docker-kluster:

Det CoreOS-baserade containerhanteringsverktyget Panamax ger användarna tillgång till en rad olika standardtekniker för containerorkestrering via ett grafiskt användargränssnitt, samt möjligheten att enkelt hantera komplexa applikationer med flera containrar i klusterarkitekturer med valfritt system (t.ex. din egen bärbara dator).

Med Panamax offentliga mallarkiv har Panamax-användare tillgång till ett offentligt mallbibliotek med olika resurser via GitHub.

Drönare

Drone är en smidig plattform för kontinuerlig integration med minimala krav. Med detta Docker-verktyg kan du automatiskt ladda din senaste build från ett Git-repository som GitHub och testa den i isolerade Docker-containrar. Du kan köra valfri testsuite och skicka rapporter och statusmeddelanden via e-post. För varje mjukvarutest skapas en ny container baserad på bilder från det offentliga Docker-registret. Det innebär att alla offentligt tillgängliga Docker-bilder kan användas som miljö för att testa koden.

Drone är integrerat i Docker och stöds av olika programmeringsspråk, såsom PHP, Node.js, Ruby, Go och Python. Containerplattformen är den enda verkliga beroendet. Du kan skapa din egen personliga plattform för kontinuerlig integration med Drone på alla system där Docker kan installeras. Drone stöder olika versionskontrollförvar, och du hittar en guide för standardinstallation med GitHub-integration på open source-projektets webbplats under readme.drone.io.

Hanteringen av plattformen för kontinuerlig integration sker via ett webbgränssnitt. Här kan du ladda programvaruversioner från valfritt Git-arkiv, slå samman dem till applikationer och köra resultatet i en fördefinierad testmiljö. För att göra detta definieras en .drone.yml-fil som anger hur applikationen ska skapas och köras för varje programvarutest.

Drone-användare får tillgång till en öppen källkodsbaserad CI-lösning som kombinerar styrkorna hos alternativa produkter som Travis och Jenkins i en användarvänlig applikation.

OpenStack

När det gäller att bygga och driva molnstrukturer med öppen källkod är det öppna molnoperativsystemet OpenStack den självklara mjukvarulösningen.

Med OpenStack kan du hantera dator-, lagrings- och nätverksresurser från en central kontrollpanel och göra dem tillgängliga för slutanvändare via ett webbgränssnitt.

Molnoperativsystemet är baserat på en modulär arkitektur som består av flera komponenter:

• Zun (containertjänst): Zun är OpenStacks containertjänst och möjliggör enkel distribution och hantering av containeriserade applikationer i OpenStack-molnet. Syftet med Zun är att låta användare hantera containrar 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-libnetwork. Zuns funktionalitet kan också utökas med ytterligare OpenStack-tjänster som Cinder och Glance.
• Neutron (nätverkskomponent): Neutron (tidigare Quantum) är en portabel, skalbar API-stödd systemkomponent som används för nätverkskontroll. Modulen tillhandahåller ett gränssnitt för komplexa nätverkstopologier och stöder olika plugins genom vilka utökade nätverksfunktioner kan integreras.
• kuryr-libnetwork (Docker-drivrutin): kuryr-libnetwork är en drivrutin som fungerar som ett gränssnitt mellan Docker och Neutron.
• Cinder (blocklagring): Cinder är smeknamnet på en komponent i OpenStack-arkitekturen som tillhandahåller permanent blocklagring för drift av virtuella maskiner. Modulen tillhandahåller virtuell lagring via ett självbetjänings-API. Genom detta kan slutanvändare utnyttja lagringsresurser utan att vara medvetna om vilken enhet som tillhandahåller lagringen.
• Keystone (identitetstjänst): Keystone tillhandahåller OpenStack-användare en central identitetstjänst. Modulen fungerar som ett autentiserings- och behörighetssystem mellan de enskilda OpenStack-komponenterna. Åtkomst till projekt i molnet regleras av hyresgäster. Varje hyresgäst representerar en användare, och flera användaråtkomster med olika rättigheter kan definieras.
• Glance (bildtjänst): Med Glance-modulen tillhandahåller OpenStack en tjänst som gör det möjligt att lagra och hämta bilder av virtuella maskiner.

Du hittar mer information om OpenStack-komponenter och -tjänster i vår artikel om OpenStack.

Utöver de komponenter som nämns ovan kan OpenStack-arkitekturen utökas med hjälp av olika moduler. Du kan läsa om de olika valfria modulerna på OpenStack-webbplatsen.

D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) är en öppen källkodsprogramvara för drift av distribuerade system som utvecklats av D2iQ Inc. (tidigare Mesosphere). Projektet baseras på den öppna källkodsklusterhanteraren Apache Mesos och är ett operativsystem för datacenter. Källkoden är tillgänglig för användare under Apache-licensen version 2 i DC/OS-arkiven på GitHub. En företagsversion av programvaran finns också tillgänglig på d2iq.com. Omfattande projektdokumentation finns på dcos.io.

Du kan tänka på DC/OS som en Mesos-distribution som ger dig alla funktioner i klusterhanteraren (via ett centralt användargränssnitt) och utökar Mesos avsevärt.

DC/OS använder den distribuerade systemkärnan i Mesos-plattformen. Detta gör det möjligt att samla resurserna i ett helt datacenter och hantera dem i form av ett aggregerat 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.

Programvaran förenklar installationen och hanteringen av distribuerade applikationer och automatiserar uppgifter som resurshantering, schemaläggning och interprocesskommunikation. Hanteringen av ett kluster baserat på D2iQ DC/OS, samt dess inkluderade tjänster, sker via ett centralt kommandoradsprogram (CLI) eller webbgränssnitt (GUI).

DC/OS isolerar klustrets resurser och tillhandahåller delade tjänster, såsom tjänsteupptäckt eller pakethantering. Programvarans kärnkomponenter körs i ett skyddat område – kärnkärnan. Detta inkluderar Mesos-plattformens master- och agentprogram, som ansvarar för resursallokering, processisolering och säkerhetsfunktioner.

• Mesos master: Mesos master är en masterprocess som körs på en masternod. Syftet med Mesos master är att kontrollera resurshanteringen och samordna uppgifter (abstrakta arbetsenheter) som utförs på en agentnod. För att göra detta fördelar Mesos master resurser till registrerade DC/OS-tjänster och tar emot resursrapporter från Mesos-agenter.
• Mesos-agenter: Mesos-agenter är processer som körs på agentkonton och ansvarar för att utföra de uppgifter som distribueras av mastern. Mesos-agenter levererar regelbundna rapporter om tillgängliga resurser i klustret till Mesos-mastern. Dessa vidarebefordras av Mesos-mastern till en schemaläggare (dvs. Marathon, Chronos eller Cassandra). Denna bestämmer vilken uppgift som ska köras på vilken nod. Uppgifterna utförs sedan i en container på ett isolerat sätt.

Alla andra systemkomponenter samt applikationer som körs av Mesos-agenterna via executor körs i användarutrymmet. De grundläggande komponenterna i en standardinstallation av DC/OS är adminroutern, Mesos DNS, en distribuerad DNS-proxy, lastbalanseraren Minuteman, schemaläggaren Marathon, Apache ZooKeeper och Exhibitor.

• Admin router: Admin router är en specialkonfigurerad webbserver baserad på NGINX som tillhandahåller DC/OS-tjänster samt central autentisering och proxyfunktioner.
• Mesos DNS: Systemkomponenten Mesos DNS tillhandahåller tjänsteupptäcktsfunktioner som gör det möjligt för enskilda tjänster och applikationer i klustret att identifiera varandra via ett centralt domännamnssystem (DNS).
• Distribuerad DNS-proxy: den distribuerade DNS-proxyn är en intern DNS-dispatcher.
• Minuteman: Systemkomponenten Minuteman fungerar som en intern lastbalanserare som arbetar på transportlagret (lager 4) i OSI-referensmodellen.
• DC/OS Marathon: Marathon är en central komponent i Mesos-plattformen som fungerar i D2iQ DC/OS som ett init-system (liknande systemd). Marathon startar och övervakar DC/OS-tjänster och applikationer i klustermiljöer. Dessutom tillhandahåller programvaran funktioner för hög tillgänglighet, tjänsteupptäckt, lastbalansering, hälsokontroller och ett grafiskt webbgränssnitt.
• Apache ZooKeeper: Apache ZooKeeper är en öppen källkodskomponent som tillhandahåller samordningsfunktioner för drift och styrning av applikationer i distribuerade system. ZooKeeper används i D2iQ DC/OS för samordning av alla installerade systemtjänster.
• Exhibitor: Exhibitor är en systemkomponent som automatiskt installeras och konfigureras med ZooKeeper på varje masternod. Exhibitor tillhandahåller också ett grafiskt användargränssnitt för ZooKeeper-användare.

Olika arbetsbelastningar kan utföras samtidigt på klusterresurser som aggregeras via DC/OS. Detta möjliggör till exempel parallell drift på klusteroperativsystemet för big data-system, mikrotjänster eller containerplattformar som Hadoop, Spark och Docker.

Inom D2iQ Universe finns en offentlig appkatalog tillgänglig för DC/OS. Med denna kan du installera applikationer som Spark, Cassandra, Chronos, Jenkins eller Kafka genom att helt enkelt klicka på det grafiska användargränssnittet.

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

Även om inkapslade processer som körs i containrar delar samma kärna, använder Docker ett antal tekniker för att isolera dem från varandra. Kärnfunktioner i Linux-kärnan, såsom Cgroups och Namespaces, används vanligtvis för detta.

Containrar erbjuder dock fortfarande inte samma grad av isolering som kan uppnås med virtuella maskiner. Trots användningen av isoleringstekniker kan viktiga kärnsubsystem som Cgroups samt kärngränssnitt i katalogerna /sys och /proc nås via containrar.

Docker-utvecklingsteamet har erkänt att dessa säkerhetsproblem är ett hinder för etableringen av containerteknologi i produktionssystem. Utöver de grundläggande isoleringsteknikerna 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ärnresurser.

• AppArmor: Med AppArmor regleras behållarnas åtkomsträttigheter till filsystemen.
• SELinux: SELinux tillhandahåller ett komplext regleringssystem där åtkomstkontroll till kärnresurser kan implementeras.
• Seccomp: Seccomp (Secure Computing Mode) övervakar anrop av systemanrop.

Utöver dessa Docker-verktyg använder Docker även Linux-funktioner för att begränsa root-behörigheterna, som Docker Engine startar containrar med.

Det finns även andra säkerhetsrisker kopplade till sårbarheter i programvaran inom applikationskomponenter som distribueras av Docker-registret. Eftersom i princip vem som helst kan skapa Docker-bilder och göra dem tillgängliga för allmänheten i Docker Hub, finns det en risk att skadlig kod introduceras i ditt system när du laddar ner en bild. Innan en applikation distribueras bör Docker-användare se till att all kod som tillhandahålls i en bild för körning av containrar kommer från en pålitlig källa.

Docker erbjuder ett verifieringsprogram som programvaruleverantörer kan använda för att kontrollera och verifiera sina Docker-bilder. Med detta verifieringsprogram vill Docker göra det enklare för utvecklare att bygga säkra programvaruförsörjningskedjor för sina projekt. Förutom att öka säkerheten för användarna syftar programmet till att erbjuda programvaruutvecklare ett sätt att differentiera sina projekt från den mängd andra resurser som finns tillgängliga. Verifierade bilder markeras med en Verified Publisher-märkning och får, förutom andra fördelar, en högre ranking i Docker Hubs sökresultat.