🥇Systematisk tilgang til variabler i Ansible

ansible devops kodestil

Hej! Mit navn er Denis Kaljuzhny jeg arbejder som ingeniør i udviklingsautomatiseringsafdelingen. Hver dag bliver nye applikationer udrullet på hundreder af virksomhedens servere. I denne artikel deler jeg erfaringer med at bruge Ansible til disse formål.

Denne guide tilbyder en måde at organisere variabler i deployment. Guiden er beregnet til dem, der allerede bruger roller i deres playbooks og har læst BestPractices, men støder på lignende problemer:

Når man finder en variabel i koden, er det umuligt at forstå, hvad den henviser til med det samme;
Der er flere roller, og variablerne skal forbindes med én værdi, men det kan ikke lade sig gøre;
Der opstår vanskeligheder med at forklare andre, hvordan logikken for variabler fungerer i dine playbooks.

Vi har mødt disse problemer i projekter i vores virksomhed, hvilket har ført til, at vi har fastlagt regler for, hvordan variabler skal formateres i vores playbooks, som på en eller anden måde har løst disse problemer.

Variabler i roller

En rolle er et separat objekt i deployment-systemet. Ligesom enhver anden objekt i systemet, skal det have et interface, der muliggør interaktion med resten af systemet. Dette interface er rollevariablerne.

Lad os tage for eksempel en rolle, apider installerer en Java-applikation på serveren. Hvilke variabler kan den have?

Rollevariabler kan opdeles i to typer:

1. Egenskaber
    a) uafhængige af miljøet
    b) afhængige af miljøet
2. Relationer
    a) lyttere 
    b) forespørgsler inden for systemet
    c) forespørgsler til miljøet

Egenskabsvariabler — er variabler, der definerer adfærden for rollen.

Forespørgselsvariabler — er variabler, hvis værdi bruges til at angive ressourcer, der er eksterne i forhold til rollen.

Lyttervariabler — er variabler, hvis værdi bruges til at danne forespørgselsvariabler.

På den anden side er 1a, 2a, 2b — variabler, der ikke er afhængige af miljøet (hardware, eksterne ressourcer osv.) og kan udfyldes med standardværdier i rollens standarder. Dog er det umuligt at udfylde variablerne af type 1b og 2c med noget andet end 'example', da de vil variere fra stand til stand afhængigt af miljøet.

Kodestil

Navnet på variablen skal nødvendigvis starte med navnet på rollen. Det vil gøre det lettere at forstå, hvilken rolle variablen kommer fra, og hvad den henviser til.
Når du bruger variabler i roller, skal du altid følge princippet om indkapsling og bruge variabler, der er defineret enten i selve rollen eller i de roller, som den nuværende afhænger af.
Prøv ikke at bruge ordbøger til variabler. Ansible tillader ikke nemt at overskrive enkeltværdier i en ordbog.
Eksempel på en dårlig variabel:
```
myrole_user:
    login: admin
    password: admin
```
Her er login en miljøuafhængig variabel, mens password er afhængig. Men
da de er samlet i en ordbog, bliver du nødt til altid at indtaste det helt
hvilket er meget besværligt. Bedre sådan:
```
myrole_user_login: admin
myrole_user_password: admin
```

Variabler i deploymentsplaybooks

Når du opretter en deploymentsplaybook (herefter playbook), følger vi reglen om, at den skal placeres i et separat repository. Ligesom rollerne: hver i sit eget git-repository. Dette gør det klart, at roller og playbook er forskellige uafhængige objekter i systemet, og ændringer i et objekt bør ikke påvirke det andet. Dette opnås ved at ændre de standardværdier, der anvendes for variabler.

Når du opretter en playbook, hvis vi skal opsummere, er der mulighed for at overskrive standardværdierne for rollevariabler på to steder: i playbook-variablerne og i inventarvariablerne.

mydeploy                        # Deploy-katalog
├── deploy.yml                  # Deploy-playbook
├── group_vars                  # Katalog til playbook-variabler
│   ├── all.yml                 # Fil til systemets forbindelsesvariabler
│   └── myapi.yml               # Fil til variabler for gruppen myapi
└── inventories                 #
    └── prod                    # Katalog til miljøet prod
        ├── prod.ini            # Inventarfil
        └── group_vars          # Katalog til inventarvariabler
            └── myapi           #
                ├── vars.yml    # Miljøuafhængige variabler for gruppen myapi
                └── vault.yml   # Hemmeligheder (altid miljøafhængige) *

* — Variabler og Vaults

Forskellen er, at playbook-variabler altid bruges, når der kaldes playbooks, der ligger på samme niveau som dem. Det betyder, at disse variabler er perfekte til at ændre standardværdier for variabler, der ikke afhænger af miljøet. Omvendt vil inventarvariabler kun blive brugt til et specifikt miljø, hvilket er ideelt til miljøafhængige variabler.

Det er vigtigt at bemærke, at prioriteringen af variabler ikke vil tillade dig at overskrive variabler først i playbook-variablerne og derefter separat i en inventar.

Dette betyder, at man allerede på dette stadium skal afgøre, om variablen er miljøafhængig eller ej, og placere den det rette sted.

For eksempel var en variabel, der ansvarligt for aktivering af SSL i et projekt i lang tid miljøafhængig, da vi ikke kunne aktivere SSL af grunde uden for vores kontrol på en af testmiljøerne. Efter vi havde løst dette problem, blev den miljøuafhængig og blev flyttet til playbook-variablerne.

Egenskabsvariabler for grupper

Lad os udvide vores model fra figur 1 ved at tilføje 2 grupper af servere med en anden Java-applikation, men med forskellige indstillinger.

Lad os forestille os, hvordan playbooken vil se ud i dette tilfælde:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Vi har tre grupper i playbooken, så det anbefales straks at oprette det samme antal gruppefiler i group_vars for inventarvariabler og playbook-variabler. En gruppefil beskriver i dette tilfælde en komponent af din applikation i playbooken. Når du åbner gruppefilen i playbook-variablerne, ser du straks alle forskelle fra standardadfærden for rollerne installeret på gruppen. I inventarvariablerne: forskellene i gruppens adfærd fra miljø til miljø.

Kodedesign

Forsøg at undgå at bruge host_vars variabler, da de ikke beskriver systemet, men kun et specifikt tilfælde, hvilket i længden vil føre til spørgsmål som: "Hvorfor adskiller denne vært sig fra de andre?", et svar som ikke altid er let at finde.

Relationsvariabler

Men hvad med relationsvariablerne?
Deres forskel er, at de skal have samme værdi i forskellige grupper.

I starten var der idé at bruge en monstrøs konstruktion af typen:
hostvars[groups['bbauth'][0]]['auth_bind_port'], men den blev straks droppet
da den har ulemper. For det første, klodsede. For det andet, afhængighed af en bestemt vært i gruppen. For det tredje, det er nødvendigt at indsamle fakta fra alle værter inden deployment, hvis vi ikke vil få en fejl om en udefineret variabel.

I sidste ende blev det besluttet at bruge relationsvariabler.

Relationsvariabler — dette er variabler, der tilhører playbooken, og som er nødvendige for at forbinde systemobjekter.

Forbindelsesvariabler udfyldes i systemets generelle variabler. group_vars/all/vars og dannes ved at flytte alle lytter-variabler fra hver gruppe og tilføje gruppens navn til starten af variablen, hvorfra lytteren blev flyttet.

På den måde sikres der ensartethed og uoverensstemmelse i navngivningen.

Lad os prøve at forbinde variablerne fra eksemplet ovenfor:

Lad os forestille os, at vi har variabler, der afhænger af hinanden:

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

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

Vi flytter til de generelle variabler group_vars/all/vars alle lyttere og tilføjer gruppens navn til navnet:

# 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 ændrer værdien af forbindelsen, er vi sikre på, at forespørgslen vil henvise til det samme sted, hvor porten er placeret.

Kodedesign

Da roller og grupper er forskellige objekter i systemet, er det nødvendigt, at de har forskellige navne, så forbindelsesvariablerne præcist viser, at de tilhører en bestemt servergruppe og ikke en rolle i systemet.

Miljøafhængige filer

I roller kan der bruges filer, der adskiller sig fra miljø til miljø.

Et eksempel på sådanne filer kan være SSL-certifikater. At opbevare dem i tekstform
i en variabel er ikke særlig praktisk. Det er derimod praktisk at opbevare stien til dem inden i en variabel.

For eksempel, brug variabelen api_ssl_key_file: "/path/to/file".

Da det åbenlyst er, at certifikatnøglen vil ændre sig fra miljø til miljø, er det en miljøafhængig variabel, og den skal derfor placeres i filen
group_vars/myapi/vars inventarvariablerne, og indeholde værdien 'til eksempel'.

Det er lettest i dette tilfælde at placere nøglefilen i playbookens repository på stien
files/prod/certs/myapi.key, så værdien af variablen bliver:
api_ssl_key_file: "prod/certs/myapi.key". Fordelen er, at de personer, der har ansvaret for at implementere systemet på et konkret setup, også har deres eget dedikerede sted i repository til at opbevare deres filer. Samtidig er der mulighed for at angive den absolute sti til certifikatet på serveren, i tilfælde af at certifikaterne leveres af et andet system.

Flere setups i ét miljø

Der er ofte behov for at implementere flere næsten identiske opsætninger i et enkelt miljø med minimale forskelle. I sådanne tilfælde opdeler vi miljøafhængige variable i dem, der forbliver uændrede inden for dette miljø, og dem, der ændres. De sidstnævnte bringes direkte ind i selve inventarfilerne. Efter denne manipulation bliver det muligt at oprette endnu en inventar direkte i miljøkataloget.

Det vil genbruge inventar group_vars og også have mulighed for at overskrive nogle variabler direkte til sig selv.

Den endelige katalogstruktur for deploy-projektet:

mydeploy                        # Deploy katalog
├── deploy.yml                  # Deploy playbook
├── files                       # Katalog til deploy filer
│   ├── prod                    # Katalog for miljøafhængige filer til prod opsætningen
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Katalog for miljøafhængige filer til test1 opsætningen
├── group_vars                  # Katalog for playbook variable
│   ├── all.yml                 # Fil for systemforbindelsesvariable
│   ├── myapi.yml               # Fil for variable til myapi-gruppen
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Katalog for prod miljø
    │   ├── group_vars          # Katalog for inventar variable
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Miljøafhængige variable for myapi-gruppen
    │   │   │   └── vault.yml   # Hemmeligheder (altid miljøafhængige)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Inventar for prod opsætningen
    └── test                    # Katalog for test miljø
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Inventar for test1 opsætningen i test miljø
        └── test2.ini           # Inventar for test2 opsætningen i test miljø

Opsummering

Efter at have organiseret variablerne i henhold til artiklen: hver fil med variabler svarer til en bestemt opgave. Og da filen har bestemte opgaver, blev det muligt at udpege en ansvarlig for korrektheden af hver fil. For eksempel bliver udvikleren af systemets implementering ansvarlig for korrektheden af variablerne i playbooken, mens administratoren, hvis miljø er beskrevet i inventar, er ansvarlig for udfyldningen af inventarvariablerne.

Roller er blevet en selvstændig enhed i udviklingen med eget interface, hvilket har givet rolloveren mulighed for at udvikle funktioner i stedet for at tilpasse rollen til systemet. Især var dette problem relevant for de fælles roller for alle systemer i kampagnen.

Systemadministratorer behøver ikke længere at forstå implementeringskoden. Alt hvad de skal gøre for en succesfuld implementering, er at udfylde filerne med miljøafhængige variabler.

Litteratur

Dokumentation

Forfatter

Denis Alexandrovich Kalyuzhny

Kilde: habr.com