Süsteemne lähenemine muutujatele Ansible'is

ansible devops koodistiil

Tere! Minu nimi on Denis Kaljužnyj ma töötan arendusprotsesside automatiseerimise insenerina. Iga päev saadetavad uued rakenduste versioonid sadu servereid. Selles artiklis jagan oma kogemusi Ansible'i kasutamisel nende eesmärkide saavutamiseks.

See juhend pakub meetodit muutuja korraldamiseks juurutamises. Juhend on suunatud neile, kes juba kasutavad rolle oma mängukeeltes ja on lugenud BestPractices, kuid kohtavad selliseid probleeme:

• Muutuja leidmine koodist ei võimalda kohe aru saada, mille eest see vastutab;
• On mitu rolli ja muutujad peavad olema seotud ühe väärtusega, kuid see ei õnnestu;
• Tekivad raskused teistele seletamisel, kuidas on muutuja loogika teie mängukeeltes korraldatud.

Selle probleemiga oleme kokku puutunud meie ettevõtte projektides, mille tõttu oleme välja töötanud reeglid muutuja vormistamiseks meie mängukeeltes, mis mingil määral lahendasid need probleemid.

Muutujad rollides

Roll on eraldi objekti juurutamise süsteemis. Nagu iga süsteemi objekt, peab ka sellel olema liidese funktsioon ülejäänud süsteemiga suhtlemiseks. Selleks liideseks on rolli muutujad.

Võtame näiteks rolli api, mis installib Java rakenduse serverisse. Millised on selle muutujad?

Rolli muutujad saab jagada kaheks tüübiks:

1. Atribuudid
    a) keskkonnast sõltumatud
    b) keskkonnast sõltuvad
2. Seosed
    a) kuulajad
    b) süsteemi sisesed päringud
    c) keskkonna päringud

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

Päringu muutujad — need on muutujad, mille väärtust kasutatakse väliste ressursside tähistamiseks, mis on rollist eraldi.

Kuulaja muutujad — need on muutujad, mille väärtust kasutatakse päringu muutujate moodustamiseks.

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

Koodistiil

• Muutuja nimi peab kindlasti algama rolli nimega. See võimaldab hiljem kergesti aru saada, millisest rollist muutuja pärineb ja mille eest ta vastutab.
• Muutujate kasutamisel rollides peate rangelt järgima kapseldamise printsiipi ja kasutama muutujaid, mis on määratud kas rollis endas või rollides, millest praegune sõltub.

• Püüdke mitte kasutada sõnastikke muutujaid jaoks. Ansible ei võimalda mugavalt üle määrata üksikute väärtuste sõnastikus.

  Halva muutuja näide:

  myrole_user:
      login: admin
      password: admin

  Siin on login keskkondade vahel sõltumatu muutuja, samas kui password on sõltuv. Kuid
  kuna need on ühendatud sõnaraamatusse, peate seda alati täielikult seadma
  mis on väga ebamugav. Paremini nii:

  myrole_user_login: admin
  myrole_user_password: admin

Muutujad juurutuspleibookides

Juurutuspleibooki koostamisel (edaspidi pleibook) järgime reeglit, et see peab asuma eraldi hoidlas. Nagu ka rollid: igaüht oma git hoidlasse. See aitab mõista, et rollid ja pleibook on erinevad sõltumatud juurutussüsteemi objektid ning muudatused ühes objektis ei tohiks mõjutada teise tööd. Seda saavutatakse muutuja vaikesätete muutmisega.

Playbook'i koostamisel on võimalik ümbersuunata rolli muutujate vaikeseaded kahes kohas: playbook'i muutujates ja inventuuri muutujates.

mydeploy                        # Rakenduse kataloog
├── deploy.yml                  # Rakenduse playbook
├── group_vars                  # Playbook'i muutujate kataloog
│   ├── all.yml                 # Fail kogu süsteemi muutujate jaoks
│   └── myapi.yml               # Grupi myapi muutujate fail
└── inventories                 #
    └── prod                    # Prod keskkonna kataloog
        ├── prod.ini            # Inventuuri fail
        └── group_vars          # Inventuuri muutujate kataloog
            └── myapi           #
                ├── vars.yml    # Grupi myapi keskkondade muutujad
                └── vault.yml   # Salajased andmed (alati keskkondade põhised) *

* — Muutujad ja seifid

Erinevus seisneb selles, et mänguplaadi muutujad kasutatakse alati koos samal tasemel olevate mänguplaatidega. See tähendab, et need muutujad sobivad suurepäraselt vaikeväärtuste muutmiseks, mis ei sõltu keskkonnast. Vastupidi, inventari muutujad kasutatakse ainult konkreetse keskkonna jaoks, mis on ideaalne keskkonnast sõltuvate muutujate jaoks.

Oluline on märkida, et muutujate prioriteet ei luba teil eelnevalt uue väärtuse määrata mänguplaadi muutujates ning seejärel eraldi inventaris.

See tähendab, et juba selles etapis tuleb otsustada, kas muutuja on keskkonnast sõltuv või mitte, ning paigutada see õigesse kohta.

Näiteks ühes projektis oli muutujal, mis vastutas SSL-i aktiveerimise eest, pikka aega keskkonnast sõltuvus, kuna me ei saanud SSL-i aktiveerida meie kontrolli alt väliste tegurite tõttu ühel platvormil. Pärast selle probleemi lahendamist muutus see keskkonnast sõltumatuks ja viidi mänguplaadi muutujate alla.

Rühmade omaduste muutujad

Kavandame oma mudelit joonisel 1, lisades 2 serverigruppi erineva Java rakendusega, kuid erinevate seadistustega.

Kujutage ette, millisena see mänguraamat välja näeb:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Meil on mänguraamatus kolm rühma, seega on soovitatav luua kohe sama palju grupifaile group_vars'i inventari muutujate ja mänguraamatu muutujate jaoks. Üks grupifail on antud juhul ühe koostisosa kirjeldus, mis asub mänguraamatus. Avades grupifaili mänguraamatu muutujates, näete kohe kõiki erinevusi vaikimisi käitumisest, mis on määratud rühmale. Inventari muutujates: rühma käitumise erinevused seadmest seadmesse.

Koodistiil

• Püüdke vältida host_vars muutujaid, kuna need ei kirjelda süsteemi, vaid ainult erijuhtu, mis võib tulevikus tekitada küsimusi: "Miks see host erineb teistest?" Vastus sellele ei pruugi alati kergesti leida.

Seose muutujad

Kuid kuidas on seose muutujatega?
Nende erinevus seisneb selles, et need peavad olema erinevates rühmades sama väärtusega.

Alguses oli idee kasutada monstroosse konstruktsiooni, nagu:
hostvars[groups['bbauth'][0]]['auth_bind_port'], kuid sellest loobuti kohe.
kuna sellel on puudusi. Esiteks, mahukus. Teiseks, sõltuvus kindlast hostist grupis. Kolmandaks, enne juurutamise algust tuleb koguda faktid kõigilt hostidelt, kui me ei soovi määramatute muutujate viga.

Kokkuvõttes otsustati kasutada ühendusmuutujaid.

Seose muutujad — need on muutujad, mis kuuluvad mänguraamatusse ja on vajalikud süsteemi objektide ühendamiseks.

Ühendusmuutujad täidetakse süsteemi üldistes muutujates group_vars/all/vars ja need moodustatakse, viies kõigi kuulajate muutujad iga grupist ning lisades muutuja algusesse grupi nime, kust kuulaja on välja viidud.

Nii tagatakse nimede järjepidevus ja ülekattumatuse.

Proovime seostada muutujaid eespool toodud näitest:

Kujutame ette, et meil on muutujad, mis üksteisest sõltuvad:

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

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

Viime kõik kuulajad üldistesse muutujatesse group_vars/all/vars ja lisame pealkirjaks grupi nime:

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

Nüüd, muutes konnektori väärtust, oleme kindlad, et päring suunatakse sinna, kus port asub.

Koodistiil

• Kuna rollid ja grupid on süsteemi erinevad objektid, peavad neil olema erinevad nimetused, et siduvad muutujad näitaksid selgelt, et need kuuluvad konkreetsele serverigrupile, mitte süsteemi rollile.

Keskkonnast sõltuvad failid

Rollides võivad kasutada faile, mis erinevad keskkonnast keskkonda.

Selliste failide näiteks on SSL-sertifikaadid. Nende salvestamine tekstivormingus
muutuja sees ei ole väga mugav. Küll aga on mugav hoida nende teed muutuja sees.

Näiteks kasutame muutujat api_ssl_key_file: "/path/to/file".

Kuna on ilmne, et võtme sertifikaat muutub keskkonnast keskkonda, siis on see keskkonnast sõltuv muutuja ja seega peab see asuma failis
group_vars/myapi/vars muutujate inventuuris ning sisaldama väärtust 'näiteks'.

Selles olukorras on kõige mugavam paigutada võtmefail mänguplaani reposse teele
files/prod/certs/myapi.key, siis on muutujate väärtus:
api_ssl_key_file: "prod/certs/myapi.key". Mugavus seisneb selles, et inimesed, kes vastutavad süsteemi käitamise eest konkreetse stendi peal, omavad samas oma eraldi kohta reposis, kus hoida oma faile. Samal ajal jääb võimalus näidata absoluutset teed sertifikaadini serveris, juhul kui sertifikaate tarnib teine süsteem.

Mitu stendi ühes keskkonnas

Sageli on vaja käitada mitu praktiliselt identset stendi ühes keskkonnas minimaalsete erinevustega. Sel juhul jagame keskkonna sõltuvad muutujad nende vahel, mis ei muutu selles keskkonnas, ja nende vahel, mis muutuvad. Viime viimased otse inventari failidesse. Pärast seda manipuleerimist on võimalik luua veel üks inventar otse keskkonna kataloogis.

See taaskasutab inventari group_vars ja võimaldab ka mõningate muutujate otse enda vajadustele vastavaks üle defineerida.

Käitusprojekti lõplik kataloogistruktuur:

mydeploy                        # Deploy kataloog
├── deploy.yml                  # Deploy playbook
├── files                       # Failide kataloog deploy'tamiseks
│   ├── prod                    # Prod keskkonna sõltuvate failide kataloog
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Test1 keskkonna sõltuvate failide kataloog
├── group_vars                  # Playbook'i muutujate kataloog
│   ├── all.yml                 # Fail süsteemi kõigi muutujate jaoks
│   ├── myapi.yml               # Myapi grupi omaduste muutujate fail
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Prod keskkonna kataloog
    │   ├── group_vars          # Inventari muutujate kataloog
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Myapi gruppi sõltuvad muutujad
    │   │   │   └── vault.yml   # Saladused (alati sõltuvad)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Prod keskkonna inventuur
    └── test                    # Test keskkonna kataloog
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Test1 keskkonna inventuur
        └── test2.ini           # Test2 keskkonna inventuur

Kokkuvõte

Pärast muutujate korraldamist vastavalt artiklile: iga muutuja fail vastutab kindla ülesande eest. Kuna failil on kindlad ülesanded, on võimalik määrata vastutav isik iga faili õigsuse eest. Näiteks vastutab rollitegevuse täitmise eest süsteemi juurutamise arendaja, samas kui inventari muutujate täitmise eest vastutab otse administraator, kelle seade on inventaris kirjeldatud.

Rolledest on saanud iseseisev arendusüksus oma kasutajaliidese ja funktsioonide arendamise võimalustega, mitte pole enam vaja rolli kohandada süsteemi. See probleem puudutas eriti kõiki süsteemide ühiseid rolle ettevõttes.

Süsteemi administraatorid ei pea enam arutama juurutamise koodi. Kõik, mida nad vajavad eduka juurutamise jaoks, on keskkonnale sõltuvate muutujate failide täitmine.

Kirjandus

1. Dokumentatsioon

Timur Gilmullin

Denis Aleksandrovich Kalyuzhny

Allikas: habr.com