ansible devops kódstílus
Hé! A nevem Mérnökként dolgozom a fejlesztési folyamatautomatizálási osztályon. Minden nap új alkalmazás-összeállításokat tesznek közzé kampányszerverek százaira. Ebben a cikkben megosztom tapasztalataimat az Ansible ilyen célokra történő használatáról.
Ez az útmutató módot kínál a változók rendszerezésére a telepítés során. Ez az útmutató azoknak készült, akik már használnak szerepet a játékkönyveikben és olvasnak de hasonló problémákba ütközik:
- Miután talált egy változót a kódban, lehetetlen azonnal megérteni, hogy miért felelős;
- Több szerep is létezik, és a változókat egy értékhez kell társítani, de ez nem működik;
- Nehezére esik elmagyarázni másoknak, hogyan működik a játékkönyvekben szereplő változók logikája
Ezekkel a problémákkal cégünk projektjei során találkoztunk, aminek eredményeként eljutottunk a változók formázási szabályaihoz a játékkönyveinkben, amelyek bizonyos mértékig megoldották ezeket a problémákat.
Változók a szerepekben
A szerepkör egy külön telepítési rendszerobjektum. Mint a rendszer bármely objektumának, ennek is rendelkeznie kell egy interfésszel a rendszer többi részével való interakcióhoz. A szerepváltozók egy ilyen interfész.
Vegyük például a szerepet api, amely egy Java alkalmazást telepít a szerverre. Milyen változói vannak?
A szerepváltozók típus szerint 2 típusra oszthatók:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Változó tulajdonságok olyan változók, amelyek egy szerep viselkedését határozzák meg.
Lekérdezési változók olyan változók, amelyek értéke a szerepen kívüli erőforrások kijelölésére szolgál.
Változó hallgatók olyan változók, amelyek értéke lekérdezési változók kialakítására szolgál.
Másrészt az 1a, 2a, 2b olyan változók, amelyek nem függenek a környezettől (vas, külső erőforrások stb.), és az alapértelmezett szerepkörben alapértelmezett értékekkel tölthetők fel. Az 1.b és 2.c változók azonban nem tölthetők fel más értékekkel, mint az „example”, mivel ezek a környezettől függően változnak.
kód stílus
- A változó nevének a szerep nevével kell kezdődnie. Ez megkönnyíti a jövőben annak kiderítését, hogy a változó milyen szerepkörből származik, és miért felelős.
- Amikor változókat használ a szerepekben, feltétlenül kövesse a beágyazás elvét, és magában a szerepkörben vagy azokban a szerepekben definiált változókat használjon, amelyektől az aktuális függ.
-
Kerülje a szótárak használatát a változókhoz. Az Ansible nem teszi lehetővé az egyes értékek kényelmes felülírását a szótárban.
Példa egy rossz változóra:
myrole_user: login: admin password: adminItt a bejelentkezés a medián változó, a jelszó pedig a függő változó. De
mivel ezek szótárban vannak egyesítve, ezt teljes egészében meg kell adnia
Mindig. Ami nagyon kényelmetlen. Jobb így:myrole_user_login: admin myrole_user_password: admin
Változók a telepítési útmutatókban
A telepítési útmutató (továbbiakban: playbook) összeállításakor betartjuk azt a szabályt, hogy azt külön tárhelyen kell elhelyezni. Akárcsak a szerepek: mindegyik a saját git-tárában. Ez lehetővé teszi annak felismerését, hogy a szerepek és a játékkönyv a telepítési rendszer különböző független objektumai, és az egyik objektum változásai nem befolyásolhatják a másik működését. Ez a változók alapértelmezett értékeinek megváltoztatásával érhető el.
A játékfüzet összeállításakor, összefoglalva, két helyen van lehetőség a szerepváltozók alapértelmezett értékeinek felülbírálására: a játékkönyv-változókban és a készletváltozókban.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
A különbség az, hogy a játékkönyv változókat mindig használjuk, amikor vele azonos szinten lévő játékkönyveket hívunk meg. Ez azt jelenti, hogy ezek a változók kiválóan alkalmasak olyan változók alapértelmezett értékeinek megváltoztatására, amelyek nem függenek a környezettől. Ezzel szemben a készletváltozók csak egy adott környezethez lesznek felhasználva, ami ideális a környezetspecifikus változókhoz.
Fontos megjegyezni, hogy a változók elsőbbsége nem teszi lehetővé a változók újradefiniálását először a forgatókönyvbeli változókban, majd külön-külön ugyanabban a leltárban.
Ez azt jelenti, hogy már ebben a szakaszban el kell dönteni, hogy a változó környezetfüggő-e vagy sem, és el kell helyezni a megfelelő helyre.
Például egy projektben az SSL engedélyezéséért felelős változó sokáig környezetfüggő volt, mivel az egyik standon rajtunk kívülálló okok miatt nem tudtuk engedélyezni az SSL-t. Miután kijavítottuk ezt a problémát, közepesen függetlenné vált, és átkerült a játékkönyv-változókra.
Tulajdonsági változók csoportokhoz
Bővítsük ki az 1. ábrán látható modellünket úgy, hogy adjunk hozzá 2 szervercsoportot eltérő Java alkalmazással, de eltérő beállításokkal.
Képzelje el, hogyan fog kinézni a játékkönyv ebben az esetben:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authA játékfüzetben három csoport található, ezért ajánlatos egyszerre minél több csoportfájlt létrehozni a group_vars leltárváltozókban és a playbook változókban. Ebben az esetben az egyik csoportfájl az alkalmazás egyik összetevőjének leírása a játékfüzetben. Amikor megnyitja a csoportfájlt a játékkönyv változóiban, azonnal látni fogja a csoporthoz rendelt szerepek alapértelmezett viselkedésétől való összes eltérést. A készletváltozókban: különbségek a csoportok viselkedésében standonként.
Kódstílus
- Lehetőleg ne használj host_vars változókat, mert nem a rendszert írják le, hanem csak egy speciális esetet, ami hosszú távon kérdéseket vet fel: "Miért különbözik ez a gazdagép a többitől?", A válasz erre az nem mindig könnyű megtalálni.
Változók összekapcsolása
Ez azonban a tulajdonságváltozókról szól, de mi a helyzet a hivatkozási változókkal?
Különbségük az, hogy különböző csoportokban azonos értékkel kell rendelkezniük.
Az elején volt használd az űrlap szörnyű konstrukcióját:
hostvars[groups['bbauth'][0]]['auth_bind_port'], de azonnal elhagyták
mert vannak hibái. Először is a terjedelmesség. Másodszor, a csoport egy adott gazdájától való függés. Harmadszor, a telepítés megkezdése előtt minden gazdagépről össze kell gyűjteni a tényeket, ha nem akarunk meghatározatlan változó hibát kapni.
Ennek eredményeként a linkváltozók használata mellett döntöttek.
Változók összekapcsolása olyan változók, amelyek a játékkönyvhöz tartoznak, és a rendszerobjektumok összekapcsolásához szükségesek.
A hivatkozási változókat az általános rendszerváltozók töltik fel group_vars/all/vars és úgy jön létre, hogy eltávolítja az összes figyelő változót az egyes csoportokból, és a változó elejéhez hozzáadja annak a csoportnak a nevét, amelyből a hallgatót eltávolították.
Így biztosítva van a nevek egyöntetűsége és metszésmentessége.
Próbáljunk meg változókat kötni a fenti példából:
Képzeljük el, hogy vannak változóink, amelyek egymástól függenek:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Tegyük közös változókba group_vars/all/vars minden hallgatót, és adja hozzá a csoport nevét a névhez:
# 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 }}"Most a csatlakozó értékének megváltoztatásával biztosak leszünk abban, hogy a kérés ugyanarra a portra fog menni.
Kódstílus
- Mivel a szerepek és a csoportok különböző rendszerobjektumok, eltérő nevük kell, hogy legyen, hogy a hivatkozási változók pontosan mutassák, hogy egy adott kiszolgálócsoporthoz tartoznak, nem pedig egy szerepkörhöz a rendszerben.
Környezeti fájlok
A szerepkörök környezetenként eltérő fájlokat használhatnak.
Ilyen fájlok például az SSL-tanúsítványok. Tárolja őket szövegként
változóban nem túl kényelmes. De célszerű a hozzájuk vezető utat egy változóban tárolni.
Például a változót használjuk api_ssl_key_file: "/path/to/file".
Mivel nyilvánvaló, hogy a kulcstanúsítvány környezetről környezetre változik, ez egy környezetfüggő változó, ami azt jelenti, hogy a fájlban kell lennie
group_vars/myapi/vars változók leltárát, és tartalmazzák a „például” értéket.
Ebben az esetben a legkényelmesebb, ha a kulcsfájlt az elérési út mentén a játékkönyvtárba helyezzük
files/prod/certs/myapi.key, akkor a változó értéke a következő lesz:
api_ssl_key_file: "prod/certs/myapi.key". A kényelem abban rejlik, hogy az adott standon a rendszer telepítéséért felelős személyeknek is van saját, dedikált helyük a tárolóban, ahol fájljaikat tárolhatják. Ugyanakkor továbbra is lehetőség van a tanúsítvány abszolút elérési útjának megadására a szerveren, ha a tanúsítványokat más rendszer szolgáltatja.
Több állvány egy környezetben
Gyakran előfordul, hogy több, szinte egyforma állványt kell telepíteni ugyanabban a környezetben minimális eltérésekkel. Ebben az esetben a környezetfüggő változókat felosztjuk azokra, amelyek nem változnak ezen a környezetben, és olyanokra, amelyek változnak. Utóbbit pedig közvetlenül magukba a leltárfájlokba visszük ki. Ezt a manipulációt követően lehetővé válik egy másik leltár létrehozása közvetlenül a környezeti könyvtárban.
Újra felhasználja a group_vars leltárt, és képes néhány változót közvetlenül saját maga számára újradefiniálni.
A telepítési projekt végső címtárstruktúrája:
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 в среде testÖsszegezve
A változók cikk szerinti rendszerezése után: minden változót tartalmazó fájl egy adott feladatért felel. És mivel a fájlnak vannak bizonyos feladatai, lehetővé vált, hogy minden fájl helyességéért felelős személyt jelöljenek ki. Például a rendszertelepítés fejlesztője lesz felelős a playbook változók helyes kitöltéséért, míg az adminisztrátor, akinek a standja a leltárban szerepel, közvetlenül a változók leltárának kitöltése.
A Roles önálló fejlesztői egységgé vált, saját felülettel, lehetővé téve a szerepfejlesztő számára, hogy funkciókat fejlesszen, ahelyett, hogy a szerepkört a rendszerhez igazította volna. Ez a probléma különösen igaz a kampány összes rendszerének közös szerepeire.
A rendszergazdáknak már nem kell érteniük a telepítési kódot. A sikeres telepítéshez mindössze annyi kell, hogy kitöltsék a környezeti változók fájljait.
Irodalom
Szerző
Kaljuzsnij Denis Alekszandrovics
Forrás: will.com