Kmom02: Configuration Management och Continuous Deployment

I kmom01 fixade ni en utvecklingsmiljö och CI/CD. I detta kmom ska vi sätta upp en produktionsmiljö och utveckla CD kedjan till Continuous Deployment.

PS! Kmom02 är två veckor långt!

Vi ska bygga en klassisk webbapp struktur, en databas, flera servrar för appen och en load balancer. För detta behöver vi tre VM’s i Azure. Vi ska utnyttja kraften av Configuration Management verktyget Ansible för att på ett hållbart sätt skapa och konfigurera servrarna i Azure. Vi ska skapa och stänga ner servrar med ett kommando, installera och konfigurera dem och tillslut ha ett kommando för att sätta upp hela produktionsmiljön, från zero to hero!

#Läsanvisningar

Läsanvisningar hittar ni på sidan bokcirkel.

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

#Produktions miljö

När man jobbar enligt devops ska saker ofta gå snabbt och automatiskt, då underlättar det om man snabbt och enkelt kan starta upp och stänga ner servrar. Därför ska vi använda oss av en molntjänst, mer specifikt Microsoft Azure. OBS! logga inte in via den länken.

#Struktur i molnet

Om er Microblog blir en superhit och ni får jättemånga användare behöver ni en strategi för att hantera all trafik. En lösning är att köpa en större VM och fortsätta ha allt på den. En annan lösning är att dela upp de olika delarna på flera VM’s. Då blir det också lättare om vi skulle behöva utöka ännu mer i framtiden.

Strukturen är att vi har två olika VM’s för Microblog. Båda kör en varsin kopia av Microblog och är kopplade till samma databas. På det sättet kan vi sprida ut hanteringen av request på två olika VM’s och kan hantera fler besökare. Förutsatt att databasen kan hantera request från två olika källor samtidigt på ett bra sätt, det borde inte vara några problem än så länge.

Steget vi har kvar är att koppla ett domännamn till båda Microblog VM’s. Det kan vi använda en load balancer. Vi sätter Nginx som en load balancer och låter den dela upp inkommande requests till de båda Microblog VM’s.

Databasen ska egentligen ligga på en egen VM. Då kan databasen och load balancern drivas och skalas var för sig, och ett fel i den ena tar inte ner den andra. För att spara kostnader i Azure återanvänder vi i kursen VM:en för load balancern och kör databasen där. Så gör man inte i produktion, tänk på det när ni skriver er redovisning. Ni ska ändå skriva er kod så att databasen är en egen roll i Ansible, med eget host namn (database), så att det går att flytta den till en egen VM senare.

På bilden har loadbalancer och databasen speciella ikoner men det är fortfarande vanliga VM’s vi ska använda. Bilden visar en egen VM för databasen, i kursen kör databasen på samma VM som load balancern.

#Att göra

Jobba igenom:

• Kom igång med Azure. I guiden visas hur ni skapar en VM manuellt. Det ska ni inte göra, vi skapar VM’s med Ansible kod istället. Det är dock bra att veta hur man gör det manuellt.

#Kostnad

Azure kostar pengar för varje VM som är igång, och även en stoppad VM kostar för disk och IP adress. Därför har vi bara tre VM’s, och ni ska stänga av dem när ni inte jobbar. I Ansible mappen finns två playbooks för det:

• stop_instances.yml stoppar alla VM’s. Servrarna, IP adresserna och diskarna finns kvar men ni betalar inte för att de körs.
• start_instances.yml startar dem igen. Det tar någon minut.

Skapa och radera hela miljön med terminate_instances.yml och site.yml tar ungefär 15 minuter och databasen med all data försvinner. Använd stop och start när ni bara tar en paus.

#Infrastructure as Code och Configuration Management

Infrastructure as Code (IaC) innebär att behandla sin infrastruktur (servrar) som mjukvara, det ska vara definierat i kod och versionshanterat. Configuration Management (CM) är typ samma sak fast med fokus på mjukvaran som körs på servrarna, att skapa använda, installera program och konfigurera dem ska göras via kod.

#Läs och titta

• An introduction to Congifuration Management.

• When to use which IaC/CM tool.

#Ansible

Låt oss lära oss mer om Ansible.

#Läs och titta

• What Is Ansible.

• Introduktion till att använda Ansible.

• Ansible Best Practices.

Jag har fått som kommentar att studenterna vill ha mer Ansible material så här är två olika spellistor för de som vill har mer om Ansible. Ni kan testa skippa dem och jobba vidare. Om ni upplever att ni behöver lära er mer så kan ni gå tillbaka till någon av dessa spellistor.

• Getting Started with Ansible
• Ansible 101

#Bekanta er med Ansible koden

Låt oss kolla på Ansible koden som redan finns i Microblog repot.

Ansible och Azure CLI finns i er dev container.

#Läs och titta

• Kolla på videorna med 20xi namnet för att bekanta er med vad som finns i Ansible mappen i Microblog repot, kursen devops. Några saker kan skilja sig från koden som visas i videorna men det ska inte vara några stora ändringar.

  • PS. Skippa inte videorna!
  • Videorna prata inte om koden som ligger i deploy_lb. Den får ni läsa och förstå själva.

• Om ni vill hänga med och skriva 10-first-minutes själva så kan ni kolla på videorna med “21x” i namnet. Videorna är lite utdaterade när det kommer till hur man exekverar filerna. Då pratar jag om AWS men om ni har kollat på de andra videorna så vet ni hur man exekverar filerna.

#Att göra

1. Uppdatera er provision Playbook så att tre servrar skapas.

• En loadbalancer och två appserver, en som heter appserver1 och en appserver2. Databasen körs på loadbalancer.
• Appservrarna ska dela security group.
• Lägg till två subdomäner som går till varsin appserver. De ska heta appserver1.<domännamn> och appserver2.<domännamn>.
• Skapa en hosts fil och lägg till subdomänerna som hosts. Namnge inte hostarna i provisioning playbook till samma namn som grupperna som gather_instances skapar (appserver, loadbalancer, database). Då matchar hosts: loadbalancer fel host och er load balancer får aldrig något deployat, utan något felmeddelande.

1. Uppdatera “10-first-minutes” Playbook så att alla gruppmedlemmars SSH-nycklar läggs till i authorized_keys. I modulen ansible-role-users kan ni se ett exempel på hur man kan göra det. Då behöver ni ladda upp allas publika nycklar i ert repo. Det är säkert att ladda upp de publika nycklarna. De kan inte användas för att återskapa den privata.
   • Tips. pub_ssh_key_location används av provisioneringen och ska vara en enda fil. Lägg gruppens nycklar som en fil per person i en egen mapp och låt 10-first-minutes läsa in alla filer i mappen.
   • PS. Tänk på att köra gather_instances.yml med 10-first-minutes för att hitta vilka VMs som finns.
   • Kör “10-first-minutes” mot alla tre VMs.

#Sätta upp Nginx som en Load balancer

Vi ska köra Nginx som Load balancer, här lär vi oss mer om Nginx.

#Läs och titta

• Nginx Tutorial for Beginners.
• Beginner’s Guide to NGINX Configuration Files.
• Nginx load balancer.

I länken ovanför skriver de inte att vi inte kan lägga ett http block i ett annat http block. Vilket vi gör om vi bara skapar en ny host i /etc/nginx/sites-available. Detta gör att vi måste ändra på config filen /etc/nginx/nginx.conf.

#Playbooks för Microblog och databas

Nu ska ni själva implementera playbooks för att sätta upp microbloggen på båda appservrarna och en mysql databas på databasen (som alltså körs på load balancer VM:en).

Att göra

1. Sätt upp Microbloggen med Ansible.

#Continuous Deployment (CD)

Vi ska utöka från Continuous Delivery till Deployment.

#Läs och titta

• The fundamentals of continuous deployment in DevOps.

• Deployment Strategies

#SSH från Github Actions till VM’s

När ni ska implementera er CD strategi behöver ni kunna logga in med SSH från GitHub Action till era servrar. Hur ni gör det kan ni hitta i Kör playbook på VM från GigHub Action.

#Deploy efter publish

En deploy ska bara köras när Docker imagen är publicerad. Ett eget workflow som triggas av samma tag kör parallellt med publish och deployar en image som inte finns än. Lägg istället deploy som ett jobb i samma workflow som publish, som väntar på att publish är klart. Hur ni skickar versionen mellan jobben får ni lista ut.

#Lästips

1. Hur man kan hantera flera användare på produktionsservern med Ansible.

#Uppgifter

1. I Azure ska ni ha strukturen med tre VMs, en Load balancer (som också kör databasen) och två app servrar. Site.yml playbook:en ska kunna sätta upp hela miljön från inget till klar.

2. Implementera en Continuous Deployment strategi med Ansible och Github Actions.

• Vid ny tag ska Actions köra Ansible playbooks som gör en valbar CD strategi för att driftsätta den nya versionen.
• Er strategi ska inte ha någon downtime, så ni kan inte använda Recreate Deployment Strategy.
• En avslutande del i er CD playbook ska verifiera att rätt version av Microblog körs på produktionsservrarna. Använd routen /version som ni skapade i kmom01 och jämför med taggen.

#Resultat & Redovisning

1. Vad menas med Idempotency inom CM och IaC?

2. Vilket av CM/IaC verktygen som presenterades i “When to use which IaC/CM tool” tycker du lät mest intressant och varför?

3. Vilken CD strategi valde ni?

4. Kan du se några problem med er CI/CD kedja?

5. Om du fick välja fritt hur skulle du vilja bygga upp CD kedjan?

6. Databasen körs på samma VM som load balancern för att spara kostnader. Varför borde databasen ha en egen VM, och vilka risker finns med att dela VM?

7. Hur var storleken på kursmomentet?

8. Veckans TIL?

#Revision history