Kmom01: Introduktion till devops och Docker

Det är en fullspäckad kurs där vi ska lära oss många nya verktyg och koncept. I kursen ska vi lära oss både om det kulturella inom devops men även det praktiska. Vi börjar med att bekanta oss med ett påbörjat projekt, packa in det i Docker och koppla det till en CI/CD kedja som bygger och publicerar en ny version varje gång vi släpper en.

Kmom01 är två veckor långt!

#Vad är devops?

#Läs och titta

Kolla på följande video för att få en introduktion till ämnet devops. Devops är ett brett ämne med många olika definitioner, här försöker skaparen av CM (Configuration Management) verktyget Chef beskriva konceptet och komma fram till en rimlig definition.

I videon nedanför får vi en kortare genomgång som fokuserar mer på arbetsflödet.

#Miljö

Tanken är att vi ska jobba med ett projekt igenom hela kursen och då behöver vi verktyg och program för att jobba med koden. Vi börjar med en lokal utvecklingsmiljö. En produktionsmiljö kommer i kmom02.

#Lokal utvecklingsmiljö

Alla verktyg ni behöver finns färdiginstallerade, med bestämda versioner, i en dev container som följer med i Microblog repot. Då slipper ni installera och versionshantera Python, make med flera själva. Den innehåller allt ni behöver under hela kursen, ni behöver inte installera något mer senare.

#Att göra

• Följ labbmiljön och starta dev containern, enligt avsnittet “Dev container”. Klona repot inuti WSL om ni använder Windows.
• Kör alla kommandon i kursen i VS Codes terminal, den körs i containern.

Om dev containern inte fungerar för er finns en reservlösning i labbmiljön, där ni installerar verktygen själva.

#Appen

Nästa steg är att bekanta dig med appen som du ska jobba med i kursen.

#Läs och titta

• Introduktion till Devops appen.

#Docker

I kursen ska ni packa in er kod i en Docker container för att underlätta utveckling, driftsättning och körning av applikationen.

#Läs och titta

• Docker i devops.

#Att göra

Jobba igenom:

• Om ni inte redan har ett, Skapa ett konto på DockerHub.
• Microblog i Docker

Läs:

• Vsupalov’s recension av Docker Usage in ‘The Flask Mega-Tutorial’.

#Continuous Integration

Vi vill ha en CI-kedja till repot så att testerna automatiskt körs när du gör push. I kursen har jag valt att använda GitHub Actions.

#Läs och titta

• Continuous Integration av Martin Fowler.

#Att göra

Jobba igenom:

• “Building and testing Python” i Actions.

#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.

#Läs och titta

• Continuous Delivery av Martin Fowler.

• Reusing workflows i Actions.

• Publishing Docker images från Actions. Dokumentation om alternativ till att bygga er image

#Hur vi jobbar med repot

Ni ska jobba enligt GitHub Flow i ert repo. Det betyder att ni ska ha feature branches, göra pull requests och göra code reviews. För att underlätta det ska ni också skriva bra commit meddelanden.

#Läs och titta

• GitHub Flow

• The seven rules of a great Git commit message. Använd reglerna när ni skriver commit meddelanden.

• Semantisk versionshantering, en bra versionsstandard för projekt.

#Lästips

• The 12 Factor App är en populär “standard” för att bygga Software-as-a-service och används mycket i devops sammanhang.

• DevOps Roadmap Visar upp vanligaste verktygen man behöver kunna för att jobba med de tekniska delarna av devops.

  • Här kan ni se vilka av verktygen vi kommer använda oss i kursen, i fylld devops roadmap

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

#Läsanvisningar

Läsanvisningar hittar ni på sidan bokcirkel.

Kolla i lektionsplanen för att se när vi träffas för bokcirkeln.

#Uppgifter

1. Jobba i ert repo enligt Hur vi jobbar med repot. Det betyder att

   • Ni ska ha feature branches och när ni är klara med en del gör ni pull request till huvudbranchen (master), den andra av er ska göra code review.
   • Ni ska skriva bra commit meddelanden.
   • Ni ska följa semantisk versionshantering.

2. Skapa en Dockerfile för Microblog. Om ni redan har jobbat igenom Docker delen så är den klar. Filen ska heta docker/Dockerfile_prod. Filen boot.sh från guiden ligger i roten av repot.

   • Validera filen med make validate-docker. Kommandot använder hadolint. Det kan klaga på saker som guiden inte nämner, läs regeln i meddelandet och rätta Dockerfilen. Passar en regel inte kan ni stänga av den för en rad med en kommentar, t.ex. # hadolint ignore=DL3018. Skriv då varför.

   • Skapa en compose fil, docker-compose.yml, i root mappen av ert repo. Lägg till en service som startar prod containern mot en MySQL container.

     • Kommandot docker-compose up prod ska starta en MySQL och en microblog container.

3. Skapa en Dockerfile för testning, docker/Dockerfile_test.

   • Vid start ska container köra make test och sen stänga ner.
     • mapparna app och tests ska inte kopieras in utan ligga som volymer.
     • installera requirements/test.txt Istället för prod.txt.
     • skapa en nytt skript som körs vid uppstart. Det ska köra make test, så alla tester körs.
     • imagen behöver innehålla make (i Alpine installeras det med apk add make) och filerna som make test använder: Makefile, pytest.ini, .pylintrc och .coveragerc.
   • Validera Docker filen med make validate-docker.
   • Lägg till en ny service i docker-compose.yml som kör test containern. Den ska gå att starta med docker-compose up test.
   • Om ni vill, ändra så testerna körs mot en MySQL server istället för SQLite.

4. Sätt upp Continuous Integration. Koppla ditt repo till GitHub Actions. När du gör en push, till vilken branch som helst, ska Actions köra alla unittester, integrationtester och validera koden och Dockerfilerna (make validate-docker).

   • Använd ubuntu-24.04 som runs-on, inte ubuntu-latest. Då ändras inte bygget av sig självt när GitHub byter Ubuntu version.
   • Workflow:et ska köras vid push till en branch men inte när ni pushar en tagg. Då körs testerna bara en gång vid en ny tagg, CD workflow:et kör dem själv.
   • Lägg till en Actions badge i README filen för repot.

5. Sätt upp Continuous Delivery i Actions.

   • Skapa ett nytt workflow (separat fil) som bygger och pushar er Docker image till DockerHub men bara om testerna från CI passerar. Ni uppnår det genom att från det nya workflow:et återanvända det som tester koden.
   • CD kedjan ska bara köras vid ny tagg, inte varje kommit.
   • Ni får inte använda latest taggen, ni ska ha unika taggar för varje ny version. T.ex. använd er semantiska version som tagg. En git tagg v11.0.1 ska ge imagen <användarnamn>/microblog:11.0.1.
   • Användarnamn och lösenord till DockerHub sparar ni som secrets i GitHub, inte i koden.
   • Workflow:et ska skicka versionen till bygget som build argument APP_VERSION, se nästa uppgift.

6. Lägg till en route, /version, i Microblog som visar vilken version av appen som körs.

   • Routen ska gå att anropa utan att logga in. Svaret är bara versionen som text, t.ex. 11.0.1.
   • Versionen ska komma från miljövariabeln APP_VERSION, som ni läser i app/config.py. Finns den inte ska svaret vara unknown.
   • Skriv tester för routen i tests/integration/main/. Testa både standardvärdet och ett satt värde.
   • Imagen ska ta emot versionen som ett build argument (ARG APP_VERSION i Dockerfilen) och sätta miljövariabeln. I docker-compose.yml kan ni skicka med APP_VERSION som build argument, ge den ett standardvärde.
   • Skapa en ny tagg (se nästa uppgift). CD kedjan ska bygga och publicera en ny image. Starta imagen från DockerHub och kontrollera att /version visar versionen från taggen.

7. Tagga repot, följ semantiska versionshantering fast börja på siffran 11.0.0. Jag har redan taggar detta repo och då kan ni inte börja på 0. Taggen ska börja med v, t.ex. v11.0.0. Om ni får komplettering på en inlämning öka versionen.

#Resultat & Redovisning

Svara på nedanstående frågor individuellt, lämna in på Canvas tillsammans med länken till ert gemensamma GitHub-repo och ert DockerHub användarnamn.

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

1. Vad var din uppfattning av devops innan kursen började?

2. Hur skulle du definiera devops än så länge?

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

4. Hur används Docker inom devops?

5. Vad är Continuous Delivery?

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

7. Veckornas TIL?

#Revision history