ansible devops codestyle
Čau! Mani sauc Strādāju par inženieri izstrādes procesu automatizācijas nodaļā. Katru dienu simtiem kampaņu serveru tiek izlaistas jaunas lietojumprogrammu versijas. Un šajā rakstā es dalos pieredzē par Ansible izmantošanu šiem mērķiem.
Šī rokasgrāmata piedāvā veidu, kā organizēt mainīgos izvietošanas laikā. Šī rokasgrāmata ir paredzēta tiem, kuri jau izmanto lomas savās rotaļu grāmatās un ir lasījuši , bet saskaras ar līdzīgām problēmām:
- Atrodot kodā mainīgo, nav iespējams uzreiz saprast, par ko tas ir atbildīgs;
- Ir vairākas lomas, un mainīgie ir jāsaista ar vienu vērtību, taču tā vienkārši nedarbojas;
- Jums ir grūtības izskaidrot citiem, kā darbojas mainīgo loģika jūsu rokasgrāmatās
Mēs saskārāmies ar šīm problēmām mūsu uzņēmuma projektos, kā rezultātā mēs nonācām pie mainīgo lielumu izstrādes noteikumiem mūsu rokasgrāmatās, kas zināmā mērā atrisināja šīs problēmas.
Mainīgie lielumi lomās
Loma ir atsevišķs izvietošanas sistēmas objekts. Tāpat kā jebkuram sistēmas objektam, tam ir jābūt saskarnei mijiedarbībai ar pārējo sistēmu. Šāda saskarne ir lomu mainīgie.
Ņemsim, piemēram, lomu api, kas serverī instalē Java lietojumprogrammu. Kādi mainīgie tajā varētu būt?
Mainīgās lomas pēc veida var iedalīt 2 veidos:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Mainīgas īpašības ir mainīgie, kas nosaka lomas uzvedību.
Vaicājuma mainīgie - tie ir mainīgie, kuru vērtība tiek izmantota, lai apzīmētu resursus ārpus lomas.
Mainīgi klausītāji - tie ir mainīgie, kuru vērtība tiek izmantota pieprasījuma mainīgo veidošanai.
No otras puses, 1a, 2a, 2b ir mainīgie, kas nav atkarīgi no vides (aparatūra, ārējie resursi utt.) un kurus var aizpildīt ar noklusējuma vērtībām noklusējuma lomā. Tomēr 1.b un 2.c tipa mainīgos nav iespējams aizpildīt ar vērtībām, kas nav “piemērs”, jo tie mainīsies atkarībā no vides.
Koda stils
- Mainīgā nosaukumam jāsākas ar lomas nosaukumu. Tas ļaus nākotnē viegli noskaidrot, no kuras lomas ir mainīgais un par ko tas ir atbildīgs.
- Izmantojot mainīgos lomās, jums noteikti jāievēro iekapsulēšanas princips un jāizmanto mainīgie, kas definēti vai nu pašā lomā, vai lomās, no kurām ir atkarīga pašreizējā.
-
Izvairieties izmantot vārdnīcas mainīgajiem. Ansible neļauj ērti ignorēt atsevišķas vērtības vārdnīcā.
Slikta mainīgā piemērs:
myrole_user: login: admin password: adminŠeit pieteikšanās ir neatkarīgais mainīgais, un parole ir atkarīgais mainīgais. Bet
tā kā tie ir apvienoti vārdnīcā, jums tas būs jānorāda pilnībā
Vienmēr. Kas ir ļoti neērti. Labāk šādi:myrole_user_login: admin myrole_user_password: admin
Mainīgie izvietošanas rokasgrāmatās
Sastādot izvietošanas rokasgrāmatu (turpmāk tekstā – rokasgrāmata), mēs ievērojam noteikumu, ka tā ir jāievieto atsevišķā repozitorijā. Tas pats, kas lomas: katra savā git repozitorijā. Tas ļauj saprast, ka lomas un rokasgrāmata ir dažādi neatkarīgi izvietošanas sistēmas objekti, un izmaiņām vienā objektā nevajadzētu ietekmēt otra darbību. Tas tiek panākts, mainot mainīgo noklusējuma vērtības.
Sastādot rokasgrāmatu, rezumējot, lomu mainīgo noklusējuma vērtības ir iespējams ignorēt divās vietās: rokasgrāmatas mainīgajos un krājumu mainīgajos.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Atšķirība ir tāda, ka rokasgrāmatas mainīgie vienmēr tiek izmantoti, izsaucot rokasgrāmatas, kas atrodas tajā pašā līmenī. Tas nozīmē, ka šie mainīgie ir lieliski piemēroti, lai mainītu no vides neatkarīgo mainīgo noklusējuma vērtības. Un otrādi, krājumu mainīgie tiks izmantoti tikai noteiktai videi, kas ir ideāli piemērota videi raksturīgiem mainīgajiem.
Ir svarīgi atzīmēt, ka mainīgā prioritāte neļaus jums ignorēt mainīgos vispirms rokasgrāmatas mainīgajos un pēc tam atsevišķi vienā krājumā.
Tas nozīmē, ka jau šajā posmā ir jāizlemj, vai mainīgais ir vai nav atkarīgs no vides, un jānovieto tas atbilstošā vietā.
Piemēram, vienā projektā mainīgais, kas atbild par SSL iespējošanu, ilgu laiku bija atkarīgs no vides, jo vienā no stendiem mēs nevarējām iespējot SSL no mums neatkarīgu iemeslu dēļ. Pēc šīs problēmas novēršanas tā kļuva neatkarīga no vides un tika pārvietota uz rokasgrāmatas mainīgajiem.
Rekvizītu mainīgie grupām
Izvērsīsim savu modeli 1. attēlā, pievienojot 2 serveru grupas ar atšķirīgu Java lietojumprogrammu, bet ar dažādiem iestatījumiem.
Iedomāsimies, kā šajā gadījumā izskatīsies rokasgrāmata:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authRokasgrāmatā ir trīs grupas, tāpēc nekavējoties ir ieteicams izveidot vienādu grupu failu skaitu inventāra mainīgajos group_vars un rokasgrāmatas mainīgajos. Viens grupas fails šajā gadījumā ir viena iepriekš minētās lietojumprogrammas komponenta apraksts rokasgrāmatā. Atverot grupas failu rokasgrāmatas mainīgajos, jūs uzreiz redzat visas atšķirības no grupā instalēto lomu noklusējuma darbības. Inventāra mainīgajos: atšķirības grupas uzvedībā no stenda līdz stendam.
Koda stils
- Centieties vispār neizmantot host_vars mainīgos, jo tie neapraksta sistēmu, bet tikai īpašu gadījumu, kas nākotnē radīs jautājumus: "Kāpēc šis resursdators atšķiras no citiem?", uz kuru atbilde nav vienmēr viegli atrast.
Komunikācijas mainīgie
Tomēr tas ir īpašību mainīgie, bet kā ar komunikācijas mainīgajiem?
To atšķirība ir tāda, ka dažādās grupās tiem ir jābūt vienādai nozīmei.
Sākumā tā bija izmantojiet briesmīgu konstrukciju, piemēram:
hostvars[groups['bbauth'][0]]['auth_bind_port'], taču viņi to uzreiz noraidīja
jo tai ir trūkumi. Pirmkārt, apjomīgums. Otrkārt, atkarība no konkrēta saimnieka grupā. Treškārt, pirms izvietošanas ir jāsavāc fakti no visiem saimniekiem, ja mēs nevēlamies iegūt nedefinēta mainīgā kļūdu.
Rezultātā tika nolemts izmantot komunikācijas mainīgos.
Komunikācijas mainīgie - tie ir mainīgie, kas pieder pie rokasgrāmatas un ir nepieciešami sistēmas objektu savienošanai.
Sakaru mainīgie tiek aizpildīti vispārīgajos sistēmas mainīgajos group_vars/all/vars un tiek veidoti, no katras grupas noņemot visus klausītāja mainīgos un mainīgā sākumam pievienojot tās grupas nosaukumu, no kuras klausītājs tika noņemts.
Tas nodrošina nosaukumu vienveidību un nepārklāšanos.
Mēģināsim saistīt mainīgos no iepriekš minētā piemēra:
Iedomāsimies, ka mums ir mainīgie, kas ir atkarīgi viens no otra:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Ieliksim to kopējos mainīgajos group_vars/all/vars visiem klausītājiem un nosaukumam pievienojiet grupas nosaukumu:
# 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 }}"Tagad, mainot savienotāja vērtību, mēs būsim pārliecināti, ka pieprasījums nonāks tajā pašā vietā, kur atrodas ports.
Koda stils
- Tā kā lomas un grupas ir dažādi sistēmas objekti, tiem ir jābūt atšķirīgiem nosaukumiem, tad saites mainīgie precīzi norādīs, ka tie pieder noteiktai serveru grupai, nevis kādai lomai sistēmā.
No vides atkarīgi faili
Lomas var izmantot failus, kas dažādās vidēs atšķiras.
Šādu failu piemērs ir SSL sertifikāti. Saglabājiet tos teksta formātā
mainīgajā nav ļoti ērti. Bet ir ērti saglabāt ceļu uz tiem mainīgā lielumā.
Piemēram, mēs izmantojam mainīgo api_ssl_key_file: "/path/to/file".
Tā kā ir skaidrs, ka atslēgas sertifikāts mainīsies no vides uz vidi, tas ir no vides atkarīgs mainīgais, kas nozīmē, ka tam jāatrodas failā
group_vars/myapi/vars mainīgo lielumu sarakstu un satur vērtību “piemēram”.
Ērtākais veids šajā gadījumā ir ievietot atslēgas failu rokasgrāmatas repozitorijā pa ceļu
files/prod/certs/myapi.key, tad mainīgā vērtība būs:
api_ssl_key_file: "prod/certs/myapi.key". Ērtības slēpjas faktā, ka cilvēkiem, kas ir atbildīgi par sistēmas izvietošanu konkrētā stendā, ir arī sava vieta krātuvē, kur glabāt savus failus. Tajā pašā laikā joprojām ir iespējams norādīt absolūto ceļu uz sertifikātu serverī, ja sertifikātus piegādā cita sistēma.
Vairāki stendi vienā vidē
Bieži vien ir nepieciešams izvietot vairākus gandrīz identiskus stendus vienā vidē ar minimālām atšķirībām. Šajā gadījumā mēs sadalām no vides atkarīgos mainīgos tajos, kas šajā vidē nemainās, un tajos, kas mainās. Un pēdējo mēs pārsūtām tieši uz pašiem inventarizācijas failiem. Pēc šīs manipulācijas kļūst iespējams izveidot citu inventāru tieši vides direktorijā.
Tas atkārtoti izmantos group_vars inventāru, kā arī varēs pārdefinēt dažus mainīgos tieši sev.
Izvēršanas projekta galīgā direktoriju 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 в среде testSummējot
Pēc mainīgo lielumu sakārtošanas saskaņā ar pantu: katrs mainīgā fails ir atbildīgs par konkrētu uzdevumu. Un tā kā failam ir noteikti uzdevumi, kļuva iespējams norīkot kādu, kas ir atbildīgs par katra faila pareizību. Piemēram, sistēmas izvietošanas izstrādātājs ir atbildīgs par pareizu rokasgrāmatas mainīgo aizpildīšanu, savukārt administrators, kura stends ir aprakstīts uzskaitē, ir tieši atbildīgs par mainīgo lielumu uzskaites aizpildīšanu.
Lomas kļuva par atsevišķu izstrādes vienību ar savu saskarni, ļaujot lomu izstrādātājam attīstīt iespējas, nevis pielāgot lomu sistēmai. Šī problēma īpaši skāra visu kampaņā iesaistīto sistēmu kopīgo lomu.
Sistēmas administratoriem vairs nav jāsaprot izvietošanas kods. Viss, kas no viņiem ir nepieciešams veiksmīgai izvietošanai, ir aizpildīt no vides atkarīgo mainīgo failus.
Literatūra
Autors
Kaļužnijs Deniss Aleksandrovičs
Avots: www.habr.com