Microbloggen i Ansible

Ni ska nu skapa playbooks för att sätta upp alla delar av microbloggen; databasen, applikationen på två servrar och en load balancer. Databasen körs på samma VM som load balancern för att spara kostnader.

#Krav

Efter kraven finns lite hjälp för att lösa er Playbooks.

1. Skapa en Ansible playbook för att starta en MySQL databas i en Docker container på en server. Den ska köra på host “database” (gruppen innehåller load balancer VM:en).
   • Installera docker
   • Starta en MySQL container.
   • OBS! datan ska ligga i en volym så att den inte raderas om containerns startas om. Om VM:en raderas försvinner volymen och datan.
   • Sätt en restart policy (unless-stopped) så att containern startar igen efter stop_instances.yml och start_instances.yml.
2. Skapa en Ansible Playbook för att starta er Microblog container. Den ska köras på host “appserver”, alltså ska den köras på både appserver1 och appserver2.
   • Installera docker
   • Starta en Microblog container som kopplas till MySQL containern som körs på host database.
   • Sätt en restart policy (unless-stopped).
3. Uppdatera Ansible playbook deploy_lb så att Nginx skickar requests till båda appservrarna. Nu skickas det bara till en. Uppdatera upstream app-hosts i load-balancer.conf.j2. Ni får inte hårdkoda servrarna. Skriv kod som gör det dynamiskt och funkar om vi lägger till flera servrar.

#Tips

I Ansible, i era playbooks använd host namnet database för installationen av databasen, appserver för era servrar med Microblog och loadbalancer för Nginx.

När ni stoppar och startar VM’s:arna startar inte Docker containrar som saknar restart policy om. Sätt en restart policy på containrarna i era playbooks.

Ni kan använda ansible-lint för att få tips på hur ni bör skriva er Ansible kod. Ni kan använda -x <list of rules> för att exkludera regler.

Tips Skapa en roll som bara installerar Docker. Den kan ni återanvända för appserver och database. Ansibles modul community.docker.docker_container kräver Python paketet docker på servern, installera apt paketet python3-docker tillsammans med docker.io.

#Database playbook

När ni startar MySQL containern kan ni 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 längre fram. MySQL kräver också att ni sätter databasens namn, användare och lösenord för användaren, se dokumentationen för mysql imagen. Lösenorden hamnar i klartext i er kod, så använd inte samma lösenord som ni använder någon annanstans.

Load balancer VM:en har bara 1 GB minne och delar det med Nginx, Docker och MySQL. MySQL 5.7 använder mycket minne som standard och första starten, när databasen skapas, kan få VM:en att sluta svara (SSH får timeout). Starta containern med flaggorna --performance-schema=off --innodb-buffer-pool-size=64M --max-connections=50 (som command till containern). Rollen 10-first-minutes lägger också till en swapfil av samma skäl. Första starten tar en stund, vänta tills MySQL går att logga in på med appens användare innan ni startar appen.

#Microblog playbook

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. Använd domännamnet ({{ domain_name }}) för databas hosten, det funkar både med den dynamiska inventoryn och med en hosts fil. {{ groups.database[0] }} finns bara efter att gather_instances har körts. 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.

#Load balancer playbook

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

Tänk på att ni kan använda sudo nginx -t som validate steg, på tasks i Ansible, för att validera er Nginx konfiguration.

Certbot och HTTPS är redan gjort i rollen deploy_lb. Läs om certbot_staging nedanför.

#Certifikat och Let’s Encrypt

Load balancern får sitt HTTPS certifikat av Let’s Encrypt via certbot. Let’s Encrypt ger bara 5 riktiga certifikat per vecka för samma domän, och varje ny load balancer VM begär ett nytt. Bygger ni om miljön flera gånger tar certifikaten slut och då går det inte att få fler på en vecka.

Därför finns variabeln certbot_staging i ansible/group_vars/all.yml. Är den true (standard) begär certbot ett test-certifikat, som inte har någon gräns men som webbläsare och curl inte litar på. Är den false begär den ett riktigt. Bygg och testa med true. Sätt den till false en gång när allt funkar, då byts testcertifikatet ut mot ett riktigt. Ett riktigt certifikat ersätts aldrig. Ni behöver läsa koden i deploy_lb för att förstå hur det går till, den ska ni kunna förklara.

#Revision history