Kmom02: Configuration Management och Continuous Deployment

Vi fortsätter med att kolla in fler sätt att automatisera flöden. Vi lär oss Ansible för Configuration Management (CM) och Infrastructure as Code (IaC). Tillsammans med Ansible och GitHub Actions ska vi också utveckla vår Continuous Delivery till Continuous Deployment (också CD).

Nästa steg i vår miljö är att utöka antalet servrar från en till fyra. Vi ska bygga en klassisk webbapp struktur, en server för databasen, flera för appen och en som load balancer (Nginx, fungerade som proxy tidigare). Med systemet vi har nu, att kopiera bash filer till servern och exekvera manuellt är inte hållbart inom devops. Vi ska utnyttja kraften av Configuration Management verktyget Ansible för att uppnå denna strukturen på att hållbart sätt. Vi flyttar över funktionaliteten från bash skripten till Ansible, som kan utföra samma sak på flera servrar samtidigt. 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!

#Infrastructure as Code och Configuration Management

Infrastructure as Code (IaC) innebär att behandla sin infrastruktur (servrar) som software, 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

• Why use IaC.

• An introduction to Congifuration Management.

• When to use which IaC/CM tool.

#Ansible

Ansible är ett verktyg för att automatisera serverkonfiguration. Läs om följande artiklar om Ansible.

#Läs och titta

• Ansibles grundkoncept.

• Introduktion till att använda Ansible.

• Ansible Best Practices.

#Att göra

• Gör fyra scenario på Killerkoda för att lära er Ansible, Ansible 101. Gör de som heter “Ansible 10X(2.11) English”, det är fyra stycken.

#Bekanta er med Ansible koden

Än så länge har vi manuellt kör kommandon på servern. Nu ska vi uppgradera oss och göra detta i Ansible istället.

Först, installer Azure-CLI och lägg till -r deploy.txt i requirements/dev.txt. Installera Ansible paketen med make install-dev``.

#Läs och titta

• Kolla på videorna med 30xi namnet för att bekanta er med vad som finns i Ansible mappen i Microblog repot, kursen devops.

• Om ni vill hänga med och skriva 10-first-minutes själva så kan ni kolla på videorna med “31x” 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.

#Continuous Deployment (CD)

Vi ska gå steget längre och gå 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 Action till era servrar. Välj en av era SSH nycklar och lägg till i Github Secrets.

cat ~/.ssh/azure

Kopiera utskriften och lägg till som en SECRET i ert repo på GitHub.

För att använda nyckeln i ett workflow behöver ni:

    - name: Setup SSH 
      shell: bash
      run: |
        eval `ssh-agent -s`
        mkdir -p /home/runner/.ssh/
        touch /home/runner/.ssh/id_rsa
        echo -e "${{secrets.SSH_PRIVATE_KEY}}" > /home/runner/.ssh/id_rsa
        chmod 700 /home/runner/.ssh/id_rsa

Då används den SSH nyckeln automatiskt när ni SSH:ar från Actions.

#Ny struktur i molnet

I uppgifterna ska ni öka antalet servrar som används för produktionsmiljön. Om det Microbloggen blir en superhit och ni får jättemånga användare, då är nog er billiga VM för dålig 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.

Den ny strukturen är att vi har en egen VM för databasen och två olika VM’s för microbloggen. 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. Steget vi har kvar är att koppla ett domännamn till båda Microblog VM’s. Det kan vi använda en load balancer till. Vi sätter Nginx som en load balancer istället för en reverse proxy på en VM och låter den dela upp inkommande requests till de båda Microblog VM’s.

På bilden har loadbalancer och databasen speciella ikoner men det är fortfarande vanliga VM’s vi ska använda.

#Läs och titta

• 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. Hur vi gör det finns i en länk bland uppgifterna.

#Lästips

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

#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. Uppdatera provision Playbook så att fyra servrar skapas.

   • En loadbalancer, en database och två appserver, en som heter appserver1 och en appserver2.
   • Appservrarna ska dela security group.
   • Lägg till två subdomäner där de går till varsin appserver. De ska heta appserver1.<domännamn> och appserver2.<domännamn>.

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

3. Sätt upp Microbloggen med Ansible.

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

   • Vid ny release 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.
   • Från GitHub Actions kan ni inte koppla upp er mot Azure och köra gather_instances. Därför la vi till att skapa subdomänerna i första uppgiften.
   • I filen ansible/hosts, lägg till ny hosts som går till appserver1.<domännamn> och appserver2.<domännamn>. Då kan ni använda de hosts i er nya CD Playbook. Ni får lägga till fler hosts om det behövs. PS. Namnge inte dem till samma groups/hosts namn som gather_instances skriptet ger.
   • En avslutande del i er CD playbook ska verifiera att rätt version av Microblog körs på produktionsservrarna.

5. På Microbloggen, lägg till en ny route som visar vilken version av appen som körs på servern.

   • Lägg till ett test som testar att det routen fungerar.

#Resultat & Redovisning

Svara på nedanstående frågor individuellt, lämna in på Canvas tillsammans med länken till ert gemensamma GitHub-repo och domännamn till microblog sidan.

1. Vad är fördelarna med IaC och CM jämfört med att sätta upp allt manuellt?

2. Vad menas med Idempotency inom CM och IaC?

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. Hur var storleken på kursmomentet?

7. Veckans TIL?

#Revision history