Kmom02: Docker

By . Latest revision .

Vi packar in vår kod i en Docker container för att underlätta utveckling, driftsättning och körning av vår applikation.

Innan ni sätter igång med kursmomentet kolla att ert Microblog repo är synkat med originalet, Syncing a fork.

#Vad är Docker?

En snabb översikten av vad Docker är kan vi hitta på Dockers egna webbsida. Docker är en container teknologi som liknar en avskalad virtuelle maskin. Vad tillför det till oss som utvecklare?

Docker låter utvecklare att utveckla och driftsätta applikationer i virtuella container miljöer. Detta ska göra att en applikation kan köras på exakt samma sätt utan kompabilitets problem oberoende av vilken dator/server den körs på, så länge Docker är installerat. Att applikationen kan köras oberoende av systemet gör att applikationen blir lättare att använda, utveckla och underhålla och driftsätta.

#Docker terminologi

  • Image: En image är typ ett exekverbart paket som innehåller allt som behövs för att köra applikationen, det inkluderar konfigurationsfiler, miljö variabler och bibliotek.
  • Dockerfile: Fil som innehåller instruktionerna för att bygga en Docker image.
  • Build: Skapa en image snapshot från Dockerfile.
  • Tag: Version av en image. Varje image har ett tag namn.
  • Container: Ett lättviktig program paket skapat från en specifik image version.
  • DockerHub: Image repository där vi kan hitta images. Typ GitHub för images.
  • Docker Daemon: Körs på host systemet. Användare kan inte jobba direkt mot Docker daemon utan gör det via Docker klienter.
  • Docker Engine: Skapar och kör Containers.
  • Docker Client: Huvud interfacet för Docker.

#Installera Docker

För att få en bättre förståelse för Docker behöver vi använda det och då måste vi installera det. Notera att det kan vara lite svårt med Docker i Windows 10 Home b.la., om ni har en annan miljö ni kan jobba på så rekommenderas det. Lösningen för tillfället är att köra Docker i VirtualBox på Windows 10 Home.

#Öva på Docker

Kolla på följande video för en kort introduktion till Docker och hur vi kan använda det.

Docker Concepts Introduction

Om ni redan har läst kursen vlinux kan ni gå vidare till nästa steg. Annars jobba igenom hela följande guide för att lära er skapa egna images och containrar.

Om ni har tid och känner att ni vill öva lite mer på Docker kan ni testa Docker på Catacoda.

#Docker i devops

Docker är väldigt populärt inom devops världen av många anledningar och ni kan läsa varför i Dockers bloggserie Docker and the Three Ways of DevOps.

#Skapa egen Docker image för produktion

Nu när vi har lite kött på benen och vet vad Docker är och hur det fungerar ska ni skapa en egen Dockerfile för microblogen.

  • Jobba igenom Microblog med docker containers för att skapa dig en Dockerfile för produktion. Döp din Dockerfile till Dockerfile_prod och lägg den i mappen docker.

Efter att ni skapat er Dockerfile kan läsa två relevanta artiklar om docker användning.

#Databas i Docker

Att köra sin databas i Docker har länge varit debatterat, många är emot men fler och fler börjar tycka att det är OK. Jag är för att köra databasen in Docker så länge man lägger data mappen som en volym så att datan inte skrivs över när vi startar om containern.

MySQL sparar sin data i mappen /var/lib/mysql så när ni kör er databas container i produktion gör den mappen till en volym på host systemet.

#Skapa en Docker image för testning

Nästa steg är att skapa en till Dockerfile, fast en som bara ska användas för testning.

När vi kör docker i produktion vill vi att containern ska vara igång för evigt. När vi istället gör en image för testning vill vi bara starta upp en container, köra alla tester i den och sedan stänga ner.

Vi vill inte behöva bygga om containern varje gång vi vill köra testerna. Det tar för lång tid. Vi kan lösa det genom att inte kopiera in koden i containern när den byggs. Istället mappar vi mappen som koden ligger i in i containern. Då behöver bara containern innehålla miljön för att köra testerna. Detta gör att vi bara behöver skapa containern en gång och sen kan vi återanvända den när vi har ändrat i koden.

Skapa en Dockerfile, döp den till Dockerfile_test och lägg den i mappen docker. Den ska inte innehålla koden för testerna eller koden som testas, det ska läggas som en volym. När containern startar ska den validera koden och köra unit och integrations testerna. När det är klart ska containerna stängas ner av sig själv.

Om ni vill kan ni ändra så integrationstesterna körs mot MySQL i docker container istället för SQLite i minnet. Testerna kommer troligen köras långsammare men testerna blir mer värdefulla då de körs mot likadant system som körs i produktion. När man kör databasen i en container för testerna brukar man inte göra data mappen till en volym, i och med att vi inte bryr oss om persistent data för tester.

Kolla så att era Dockerfiler validerar med hadolint. Make kommandot make validate-docker kör validering på Dockerfile_prod och Dockerfile_test.

#Spara konfiguration som kod

En viktigt del av det praktiska inom devops är att spara konfiguration som kod och versionshantera den. Detta är för att undvika att tillfällen uppstår där det bara är specifika personer som vet hur man startar/kör/konfigurerar något. Allt ska finnas som kod och versionshanterat så alla kan göra det.

En typisk sån sak är att bygga/köra Docker images. Att bygga/starta en image behöver ofta någon slags konfiguration t.ex. vad ska vara volymer, miljövariabler eller vilken port som ska öppnas. Om detta inte finns som kod blir det svårt för någon annan än för den som skrev koden att göra det.

För Docker använder vi docker-compose i detta syftet. Om ni jobbade igenom hela docker guiden längre upp borde ni ha det installerat. Annars jobba igenom följande guide.

Skapa filen docker-compose.yml i root mappen av repot. I den, lägg till en service för att köra test container och en som startar prod containern mot en MySQL container.

docker-compose up test ska starta test containern och köra alla tester.

docker-compose up prod ska starta en MySQL container och er prod container.

Updatera make test så det startar er test container och kör alla tester.

#CircleCI och Continuous Delivery

Vi kan se Continuous Delivery som steget efter Continuous Integration. I CI har vi ett flöde där vi kör tester automatisk, nästa steg är när alla tester har blivit godkända. Då vill vi bygga vår applikation så att den finns tillgänglig för driftsättning med de senaste uppdateringarna. Vår applikation bygger vi genom att skapa en fungerande docker image. Läs en mer detaljerad förklaring av Martin Fowler, ett av de stora namnen inom Microservices, Software Development och Continuous Integration/Delivery/Deployment. I nästa kursmoment ska vi ta det ett steg längre och uppnå Continuous Deployment, vilket lägger till att automatisk driftsätta applikationen efter vi testat och byggt den.

Vi ska inte uppnå “riktigt” CD då vi inte har en staging miljö och vi borde testa koden mer rigoröst. Men vi jobbar med det vi har. Vi har redan ett CI flöde på CircleCi, nu ska ni bygga ut det med delivery steget. Om testerna går igenom ska ni bygga er produktions image och publicera den på DockerHub.

Om ni inte redan har ett, skapa först ett konto på DockerHub. Skapa sen ett nytt repo där ni kan ladda upp er produktions image. När ni gjort det testa ladda upp er första image manuellt.

Nu vill vi att er produktions image byggs och pushas till dockerhub automatiskt när ni pushar uppdateringar i er kod till GitHub. Vi gör så att detta sker i CircleCi. Läs följande artikeln för att se hur ni kan skriva er CircleCi config för att bygga och publicera er image till DockerHub. Tänk på att ni bara vill bygga och publicera en ny image om alla tester går igenom. Innan ni gör det kan ni installera CircleCi CLI för att slippa massa commit där CircleCi configen inte validerar.

Gör ett aktivt val mellan att bara publicera ny image för varje ny release eller om det ska ske vid varje commit.

Vi vill inte spara lösenord eller annan känslig information i kod så att det finns publikt på GitHub. Samtidigt behöver vi använda oss av t.ex. lösenord när vi kör saker i CircleCi. Känslig information kan vi spara som miljövariabler i CircleCi och sen använda i CircleCI flödet.

#Kör i produktion

Det sista steget är att köra er produktions container på er VM i Azure. Installera Docker på servern och starta up er microblog med docker-compose. Bygg inte containerna på servern utan använd den som byggts på CircleCi och laddas upp till DockerHub.

Ni ska inte använda supervisor längre. Vi använde supervisor för att se till att det hela tiden finns en Gunicorn process igång men det ansvaret flyttas över till Docker. Lägg till restart: always i er docker-compose fil.

Läs om vad Docker tycker om att använda compose i produktion.

#Video

Det finns generellt kursmaterial i video form.

  1. Kursen innehåller föreläsningar som spelas in och därefter läggs i spellistan “devops streams ht20”.

  2. I “kursen devops” hittar du alla videor som är kopplade till kursmomentet, de börjar på 2xx i namnet.

#Uppgifter

Följande uppgifter skall utföras och resultatet skall redovisas.

  1. Två Dockerfile’s i mappen docker, en för produktion som heter Dockerfile_prod och en som heter Dockerfile_test.

  2. En docker-compose fil för att köra test och starta prod miljön.

  3. make test kör testerna och validerar kod i Docker. validate-docker funkar inte på CircleCi, om ni vill lägga till att validera era dockerfiler behöver ni använda en docker orb

  4. CircleCi kör testerna, validering och bygger produktions image och pushar till DockerHub.

  5. Försäkra dig om att du har pushat repot med din senaste kod och taggat din inlämning med version v2.0.0. Om du pushar kmom02 flera gånger kan du öka siffrorna efter 2:an.

  6. Inkludera en länk till ditt GitHub repo och din webbsida (domännamn) i din inlämning på Canvas.

#Lästips

Multistage builds, för vår app är detta kanske inte nödvändigt men det är väldigt bra att känna till.

Best practices för Docker.

Docker latest tag, ett annat hett ämne inom Docker är om man ska använda latest taggen för att köra images eller ej.

Building Your Production Tech Stack for Docker Container Platform, video från DockerCon 2018.

#Resultat & Redovisning

Läs instruktionen om hur du skall redovisa.

Se till att följande frågor besvaras i texten:

  1. Har du använt Docker förut? Gick det bra att använda det nu?

  2. Valde du att bygga ny Docker image vid varje commit eller release? Varför?

  3. Vad är Continuous Delivery?

  4. Uppdaterade du deploy skripten med Docker?

  5. Hur var storleken på kursmomentet? Vad tycker du om upplägget på kursmomentet?

  6. Veckans TIL?

#Revision history

  • 2020-11-06: (B, aar) Ready for HT20.
  • 2019-11-01: (A, aar) Första versionen.

Document source.