ansible devops kodo stilius
Ei! Mano vardas yra Dirbu inžinieriumi kūrimo procesų automatizavimo skyriuje. Kasdien šimtuose kampanijos serverių išleidžiamos naujos taikomųjų programų versijos. Ir šiame straipsnyje dalinuosi savo patirtimi naudojant Ansible šiems tikslams.
Šiame vadove pateikiamas būdas sutvarkyti kintamuosius diegimo metu. Šis vadovas skirtas tiems, kurie jau naudoja vaidmenis savo žaidimų knygelėse ir perskaitė , bet susiduria su panašiomis problemomis:
- Kode radus kintamąjį, iš karto neįmanoma suprasti, už ką jis atsakingas;
- Yra keli vaidmenys, o kintamieji turi būti susieti su viena reikšme, bet tai tiesiog neveikia;
- Sunku paaiškinti kitiems, kaip veikia jūsų žaidimų knygelėse esančių kintamųjų logika
Mes susidūrėme su šiomis problemomis vykdydami savo įmonės projektus, todėl priėjome prie kintamųjų projektavimo taisyklių mūsų žaidimuose, kurios iš dalies išsprendė šias problemas.
Kintamieji vaidmenyse
Vaidmuo yra atskiras diegimo sistemos objektas. Kaip ir bet kuris sistemos objektas, jis turi turėti sąsają sąveikai su likusia sistemos dalimi. Tokia sąsaja yra vaidmens kintamieji.
Paimkime, pavyzdžiui, vaidmenį api, kuri serveryje įdiegia Java programą. Kokius kintamuosius jis gali turėti?
Kintamieji vaidmenys gali būti suskirstyti į 2 tipus pagal tipą:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Kintamos savybės yra kintamieji, lemiantys vaidmens elgesį.
Užklausos kintamieji - tai yra kintamieji, kurių reikšmė naudojama išoriniams ištekliams priskirti vaidmeniui.
Kintamieji klausytojai - tai kintamieji, kurių reikšmė naudojama formuojant užklausos kintamuosius.
Kita vertus, 1a, 2a, 2b yra kintamieji, kurie nepriklauso nuo aplinkos (aparatinės įrangos, išorinių išteklių ir kt.) ir gali būti užpildyti numatytosiomis reikšmėmis pagal numatytuosius nustatymus. Tačiau 1.b ir 2.c tipo kintamųjų neįmanoma užpildyti kitomis reikšmėmis nei „pavyzdys“, nes jie keisis nuo stovo iki stovo, priklausomai nuo aplinkos.
Kodo stilius
- Kintamojo pavadinimas turi prasidėti vaidmens pavadinimu. Ateityje taip bus nesunku išsiaiškinti, iš kokio vaidmens priklauso kintamasis ir už ką jis atsakingas.
- Naudodami kintamuosius vaidmenyse, turite laikytis inkapsuliavimo principo ir naudoti kintamuosius, apibrėžtus pačiame vaidmenyje arba vaidmenyse, nuo kurių priklauso dabartinis.
-
Venkite naudoti kintamiesiems skirtus žodynus. Ansible neleidžia patogiai nepaisyti atskirų reikšmių žodyne.
Blogo kintamojo pavyzdys:
myrole_user: login: admin password: adminČia prisijungimas yra nepriklausomas kintamasis, o slaptažodis yra priklausomas kintamasis. Bet
kadangi jie yra sujungti į žodyną, turėsite jį visiškai nurodyti
Visada. Kas yra labai nepatogu. Geriau taip:myrole_user_login: admin myrole_user_password: admin
Kintamieji diegimo knygelėse
Sudarydami diegimo sąsiuvinį (toliau – planų knyga), laikomės taisyklės, kad ji turi būti patalpinta į atskirą saugyklą. Tas pats kaip vaidmenys: kiekvienas savo git saugykloje. Tai leidžia suprasti, kad vaidmenys ir žaidimo knyga yra skirtingi nepriklausomi diegimo sistemos objektai, o vieno objekto pakeitimai neturėtų turėti įtakos kito veikimui. Tai pasiekiama pakeitus numatytąsias kintamųjų reikšmes.
Sudarant žaidimų knygą, apibendrinant, galima perrašyti numatytąsias vaidmenų kintamųjų reikšmes dviejose vietose: žaidimo knygos kintamuosiuose ir inventoriaus kintamuosiuose.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Skirtumas tas, kad žaidimo knygos kintamieji visada naudojami skambinant į tame pačiame lygyje esančias žaidimų knygas. Tai reiškia, kad šie kintamieji puikiai tinka norint pakeisti numatytąsias nuo aplinkos nepriklausomų kintamųjų vertes. Atvirkščiai, atsargų kintamieji bus naudojami tik konkrečiai aplinkai, kuri idealiai tinka aplinkai būdingiems kintamiesiems.
Svarbu pažymėti, kad kintamųjų prioritetas neleis nepaisyti kintamųjų iš pradžių žaidimų knygelės kintamuosiuose, o paskui atskirai vienoje inventoriuje.
Tai reiškia, kad jau šiame etape reikia nuspręsti, ar kintamasis priklauso nuo aplinkos, ar ne, ir įdėti jį į atitinkamą vietą.
Pavyzdžiui, viename projekte kintamasis, atsakingas už SSL įjungimą, ilgą laiką priklausė nuo aplinkos, nes viename stende negalėjome įjungti SSL dėl nuo mūsų nepriklausančių priežasčių. Po to, kai išsprendėme šią problemą, ji tapo nepriklausoma nuo aplinkos ir perėjo prie žaidimo knygos kintamųjų.
Grupių nuosavybės kintamieji
Išplėskime savo modelį 1 paveiksle, pridėdami 2 serverių grupes su skirtinga Java programa, bet su skirtingais nustatymais.
Įsivaizduokime, kaip šiuo atveju atrodys žaidimo knyga:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authŽaidimo knygelėje turime tris grupes, todėl iš karto rekomenduojama sukurti tiek pat grupės failų group_vars inventoriaus kintamuosiuose ir žaidimų knygos kintamuosiuose. Šiuo atveju vienas grupės failas yra vieno anksčiau nurodytos programos komponento aprašymas vadove. Kai atidarote grupės failą žaidimo knygos kintamuosiuose, iškart matote visus skirtumus nuo numatytosios grupėje įdiegtų vaidmenų. Inventoriaus kintamieji: grupės elgesio skirtumai nuo stovo iki stovo.
Kodo stilius
- Stenkitės visai nenaudoti host_vars kintamųjų, nes jie neapibūdina sistemos, o tik specialų atvejį, dėl kurio ateityje kils klausimų: „Kodėl šis kompiuteris skiriasi nuo kitų?“, į kurį atsakymas nėra visada lengva rasti.
Komunikacijos kintamieji
Tačiau tai yra nuosavybės kintamieji, o kaip su komunikacijos kintamaisiais?
Jų skirtumas yra tas, kad skirtingose grupėse jie turėtų turėti tą pačią reikšmę.
Iš pradžių buvo naudokite siaubingą konstrukciją, pavyzdžiui:
hostvars[groups['bbauth'][0]]['auth_bind_port'], bet jie iškart jį atmetė
nes turi trūkumų. Pirma, masyvumas. Antra, priklausomybė nuo konkretaus šeimininko grupėje. Trečia, prieš pradedant diegimą, būtina surinkti faktus iš visų kompiuterių, jei nenorime gauti neapibrėžto kintamojo klaidos.
Dėl to buvo nuspręsta naudoti komunikacijos kintamuosius.
Komunikacijos kintamieji - tai yra kintamieji, priklausantys žaidimo knygai ir reikalingi sistemos objektams sujungti.
Ryšio kintamieji pateikiami bendruosiuose sistemos kintamuosiuose group_vars/all/vars ir yra suformuojami pašalinus visus klausytojo kintamuosius iš kiekvienos grupės ir į kintamojo pradžią pridedant grupės, iš kurios klausytojas buvo pašalintas, pavadinimą.
Taip užtikrinamas pavadinimų vienodumas ir nepersidengimas.
Pabandykime susieti kintamuosius iš aukščiau pateikto pavyzdžio:
Įsivaizduokime, kad turime kintamuosius, kurie priklauso vienas nuo kito:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Sudėkime jį į bendruosius kintamuosius group_vars/all/vars visus klausytojus ir prie pavadinimo pridėkite grupės pavadinimą:
# 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 }}"Dabar, pakeitę jungties vertę, būsime tikri, kad užklausa pateks į tą pačią vietą, kur yra prievadas.
Kodo stilius
- Kadangi vaidmenys ir grupės yra skirtingi sistemos objektai, jie turi turėti skirtingus pavadinimus, tada nuorodos kintamieji tiksliai nurodys, kad jie priklauso konkrečiai serverių grupei, o ne sistemos vaidmeniui.
Nuo aplinkos priklausomi failai
Vaidmenyse gali būti naudojami failai, kurie įvairiose aplinkose skiriasi.
Tokių failų pavyzdys yra SSL sertifikatai. Išsaugokite juos teksto forma
kintamajame nėra labai patogu. Tačiau kelią į juos patogu saugoti kintamajame.
Pavyzdžiui, mes naudojame kintamąjį api_ssl_key_file: "/path/to/file".
Kadangi akivaizdu, kad rakto sertifikatas keisis iš aplinkos į aplinką, tai yra nuo aplinkos priklausomas kintamasis, o tai reiškia, kad jis turi būti faile
group_vars/myapi/vars kintamųjų sąrašą ir turi reikšmę „pavyzdžiui“.
Patogiausias būdas šiuo atveju yra įdėti rakto failą į žaidimų knygelės saugyklą palei kelią
files/prod/certs/myapi.key, tada kintamojo reikšmė bus tokia:
api_ssl_key_file: "prod/certs/myapi.key". Patogumas slypi tame, kad asmenys, atsakingi už sistemos diegimą konkrečiame stende, taip pat turi savo vietą saugykloje savo failams saugoti. Tuo pačiu metu išlieka galimybė nurodyti absoliutų kelią iki sertifikato serveryje, jei sertifikatus teikia kita sistema.
Keli stendai vienoje aplinkoje
Dažnai toje pačioje aplinkoje reikia įrengti kelis beveik vienodus stendus su minimaliais skirtumais. Šiuo atveju nuo aplinkos priklausomus kintamuosius skirstome į tuos, kurie nesikeičia šioje aplinkoje, ir tuos, kurie kinta. O pastarąsias perkeliame tiesiai į pačias inventorizacijos bylas. Po šio manipuliavimo atsiranda galimybė sukurti kitą inventorių tiesiogiai aplinkos kataloge.
Jis pakartotinai naudos group_vars inventorių, taip pat galės iš naujo apibrėžti kai kuriuos kintamuosius tiesiogiai sau.
Galutinė diegimo projekto katalogo struktūra:
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 в среде testApibendrinant
Sutvarkius kintamuosius pagal straipsnį: kiekvienas kintamųjų failas yra atsakingas už konkrečią užduotį. Ir kadangi failas turi tam tikras užduotis, tapo įmanoma paskirti asmenį, atsakingą už kiekvieno failo teisingumą. Pavyzdžiui, sistemos diegimo kūrėjas tampa atsakingas už teisingą žaidimo knygos kintamųjų užpildymą, o administratorius, kurio stendas aprašytas inventoriuje, yra tiesiogiai atsakingas už kintamųjų inventoriaus pildymą.
Vaidmenys tapo atskiru kūrimo padaliniu su savo sąsaja, leidžiančiu vaidmenų kūrėjui plėtoti galimybes, o ne pritaikyti vaidmenį sistemai. Ši problema ypač susijusi su bendromis visų kampanijos sistemų vaidmenimis.
Sistemos administratoriams nebereikia suprasti diegimo kodo. Viskas, ko iš jų reikia sėkmingam diegimui, yra užpildyti nuo aplinkos priklausančių kintamųjų failus.
Literatūra
autorius
Kaljužnis Denisas Aleksandrovičius
Šaltinis: www.habr.com