Sådan bruger du Docker i udvikling og produktion

Scott/Tiger - IT konsulenthus / Udvikling  / Sådan bruger du Docker i udvikling og produktion

Sådan bruger du Docker i udvikling og produktion

Docker er et Open-Source produkt, der gør det muligt at pakke et stykke software i en ”container”. Og dernæst køre dette software i isolation. Hver container ser sig selv som en selvstændig maskine inkl. Operativ system. Ens software kan m.a.o. køre i fuld isolation i Docker, med kun de nødvendige netværksporte åbnet til omverdenen.
Figur 1 Docker arkitektur (kilde: docker.com)
Nedenstående beskrivelse er en kort version af Dockers egen beskrivelse af arkitekturen.
Client
Docker klienten er et program, der køres fra kommondo-linje. Dets formål er at kommunikere med en Docker-daemon og en host-maskine.
Docker host
Er en maskine, der kører en docker-daemon.
Docker-daemon
Dette er programmet, der udfører arbejdet med at hente, gemme og starte docker-images.
Docker-images
Kan ses som images til små virtuelle maskiner ligesom f.eks. VMWare eller VirtualBox (men med mindre overhead).
Docker-containers
Er kørende images. Bemærk at samme image kan køre i flere containers samtidigt.
Registry
Er et eksternt (for docker-host’en) site, hvor images opbevares.
En lille applikation som eksempel
Lad os starte med en lille applikation som udgangspunkt. Lad os forestille os, at der bliver udviklet løbende – måske med forskellige teams – på alle dele af applikationen.
I dette tilfælde en microservice arkitektur. Men det er ikke afgørende.
Applikationen indeholder:
  • tre “services”
  • tre databaser
  • en “gateway”
  • en webapplikation
  • mobil applikation
Uden docker
I en “normal” opsætning af vores applikation kunne man forestille sig databaserne placeret på én (enten samlet eller på hver sin server). Tilsvarende kunne Web Applikationen, Gateway samt Service A, B og C én server eller hver sin. Man kunne også forestille sig alt kørende på samme server.
Lad os forestille os en udvikler, hvis opgave er at implementere Mobil Applikationen. For at kunne gøre dette skal vedkommende, enten på egen maskine eller på anden maskine, have adgang til Gateway’en. For at gateway’en kan køre skal den bruge service a, b og c … og disse skal bruge deres databaser. Hvis en udvikler skal køre alt på egen maskine er det en del pull->build->run kommandoer – med tilhørende risiko for at “nogen” har lagt kode op, som ikke oversætter, fejler under test osv.
Docker i udviklingsmiljøet
For at starte noget i Docker, er udgangspunktet et “docker-image”. Tænk på et VMWare/Virtualbox image, så lille som muligt med alt der skal bruges .. Hvordan man kommer til dette er meget simpelt:
Man tager et lille eksisterende base-image (en slags skabelon). Udfører et antal kommandoer, der installerer hvad der mangler, kopierer sin egen kode ind på plads og starter servicen.
Alt ovenstående kan beskrives i en såkaldt “Dockerfile” (stort set som man selv ville gøre det). Derefter beder man docker om at bygge det nye image. Når det er klar, så kan man bede docker om at starte ens nye image.
Udover at starte ens image vil det være godt, hvis man dokumenterer (i sin Dockerfile), hvilke porte der skal være tilgængelige udefra (f.eks. tcp:80 til en web-server). Docker søger derefter for at disse porte er tilgængelige og routet som definet i filen (f.eks. 8880 -> 80 internt, hvis man kører en http-service i docker).
Figur 2 Standard CD flow
I et standard CI/CD flow, som beskrevet herover, vil et succesfuldt build også inkludere bygningen af et docker image. Både docker-image og andre build-artifacts (jar-filer, exe-filer, …) sørger build-serveren for at gemme et passende sted (Artifact server).
Nu har vi et versioneret docker-image, som vi til enhver tid kan  starte lokalt eller på en test/produktions-server. Bemærk at det nu er samme konfiguration, der kører både lokalt til udviklingsbrug og i produktion (vi styrer allokering af hukommelse, disk-plads osv. via environment-variable).
Yderligere features
Docker-compose
Services afhænger af hinanden. Med docker-compose kan man beskrive, hvilke docker-images, der afhænger af hvilke, samt definere miljø-variable for de omtalte services. Når ens ”compose”-fil er skrevet, kan man med én kommando starte hele eller dele af stakken.
I ovenstående applikation ville man kunne beskrive afhængighederne, og derefter bede docker om at starte ”gateway” servicen. Dette ville resultere i, at alle databaser og services blev startet – i den rigtige rækkefølge. Bad man docker om kun at starte ”Service B, så ville kun ”Database B” og ”Service B” blive startet.
Figur 3 Applikationen som containers
Docker swarm
Man kan hurtigt komme i en situation, hvor en eller flere af ens services skal køre i en eller anden form for cluster. Denne funktion er indbygget i Docker – i form af dens “Swarm-mode”. Her oprettes maskiner med Docker og alle sættes i swarm-mode. Herefter kan der deployes services til sværmen, og angives hvor mange kopier man ønsker at køre. Load-balancing er indbygget.
I eksemplet til højre er Service B og Service C sat i swarm-mode. Der kører flere kopier af de to images og load-balancing håndteres af docker selv.

Figur 4 Swarm-mode
Docker i produktionsmiljøet
Da jeg første gang hørte om Docker, var min tanke at det at køre en fuld “maskine” lokalt måtte koste voldsomt. På samme vis som det at køre en virtuel maskine har et overhead (særligt I/O lider under virtualiseringen).
Men det viser sig at overhead ved at køre et docker-image er (stort set) ikke-eksisterende. Bemærk at test er foretaget på Linux, hvor “kernel namespaces” (som docker er baseret på) er direkte understøttet.
(Kilde: http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf)
Docker i skyen
Som tidligere bemærk vil en virtualiseret maskine, uanset hvilken hypervisor, der benyttes, have et større eller mindre overhead. Og særligt på I/O-fronten. Det er dog vigtigt at holde sig for øje, at hvis man allerede kører på virtuelle maskiner, så er “prisen for det allerede betalt”. Performance-mæssigt vil docker (næsten) ikke påvirke.
Hvad angår produktions-parathed, så har Docker selv en Docker case stories som PayPal, BBC News, ebay o.lign.
Kontakt os
Ønsker du yderlige information og vejledning i, hvordan Docker kan hjælpe dit projekt, så kontakt os på info@scott-tiger.dk eller 4546 0300.
Skrevet af:
Michael Willer
Principal Consultant, Scott/Tiger