Hva er de beste Docker-verktøyene? En oversikt

Det omfattende Docker-økosystemet gir utviklere en rekke muligheter til å distribuere applikasjoner, koordinere containere og mye mer. Vi skal gå gjennom de viktigste Docker-verktøyene og gi deg en oversikt over de mest populære tredjepartsprosjektene som utvikler åpen kildekode-verktøy for Docker.

Hva er de viktigste Docker-verktøyene/komponentene?

I dag er Docker langt mer enn bare en avansert plattform for administrasjon av programvarekontainere. Utviklere har laget en rekke ulike Docker-verktøy for å gjøre distribusjon av applikasjoner via distribuert infrastruktur og skymiljøer enklere, raskere og mer fleksibelt. I tillegg til verktøy for klyngedannelse og orkestrering finnes det også en sentral app-markedsplass og et verktøy for administrasjon av skyressurser.

Docker Engine

Når utviklere snakker om «Docker», mener de vanligvis den åpne kildekode-baserte klient-server-applikasjonen somdanner grunnlaget for containerplattformen. Denne applikasjonen kalles Docker Engine. Sentrale komponenter i Docker Engine er Docker-daemonen, et REST-API og et CLI (kommandolinjegrensesnitt) som fungerer som brukergrensesnitt.

Med denne løsningen kan du kommunisere med Docker Engine via kommandolinjekommandoer og enkelt administrere Docker-bilder, Docker-filer og Docker-containere fra terminalen.

Du finner en detaljert beskrivelse av Docker Engine i vår Docker-veiledning for nybegynnere : Docker-veiledning: installasjon og første skritt.

Docker Hub

Docker Hub tilbyr brukerne et skybasert register som gjør det mulig å laste ned, sentralt administrere og dele Docker-bilder med andre Docker-brukere. Registrerte brukere kan lagre Docker-bilder i offentlige eller private arkiver. Det kreves ingen brukerkonto for å laste ned et offentlig bilde (kalt «pulling» i Docker-terminologi). En integrert taggmekanisme gjør det mulig å versjonere bildene.

I tillegg til de offentlige arkivene til andre Docker-brukere finnes det også mange ressurser fra Docker-utviklerteamet og kjente åpen kildekode-prosjekter i de offisielle arkivene på Docker Hub. Blant de mest populære Docker-bildene finner man NGINX-webserveren, Redis-databasen som kjører i minnet, BusyBox-verktøysettet for Unix og Ubuntu-Linux-distribusjonen.

Organisasjoner er en annen viktig funksjon i Docker Hub, som gjør det mulig for Docker-brukere å opprette private repositorier som kun er tilgjengelige for en utvalgt gruppe personer. Tilgangsrettigheter administreres innenfor en organisasjon ved hjelp av team og gruppemedlemskap.

Docker Swarm

Docker Engine har en innebygd funksjon som gjør det mulig for brukerne å administrere Docker-verter i klynger kalt swarms. Funksjonene for klyngeadministrasjon og orkestrering som er innebygd i Docker Engine, er basert på Swarmkit-verktøysettet. Hvis du bruker en eldre versjon av containerplattformen, er Docker-verktøyet tilgjengelig som et frittstående program.

Som et innebygd Docker-klyngeverktøy samler Swarm en gruppe Docker-verter til én virtuell vert og betjener Docker REST API. Ethvert Docker-verktøy som er knyttet til Docker-daemonen, kan få tilgang til Swarm og skalere over et hvilket som helst antall Docker-verter. Med Docker Engine CLI kan brukerne opprette swarms, distribuere applikasjoner i klyngen og administrere swarmens oppførsel uten å måtte bruke ekstra orkestreringsprogramvare.

Docker-motorer som er samlet i klynger, kjører i swarm-modus. Velg dette hvis du vil opprette en ny klynge eller legge til en Docker-vert i en eksisterende swarm. De enkelte Docker-vertene i en klynge kalles «noder». Nodene i en klynge kan kjøre som virtuelle verter på samme lokale system, men oftere benyttes en skybasert løsning, der de enkelte nodene i Docker-swarm-en er fordelt på ulike systemer og infrastrukturer.

Programvaren er basert på en master-worker-arkitektur. Når oppgaver skal fordeles i Swarm, sender brukerne en tjeneste til administratorknuten. Administratoren har da ansvaret for å planlegge containere i klyngen og fungerer som det primære brukergrensesnittet for tilgang til Swarm-ressurser.

Ledernoden sender enkeltstående enheter, kalt oppgaver, til arbeidernodene.

• Tjenester: Tjenester er sentrale strukturer i Docker-klynger. En tjeneste definerer en oppgave som skal utføres i en Docker-klynge. En tjeneste omfatter en gruppe containere som er basert på samme bilde. Når man oppretter en tjeneste, angir brukeren hvilket bilde og hvilke kommandoer som skal brukes. I tillegg gir tjenester muligheten til å skalere applikasjoner. Brukere av Docker-plattformen angir ganske enkelt hvor mange containere som skal startes for en tjeneste.
• Oppgaver: For å distribuere tjenester i klyngen deles de inn i individuelle arbeidsenheter (oppgaver) av administrasjonsnoden. Hver oppgave inkluderer en Docker-container samt kommandoene som utføres i den.

I tillegg til å håndtere klyngestyring og orkestrering av containere, kan administrasjonsnoder som standard også utføre funksjoner som tilhører arbeidsnoder – med mindre du begrenser oppgavene til disse nodene strengt til administrasjon.

Det kjører et agentprogram på hver arbeidernode. Dette mottar oppgaver og sender statusrapporter til den tilhørende hovednoden om fremdriften i den overførte oppgaven. Figuren nedenfor viser en skjematisk fremstilling av en Docker Swarm:

Når man implementerer en Docker Swarm, bruker man vanligvis Docker-maskinen.

Docker Compose

Docker Compose gjør det mulig å samle flere containere og kjøre dem med én enkelt kommando. Det grunnleggende elementet i Compose er den sentrale kontrollfilen, som er basert på det prisbelønte språket YAML. Syntaksen i denne Compose-filen ligner på syntaksen i åpen kildekode-programvaren Vagrant, som brukes til å opprette og konfigurere virtuelle maskiner.

I filen docker-compose.yml kan du definere et hvilket som helst antall programvarebeholdere, inkludert alle avhengigheter, samt hvordan de forholder seg til hverandre. Slike applikasjoner med flere beholdere styres etter samme mønster som enkeltstående programvarebeholdere. Bruk kommandoendocker-compose sammen med den ønskede underkommandoen for å administrere hele applikasjonens livssyklus.

Dette Docker-verktøyet kan enkelt integreres i en klynge basert på Swarm. På denne måten kan du kjøre applikasjoner med flere containere, laget med Compose, på distribuerte systemer like enkelt som på en enkelt Docker-vert.

En annen funksjon i Docker Compose er en integrert skaleringsmekanisme. Med dette orkestreringsverktøyet kan du enkelt bruke kommandolinjeprogrammet til å angi hvor mange containere du ønsker å starte for en bestemt tjeneste.

Hvilke Docker-verktøy fra tredjeparter finnes det?

I tillegg til den interne utviklingen fra Docker Inc. finnes det ulike programvareverktøy og plattformer fra eksterne leverandører som tilbyr grensesnitt for Docker Engine eller som er spesielt utviklet for den populære containerplattformen. Innenfor Docker-økosystemet er de mest populære åpen kildekode-prosjektene blant annet orkestreringsverktøyet Kubernetes, klyngestyringsverktøyet Shipyard, løsningen for transport av flere containere Panamax, plattformen for kontinuerlig integrasjon Drone, det skybaserte operativsystemet OpenStack og datasenteroperativsystemet D2iQ DC/OS, som er basert på klyngestyringsverktøyet Mesos.

Kubernetes

Det er ikke alltid mulig for Docker å utvikle egne orkestreringsverktøy som Swarm og Compose. Av denne grunn har ulike selskaper i mange år investert i eget utviklingsarbeid for å skape skreddersydde verktøy som skal forenkle driften av containerplattformen i store, distribuerte infrastrukturer. Blant de mest populære løsningene av denne typen finner vi åpen kildekode-prosjektet Kubernetes.

Kubernetes er en klyngestyringstjeneste for containerbaserte applikasjoner. Målet med Kubernetes er å automatisere applikasjoner i en klynge. For å gjøre dette bruker orkestreringsverktøyet en REST-API, et kommandolinjeprogram og et grafisk webgrensesnitt som styringsgrensesnitt. Gjennom disse grensesnittene kan man sette i gang automatiseringer og be om statusrapporter. Du kan bruke Kubernetes til å:

• kjøre containerbaserte applikasjoner på et klyngesystem,
• installere og administrere applikasjoner i distribuerte systemer,
• skalere applikasjoner, og
• utnytte maskinvaren best mulig.

For dette formålet grupperer Kubernetes containere i logiske enheter som kalles pods. Pods utgjør de grunnleggende enhetene i klyngestyringssystemet, og disse kan fordeles i klyngen gjennom planlegging.

I likhet med Docker Swarm er også Kubernetes basert på en master-worker-arkitektur. En klynge består av en Kubernetes-master og en rekke arbeidere, som også kalles Kubernetes-noder (eller minions). Kubernetes-masteren fungerer som et sentralt kontrollplan i klyngen og består av fire grunnleggende komponenter, som muliggjør direkte kommunikasjon i klyngen og oppgavefordeling. En Kubernetes-master består av en API-server, konfigurasjonsminnet etcd, en planlegger og en kontrollmanager.

• API-server: Alle automatiseringer i Kubernetes-klyngen igangsettes via REST-API gjennom en API-server. Denne fungerer som det sentrale administrasjonsgrensesnittet i klyngen.
• etcd: Du kan tenke på det åpne kildekode-konfigurasjonsminnet etcd som minnet til en Kubernetes-klynge. Key Value Store, som CoreOS utviklet spesielt for distribuerte systemer, lagrer konfigurasjonsdata og gjør dem tilgjengelige for hver node i klyngen. Den aktuelle tilstanden til en klynge kan administreres når som helst via etcd.
• Scheduler: Scheduleren er ansvarlig for å fordele containergrupper (pods) i klyngen. Den bestemmer ressursbehovet til en pod og matcher dette med de tilgjengelige ressursene til de enkelte nodene i klyngen.
• Controller manager: controller manager er en tjeneste i Kubernetes-masteren og styrer orkestreringen ved å regulere klyngens tilstand og utføre rutineoppgaver. Controller managerens hovedoppgave er å sikre at klyngens tilstand samsvarer med den definerte måltilstanden.

Alle komponentene i Kubernetes-masteren kan være plassert på samme vert eller fordelt på flere master-verter innenfor et klyngesystem med høy tilgjengelighet.

Mens Kubernetes-masteren har ansvaret for orkestreringen, kjøres podene som er fordelt i klyngen på verter, altså Kubernetes-noder, som er underordnet masteren. For at dette skal fungere, må det kjøre en containermotor på hver Kubernetes-node. Selv om Docker er de facto-standarden, er Kubernetes ikke bundet til å bruke en bestemt containermotor.

I tillegg til container-motoren omfatter Kubernetes-noder følgende komponenter:

• kubelet: kubelet er en agent som kjører på hver Kubernetes-node og brukes til å kontrollere og administrere noden. Som det sentrale kontaktpunktet for hver node er kubelet koblet til Kubernetes-masteren og sørger for at informasjon sendes til og mottas fra kontrollplanet.
• kube-proxy: i tillegg kjører proxy-tjenesten kube-proxy på hver Kubernetes-node. Dette sikrer at forespørsler fra utsiden videresendes til de respektive containerne og leverer tjenester til brukere av containerbaserte applikasjoner. Kube-proxy tilbyr også grunnleggende lastbalansering.

Figuren nedenfor viser en skjematisk fremstilling av master-node-arkitekturen som orkestreringsplattformen Kubernetes bygger på:

I tillegg til selve Kubernetes-prosjektet finnes det også en rekke verktøy og utvidelser som gjør det mulig å utvide orkestreringsplattformen med flere funksjoner. De mest populære er overvåkings- og feildiagnostiseringsverktøyene Prometheus, Weave Scope og sysdig, samt pakkehåndtereren Helm. Det finnes også plugins for Apache Maven og Gradle, samt et Java-API som gjør det mulig å fjernstyre Kubernetes.

Skipsverft

Shipyard er en brukerutviklet administrasjonsløsning basert på Swarm, som lar brukerne administrere Docker-ressurser som containere, bilder, verter og private registre via et grafisk brukergrensesnitt. Den er tilgjengelig som en nettapplikasjon via nettleseren. I tillegg til funksjonene for klyngeadministrasjon som er tilgjengelige via et sentralt nettgrensesnitt, tilbyr Shipyard også brukergodkjenning og rollebasert tilgangskontroll.

Programvaren er 100 % kompatibel med Docker Remote API og bruker den åpne kildekode-NoSQL-databasen RethinkDB til å lagre data for brukerkontoer, adresser og hendelser. Programvaren er basert på klyngestyringsverktøyet Citadel og består av tre hovedkomponenter: kontrolleren, API-et og brukergrensesnittet.

• Shipyard-kontrolleren: Kontrolleren er kjernekomponenten i administrasjonsverktøyet Shipyard. Shipyard-kontrolleren kommuniserer med RethinkDB for å lagre data, og gjør det mulig å henvende seg til enkeltstående verter i et Docker-klynge og å styre hendelser.
• Shipyard API: Shipyard API er basert på REST. Alle funksjonene i administrasjonsverktøyet styres via Shipyard API.
• Shipyard-brukergrensesnitt (UI): Shipyard-brukergrensesnittet er en AngularJS-app som gir brukerne et grafisk brukergrensesnitt for administrasjon av Docker-klynger i nettleseren. All interaksjon i brukergrensesnittet skjer via Shipyard API.

Du finner mer informasjon om åpen kildekode-prosjektet på Shipyards offisielle nettside.

Panamax

Utviklerne av det åpne kildekode-prosjektet Panamax har som mål å forenkle distribusjonen av apper som består av flere containere. Det gratis verktøyet gir brukerne et grafisk brukergrensesnitt som gjør det mulig å utvikle, distribuere og spre komplekse applikasjoner basert på Docker-containere på en enkel måte ved hjelp av dra-og-slipp-funksjonalitet.

Panamax gjør det mulig å lagre komplekse applikasjoner med flere containere som applikasjonsmaler og distribuere dem i klyngearkitekturer med bare ett klikk. Ved hjelp av en integrert app-markedsplass som ligger på GitHub, kan maler for egenutviklede applikasjoner lagres i Git-repositorier og gjøres tilgjengelige for andre brukere.

De grunnleggende komponentene i Panamax-arkitekturen kan deles inn i to grupper: Panamax Local Client og et hvilket som helst antall eksterne distribusjonsmål.

Den lokale Panamax-klienten er kjernekomponenten i dette Docker-verktøyet. Den kjøres på det lokale systemet og gjør det mulig å lage komplekse containerbaserte applikasjoner. Den lokale klienten består av følgende komponenter:

• CoreOS: Installasjonen av den lokale Panamax-klienten krever Linux-distribusjonen CoreOS som vertsystem, som er spesielt utviklet for programvarekontainere. Panamax-klienten kjøres deretter som en Docker-kontainer i CoreOS. I tillegg til Docker-funksjonene har brukerne tilgang til ulike CoreOS-funksjoner. Disse inkluderer blant annet Fleet og Journalctl:
• Fleet: i stedet for å integrere direkte med Docker, bruker Panamax-klienten klyngestyringsverktøyet Fleet til å koordinere containerne sine. Fleet er et klyngestyringsverktøy som kontrollerer Linux-daemonen systemd i dataklynger.
• Journalctl: Panamax-klienten bruker Journalctl til å be om loggmeldinger fra Linux-systemadministratoren systemd fra journalen.
• Lokal klientinstallasjon: Den lokale klientinstallasjonen inneholder alle komponenter som er nødvendige for å installere Panamax-klienten på et lokalt system.
• Panamax lokal agent: den sentrale komponenten i den lokale klienten er den lokale agenten. Denne er koblet til ulike andre komponenter og avhengigheter via Panamax API. Disse inkluderer den lokale Docker-verten, Panamax-brukergrensesnittet, eksterne registre og de eksterne agentene til distribusjonsmålene i klyngen. Den lokale agenten kommuniserer med følgende programgrensesnitt på det lokale systemet via Panamax API for å utveksle informasjon om kjørende applikasjoner:
• Docker-fjern-API: Panamax søker etter bilder på det lokale systemet via Docker-fjern-API og henter informasjon om kjørende containere.
• etcd API: filer overføres til CoreOS Fleet-daemonen via etcd API.
• systemd-journal-gatewayd.services: Panamax henter journalutdataene fra tjenester som kjører via systemd-journal-gatewayd.services.

I tillegg støtter Panamax API også samhandling med ulike eksterne API-er.

• Docker Registry API: Panamax henter bildetagger fra Docker Registry via Docker Registry API.
• GitHub-API: Panamax laster inn maler fra GitHub-repositoriet ved hjelp av GitHub-API-et.
• KissMetrics API: KissMetrics API samler inn data om maler som brukerne kjører.
• Panamax UI: Panamax UI fungerer som et brukergrensesnitt på det lokale systemet og gjør det mulig for brukere å styre Docker-verktøyet via et grafisk grensesnitt. Brukerinnspill videresendes direkte til den lokale agenten via Panamax API. Panamax UI er basert på CTL Base UI Kit, et bibliotek med UI-komponenter for webprosjekter fra CenturyLink.

I Panamax-terminologien kalles hver node i et Docker-klynge uten administrasjonsoppgaver for et eksternt distribusjonsmål. Distribusjonsmål består av en Docker-vert som er konfigurert til å distribuere Panamax-maler ved hjelp av følgende komponenter:

• Installasjonsprogram for distribusjonsmål: Installasjonsprogrammet for distribusjonsmål starter en Docker-vert, komplett med en Panamax-fjernagent og en orkestreringsadapter.
• Panamax-fjernagent: hvis en Panamax-fjernagent er installert, kan applikasjoner distribueres via den lokale Panamax-klienten til hvilket som helst ønsket endepunkt i klyngen. Panamax-fjernagenten kjører som en Docker-container på hvert distribusjonsmål i klyngen.
• Panamax-orkestreringsadapter: I orkestreringsadapteren tilbys programlogikken for hvert orkestreringsverktøy som er tilgjengelig for Panamax i et uavhengig adapterlag. På grunn av dette har brukerne muligheten til alltid å velge nøyaktig hvilken orkestreringsteknologi som skal støttes av deres målmiljø. Forhåndskonfigurerte adaptere inkluderer Kubernetes og Fleet:
• Panamax Kubernetes-adapter: i kombinasjon med Panamax-fjernagenten muliggjør Panamax Kubernetes-adapteren distribusjon av Panamax-maler i Kubernetes-klynger.
• Panamax Fleet-adapter: i kombinasjon med Panamax-fjernagenten muliggjør Panamax Fleet-adapteren distribusjon av Panamax-maler i klynger som styres ved hjelp av Fleet-klyngemanageren.

Følgende diagram viser samspillet mellom de enkelte Panamax-komponentene i et Docker-klynge:

Det CoreOS-baserte containeradministrasjonsverktøyet Panamax gir brukerne tilgang til en rekke standardteknologier for containerorkestrering via et grafisk brukergrensesnitt, samt muligheten til å administrere komplekse applikasjoner med flere containere på en enkel måte i klyngearkitekturer ved hjelp av hvilket som helst system (f.eks. din egen bærbare PC).

Gjennom Panamax’ offentlige malarkiv har Panamax-brukere tilgang til et offentlig malbibliotek med ulike ressurser via GitHub.

Drone

Drone er en slank plattform for kontinuerlig integrasjon med minimale krav. Med dette Docker-verktøyet kan du automatisk laste inn den nyeste versjonen fra et Git-depot som GitHub og teste den i isolerte Docker-containere. Du kan kjøre hvilken som helst testpakke og sende rapporter og statusmeldinger via e-post. For hver programvaretest opprettes en ny container basert på bilder fra det offentlige Docker-registeret. Dette betyr at ethvert offentlig tilgjengelig Docker-bilde kan brukes som miljø for testing av koden.

Drone er integrert i Docker og støttes av ulike programmeringsspråk, som PHP, Node.js, Ruby, Go og Python. Containerplattformen er den eneste egentlige forutsetningen. Du kan opprette din egen personlige plattform for kontinuerlig integrasjon med Drone på ethvert system der Docker kan installeres. Drone støtter ulike versjonskontrollrepositorier, og du finner en veiledning for standardinstallasjon med GitHub-integrasjon på nettstedet til åpen kildekode-prosjektet under readme.drone.io.

Administrasjonen av plattformen for kontinuerlig integrasjon skjer via et webgrensesnitt. Her kan du laste inn programvareversjoner fra hvilket som helst Git-repositorium, slå dem sammen til applikasjoner og kjøre resultatet i et forhåndsdefinert testmiljø. For å gjøre dette opprettes en .drone.yml-fil som angir hvordan applikasjonen skal opprettes og kjøres for hver programvaretest.

Dronebrukere får tilgang til en åpen kildekode-CI-løsning som kombinerer fordelene ved alternative produkter som Travis og Jenkins i et brukervennlig program.

OpenStack

Når det gjelder å bygge og drifte åpne kildekode-baserte skystrukturer, er det åpne kildekode-baserte skyoperativsystemet OpenStack den foretrukne programvareløsningen.

Med OpenStack kan du administrere datamaskin-, lagrings- og nettverksressurser fra et sentralt kontrollpanel og gjøre dem tilgjengelige for sluttbrukere via et webgrensesnitt.

Skyoperativsystemet er basert på en modulær arkitektur som består av flere komponenter:

• Zun (containertjeneste): Zun er OpenStacks containertjeneste og gjør det enkelt å distribuere og administrere containerbaserte applikasjoner i OpenStack-skyen. Formålet med Zun er å la brukerne administrere containere gjennom et REST-API uten å måtte administrere servere eller klynger. For å bruke Zun må du ha tre andre OpenStack-tjenester, nemlig Keystone, Neutron og kryr-libnetwork. Funksjonaliteten til Zun kan også utvides gjennom tilleggstjenester i OpenStack, som Cinder og Glance.
• Neutron (nettverkskomponent): Neutron (tidligere Quantum) er en portabel, skalerbar og API-støttet systemkomponent som brukes til nettverkskontroll. Modulen tilbyr et grensesnitt for komplekse nettverkstopologier og støtter ulike plugins som gjør det mulig å integrere utvidede nettverksfunksjoner.
• kuryr-libnetwork (Docker-driver): kuryr-libnetwork er en driver som fungerer som et grensesnitt mellom Docker og Neutron.
• Cinder (blokklagring): Cinder er kallenavnet på en komponent i OpenStack-arkitekturen som tilbyr permanent blokklagring for drift av virtuelle maskiner. Modulen tilbyr virtuell lagring via et selvbetjent API. Gjennom dette kan sluttbrukere benytte seg av lagringsressurser uten å være klar over hvilken enhet som leverer lagringen.
• Keystone (identitetstjeneste): Keystone gir OpenStack-brukere en sentral identitetstjeneste. Modulen fungerer som et autentiserings- og tillatelsessystem mellom de enkelte OpenStack-komponentene. Tilgang til prosjekter i skyen reguleres av leietakere. Hver leietaker representerer en bruker, og det kan defineres flere brukeradganger med forskjellige rettigheter.
• Glance (bildetjeneste): Med Glance-modulen tilbyr OpenStack en tjeneste som gjør det mulig å lagre og hente bilder av virtuelle maskiner.

Du finner mer informasjon om OpenStack-komponenter og -tjenester i artikkelen vår om OpenStack.

I tillegg til komponentene nevnt ovenfor kan OpenStack-arkitekturen utvides ved hjelp av ulike moduler. Du kan lese mer om de ulike valgfrie modulene på OpenStack-nettstedet.

D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) er en åpen kildekode-programvare for drift av distribuerte systemer, utviklet av D2iQ Inc. (tidligere Mesosphere). Prosjektet er basert på den åpne kildekode-klyngemanageren Apache Mesos og er et operativsystem for datasentre. Kildekoden er tilgjengelig for brukere under Apache-lisensen versjon 2 i DC/OS-repositoriene på GitHub. En bedriftsversjon av programvaren er også tilgjengelig på d2iq.com. Omfattende prosjektdokumentasjon finnes på dcos.io.

Du kan tenke på DC/OS som en Mesos-distribusjon som gir deg alle funksjonene til klyngestyringsverktøyet (via et sentralt brukergrensesnitt) og utvider Mesos betydelig.

DC/OS benytter kjernen i det distribuerte systemet til Mesos-plattformen. Dette gjør det mulig å samle ressursene i et helt datasenter og administrere dem som et samlet system, på samme måte som en enkelt logisk server. På denne måten kan du styre hele klynger av fysiske eller virtuelle maskiner like enkelt som du ville betjent en enkelt datamaskin.

Programvaren forenkler installasjonen og administrasjonen av distribuerte applikasjoner og automatiserer oppgaver som ressursadministrasjon, planlegging og kommunikasjon mellom prosesser. Administrasjonen av et klyngesystem basert på D2iQ DC/OS, samt de medfølgende tjenestene, skjer via et sentralt kommandolinjeprogram (CLI) eller et webgrensesnitt (GUI).

DC/OS isolerer klyngens ressurser og tilbyr delte tjenester, som for eksempel tjenesteoppdagelse og pakkehåndtering. Programvarens kjernekomponenter kjører i et beskyttet område – kjernen. Dette omfatter master- og agentprogrammene til Mesos-plattformen, som har ansvaret for ressurstildeling, prosessisolering og sikkerhetsfunksjoner.

• Mesos-master: Mesos-masteren er en masterprosess som kjører på en masternode. Formålet med Mesos-masteren er å styre ressursforvaltningen og koordinere oppgaver (abstrakte arbeidsenheter) som utføres på en agentnode. For å gjøre dette fordeler Mesos-masteren ressurser til registrerte DC/OS-tjenester og mottar ressursrapporter fra Mesos-agenter.
• Mesos-agenter: Mesos-agenter er prosesser som kjører på agentkontoer og er ansvarlige for å utføre oppgavene som distribueres av masteren. Mesos-agenter leverer regelmessige rapporter om de tilgjengelige ressursene i klyngen til Mesos-masteren. Disse videresendes av Mesos-masteren til en planlegger (dvs. Marathon, Chronos eller Cassandra). Denne bestemmer hvilken oppgave som skal kjøres på hvilken node. Oppgavene utføres deretter i en container på en isolert måte.

Alle andre systemkomponenter samt applikasjoner som kjøres av Mesos-agentene via executor, kjører i brukerrommet. De grunnleggende komponentene i en standard DC/OS-installasjon er admin-ruteren, Mesos DNS, en distribuert DNS-proxy, lastbalanseringsverktøyet Minuteman, planleggingsverktøyet Marathon, Apache ZooKeeper og Exhibitor.

• Administratorruter: Administratorruteren er en spesialkonfigurert webserver basert på NGINX som tilbyr DC/OS-tjenester samt sentrale autentiserings- og proxyfunksjoner.
• Mesos DNS: Systemkomponenten Mesos DNS tilbyr tjenesteoppdagingsfunksjoner som gjør det mulig for individuelle tjenester og applikasjoner i klyngen å identifisere hverandre gjennom et sentralt domenenavnsystem (DNS).
• Distribuert DNS-proxy: Den distribuerte DNS-proxyen er en intern DNS-dispatcher.
• Minuteman: Systemkomponenten Minuteman fungerer som en intern lastbalanser som opererer på transportlaget (Layer 4) i OSI-referansemodellen.
• DC/OS Marathon: Marathon er en sentral komponent i Mesos-plattformen som fungerer i D2iQ DC/OS som et init-system (lignende systemd). Marathon starter og overvåker DC/OS-tjenester og -applikasjoner i klyngemiljøer. I tillegg tilbyr programvaren funksjoner for høy tilgjengelighet, tjenesteoppdagelse, lastbalansering, helsesjekker og et grafisk webgrensesnitt.
• Apache ZooKeeper: Apache ZooKeeper er en åpen kildekode-programvarekomponent som tilbyr koordineringsfunksjoner for drift og kontroll av applikasjoner i distribuerte systemer. ZooKeeper brukes i D2iQ DC/OS til koordinering av alle installerte systemtjenester.
• Exhibitor: Exhibitor er en systemkomponent som automatisk installeres og konfigureres med ZooKeeper på hver masternode. Exhibitor tilbyr også et grafisk brukergrensesnitt for ZooKeeper-brukere.

Ulike arbeidsbelastninger kan kjøres samtidig på klyngeressurser som er samlet via DC/OS. Dette muliggjør for eksempel parallell drift på klyngeoperativsystemet for big data-systemer, mikrotjenester eller containerplattformer som Hadoop, Spark og Docker.

I D2iQ Universe finnes det en offentlig appkatalog for DC/OS. Her kan du installere applikasjoner som Spark, Cassandra, Chronos, Jenkins eller Kafka ved ganske enkelt å klikke i det grafiske brukergrensesnittet.

Hvilke Docker-verktøy finnes det for sikkerhet?

Selv om innkapslede prosesser som kjører i containere deler samme kjernen, bruker Docker en rekke teknikker for å isolere dem fra hverandre. Til dette formålet benyttes vanligvis kjernefunksjoner i Linux-kjernen, som Cgroups og Namespaces.

Containere gir imidlertid fortsatt ikke samme grad av isolasjon som man kan oppnå med virtuelle maskiner. Til tross for bruk av isolasjonsteknikker kan viktige kjernesubsystemer som Cgroups, samt kjernelgrensesnitt i katalogene /sys og /proc, nås gjennom containere.

Docker-utviklerteamet har erkjent at disse sikkerhetshensynene utgjør et hinder for innføringen av containerteknologi i produksjonssystemer. I tillegg til de grunnleggende isoleringsteknikkene i Linux-kjernen støtter nyere versjoner av Docker Engine også rammeverkene AppArmor, SELinux og Seccomp, som fungerer som en slags brannmur for kjernefunksjoner.

• AppArmor: Med AppArmor reguleres containerenes tilgangsrettigheter til filsystemene.
• SELinux: SELinux tilbyr et komplekst reguleringssystem der tilgangskontroll til kjernefunksjoner kan implementeres.
• Seccomp: Seccomp (Secure Computing Mode) overvåker utførelsen av systemkall.

I tillegg til disse Docker-verktøyene benytter Docker også Linux-funksjoner for å begrense root-rettighetene som Docker Engine starter containere med.

Det finnes også andre sikkerhetsrisikoer knyttet til sårbarheter i programvarekomponenter som distribueres via Docker-registeret. Siden praktisk talt hvem som helst kan opprette Docker-bilder og gjøre dem offentlig tilgjengelige for fellesskapet på Docker Hub, er det en risiko for at skadelig kode kan komme inn i systemet ditt når du laster ned et bilde. Før en applikasjon tas i bruk, bør Docker-brukere forsikre seg om at all koden i et bilde som brukes til å kjøre containere, stammer fra en pålitelig kilde.

Docker tilbyr et verifiseringsprogram som programvareleverandører kan bruke til å få sine Docker-bilder sjekket og verifisert. Med dette verifiseringsprogrammet ønsker Docker å gjøre det enklere for utviklere å bygge sikre programvareforsyningskjeder for prosjektene sine. I tillegg til å øke sikkerheten for brukerne, har programmet som mål å gi programvareutviklere en måte å skille prosjektene sine fra de mange andre ressursene som finnes tilgjengelig. Verifiserte bilder merkes med et «Verified Publisher »-merke og får, i tillegg til andre fordeler, en høyere rangering i søkeresultatene på Docker Hub.