Ansible Galaxy är helt enkelt det enklaste sättet att hitta redan skrivna Ansible-roller, skapa och dela dina roller och hoppa in i galaxen av Ansible-innehåll!

====================Meddelande på bästa sändningstiden! =====================

FOSDEM PGDay 2016 kommer att vara den 29 januari innan FOSDEM som är Europas största evenemang med öppen källkod och PostgreSQL Devroom kommer att vara den 31 januari på FOSDEM i Bryssel.

Om du är intresserad av konfigurationshantering, serverorkestrering, automatiserad distribution (det är därför du läser det här blogginlägget, eller hur?) och du gillar att arbeta med PostgreSQL (säkert) på AWS (valfritt), då kanske du vill gå med i mitt föredrag "Hantera PostgreSQL med Ansible" den 29 januari, 12:30-13:20.

Kontrollera det fantastiska schemat för båda evenemangen! Hoppas vi ses i Bryssel den här veckan!

====================Meddelande på bästa sändningstiden! =====================

Hej Ansible Galaxy!

Ansible har en kraftfull gemenskap som gör dem ännu mer kraftfulla. Utvecklare som bidrar till Ansible bidrar gärna och användare som använder Ansible för sina egna system använder det gärna.

Ansible-innehållet de hänvisade till på sin webbsida är i princip Ansible-roller. Låt oss fortsätta med roller i det här blogginlägget och försöka förstå vad Ansible-roll betyder och vad som är skillnader mellan roller, spelböcker och uppgifter.

Vad är en Ansible roll?

Du borde absolut använda roller. Roller är fantastiska. Använd roller. Roller! Sa vi det tillräckligt? Roller är fantastiska.

Innan vi pratar om roller, låt oss komma ihåg definitionen av uppgift och spelbok i Ansible-terminologi.

Uppgift

Uppgifter är ansvariga för att anropa en modul med en specifik uppsättning parametrar.

Du kan läsa mitt tidigare blogginlägg för att lära dig mer om Ansible-moduler och kolla Ansible Postgres-moduler med exempel.

Varje Ansible-uppgift innehåller ett namn, en modul som ska anropas, modulparametrar och eventuellt för-/eftervillkor. De tillåter oss att ringa Ansible-moduler och skicka information till på varandra följande uppgifter.

Uppgiften nedan anropar filmodulen genom att tillhandahålla 4 parametrar.

- name: Ensure the data folder has right ownership
  file: path="/var/lib/postgresql" state=directory owner=postgres group=postgres

Det säkerställer att tre villkor är sanna:

• /var/lib/postgresql finns som en katalog
• ägare av /var/lib/postgresql är "postgres"
• gruppen av /var/lib/postgresql är "postgres"

Om den inte finns skapar Ansible katalogen och tilldelar ägare och grupp. Om bara ägaren är annorlunda, gör Ansible det till "postgres".

Playbook

Playbooks innehåller pjäser och pjäser innehåller uppgifter. Uppgifter anropar moduler och kan (valfritt) triggerhanterare (kör en gång, kör i slutet) .

Nu kan vi kolla in ett mycket enkelt exempel på en lekbok nedan:

- name: Ensure all virtual machines are ready
  hosts: 127.0.0.1
  connection: local
  vars_files: # load default variables from YAML files below
    - 'defaults/postgresql.yml'
    - 'defaults/aws.yml'
  tasks:
    - include: 'tasks/provision.yml' # load infrastructure setup tasks

- name: Ensure all required PostgreSQL dependencies ready
  hosts: postgresql-all # manage all PostgreSQL servers
  sudo: yes
  sudo_user: root
  vars_files:
    - 'defaults/postgresql.yml'
    - 'defaults/aws.yml'
  tasks:
    - include: 'tasks/postgresql.yml' # load PostgreSQL setup tasks

I den här lekboken har vi två pjäser:

Första spelet säkerställer att alla virtuella maskiner är redo och fungerar på localhost. Den laddar standardvariabler från YAML-filer med namnet postgresql.yml och aws.yml. Du kan tänka på dessa filer som konfigurationsfiler för PostgreSQL och AWS (i vårt exempel) roller och spelböcker, eftersom du kan se att båda pjäserna använder dessa filer för standardvariabler. Denna pjäs anropar provision.yml-uppgiften som innehåller infrastrukturinstallationsuppgifter.

Second play säkerställer att alla nödvändiga PostgreSQL-beroenden är klara och fungerar på postgres-servrar som är definierade i inventeringsfilen. Denna pjäs anropar postgresql.yml uppgift som innehåller PostgreSQL-installationsuppgifter.

Om du vill se hela spelboken är du välkommen att kolla mitt arkiv och bidra med det för att göra det bättre.

För att förstå spelbokkonceptet bättre kan du titta på exempel på spelböcker som föreslås i Ansible docs.

Låt oss återgå till att prata om roller. I Ansible;

• Playbooks organisera uppgifter
• Roller organisera spelböcker

Föreställ dig att vi har massor av oberoende resurser att hantera (t.ex. webbservrar, PostgreSQL-servrar, loggning, övervakning, AWS). Att lägga allt i en enda spelbok kan resultera i en ohållbar lösning.

För att minska denna komplexitet hjälper roller oss med:

Dela upp uppgifter i mycket mindre spelböcker

Detta gör att vi kan fokusera på resurser, oberoende. Det gör det enklare att underhålla och felsöka. Det blir också mycket lättare att förstå strukturen.

Återanvändning av konfigurationer, filer, mallar, uppgifter

På så sätt kan vi enkelt dela dessa komponenter mellan playbooks, utan att skriva om om och om igen.

Hantera playbook-beroenden

När vi utför en roll kan vi vara säkra på att alla förutsättningar är uppfyllda för den rollen.

Här kan du se ett beroendediagram och motsvarande rollkatalogstruktur:

PostgreSQL-roller i Ansible Galaxy

Medan jag skrev det här blogginlägget fanns det 146 roller som blir resultatet av postgresql och postgres filtersökning.

Jag föreslår personligen att du kontrollerar ett par av dessa roller och använder dem i din arkitektur om de är tillräckligt bra och uppfyller dina behov; om de inte är det, registrera dig på Ansible Galaxy och skapa dina egna roller.

Lycka till med hackandet!

För mer information om Ansible:

• Kolla in deras välskrivna dokument.
• Titta på Ansible-snabbstartsvideon som är en väldigt användbar självstudie.
• Följ deras webinarschema, det finns några coola kommande webbseminarier på listan.