ansible devops koodistiil
Hei! Minu nimi on Töötan insenerina arendusprotsesside automatiseerimise osakonnas. Iga päev levitatakse uusi rakenduste järge sadadesse kampaaniaserveritesse. Ja selles artiklis jagan oma kogemusi Ansible'i kasutamisest nendel eesmärkidel.
See juhend pakub viisi muutujate korraldamiseks juurutamisel. See juhend on mõeldud neile, kes juba kasutavad oma mänguraamatutes rolle ja loevad kuid sarnaste probleemidega:
- Olles leidnud koodist muutuja, on võimatu kohe aru saada, mille eest see vastutab;
- Rolle on mitu ja muutujad tuleb seostada ühe väärtusega, kuid see ei tööta;
- Teil on raske teistele selgitada, kuidas teie mänguraamatute muutujate loogika töötab
Nende probleemidega puutusime kokku oma ettevõtte projektides, mille tulemusena jõudsime oma mänguraamatutes muutujate vormindamise reegliteni, mis need probleemid mingil määral lahendasid.
Muutujad rollides
Roll on eraldi juurutussüsteemi objekt. Nagu igal süsteemiobjektil, peab ka sellel olema liides ülejäänud süsteemiga suhtlemiseks. Selliseks liideseks on rollimuutujad.
Võtame näiteks rolli api, mis installib serverisse Java-rakenduse. Millised muutujad sellel on?
Rollimuutujad võib tüübi järgi jagada kahte tüüpi:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Muutuvad omadused on muutujad, mis määravad rolli käitumise.
Päringu muutujad on muutujad, mille väärtust kasutatakse rolliväliste ressursside määramiseks.
Muutuvad kuulajad on muutujad, mille väärtust kasutatakse päringumuutujate moodustamiseks.
Teisest küljest on 1a, 2a, 2b muutujad, mis ei sõltu keskkonnast (raud, välised ressursid jne) ja mida saab täita vaikeväärtustega vaikerollis. Muutujaid, nagu 1.b ja 2.c, ei saa aga täita muude väärtustega kui „example”, kuna need muutuvad olenevalt keskkonnast.
koodi stiil
- Muutuja nimi peab algama rolli nimega. Nii on tulevikus lihtne aru saada, mis rollist muutuja on ja mille eest see vastutab.
- Muutujate kasutamisel rollides tuleb kindlasti järgida kapseldamise põhimõtet ja kasutada muutujaid, mis on defineeritud kas rollis endas või rollides, millest praegune sõltub.
-
Vältige muutujate jaoks sõnastike kasutamist. Ansible ei võimalda teil sõnastikus üksikuid väärtusi mugavalt alistada.
Näide halvast muutujast:
myrole_user: login: admin password: adminSiin on sisselogimine keskmine muutuja ja parool sõltuv muutuja. Aga
kuna need on ühendatud sõnastiks, peate selle täielikult täpsustama
Alati. Mis on väga ebamugav. Parem nii:myrole_user_login: admin myrole_user_password: admin
Muutujad juurutamise käsiraamatutes
Kasutuselevõtu käsiraamatu (edaspidi mänguraamat) koostamisel järgime reeglit, et see tuleks paigutada eraldi hoidlasse. Täpselt nagu rollid: igaüks oma git-hoidlas. See võimaldab teil mõista, et rollid ja mänguraamat on juurutussüsteemi erinevad sõltumatud objektid ning muudatused ühes objektis ei tohiks mõjutada teise tööd. See saavutatakse muutujate vaikeväärtuste muutmisega.
Mänguraamatu koostamisel on kokkuvõtteks võimalik rollimuutujate vaikeväärtusi alistada kahes kohas: mänguraamatu muutujates ja laomuutujates.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Erinevus seisneb selles, et nendega samal tasemel asuvate mänguraamatute kutsumisel kasutatakse alati mänguraamatu muutujaid. See tähendab, et need muutujad sobivad suurepäraselt muutujate vaikeväärtuste muutmiseks, mis ei sõltu keskkonnast. Ja vastupidi, varude muutujaid kasutatakse ainult konkreetse keskkonna jaoks, mis sobib ideaalselt keskkonnaspetsiifiliste muutujate jaoks.
Oluline on märkida, et muutujate prioriteetsus ei võimalda teil muutujaid uuesti määratleda esmalt esitusraamatu muutujates ja seejärel samas loendis eraldi.
See tähendab, et juba selles etapis tuleb otsustada, kas muutuja on keskkonnast sõltuv või mitte, ja asetada see õigesse kohta.
Näiteks ühes projektis oli SSL-i lubamise eest vastutav muutuja pikka aega keskkonnast sõltuv, kuna me ei saanud meist mitteolenevatel põhjustel ühes stendis SSL-i lubada. Pärast probleemi lahendamist muutus see keskmisest sõltumatuks ja viidi üle mänguraamatu muutujatele.
Atribuutide muutujad rühmade jaoks
Laiendame oma mudelit joonisel 1, lisades 2 erineva Java-rakendusega, kuid erinevate seadistustega serverite rühma.
Kujutage ette, kuidas mänguraamat sel juhul välja näeb:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authMeil on käsiraamatus kolm rühma, seega on soovitatav luua korraga nii palju grupifaile, mis on group_vars laomuutujad ja käsiraamatu muutujad. Üks rühmafail on sel juhul teie rakenduse ühe komponendi kirjeldus mänguraamatus. Kui avate grupifaili mänguraamatu muutujates, näete kohe kõiki erinevusi rühmale määratud rollide vaikekäitumisest. Varude muutujates: erinevused grupi käitumises boksiti.
Koodi stiil
- Proovige host_vars muutujaid üldse mitte kasutada, kuna need ei kirjelda süsteemi, vaid ainult erijuhtumit, mis pikemas perspektiivis tekitab küsimusi: "Miks see host erineb teistest?", millele vastus on pole alati lihtne leida.
Lingi muutujad
See puudutab aga atribuutmuutujaid, aga kuidas on lood lingimuutujatega?
Nende erinevus seisneb selles, et neil peab erinevates rühmades olema sama väärtus.
Alguses oli kasutage vormi koletu konstruktsiooni:
hostvars[groups['bbauth'][0]]['auth_bind_port'], kuid see jäeti kohe maha
sest sellel on vigu. Esiteks mahukus. Teiseks sõltuvus konkreetsest peremehest rühmas. Kolmandaks on vaja enne juurutamise alustamist kõikidelt hostidelt fakte koguda, kui me ei soovi saada määratlemata muutuja viga.
Selle tulemusena otsustati kasutada lingi muutujaid.
Lingi muutujad on muutujad, mis kuuluvad mänguraamatusse ja on vajalikud süsteemiobjektide linkimiseks.
Lingi muutujad sisestatakse üldistesse süsteemimuutujatesse group_vars/all/vars ja moodustatakse, eemaldades igast rühmast kõik kuulaja muutujad ja lisades muutuja algusesse selle rühma nime, kust kuulaja eemaldati.
Seega on tagatud nimede ühtsus ja mitteristumine.
Proovime siduda muutujaid ülaltoodud näitest:
Kujutage ette, et meil on muutujad, mis sõltuvad üksteisest:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Paneme selle ühisteks muutujateks group_vars/all/vars kõik kuulajad ja lisage nimele rühma nimi:
# 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 läheb samasse kohta, kus asub port.
Koodi stiil
- Kuna rollid ja rühmad on süsteemis erinevad objektid, peavad teil olema nende jaoks erinevad nimed, siis näitavad lingimuutujad täpselt, et need kuuluvad teatud serverite rühma, mitte süsteemi rolli.
Keskkonna failid
Rollid võivad kasutada faile, mis erinevad keskkonnati.
SSL-sertifikaadid on selliste failide näide. Salvestage need tekstina
muutujas ei ole eriti mugav. Kuid tee nendeni on mugav salvestada muutuja sisse.
Näiteks kasutame muutujat api_ssl_key_file: "/path/to/file".
Kuna on ilmne, et võtme sertifikaat muutub keskkonnast keskkonda, on see keskkonnast sõltuv muutuja, mis tähendab, et see peaks asuma failis
group_vars/myapi/vars muutujate loend ja sisaldavad väärtust „näiteks”.
Sel juhul on kõige mugavam panna võtmefail tee ääres esitusraamatu hoidlasse
files/prod/certs/myapi.key, siis on muutuja väärtus:
api_ssl_key_file: "prod/certs/myapi.key". Mugavus seisneb selles, et inimestel, kes vastutavad süsteemi juurutamise eest konkreetsel stendil, on hoidlas oma failide hoidmiseks eraldi koht. Samal ajal on võimalik määrata sertifikaadi absoluutne tee serveris, juhul kui sertifikaate tarnib mõni muu süsteem.
Mitu stendi ühes keskkonnas
Sageli on vajadus paigutada samasse keskkonda mitu peaaegu identset stendi minimaalsete erinevustega. Sel juhul jagame keskkonnast sõltuvad muutujad nendeks, mis selles keskkonnas ei muutu, ja nendeks, mis muutuvad. Ja viimase võtame välja otse inventarifailidesse. Pärast seda manipuleerimist on võimalik luua uus inventar otse keskkonnakataloogis.
See kasutab uuesti inventuuri group_vars ja suudab ka mõned muutujad otse enda jaoks uuesti määratleda.
Juurutusprojekti lõplik kataloogistruktuur:
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── files # Каталог для файлов деплоя
│ ├── prod # Католог для средозависимых файлов стенда prod
│ │ └── certs #
│ │ └── myapi.key #
│ └── test1 # Каталог для средозависимых файлов стенда test1
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ ├── myapi.yml # Файл переменных свойств группы myapi
│ ├── bbauth.yml #
│ └── ghauth.yml #
└── inventories #
├── prod # Каталог окружения prod
│ ├── group_vars # Каталог для переменных инвентори
│ │ ├── myapi #
│ │ │ ├── vars.yml # Средозависимые переменные группы myapi
│ │ │ └── vault.yml # Секреты (всегда средозависимы)
│ │ ├── bbauth #
│ │ │ ├── vars.yml #
│ │ │ └── vault.yml #
│ │ └── ghauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── prod.ini # Инвентори стенда prod
└── test # Каталог окружения test
├── group_vars #
│ ├── myapi #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ ├── bbauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── ghauth #
│ ├── vars.yml #
│ └── vault.yml #
├── test1.ini # Инвентори стенда test1 в среде test
└── test2.ini # Инвентори стенда test2 в среде testSummeerida
Pärast muutujate korraldamist vastavalt artiklile: iga muutujatega fail vastutab konkreetse ülesande eest. Ja kuna failil on teatud ülesanded, sai võimalikuks määrata iga faili õigsuse eest vastutav isik. Näiteks vastutab mänguraamatu muutujate korrektse täitmise eest süsteemi juurutuse arendaja, muutujate loendi täitmise eest aga otseselt administraator, kelle stend on inventuuris kirjeldatud.
Rollidest sai iseseisev arendusüksus, millel on oma liides, mis võimaldas rolliarendajal funktsioone arendada, mitte kohandada rolli süsteemiga sobivaks. See probleem kehtis eriti kampaania kõigi süsteemide ühiste rollide puhul.
Süsteemiadministraatorid ei pea enam juurutuskoodist aru saama. Kõik, mida neilt edukaks juurutamiseks nõutakse, on keskkonnamuutujate failide täitmine.
Kirjandus
Autor
Kaljužnõi Denis Aleksandrovitš
Allikas: www.habr.com