ansible devops codestyle
hej Moje ime je Radim kao inženjer u odjelu za automatizaciju razvojnih procesa. Svakodnevno se nove verzije aplikacija postavljaju na stotine poslužitelja kampanja. U ovom članku dijelim svoje iskustvo korištenja Ansiblea u te svrhe.
Ovaj vodič nudi način organiziranja varijabli u implementaciji. Ovaj je vodič osmišljen za one koji već koriste uloge u svojim knjigama i čitaju ali nailazi na slične probleme:
- Pronašavši varijablu u kodu, nemoguće je odmah razumjeti za što je odgovorna;
- Postoji nekoliko uloga, a varijable treba povezati s jednom vrijednošću, ali to ne radi;
- Imate poteškoća s objašnjavanjem drugima kako funkcionira logika varijabli u vašim knjigama
S tim problemima smo se susreli na projektima u našoj tvrtki, slijedom čega smo došli do pravila za formatiranje varijabli u našim igrama, koja su donekle riješila te probleme.
Varijable u ulogama
Uloga je zasebni objekt sustava implementacije. Kao i svaki objekt sustava, mora imati sučelje za interakciju s ostatkom sustava. Varijable uloga su takvo sučelje.
Uzmimo, na primjer, ulogu api, koji instalira Java aplikaciju na poslužitelj. Koje varijable ima?
Varijable uloga mogu se podijeliti u 2 vrste prema vrsti:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Varijabilna svojstva su varijable koje definiraju ponašanje uloge.
Varijable upita su varijable čija se vrijednost koristi za označavanje resursa izvan uloge.
Varijabilni slušatelji su varijable čija se vrijednost koristi za formiranje varijabli upita.
S druge strane, 1a, 2a, 2b su varijable koje ne ovise o okolini (željezo, vanjski resursi itd.) i mogu se ispuniti zadanim vrijednostima u zadanoj ulozi. Međutim, varijable poput 1.b i 2.c ne mogu se ispuniti drugim vrijednostima osim 'primjer', jer će se mijenjati od postolja do postolja ovisno o okruženju.
stil koda
- Naziv varijable mora započeti imenom uloge. To će u budućnosti olakšati odgonetnuti koja je uloga varijable i za što je odgovorna.
- Kada koristite varijable u ulogama, morate biti sigurni da slijedite načelo enkapsulacije i koristite varijable definirane ili u samoj ulozi ili u ulogama o kojima trenutna ovisi.
-
Izbjegavajte korištenje rječnika za varijable. Ansible vam ne dopušta prikladno nadjačavanje pojedinačnih vrijednosti u rječniku.
Primjer loše varijable:
myrole_user: login: admin password: adminOvdje je prijava srednja varijabla, a lozinka zavisna varijabla. Ali
budući da su spojeni u rječnik, morat ćete ga navesti u cijelosti
Stalno. Što je vrlo nezgodno. Bolje ovako:myrole_user_login: admin myrole_user_password: admin
Varijable u priručnicima za implementaciju
Prilikom sastavljanja priručnika za implementaciju (u daljnjem tekstu priručnik) pridržavamo se pravila da isti treba biti smješten u zasebno spremište. Baš kao i uloge: svaka u svom git repozitoriju. To vam omogućuje da shvatite da su uloge i priručnik različiti neovisni objekti sustava za implementaciju, a promjene u jednom objektu ne bi trebale utjecati na rad drugog. To se postiže promjenom zadanih vrijednosti varijabli.
Prilikom sastavljanja priručnika, da rezimiramo, moguće je nadjačati zadane vrijednosti varijabli uloga na dva mjesta: u varijablama priručnika i u varijablama inventara.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Razlika je u tome što se varijable playbooka uvijek koriste kada se pozivaju playbooks koji se nalaze na istoj razini s njim. To znači da su ove varijable izvrsne za promjenu zadanih vrijednosti varijabli koje ne ovise o okruženju. Suprotno tome, varijable inventara koristit će se samo za određeno okruženje, što je idealno za varijable specifične za okruženje.
Važno je napomenuti da vam prioritet varijable neće dopustiti da redefinirate varijable prvo u varijablama priručnika, a zatim zasebno u istom popisu.
To znači da već u ovoj fazi morate odlučiti je li varijabla ovisna o okolini ili ne i postaviti je na pravo mjesto.
Na primjer, u jednom projektu, varijabla odgovorna za omogućavanje SSL-a je dugo vremena ovisila o okruženju, budući da nismo mogli omogućiti SSL iz razloga izvan naše kontrole na jednom od štandova. Nakon što smo riješili ovaj problem, postao je srednje neovisan i prešao na varijable priručnika.
Varijable svojstava za grupe
Proširimo naš model na slici 1 dodavanjem 2 grupe poslužitelja s različitim Java aplikacijama, ali s različitim postavkama.
Zamislite kako će knjiga izgledati u ovom slučaju:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authImamo tri grupe u priručniku, pa se preporučuje stvaranje što više grupnih datoteka u varijablama inventara group_vars i varijablama priručnika odjednom. Jedna grupna datoteka u ovom slučaju je opis jedne komponente vaše aplikacije u priručniku. Kada otvorite datoteku grupe u varijablama priručnika, odmah ćete vidjeti sve razlike u odnosu na zadano ponašanje uloga dodijeljenih grupi. U varijablama inventara: razlike u grupnom ponašanju od kabine do kabine.
stil koda
- Pokušajte uopće ne koristiti varijable host_vars, jer one ne opisuju sustav, već samo poseban slučaj, što će dugoročno dovesti do pitanja: "Zašto je ovaj host drugačiji od ostalih?", odgovor na koje je nije uvijek lako pronaći.
Povežite varijable
Međutim, to je o varijablama svojstava, ali što je s varijablama veze?
Njihova razlika je u tome što moraju imati istu vrijednost u različitim skupinama.
Na početku je bilo koristiti monstruoznu konstrukciju oblika:
hostvars[groups['bbauth'][0]]['auth_bind_port'], ali je odmah napušten
jer ima nedostataka. Prvo, glomaznost. Drugo, ovisnost o određenom domaćinu u skupini. Treće, potrebno je prikupiti činjenice sa svih hostova prije početka implementacije, ako ne želimo dobiti nedefiniranu varijablu pogreške.
Kao rezultat toga, odlučeno je koristiti varijable veze.
Povežite varijable su varijable koje pripadaju priručniku i potrebne su za povezivanje objekata sustava.
Varijable veze popunjavaju se u općim varijablama sustava group_vars/all/vars i formiraju se uklanjanjem svih varijabli slušatelja iz svake grupe i dodavanjem imena grupe iz koje je slušatelj uklonjen na početak varijable.
Tako je osigurana ujednačenost i ne-presikanje imena.
Pokušajmo vezati varijable iz gornjeg primjera:
Zamislimo da imamo varijable koje ovise jedna o drugoj:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Stavimo to u zajedničke varijable group_vars/all/vars sve slušatelje i nazivu dodajte naziv grupe:
# 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 }}"Sada ćemo promjenom vrijednosti konektora biti sigurni da će zahtjev ići na isto mjesto gdje se nalazi port.
stil koda
- Budući da su uloge i grupe različiti objekti sustava, moraju imati različita imena kako bi varijable veze točno pokazivale da pripadaju određenoj grupi poslužitelja, a ne ulozi u sustavu.
Datoteke okruženja
Uloge mogu koristiti datoteke koje se razlikuju od okruženja do okruženja.
SSL certifikati su primjer takvih datoteka. Pohranite ih kao tekst
u varijabli nije baš zgodno. Ali zgodno je pohraniti put do njih unutar varijable.
Na primjer, koristimo varijablu api_ssl_key_file: "/path/to/file".
Budući da je očito da će se certifikat ključa mijenjati od okruženja do okruženja, ovo je varijabla ovisna o okruženju, što znači da bi se trebala nalaziti u datoteci
group_vars/myapi/vars inventar varijabli, a sadrže vrijednost 'na primjer'.
Najprikladniji način u ovom slučaju je staviti ključnu datoteku u repozitorij playbook duž staze
files/prod/certs/myapi.key, tada će vrijednost varijable biti:
api_ssl_key_file: "prod/certs/myapi.key". Pogodnost leži u činjenici da osobe odgovorne za postavljanje sustava na određenom postolju također imaju svoje namjensko mjesto u repozitoriju za pohranu svojih datoteka. U isto vrijeme, ostaje moguće odrediti apsolutni put do certifikata na poslužitelju, u slučaju da certifikate isporučuje drugi sustav.
Više postolja u jednom okruženju
Često postoji potreba za postavljanjem nekoliko gotovo identičnih tribina u istom okruženju s minimalnim razlikama. U ovom slučaju, varijable ovisne o okruženju dijelimo na one koje se ne mijenjaju unutar tog okruženja i one koje se mijenjaju. A potonje vadimo izravno u same datoteke inventara. Nakon ove manipulacije, postaje moguće stvoriti drugi inventar izravno u direktoriju okruženja.
Ponovno će koristiti inventar group_vars i također moći redefinirati neke varijable izravno za sebe.
Konačna struktura direktorija za projekt implementacije:
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 в среде testSumirati
Nakon organiziranja varijabli u skladu s člankom: svaka datoteka s varijablama odgovorna je za određeni zadatak. A budući da datoteka ima određene zadatke, postalo je moguće odrediti osobu odgovornu za ispravnost svake datoteke. Na primjer, programer implementacije sustava postaje odgovoran za ispravno popunjavanje varijabli playbook-a, dok je administrator, čiji je stav opisan u inventaru, direktno odgovoran za popunjavanje inventara varijabli.
Uloge su postale samostalna razvojna jedinica s vlastitim sučeljem, omogućujući programeru uloge da razvije značajke umjesto da ulogu prilagođava sustavu. Ovaj se problem posebno odnosio na zajedničke uloge za sve sustave u kampanji.
Administratori sustava više ne moraju razumjeti kod za implementaciju. Sve što se od njih traži za uspješnu implementaciju je popuniti datoteke varijabli okoline.
Književnost
Autor
Kaljužni Denis Aleksandrovič
Izvor: www.habr.com