Süsteemne lähenemine Ansible'i muutujatele

ansible devops koodistiil

Tere! Minu nimi on Denis Kaljužny ma töötan insenerina arenduse automatiseerimise osakonnas. Iga päev installitakse uusi rakenduste kogumeid sadu ettevõtte servereid. Ja selles artiklis jagan ma oma kogemusi Ansible'i kasutamisel nende eesmärkide nimel.

See juhend pakub meetodit muutujate korraldamiseks juurutamises. Juhend on mõeldud neile, kes juba kasutavad rolle oma mängudes ja on lugenud BestPractices, kuid seisavad silmitsi järgmiste probleemidega:

• Muuta muutuja leidmine koodis ei anna kohe arusaama, mille eest see vastutab;
• On mitu rolli ja muutujaid tuleb siduda ühe väärtusega, kuid see ei õnnestu;
• Tekivad raskused selgitamisel teistele, kuidas teie mängudes muutujate loogika toimib.

Nende probleemidega oleme kokku puutunud meie ettevõtte projektides, mille tulemusena oleme välja töötanud reeglid muutujate vormistamiseks meie mängudes, mis mingil määral on need probleemid lahendanud.

Muudatused mängudes

Roll on eraldi juurutussüsteemi objekt. Nagu iga süsteemi objekt, peab tal olema suhtlemise liides ülejäänud süsteemiga. Selliseks liideseks on rolli muutujad.

Võtame näiteks rolli api, mis installib Java rakenduse serverisse. Millised muutujad võivad sellel olla?

Rooli muutujaid saab jagada kaheks tüübiks:

1. Atribuudid
    a) sõltumatud keskkonnast
    b) sõltuvad keskkonnast
2. Seosed
    a) kuulajad
    b) päringud süsteemis
    c) päringud keskkonda

Muutujate atribuudid — need on muutujad, mis määratlevad rolli käitumise.

Muutujad — need on muutujad, mille väärtust kasutatakse väliste, rolliga seotud ressursside määratlemiseks.

Kuulajate muutujad — need on muutujad, mille väärtust kasutatakse päringute muutujate moodustamiseks.

Teisest küljest, 1a, 2a, 2b — need on muutujad, mis ei sõltu keskkonnast (riistvara, välised ressursid jne) ja neid saab täita vaikimisi väärtustega rolli defaults. Siiski, muutujaid tüüpi 1b ja 2c ei saa täita muude väärtustega kui 'example', kuna need muutuvad sõltuvalt keskkonnast.

Koodistiil

• Muutuja nimi peab algama rolli nimetusega. See aitab hiljem hõlpsasti mõista, millisest rollist muutuja pärineb ja mille eest see vastutab.
• Rolleides kasutamisel peate kindlasti järgima kapseldamise põhimõtet ja kasutama muutujaid, mis on määratletud kas rollis endas või rollides, millest praegune sõltub.

• Püüdke mitte kasutada sõnastikke muutujaid. Ansible ei võimalda mugavalt eraldi väärtuste ülekirjutamist sõnastikus.

  Halva muutuja näide:

  myrole_user:
      login: admin
      password: admin

  Siin on login keskkonna sõltumatu muutuja, kuid password on sõltuv. Kuid
  kuna nad on ühendatud sõnastikku, peate selle alati täielikult määrama,
  mis on väga ebamugav. Paremini nii:

  myrole_user_login: admin
  myrole_user_password: admin

Muudatused paigaldusplaanides

Paigaldusplaani koostamisel (edaspidi paigaldusplaan) järgime reeglit, et see peaks olema paigutatud eraldi hoidlasse. Nii nagu rollid: igaüks oma git-hoidlas. See võimaldab mõista, et rollid ja paigaldusplaan on erinevad sõltumatud objektid paigaldussüsteemis ning ühe objekti muutused ei tohiks mõjutada teise toimimist. Seda saavutatakse muutujaede vaikimisi väärtuste muutmisega.

Paigaldusplaani koostamisel, kui üldiselt kokku võtta, on võimalik ületada rolli muutujaede vaikimisi väärtusi kahes kohas: paigaldusplaani muutujaedes ja inventeerimise muutujaedes.

mydeploy                        # Paigalduskaust
├── deploy.yml                  # Paigaldusplaan
├── group_vars                  # Paigaldusplaani muutujaede kaust
│   ├── all.yml                 # Fail kogu süsteemi muutujaede jaoks
│   └── myapi.yml               # Grupi myapi omaduste muutujaede fail
└── inventories                 #
    └── prod                    # Prod keskkonna kaust
        ├── prod.ini            # Inventeerimise fail
        └── group_vars          # Inventeerimise muutujaede kaust
            └── myapi           #
                ├── vars.yml    # Grupiga myapi keskkonna sõltumatud muutujaed
                └── vault.yml   # Saladused (alati keskkonna sõltuvad) *

* — Muutujaed ja Seifid

Erinevus seisneb selles, et paigaldusplaani muutujaed kasutatakse alati, kui kutsutakse esile paigaldusplaanid, mis asuvad sellel tasemel. Seetõttu sobivad need muutujaed suurepäraselt keskkonnast sõltumatute muutujaede vaikimisi väärtuste muutmiseks. Vastupidi, inventeerimise muutujaed kasutatakse ainult konkreetse keskkonna jaoks, mis on ideaalne keskkonnast sõltuvate muutujaede jaoks.

Oluline on märkida, et muutuja prioriteet ei luba teil algul ületada muutujaid mänguplaadis ning seejärel eraldi ühes inventuuris.

See tähendab, et juba sel etapil tuleb otsustada, kas muutuja sõltub keskkonnast või mitte, ning paigutada see õigesse kohta.

Näiteks ühes projektis oli muutuja, mis vastutas SSL-i sisselülitamise eest, pikka aega keskkonnast sõltuv, kuna me ei saanud SSL-i sisselülitada meie kontrolli alt väljas olevatel põhjustel ühes testkeskkonnas. Pärast probleemi lahendamist muutus see keskkonnast sõltumatuks ja viidi mänguplaadi muutujate hulka.

Rühma omaduste muutujad

Laiendame meie mudelit joonisel 1, lisades 2 serverigruppi teise Java rakendusega, kuid erinevate seadistustega.

Kujutame ette, kuidas mänguplaan sel juhul välja näeb:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Meil on mänguplaanis kolm gruppi, seega on soovitatav kohe luua sama palju grupifaile group_vars muutujate inventuuris ja mänguplaanis. Üks grupifail on sel juhul ühe teie rakenduse komponendi kirjelduseks mänguplaanis. Avades grupifaili muutujates, näete kohe kõiki erinevusi gruppi kehtestatud rollide vaikimisi käitumisest. Muutujate inventuuris: grupi käitumise erinevused seadmest seadmest.

Koodistiil

• Püüdke üldse mitte kasutada host_vars muutujaid, kuna need ei kirjelda süsteemi, vaid ainult erandjuhte, mis tulevikus toob kaasa küsimusi: "Miks see host erineb teistest?", millele vastuse leidmine ei ole alati kerge.

Sidusmuutujad

Kuid see puudutab omaduste muutujaid, kuid kuidas on sidusmuutujatega?
Nende eripära on see, et need peavad olema erinevates gruppides sama väärtusega.

Alguses oli idee kasutada monstrossset struktuuri nagu:
hostvars[groups['bbauth'][0]]['auth_bind_port'], kuid sellest loobuti kohe
sest sellel on puudused. Esiteks, mahukus. Teiseks, sõltuvus teatud hostist grupis. Kolmandaks, enne juurutamise alustamist tuleb koguda faktid kõigilt hostidelt, kui me ei taha saada määramata muutuja viga.

Lõppkokkuvõttes otsustati kasutada sidusmuutujaid.

Sidusmuutujad — need to be variables that belong to the playbook and are required to link system objects.

Linking variables are filled in the system's common variables. group_vars/all/vars and are formed by extracting all listener variables from each group and adding the name of the group from which the listener was extracted to the beginning of the variable.

This ensures uniformity and non-overlapping names.

Let's try to link the variables from the example above:

Imagine we have variables that depend on each other:

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

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

We will extract all listeners into common variables group_vars/all/vars and add the group's name to the title:

# 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 }}"

Now, by changing the value of the connector, we will be confident that the request will point to where the port is located.

Koodistiil

• Since roles and groups are different objects in the system, they need to have different names, then the linking variables will clearly show that they belong to a specific server group, not a role in the system.

Environment-dependent files

Files that may differ from environment to environment can be used in roles.

An example of such files can be SSL certificates. Storing them in text form
in a variable is not very convenient. However, it is convenient to store the path to them within the variable.

For example, we use the variable api_ssl_key_file: "/path/to/file".

Since it is obvious that the key certificate will change from environment to environment, this is an environment-dependent variable, and it should therefore be located in the file
group_vars/myapi/vars inventory of variables and contain the value 'for example'.

It is most convenient in this case to place the key file in the playbook repository at the path
files/prod/certs/myapi.key, then the value of the variable will be:
api_ssl_key_file: "prod/certs/myapi.key". The convenience here is that the people responsible for deploying the system on a specific stand also have their designated space in the repository for storing their files. At the same time, there remains the possibility to indicate the absolute path to the certificate on the server, in case the certificates are provided by another system.

Multiple stands in one environment

Tihtipeale on vaja juurutada mitmeid praktiliselt identsed keskkondi minimaalsed erinevused. Sellisel juhul jaotame keskkonnapõhised muutujad nende vahel, mis ei muutu selle keskkonna piires ja nende vahel, mis muutuvad. Viime viimased otse inventarifailidesse. Pärast seda manipuleerimist on võimalik luua veel üks inventar otse keskkonna kataloogis.

See kasutab uuesti inventarigrupi muutujaid ning tal on võimalus ületada mõned muutujad otse enda alla.

Lõplik kataloogistruktuur juurutusprojekti jaoks:

mydeploy                        # Juurutuskaust
├── deploy.yml                  # Juurutuse mängu fail
├── files                       # Juurutuse failide kaust
│   ├── prod                    # Keskkonnapõhiste failide kaust prod seismise jaoks
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Keskkonnapõhiste failide kaust test1 seismise jaoks
├── group_vars                  # Mängu muutuja kaust
│   ├── all.yml                 # Fail kogu süsteemi seotuse muutujate jaoks
│   ├── myapi.yml               # Fail myapi grupi omaduste muutujate jaoks
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Prod keskkonna kaust
    │   ├── group_vars          # Inventarimuutujate kaust
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Keskkonnapõhised myapi grupi muutujad
    │   │   │   └── vault.yml   # Salajased (alati keskkonnapõhised)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Prod seismise inventar
    └── test                    # Test keskkonna kaust
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Testi olukorra test1 inventar
        └── test2.ini           # Testi olukorra test2 inventar

Kokkuvõte

Pärast muutujate korraldamist artikli järgi: iga muutujafail vastutab teatud ülesande eest. Kuna failil on kindlad ülesanded, on võimalik määrata vastutav isik iga faili õigsuse eest. Näiteks playbook'i muutujate õiguse eest vastutab süsteemi deploy arendaja, samas kui inventari muutujate täitmise eest vastutab otseselt administraator, kelle stall on inventaris kirjas.

Rollidest said iseseisvad arenduse üksused oma liidesele, mis võimaldas rolli arendajal arendada võimalusi, mitte kohandada rolli süsteemi järgi. See probleem puudutas eriti üldisi rolle kogu kampaania süsteemide jaoks.

Süsteemi administraatorid ei pea enam aru saama deploy koodist. Kõik, mida neilt nõutakse eduka deploy jaoks, on täita keskkondade sõltuvate muutujate failid.

Kirjandus

1. Dokumentatsioon

Autor

Kaljužny Denis Aleksandrovitš

Allikas: habr.com