povolený devops kódový štýl
Ahoj! Moje meno je Pracujem ako inžinier na oddelení automatizácie vývojových procesov. Každý deň sa na stovky serverov kampaní zavádzajú nové zostavy aplikácií. A v tomto článku zdieľam svoje skúsenosti s používaním Ansible na tieto účely.
Táto príručka ponúka spôsob organizácie premenných v nasadení. Táto príručka je určená pre tých, ktorí už používajú roly vo svojich učebniciach a čítajú , ale čelí podobným problémom:
- Po nájdení premennej v kóde nie je možné okamžite pochopiť, za čo je zodpovedná;
- Existuje niekoľko rolí a premenné musia byť spojené s jednou hodnotou, ale to nefunguje;
- Máte problém vysvetliť ostatným, ako funguje logika premenných vo vašich príručkách
S týmito problémami sme sa stretli na projektoch v našej spoločnosti, v dôsledku čoho sme sa dostali k pravidlám formátovania premenných v našich playbookoch, ktoré tieto problémy do istej miery vyriešili.
Premenné v rolách
Rola je samostatný objekt systému nasadenia. Ako každý objekt systému musí mať rozhranie na interakciu so zvyškom systému. Takýmto rozhraním sú premenné rolí.
Vezmite si napríklad rolu api, ktorý nainštaluje Java aplikáciu na server. Aké má premenné?
Premenné roly možno rozdeliť do 2 typov podľa typu:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Variabilné vlastnosti sú premenné, ktoré definujú správanie roly.
Premenné dopytu - sú to premenné, ktorých hodnota sa používa na označenie zdrojov mimo roly.
Variabilní poslucháči sú premenné, ktorých hodnota sa používa na vytvorenie dotazovaných premenných.
Na druhej strane, 1a, 2a, 2b sú premenné, ktoré nezávisia od prostredia (železo, externé zdroje atď.) a môžu byť naplnené predvolenými hodnotami v role defaults. Premenné ako 1.ba 2.c však nemožno naplniť inými hodnotami ako „príklad“, pretože sa budú meniť od stojana k stojanu v závislosti od prostredia.
štýl kódu
- Názov premennej musí začínať názvom roly. V budúcnosti tak bude ľahké zistiť, z akej úlohy premenná pochádza a za čo je zodpovedná.
- Pri používaní premenných v rolách musíte dodržiavať princíp zapuzdrenia a používať premenné definované buď v samotnej role, alebo v rolách, od ktorých závisí aktuálna.
-
Vyhnite sa používaniu slovníkov pre premenné. Ansible vám neumožňuje pohodlne prepísať jednotlivé hodnoty v slovníku.
Príklad zlej premennej:
myrole_user: login: admin password: adminPrihlásenie je tu stredná premenná a heslo je závislá premenná. ale
keďže sú spojené do slovníka, budete ho musieť špecifikovať v plnom rozsahu
Vždy. Čo je veľmi nepohodlné. Lepšie takto:myrole_user_login: admin myrole_user_password: admin
Premenné v príručkách nasadenia
Pri zostavovaní nasadzovacieho playbooku (ďalej len playbook) sa držíme pravidla, že by mal byť umiestnený v samostatnom úložisku. Rovnako ako role: každá vo svojom vlastnom úložisku git. To vám umožní uvedomiť si, že roly a zoznam sú rôzne nezávislé objekty systému nasadenia a zmeny v jednom objekte by nemali ovplyvniť fungovanie druhého objektu. To sa dosiahne zmenou predvolených hodnôt premenných.
Keď to zhrnieme, pri zostavovaní zošita je možné prepísať predvolené hodnoty premenných rolí na dvoch miestach: v premenných zošita a v premenných inventára.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Rozdiel je v tom, že premenné playbooku sa vždy používajú pri volaní playbookov umiestnených na rovnakej úrovni s nimi. To znamená, že tieto premenné sú skvelé na zmenu predvolených hodnôt premenných, ktoré nezávisia od prostredia. Naopak, premenné inventára sa použijú len pre konkrétne prostredie, čo je ideálne pre premenné špecifické pre dané prostredie.
Je dôležité poznamenať, že priorita premennej vám nedovolí predefinovať premenné najskôr v premenných v príručke a potom samostatne v tom istom inventári.
To znamená, že už v tejto fáze sa musíte rozhodnúť, či je premenná závislá od prostredia alebo nie a umiestniť ju na správne miesto.
Napríklad v jednom projekte bola premenná zodpovedná za aktiváciu SSL dlhý čas závislá od prostredia, pretože sme nemohli povoliť SSL z dôvodov, ktoré sme nemohli ovplyvniť na jednom zo stánkov. Keď sme tento problém vyriešili, stal sa nezávislým od média a presunul sa do premenných v príručke.
Premenné vlastností pre skupiny
Rozšírme náš model na obrázku 1 pridaním 2 skupín serverov s odlišnou Java aplikáciou, ale s odlišnými nastaveniami.
Predstavte si, ako bude v tomto prípade vyzerať príručka:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authV playbooku máme tri skupiny, preto sa odporúča vytvoriť čo najviac súborov skupín v premenných inventára group_vars a premenných playbooku naraz. Jeden skupinový súbor je v tomto prípade popisom jedného komponentu vašej aplikácie v playbooku. Keď otvoríte súbor skupiny v premenných playbooku, okamžite uvidíte všetky rozdiely oproti predvolenému správaniu rolí priradených skupine. V inventárnych premenných: rozdiely v správaní skupín od stánku k stánku.
Štýl kódu
- Pokúste sa vôbec nepoužívať premenné host_vars, pretože nepopisujú systém, ale iba špeciálny prípad, ktorý z dlhodobého hľadiska povedie k otázkam: „Prečo je tento hostiteľ iný ako ostatní?“, odpoveď na ktorú je nie vždy je ľahké nájsť.
Premenné prepojenia
To je však o premenných vlastností, ale čo premenné odkazov?
Ich rozdiel je v tom, že musia mať rovnakú hodnotu v rôznych skupinách.
Na začiatku bolo použite obludnú konštrukciu formulára:
hostvars[groups['bbauth'][0]]['auth_bind_port'], ale okamžite sa od toho upustilo
lebo má nedostatky. Po prvé, objemnosť. Po druhé, závislosť od konkrétneho hostiteľa v skupine. Po tretie, pred spustením nasadenia je potrebné zozbierať fakty od všetkých hostiteľov, ak nechceme dostať nedefinovanú chybu premennej.
V dôsledku toho bolo rozhodnuté použiť premenné prepojenia.
Premenné prepojenia sú premenné, ktoré patria do playbooku a sú potrebné na prepojenie systémových objektov.
Premenné odkazu sú vyplnené vo všeobecných systémových premenných group_vars/all/vars a sú tvorené odstránením všetkých premenných poslucháča z každej skupiny a pridaním názvu skupiny, z ktorej bol poslucháč odstránený, na začiatok premennej.
Je tak zabezpečená jednotnosť a neprelínanie mien.
Skúsme naviazať premenné z vyššie uvedeného príkladu:
Predstavte si, že máme premenné, ktoré na sebe závisia:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Dajme to do spoločných premenných group_vars/all/vars všetkých poslucháčov a k názvu pridajte názov skupiny:
# 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 }}"Teraz zmenou hodnoty konektora budeme mať istotu, že požiadavka pôjde na to isté miesto, kde sa nachádza port.
Štýl kódu
- Keďže roly a skupiny sú rôzne objekty v systéme, musíte pre ne mať rôzne názvy, potom premenné odkazu presne ukážu, že patria do špecifickej skupiny serverov a nie do roly v systéme.
Súbory prostredia
Roly môžu používať súbory, ktoré sa líšia v závislosti od prostredia.
Príkladom takýchto súborov sú certifikáty SSL. Uložte ich ako text
v premennej nie je veľmi pohodlné. Cestu k nim je však vhodné uložiť do premennej.
Napríklad používame premennú api_ssl_key_file: "/path/to/file".
Keďže je zrejmé, že certifikát kľúča sa bude meniť z prostredia na prostredie, ide o premennú závislú od prostredia, čo znamená, že by sa mala nachádzať v súbore
group_vars/myapi/vars inventár premenných a obsahujú hodnotu „napríklad“.
Najpohodlnejším spôsobom v tomto prípade je vložiť súbor kľúča do úložiska playbooku pozdĺž cesty
files/prod/certs/myapi.key, potom bude hodnota premennej:
api_ssl_key_file: "prod/certs/myapi.key". Pohodlie spočíva v tom, že ľudia zodpovední za nasadenie systému na konkrétnom stojane majú aj svoje vyhradené miesto v úložisku na ukladanie svojich súborov. Zároveň zostáva možnosť zadať absolútnu cestu k certifikátu na serveri v prípade, že certifikáty dodáva iný systém.
Viac stojanov v jednom prostredí
Často vzniká potreba nasadiť niekoľko takmer rovnakých stojanov do rovnakého prostredia s minimálnymi rozdielmi. V tomto prípade delíme premenné závislé od prostredia na tie, ktoré sa v rámci tohto prostredia nemenia, a tie, ktoré sa menia. A to posledné vyberieme priamo do samotných súborov inventára. Po tejto manipulácii je možné vytvoriť ďalší inventár priamo v adresári prostredia.
Znovu použije inventár group_vars a tiež bude môcť predefinovať niektoré premenné priamo pre seba.
Konečná adresárová štruktúra pre projekt nasadenia:
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 в среде testZhrnutie
Po usporiadaní premenných v súlade s článkom: každý súbor s premennými je zodpovedný za konkrétnu úlohu. A keďže súbor má určité úlohy, bolo možné určiť osobu zodpovednú za správnosť každého súboru. Napríklad vývojár nasadenia systému sa stáva zodpovedným za správne vyplnenie premenných playbooku, zatiaľ čo správca, ktorého stojan je popísaný v inventári, je priamo zodpovedný za vyplnenie inventára premenných.
Roly sa stali samostatnou vývojovou jednotkou s vlastným rozhraním, čo vývojárovi roly umožňuje skôr vyvíjať funkcie, než prispôsobovať rolu tak, aby vyhovovala systému. Tento problém sa týkal najmä spoločných rolí pre všetky systémy v kampani.
Správcovia systému už nemusia rozumieť kódu nasadenia. Všetko, čo sa od nich vyžaduje pre úspešné nasadenie, je vyplniť súbory premenných prostredia.
Literatúra
Autor
Kaljužnyj Denis Alexandrovič
Zdroj: hab.com