ansible devops codestyle
Hej! Unë quhem Unë punoj si inxhinier në departamentin e automatizimit të procesit të zhvillimit. Çdo ditë, ndërtimet e reja të aplikacioneve shpërndahen në qindra serverë të fushatës. Dhe në këtë artikull unë ndaj përvojën time të përdorimit të Ansible për këto qëllime.
Ky udhëzues ofron një mënyrë për të organizuar variablat në vendosje. Ky udhëzues është menduar për ata që tashmë përdorin role në librat e tyre të lojërave dhe kanë lexuar , por përballet me probleme të ngjashme:
- Pasi të keni gjetur një variabël në kod, është e pamundur të kuptohet menjëherë se për çfarë është përgjegjës;
- Ka disa role, dhe variablat duhet të shoqërohen me një vlerë, por thjesht nuk funksionon;
- Duke pasur vështirësi t'u shpjegoni të tjerëve se si funksionon logjika e variablave në librat tuaj të lojërave
Ne i hasëm këto probleme në projektet në kompaninë tonë, si rezultat i të cilave arritëm në rregulla për hartimin e variablave në librat tanë, të cilat në një farë mase i zgjidhën këto probleme.
Variablat në role
Një rol është një objekt i veçantë i sistemit të vendosjes. Si çdo objekt i sistemit, ai duhet të ketë një ndërfaqe për ndërveprim me pjesën tjetër të sistemit. Një ndërfaqe e tillë është variablat e roleve.
Le të marrim, për shembull, rolin api, i cili instalon një aplikacion Java në server. Çfarë variablash mund të ketë?
Rolet e ndryshueshme mund të ndahen në 2 lloje sipas llojit:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Vetitë e ndryshueshme janë variabla që përcaktojnë sjelljen e një roli.
Variablat e pyetjeve - këto janë variabla, vlera e të cilave përdoret për të përcaktuar burimet e jashtme të rolit.
Dëgjues të ndryshueshëm - këto janë variabla vlera e të cilave përdoret për të formuar variablat e kërkesës.
Nga ana tjetër, 1a, 2a, 2b janë variabla që nuk varen nga mjedisi (hardueri, burimet e jashtme, etj.) dhe mund të plotësohen me vlerat e paracaktuara në rolin e parazgjedhur. Megjithatë, është e pamundur të plotësohen variablat e tipit 1.b dhe 2.c me vlera të tjera përveç "shembullit", pasi ato do të ndryshojnë nga një pozicion në tjetrin në varësi të mjedisit.
Stili i kodit
- Emri i ndryshores duhet të fillojë me emrin e rolit. Kjo do ta bëjë të lehtë të kuptosh në të ardhmen se nga cili rol është variabla dhe për çfarë është përgjegjëse.
- Kur përdorni variabla në role, duhet të jeni të sigurt që të ndiqni parimin e kapsulimit dhe të përdorni variabla të përcaktuara ose në vetë rolin ose në rolet nga të cilat varet ai aktual.
-
Shmangni përdorimin e fjalorëve për variabla. Ansible nuk ju lejon të anashkaloni me lehtësi vlerat individuale në një fjalor.
Shembull i një ndryshoreje të keqe:
myrole_user: login: admin password: adminKëtu hyrja është ndryshorja e pavarur, dhe fjalëkalimi është ndryshorja e varur. Por
meqenëse ato janë të kombinuara në një fjalor, do të duhet ta specifikoni plotësisht
Gjithmonë. E cila është shumë e papërshtatshme. Më mirë në këtë mënyrë:myrole_user_login: admin myrole_user_password: admin
Variablat në librat e vendosjes
Kur përpilojmë një libër lojërash të vendosjes (në tekstin e mëtejmë referuar si libri i luajtjes), ne i përmbahemi rregullit që ai duhet të vendoset në një depo të veçantë. Njëlloj si rolet: secili në depon e vet të git. Kjo ju lejon të kuptoni se rolet dhe libri i lojërave janë objekte të ndryshme të pavarura të sistemit të vendosjes dhe ndryshimet në një objekt nuk duhet të ndikojnë në funksionimin e tjetrit. Kjo arrihet duke ndryshuar vlerat e paracaktuara të variablave.
Kur përpiloni një libër lojërash, për ta përmbledhur, është e mundur që të anashkalohen vlerat e paracaktuara të variablave të roleve në dy vende: në variablat e librit të lojërave dhe në variablat e inventarit.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Dallimi është se ndryshoret e librit të luajtjes përdoren gjithmonë kur thirren librat e lojërave që ndodhen në të njëjtin nivel me të. Kjo do të thotë që këto variabla janë të shkëlqyera për ndryshimin e vlerave të paracaktuara të variablave të pavarur nga mjedisi. Në të kundërt, variablat e inventarit do të përdoren vetëm për një mjedis specifik, i cili është ideal për variablat specifike të mjedisit.
Është e rëndësishme të theksohet se përparësia e ndryshores nuk do t'ju lejojë të anashkaloni variablat fillimisht në variablat e librit të lojës dhe më pas veçmas në një inventar.
Kjo do të thotë që tashmë në këtë fazë është e nevojshme të vendoset nëse ndryshorja është e varur nga mjedisi apo jo dhe ta vendosim atë në vendin e duhur.
Për shembull, në një projekt, ndryshorja përgjegjëse për aktivizimin e SSL ishte e varur nga mjedisi për një kohë të gjatë, pasi ne nuk mund të aktivizonim SSL për arsye përtej kontrollit tonë në një nga stendat. Pasi e rregulluam këtë problem, ai u bë i pavarur nga mjedisi dhe kaloi në variablat e librit të luajtjes.
Variablat e vetive për grupet
Le të zgjerojmë modelin tonë në figurën 1 duke shtuar 2 grupe serverësh me një aplikacion të ndryshëm Java, por me cilësime të ndryshme.
Le të imagjinojmë se si do të duket libri i lojërave në këtë rast:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authNe kemi tre grupe në playbook, kështu që rekomandohet menjëherë krijimi i të njëjtit numër skedarësh grupi në variablat e inventarit group_vars dhe variablat e librit të luajtjes. Një skedar grupi në këtë rast është një përshkrim i një komponenti të aplikacionit të mësipërm në librin e lojërave. Kur hapni një skedar grupi në variablat e librit të luajtjes, menjëherë shihni të gjitha ndryshimet nga sjellja e paracaktuar e roleve të instaluara në grup. Në variablat e inventarit: dallimet në sjelljen e grupit nga baza në stacion.
Stili i kodit
- Mundohuni të mos përdorni fare variablat host_vars, pasi ato nuk përshkruajnë sistemin, por vetëm një rast të veçantë, i cili në të ardhmen do të çojë në pyetjet: "Pse ky host është i ndryshëm nga të tjerët?", përgjigja për të cilën nuk është gjithmonë e lehtë për t'u gjetur.
Variablat e komunikimit
Megjithatë, kjo është ajo që variablat e vetive kanë të bëjnë, por çfarë ndodh me variablat e komunikimit?
Dallimi i tyre është se ato duhet të kenë të njëjtin kuptim në grupe të ndryshme.
Në fillim ishte përdorni një ndërtim monstruoz si:
hostvars[groups['bbauth'][0]]['auth_bind_port'], por ata e refuzuan menjëherë
sepse ka disavantazhe. Së pari, vëllimi. Së dyti, varësia nga një host specifik në grup. Së treti, para fillimit të vendosjes, është e nevojshme të mblidhen fakte nga të gjithë hostet nëse nuk duam të marrim një gabim të një ndryshoreje të papërcaktuar.
Si rezultat, u vendos që të përdoren variablat e komunikimit.
Variablat e komunikimit - këto janë variabla që i përkasin librit të lojërave dhe nevojiten për të lidhur objektet e sistemit.
Variablat e komunikimit janë të mbushura në variablat e përgjithshëm të sistemit group_vars/all/vars dhe formohen duke hequr të gjitha variablat e dëgjuesit nga secili grup, dhe duke shtuar emrin e grupit nga i cili është hequr dëgjuesi në fillim të ndryshores.
Kjo siguron uniformitetin dhe mos mbivendosjen e emrave.
Le të përpiqemi të lidhim variablat nga shembulli i mësipërm:
Le të imagjinojmë se kemi variabla që varen nga njëri-tjetri:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Le ta vendosim atë në ndryshore të zakonshme group_vars/all/vars të gjithë dëgjuesit dhe shtoni emrin e grupit në titull:
# 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 }}"Tani, duke ndryshuar vlerën e lidhësit, do të jemi të sigurt që kërkesa do të shkojë në të njëjtin vend ku ndodhet porti.
Stili i kodit
- Meqenëse rolet dhe grupet janë objekte të ndryshme të sistemit, ato duhet të kenë emra të ndryshëm, atëherë variablat e lidhjes do të tregojnë me saktësi se ato i përkasin një grupi të caktuar serverësh dhe jo një roli në sistem.
Skedarët e varur nga mjedisi
Rolet mund të përdorin skedarë që ndryshojnë nga mjedisi në mjedis.
Një shembull i skedarëve të tillë janë certifikatat SSL. Ruani ato në formë teksti
në një variabël nuk është shumë i përshtatshëm. Por është e përshtatshme të ruash shtegun drejt tyre brenda një ndryshoreje.
Për shembull, ne përdorim variablin api_ssl_key_file: "/path/to/file".
Meqenëse është e qartë se certifikata kryesore do të ndryshojë nga mjedisi në mjedis, kjo është një variabël e varur nga mjedisi, që do të thotë se duhet të gjendet në skedar
group_vars/myapi/vars inventari i variablave dhe përmban vlerën 'për shembull'.
Mënyra më e përshtatshme në këtë rast është vendosja e skedarit kyç në depon e librit të luajtjes përgjatë rrugës
files/prod/certs/myapi.key, atëherë vlera e ndryshores do të jetë:
api_ssl_key_file: "prod/certs/myapi.key". Komoditeti qëndron në faktin se personat përgjegjës për vendosjen e sistemit në një stendë specifike kanë gjithashtu hapësirën e tyre të dedikuar në depo për të ruajtur skedarët e tyre. Në të njëjtën kohë, mbetet e mundur të specifikohet shtegu absolut i certifikatës në server, në rast se certifikatat furnizohen nga një sistem tjetër.
Stenda të shumta në një ambient
Shpesh ka nevojë për të vendosur disa stenda pothuajse identike në të njëjtin mjedis me dallime minimale. Në këtë rast, ne i ndajmë variablat e varur nga mjedisi në ato që nuk ndryshojnë brenda këtij mjedisi dhe ato që ndryshojnë. Dhe ne e transferojmë këtë të fundit direkt në vetë skedarët e inventarit. Pas këtij manipulimi, bëhet e mundur krijimi i një inventari tjetër direkt në direktorinë e mjedisit.
Ai do të ripërdorë inventarin group_vars dhe gjithashtu do të jetë në gjendje të ripërcaktojë disa variabla drejtpërdrejt për vete.
Struktura përfundimtare e drejtorisë për projektin e vendosjes:
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 в среде testDuke përmbledhur
Pas organizimit të variablave në përputhje me artikullin: çdo skedar variabël është përgjegjës për një detyrë specifike. Dhe meqenëse skedari ka detyra të caktuara, u bë e mundur të caktohej dikush përgjegjës për korrektësinë e secilit skedar. Për shembull, zhvilluesi i vendosjes së sistemit bëhet përgjegjës për plotësimin e saktë të variablave të librit të lojës, ndërsa administratori qëndrimi i të cilit përshkruhet në inventar është drejtpërdrejt përgjegjës për plotësimin e inventarit të variablave.
Rolet u bënë njësia e tyre e zhvillimit me ndërfaqen e tyre, duke i lejuar zhvilluesit të roleve të zhvillojnë aftësi në vend që ta përshtatin rolin me sistemin. Ky problem kishte të bënte veçanërisht me rolet e përbashkëta për të gjitha sistemet në fushatë.
Administratorët e sistemit nuk kanë më nevojë të kuptojnë kodin e vendosjes. Gjithçka që kërkohet prej tyre për vendosjen e suksesshme është të plotësojnë skedarët e variablave të varur nga mjedisi.
Letërsi
Autor
Kalyuzhny Denis Alexandrovich
Burimi: www.habr.com