Systematiskt angreppssätt för variabler i Ansible

ansible devops kodstandard

Hej! Jag heter Denis Kalyuzhnyy jag arbetar som ingenjör inom automatisering av utvecklingsprocesser. Varje dag distribueras nya applikationsversioner på hundratals servrar i företaget. I den här artikeln delar jag med mig av min erfarenhet av att använda Ansible för dessa ändamål.

Denna guide erbjuder ett sätt att organisera variabler i distributionen. Guiden är riktad till dem som redan använder roller i sina spelböcker och har läst BestPractices, men stöter på liknande problem:

• När man hittar en variabel i koden är det svårt att förstå vad den står för;
• Det finns flera roller och variabler som måste kopplas med ett värde, men det går inte;
• Det uppstår svårigheter i att förklara för andra hur logiken bakom variabler i dina spelböcker fungerar.

Vi har stött på dessa problem i våra företags projekt, vilket ledde oss till att vi etablerade regler för hur vi formaterar variabler i våra spelböcker, vilket på något sätt löste dessa problem.

Variabler i roller

En roll är ett separat objekt i distributionssystemet. Precis som vilket objekt som helst i systemet, måste den ha ett gränssnitt för interaktion med resten av systemet. Detta gränssnitt utgörs av rollvariabler.

Låt oss ta exempelvis en roll api, som installerar en Java-applikation på servern. Vilka variabler kan den ha?

Rollvariabler kan delas in i 2 typer:

1. Egenskaper
    a) oberoende av miljön
    b) beroende av miljön
2. Relationer
    a) lyssnare
    b) interna systemförfrågningar
    c) externa förfrågningar

Egenskapsvariabler är variabler som definierar rollens beteende.

Förfrågningsvariabler är variabler vars värden används för att ange externa resurser i förhållande till rollen.

Lyssnarvariabler är variabler vars värden används för att skapa förfrågningsvariabler.

Å andra sidan är 1a, 2a och 2b variabler som inte är beroende av miljön (hårdvara, externa resurser etc.) och kan fyllas med standardvärden i rollens defaults. Men variabler av typen 1b och 2c kan endast fyllas med värden som ‘exempel’, eftersom de kommer att variera från miljö till miljö.

Kodstandard

• Variabelnamnet ska alltid börja med namnet på rollen. Detta underlättar för att förstå vilken roll variabeln tillhör och vad den står för.
• När du använder variabler i roller måste du följa principen om inkapsling och använda variabler som definieras antingen i själva rollen eller i rollerna som den aktuella beror på.

• Försök att inte använda ordböcker för variabler. Ansible tillåter inte enkel överskrivning av enskilda värden i en ordbok.

  Exempel på en dålig variabel:

  myrole_user:
      login: admin
      password: admin

  Här är login en miljöoberoende variabel, medan password är beroende. Men
  eftersom de är sammanslagna i en ordbok måste du alltid ange den helt
  vilket är mycket besvärligt. Bättre så här:

  myrole_user_login: admin
  myrole_user_password: admin

Variabler i distributionsspelplaner

När vi skriver en distributionsspelplan (hädanefter spelplan) följer vi regeln att den ska placeras i ett separat repository. Precis som roller: varje i sitt eget git-repository. Detta gör att vi inser att roller och spelplan är olika oberoende objekt i distributionssystemet, och ändringar i ett objekt bör inte påverka det andra. Detta uppnås genom att ändra standardvärdena för variabler.

När vi skriver spelplanen finns det, sammanfattningsvis, möjlighet att överskrida standardvärdena för rollvariabler på två ställen: i spelplanens variabler och i inventariens variabler.

mydeploy                        # Distributionskatalog
├── deploy.yml                  # Distributionsspelplan
├── group_vars                  # Katalog för spelplanens variabler
│   ├── all.yml                 # Fil för systemets gemensamma variabler
│   └── myapi.yml               # Fil för gruppens myapi-egenskapsvariabler
└── inventories                 #
    └── prod                    # Katalog för prod-miljön
      ├── prod.ini              # Inventariefil
      └── group_vars            # Katalog för inventariens variabler
          └── myapi             #
              ├── vars.yml      # Miljöoberoende variabler för gruppen myapi
              └── vault.yml     # Hemligheter (alltid miljöberoende) *

* — Variabler och valv

Skillnaden är att spelplansvariabler alltid används vid anrop av spelplaner som ligger på samma nivå. Därför passar dessa variabler utmärkt för att ändra standardvärdena för miljöoberoende variabler. Å andra sidan kommer inventariens variabler endast att användas för specifika miljöer, vilket är perfekt för miljöberoende variabler.

Det är viktigt att notera att prioritetsvariablerna inte tillåter att du åsidosätter variabler först i playbook-variablerna och sedan separat i en inventering.

Detta innebär att du redan på detta stadium måste bestämma om variabeln är miljöberoende eller inte och placera den på rätt ställe.

Till exempel har en variabel i ett projekt, som ansvarade för att aktivera SSL, länge varit miljöberoende eftersom vi inte kunde aktivera SSL av skäl utanför vår kontroll på en av miljöerna. När vi löste det problemet blev den miljöoberoende och flyttades till playbook-variablerna.

Egenskapsvariabler för grupper

Låt oss utvidga vår modell i figur 1 genom att lägga till 2 grupper av servrar med olika Java-applikationer, men med olika inställningar.

Låt oss föreställa oss hur playbooken kommer att se ut i det här fallet:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Vi har tre grupper i playbooken, så det rekommenderas omedelbart att skapa lika många gruppfiler i group_vars i både inventeringsvariablerna och playbooken. En gruppfil i det här fallet fungerar som en beskrivning av en komponent i den övergripande applikationen i playbooken. När du öppnar gruppfilen i playbookens variabler ser du genast alla avvikelser från standardbeteendet för roller som är installerade på gruppen. I inventeringsvariablerna: avvikelser i gruppens beteende från miljö till miljö.

Kodstil

• Försök att överhuvudtaget inte använda host_vars-variabler, eftersom de inte beskriver systemet, utan bara ett specifikt fall, vilket i framtiden kan leda till frågan: "Varför skiljer sig denna värd från de andra?" vilket svar inte alltid är lätt att hitta.

Relationsvariabler

Men det gäller relationsvariabler, hur ska vi hantera dem?
Deras skillnad är att de måste ha samma värde i olika grupper.

I början var idé att använda en monstruös konstruktion av typen:
hostvars[groups['bbauth'][0]]['auth_bind_port'], men den övergavs omedelbart
eftersom den har nackdelar. För det första, otympligheten. För det andra, beroendet av en specifik värd i gruppen. För det tredje, det är nödvändigt att samla in fakta från alla värdar innan distribution om vi inte vill ha felmeddelandet om att variabeln är obestämd.

Slutligen beslutades det att använda relationsvariabler.

Relationsvariabler — det är variabler som tillhör playbooken och behövs för att koppla samman systemobjekt.

Variabler för kopplingar fylls i de gemensamma systemvariablerna group_vars/all/vars och bildas genom att extrahera alla lyssnare från varje grupp och lägga till grupnamnet i början av variabeln som lyssnaren extraherades från.

På så sätt säkerställs enhetlighet och ingen överlappning av namn.

Låt oss koppla variablerna från exemplet ovan:

Tänk dig att vi har variabler som är beroende av varandra:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

Låt oss flytta ut alla lyssnare till gemensamma variabler group_vars/all/vars och lägga till gruppnamnet i titeln:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

Nu, när vi ändrar värdet på anslutningen, kan vi vara säkra på att förfrågan kommer att gå till samma plats där porten är belägen.

Kodstil

• Eftersom roller och grupper är olika objekt i systemet, måste de ha olika namn för att variablerna för kopplingar tydligt ska visa att de tillhör en specifik servergrupp och inte en roll i systemet.

Miljöberoende filer

I roller kan filer användas som skiljer sig åt mellan olika miljöer.

Exempel på sådana filer är SSL-certifikat. Att lagra dem i textformat
i en variabel är inte särskilt praktiskt. Men det är bekvämt att lagra sökvägen till dem inuti en variabel.

Till exempel kan vi använda variabeln api_ssl_key_file: "/path/to/file".

Eftersom det är uppenbart att certifikatsnyckeln kommer att variera mellan miljöer, är det en miljöberoende variabel och måste därför placeras i filen
group_vars/myapi/vars inventories av variabler, och innehålla värdet 'för exempel'.

Det är mest bekvämt att lägga nyckelfilen i playbook-repositoriet på vägen
files/prod/certs/myapi.key, då blir variabelns värde:
api_ssl_key_file: "prod/certs/myapi.key". Bekvämligheten ligger i att de personer som ansvarar för att rulla ut systemet på en specifik installation också har ett eget dedikerat utrymme i repositoriet för att lagra sina filer. Samtidigt finns det möjlighet att ange en absolut sökväg till certifikatet på servern, ifall certifikaten tillhandahålls av ett annat system.

Flera installationer i samma miljö

Det uppstår ofta behov av att distribuera flera nästan identiska miljöer med minimala skillnader. I detta fall delar vi upp miljöberoende variabler i de som inte ändras inom denna miljö och de som ändras. Vi tar ut de senaste direkt till inventariefilerna. Efter denna åtgärd blir det möjligt att skapa en ny inventariefil direkt i miljökatalogen.

Den kommer att återanvända inventariegroupegenskaper, samt ha möjlighet att överskrida vissa variabler direkt för sig själv.

Den slutliga katalogstrukturen för distributionsprojektet:

mydeploy                        # Distributionskatalog
├── deploy.yml                  # Distributionsspelbok
├── files                       # Katalog för distributionsfiler
│   ├── prod                    # Katalog för miljöberoende filer av prod-stand
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Katalog för miljöberoende filer av test1-stand
├── group_vars                  # Katalog för spelvariabler
│   ├── all.yml                 # Fil för systemövergripande variabler
│   ├── myapi.yml               # Fil för gruppmyapi variabler
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Katalog för prod-miljö
    │   ├── group_vars          # Katalog för inventarievillkor
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Miljöberoende variabler för grupp myapi
    │   │   │   └── vault.yml   # Hemligheter (alltid miljöberoende)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Inventariefil för prod-stand
    └── test                    # Katalog för test-miljö
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Inventariefil för test1-stand i test-miljö
        └── test2.ini           # Inventariefil för test2-stand i test-miljö

Sammanfattning

Efter att ha organiserat variablerna enligt artikeln: varje fil med variabler ansvarar för en viss uppgift. Eftersom filen har specifika uppgifter har det blivit möjligt att utse en ansvarig för riktigheten av varje fil. Till exempel, för korrektheten av variablerna i spelboken blir utvecklaren av systemets distribueringsprocess ansvarig, medan administratören för den beskrivna ståndpunkten i inventariet ansvarar för ifyllnaden av inventarieveckans variabler.

Rollerna har blivit en självständig enhet inom utvecklingen med ett eget gränssnitt, vilket möjliggör för rollerutvecklaren att utveckla funktioner istället för att anpassa rollen till systemet. Särskilt var detta problem relevant för gemensamma roller för alla system inom företaget.

Systemadministratörer behöver inte längre förstå sig på distributionskoden. Allt som krävs av dem för en framgångsrik distribution är att fylla i filerna för miljöberoende variabler.

Litteratur

1. Dokumentation

Författare

Kaljuzhny Denis Alexandrovich

Källa: habr.com