Kmom03: 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 CircleCI 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 tre. Vi ska bygga en klassisk webbapp struktur, en server för databasen, en 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 innebär att behandla sin infrastruktur (servrar) som software, det ska vara definierat i kod och versionshanterat, för ett längre mer djupgående utlägg läs följande:

• Why use IaC.

För att få en översikt av vad CM är har Digital Ocean gjort en bra sammanfattning:

• An introduction to Congifuration Management.

När ni fått lite bättre koll på IaC och CM kan ni läsa om olika verktyg som finns och var de passar in inom IaC och CM.

#Ansible

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

• Ansibles grundkoncept.

• Introduktion till att använda Ansible.

• Ansible Best Practices.

• Träna på Ansible på killercoda.

#Förbered för Ansible

Innan ni fortsätter ska ni ta bort era gamla VMs och resurser. På Azure portalen, gå till All resources och radera allt utom er “DNS zone” och “SSH key”!

#Bekanta er med Ansible skripten

Än så länge har vi kopierat skript från scripts mappen över till servern och exekverat för att konfigurera servern. Nu ska vi uppgradera oss och göra detta i Ansible istället.

I följande playlist, kollar på videorna med 30xi namnet för att bekanta er med vad som finns i Ansible mappen i Microblog repot.

• kursen devops.

#10 first minutes on a server i Ansible

Nästa steg är att skapa er egna playbook för 10 first minutes on a server, kolla på videorna med 31x i namnet och skapa en playbook för 10-first-minutes skripten.
Notera några rättelser i videon:

• I videon används gather_aws_instances.yml, ni ska istället använda gather_vm_instances.yml.

• Ni ska även ändra remote_user från admin till azureuser.

• Kolla nu på videorna 31x i kursen devops

#Playbooks för app strukturen

Nu har vi en grund att utgå från, vi har tre servrar som är konfigurerade och installerade som en grund server. Nästa steg är att konfigurerar varje server för sig.

Ni ska nu skapa en playbook för att sätta upp databasen på en server, applikationen på en och en load balancer på den sista. När vi bara hade en server använde vi Nginx som en reverse proxy för att skicka vidare requests till Flask appen. Nu ska vi använda Nginx som en load balancer istället. Med Nginx som en load balancer istället för en reverse proxy kan vi lätta utöka antalet applikations servrar när vår hemsida blir populär och besöks antalet ökar.

I Ansible, i era playbooks använd host namnet database för installationen av databasen, appServer för er servern med Microblog och loadBalancer för Nginx.

Tips Skapa en playbook som bara installerar Docker. Den kan ni återanvända för appServer och database.

#Database playbook

Skapa en playbook som startar en Docker container med MySQL på servern. Ni kan inte använda hashade lösenord, MySql klara inte av det. De måste vara i plain-text.

När ni startar containern skicka också med - MYSQL_ROOT_PASSWORD=<password> som environment variabel, ni kommer använda det i kmom04.

#Applikations playbook

Skapa en playbook som startar en Docker container med er senaste Microblog imagen på servern. När ni ska koppla Flask appen till databasen behöver ni IP addressen för databas servern, ni kan inte längre använda er av Dockers länkning för att de körs på två olika maskiner. I ansible kan ni använda {{ groups.database[0] }} för att få ut IP för databas hosten. Tips om ni inte lyckas koppla upp er mot database kan ni logga in på er VM och köra docker logs <microblog container namn> för att se loggen för docker containern.

Ni behöver inte längre installera Supervisor på appServern, nu ska Docker se till att det alltid finns en applikation körandes.

#Load balancer playbook

Skapa en playbook som installerar Nginx och konfigurerar det som en load balancer. Nginx ska skicka vidare requests till applikations servern. Vi har bara en applikations server än så länge så en load balancer tillför inte direkt något, men det är bra att känna till hur man gör en load balancer.

Läs Nginxs dokumentation om att skapa en load balancer. Vad de inte skriver är 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.

• Nginx load balancer.

• Ni kan hitta två config filer för Nginx som load balancer på Gist.

Använd template modulen i Ansible för att flytta conf filerna. Notera variablerna i load-balancer.conf.j2 som ni behöver ha värden till i Ansible.

• nginx.conf.j2 till /etc/nginx/nginx.conf

• load-balancer.conf.j2 till /etc/nginx/sites-available/load-balancer.conf.

Ni kan använda file modulen för att länka load-balancer.conf till sites-enabled mappen.

Tips Ni hittar logfilerna för Nginx i /var/log/nginx. Om en konfig fil inte fungerar kan ni köra nginx -t för att validera den.

För att få till HTTPS via Ansible kolla nedanför.

HTTPS via Ansible

Det finns flera metoder för att få till HTTPS, vissa svårare än andra. Ni kan välja själva om ni tar genvägen och kolla på hur jag har gjort eller lösa det själva. För mitt sätt, kolla gist länken nedanför.

• Ansible kod för Nginx. Se till att det ligger överst i er main.yml för Nginx installationen annars kan det blir problem med config filerna.

#Ansible på GitHub Actions för CD

Vi kommer bara göra en väldigt simpel CD kedja som bara hanterar att uppdatera microblogen. Hur gör vi med ändringar i Nginx eller databasen? Vi nöjer oss med att bara klara av att uppdatera Microbloggen via CD och sköter databasen och Nginx manuellt men vi kan tänka på hur vi skulle gjort. Egentligen borde vi kanske dela upp vårt repo i tre stycken, en för vår load balancer, en för microblog och en för databasen. Då krävs tre separate utvecklings miljöer med Ansible och Makefiler. Men vi hade kunnat få till en bra uppdelning och minskat mängden filer och kod (speciellt i Ansible). En annan lösning är att börja med mer “ordentliga” commit meddelanden och ge den en specifik struktur. T.ex. lägga till taggar i dem och beroende på vilken tag som finns i meddelandet kör vi olika jobb på CircleCi. Det sista alternativet är nog det som är lättast för oss och det vi hade valt. Medan om vi jobbade på ett större projekt hade vi i slutändan tjänat på att dela upp repot i flera mindre.

• Läs en snabb överblick av olika Deployment strategies.

name: Deploy microblog

on:
  workflow_call:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Create .azure folder
      run: mkdir ~/.azure
    - name: Write credentials
      run: echo "${{ secrets.AZURE_CREDENTIALS }}" | base64 -d > ~/.azure/credentials

    - name: Cache pip
      uses: actions/setup-python@v3
      with:
        python-version: "3.9"
        cache: 'pip'
        cache-dependency-path: |
          requirements/deploy.txt
          ansible/requirements.yml
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements/deploy.txt
        cd ansible && ansible-galaxy install -r requirements.yml

    - 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

    - name: Run playbook
      run: cd ansible/ && ansible-playbook gather_az_instances.yml deploy_app.yml

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

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

#Uppgifter

Följande uppgifter skall utföras och resultatet skall redovisas via me-sidan.

1. Använd Ansible för att skapa och konfigurera tre servrar. En som databas, en till microblogen och en som load-balancer.

1. Försäkra dig om att du har pushat repot med din senaste kod och taggat din inlämning med version v13.0.0, om du pushar kmom03 flera gånger kan du öka siffrorna efter 13:an.

#Lästips

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

#Läsanvisningar

I kursen ska ni läsa boken Effective DevOps. Boken är inte kopplad till kursmomenten, men den behövs när ni ska skriva rapporten i slutet av kursen. Ni kan själva välja upplägg för när ni läser den. Ett rekommenderat upplägg är att läsa en del, "part", i veckan. Då har ni läst igenom hela boken efter kmom06.

Rekommendationen för denna veckan är att läsa "Part III. Affinity".

#Resultat & Redovisning

Läs instruktionen om hur du skall redovisa.

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

1. Vad är IaC?

2. Vad är CM?

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

4. Vad är Continuous Deployment?

5. Kan du se några problem med vår CI/CD kedja (tänk hur den skulle sätt ut om Azure hade funkat för oss)?

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

7. Hur var storleken på kursmomentet? Har du haft tid över så att du hade hunnit med att driftsätta via Github Actions?

#Revision history