ansible devops codestyle
Haai! My naam is Ek werk as 'n ingenieur in die ontwikkelingsproses-outomatiseringsafdeling. Elke dag word nuwe toepassings op honderde veldtogbedieners uitgerol. En in hierdie artikel deel ek my ervaring van die gebruik van Ansible vir hierdie doeleindes.
Hierdie gids bied 'n manier om veranderlikes in 'n ontplooiing te organiseer. Hierdie gids is ontwerp vir diegene wat reeds rolle in hul speelboeke gebruik en lees maar ondervind soortgelyke probleme:
- Nadat 'n veranderlike in die kode gevind is, is dit onmoontlik om dadelik te verstaan waarvoor dit verantwoordelik is;
- Daar is verskeie rolle, en die veranderlikes moet met een waarde geassosieer word, maar dit werk nie;
- Dit is moeilik om aan ander te verduidelik hoe die logika van die veranderlikes in jou speelboeke werk
Ons het hierdie probleme op projekte in ons maatskappy teëgekom, waardeur ons by die reëls vir die formatering van veranderlikes in ons speelboeke gekom het, wat tot 'n mate hierdie probleme opgelos het.
Veranderlikes in rolle
'n Rol is 'n aparte ontplooiingstelselvoorwerp. Soos enige voorwerp van die stelsel, moet dit 'n koppelvlak hê vir interaksie met die res van die stelsel. Rolveranderlikes is so 'n koppelvlak.
Neem byvoorbeeld die rol api, wat 'n Java-toepassing op die bediener installeer. Watter veranderlikes het dit?
Rolveranderlikes kan volgens tipe in 2 tipes verdeel word:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Veranderlike eienskappe is veranderlikes wat die gedrag van 'n rol definieer.
Navraag veranderlikes is veranderlikes waarvan die waarde gebruik word om hulpbronne buite die rol aan te wys.
Veranderlike luisteraars is veranderlikes waarvan die waarde gebruik word om navraagveranderlikes te vorm.
Aan die ander kant is 1a, 2a, 2b veranderlikes wat nie van die omgewing afhanklik is nie (yster, eksterne hulpbronne, ens.) en kan gevul word met verstekwaardes in die verstekrol. Veranderlikes soos 1.b en 2.c kan egter nie met ander waardes as 'voorbeeld' gevul word nie, aangesien hulle van stand tot stand sal verander afhangende van die omgewing.
kode styl
- Die naam van die veranderlike moet begin met die naam van die rol. Dit sal dit maklik maak om in die toekoms uit te vind watter rol die veranderlike is en waarvoor dit verantwoordelik is.
- Wanneer jy veranderlikes in rolle gebruik, moet jy seker wees om die beginsel van inkapseling te volg en veranderlikes te gebruik wat óf in die rol self óf in die rolle waarvan die huidige een afhang, gedefinieer word.
-
Vermy die gebruik van woordeboeke vir veranderlikes. Ansible laat jou nie toe om individuele waardes gerieflik in 'n woordeboek te ignoreer nie.
'n Voorbeeld van 'n slegte veranderlike:
myrole_user: login: admin password: adminHier is login die mediaan veranderlike, en wagwoord is die afhanklike veranderlike. Maar
aangesien hulle in 'n woordeboek gekombineer is, sal jy dit volledig moet spesifiseer
Altyd. Wat baie ongerieflik is. Beter so:myrole_user_login: admin myrole_user_password: admin
Veranderlikes in ontplooiing speelboeke
Wanneer ons 'n ontplooiingsspeelboek saamstel (hierna na verwys as 'n speelboek), hou ons by die reël dat dit in 'n aparte bewaarplek geplaas moet word. Net soos rolle: elkeen in sy eie git-bewaarplek. Dit laat jou toe om te besef dat die rolle en die speelboek verskillende onafhanklike voorwerpe van die ontplooiingstelsel is, en veranderinge in een voorwerp behoort nie die werking van die ander te beïnvloed nie. Dit word bereik deur die verstekwaardes van die veranderlikes te verander.
Wanneer 'n speelboek saamgestel word, om op te som, is dit moontlik om die verstekwaardes van rolveranderlikes op twee plekke te ignoreer: in speelboekveranderlikes en in voorraadveranderlikes.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Die verskil is dat speelboekveranderlikes altyd gebruik word wanneer speelboeke wat op dieselfde vlak daarmee geleë is, genoem word. Dit beteken dat hierdie veranderlikes ideaal is om die verstekwaardes van veranderlikes wat nie van die omgewing afhang nie, te verander. Omgekeerd sal voorraadveranderlikes slegs vir 'n spesifieke omgewing gebruik word, wat ideaal is vir omgewingspesifieke veranderlikes.
Dit is belangrik om daarop te let dat veranderlike voorrang jou nie sal toelaat om veranderlikes eers in speelboekveranderlikes en dan afsonderlik in dieselfde voorraad te herdefinieer nie.
Dit beteken dat jy reeds op hierdie stadium moet besluit of die veranderlike omgewingsafhanklik is of nie en dit op die regte plek moet plaas.
Byvoorbeeld, in een projek was die veranderlike verantwoordelik vir die aktivering van SSL vir 'n lang tyd omgewingsafhanklik, aangesien ons nie SSL kon aktiveer om redes buite ons beheer by een van die erwe nie. Nadat ons hierdie probleem opgelos het, het dit medium onafhanklik geword en na speelboekveranderlikes oorgeskuif.
Eiendomsveranderlikes vir groepe
Kom ons brei ons model in Figuur 1 uit deur 2 groepe bedieners by te voeg met 'n ander Java-toepassing, maar met verskillende instellings.
Stel jou voor hoe die speelboek in hierdie geval sal lyk:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authOns het drie groepe in die speelboek, so dit word aanbeveel om soveel groeplêers in group_vars-voorraadveranderlikes en speelboekveranderlikes gelyktydig te skep. Een groeplêer in hierdie geval is die beskrywing van een komponent van jou toepassing in die speelboek. Wanneer jy die groeplêer in die speelboekveranderlikes oopmaak, sien jy dadelik al die verskille van die verstekgedrag van die rolle wat aan die groep toegeken is. In voorraadveranderlikes: verskille in groepgedrag van stand tot stand.
kode styl
- Probeer om glad nie host_vars veranderlikes te gebruik nie, aangesien dit nie die stelsel beskryf nie, maar slegs 'n spesiale geval, wat op die lang termyn tot vrae sal lei: "Hoekom is hierdie gasheer anders as die res?", Die antwoord waarop is nie altyd maklik om te vind nie.
Koppel veranderlikes
Dit gaan egter oor eiendomsveranderlikes, maar wat van skakelveranderlikes?
Hulle verskil is dat hulle dieselfde waarde in verskillende groepe moet hê.
Aan die begin was daar gebruik 'n monsteragtige konstruksie van die vorm:
hostvars[groups['bbauth'][0]]['auth_bind_port'], maar dit is dadelik laat vaar
want dit het gebreke. Eerstens die omvangrykheid. Tweedens, afhanklikheid van 'n spesifieke gasheer in die groep. Derdens is dit nodig om feite van alle gashere in te samel voordat die ontplooiing begin word, as ons nie 'n ongedefinieerde veranderlike fout wil kry nie.
As gevolg hiervan is besluit om skakelveranderlikes te gebruik.
Koppel veranderlikes is veranderlikes wat aan die speelboek behoort en wat nodig is om stelselvoorwerpe te koppel.
Skakelveranderlikes word in algemene stelselveranderlikes gevul group_vars/all/vars en word gevorm deur alle luisteraarveranderlikes uit elke groep te verwyder, en die naam van die groep waaruit die luisteraar verwyder is by die begin van die veranderlike by te voeg.
So word die eenvormigheid en nie-kruising van name verseker.
Kom ons probeer veranderlikes uit die voorbeeld hierbo bind:
Stel jou voor dat ons veranderlikes het wat van mekaar afhanklik is:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Kom ons plaas dit in algemene veranderlikes group_vars/all/vars alle luisteraars, en voeg die naam van die groep by die naam:
# 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 }}"Nou, deur die waarde van die verbinding te verander, sal ons seker wees dat die versoek na dieselfde plek sal gaan waar die poort geleë is.
kode styl
- Aangesien rolle en groepe verskillende voorwerpe in die stelsel is, moet jy verskillende name daarvoor hê, dan sal die skakelveranderlikes akkuraat wys dat hulle aan 'n spesifieke groep bedieners behoort, en nie aan 'n rol in die stelsel nie.
Omgewingslêers
Rolle kan lêers gebruik wat van omgewing tot omgewing verskil.
SSL-sertifikate is 'n voorbeeld van sulke lêers. Stoor dit as teks
in 'n veranderlike is nie baie gerieflik nie. Maar dit is gerieflik om die pad na hulle binne 'n veranderlike te stoor.
Ons gebruik byvoorbeeld die veranderlike api_ssl_key_file: "/path/to/file".
Aangesien dit duidelik is dat die sleutelsertifikaat van omgewing tot omgewing sal verander, is dit 'n omgewingsafhanklike veranderlike, wat beteken dat dit in die lêer geleë moet wees
group_vars/myapi/vars inventaris van veranderlikes, en bevat die waarde 'byvoorbeeld'.
Die gerieflikste manier in hierdie geval is om die sleutellêer in die speelboekbewaarplek langs die pad te plaas
files/prod/certs/myapi.key, dan sal die waarde van die veranderlike wees:
api_ssl_key_file: "prod/certs/myapi.key". Die gerief lê daarin dat die mense wat verantwoordelik is vir die implementering van die stelsel op 'n spesifieke staanplek ook hul eie toegewyde plek in die bewaarplek het om hul lêers te stoor. Terselfdertyd bly dit moontlik om die absolute pad na die sertifikaat op die bediener te spesifiseer, ingeval die sertifikate deur 'n ander stelsel verskaf word.
Veelvuldige staanplekke in een omgewing
Dikwels is daar 'n behoefte om verskeie byna identiese erwe in dieselfde omgewing te ontplooi met minimale verskille. In hierdie geval verdeel ons omgewingsafhanklike veranderlikes in dié wat nie binne hierdie omgewing verander nie en dié wat wel verander. En ons neem laasgenoemde direk in die voorraadlêers self uit. Na hierdie manipulasie word dit moontlik om 'n ander voorraad direk in die omgewingsgids te skep.
Dit sal die group_vars-voorraad hergebruik en ook in staat wees om sommige veranderlikes direk vir homself te herdefinieer.
Die finale gidsstruktuur vir die ontplooiingsprojek:
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 в среде testOpsomming
Nadat die veranderlikes in ooreenstemming met die artikel georganiseer is: elke lêer met veranderlikes is verantwoordelik vir 'n spesifieke taak. En aangesien die lêer sekere take het, het dit moontlik geword om 'n persoon aan te wys wat verantwoordelik is vir die korrektheid van elke lêer. Byvoorbeeld, die ontwikkelaar van die stelselontplooiing word verantwoordelik vir die korrekte invul van die speelboekveranderlikes, terwyl die administrateur, wie se stand in die inventaris beskryf word, direk verantwoordelik is vir die invul van die inventaris van veranderlikes.
Rolle het 'n selfstandige ontwikkelingseenheid met hul eie koppelvlak geword, wat die rolontwikkelaar in staat gestel het om kenmerke te ontwikkel eerder as om die rol aan te pas om by die stelsel te pas. Hierdie kwessie was veral waar vir algemene rolle vir alle stelsels in 'n veldtog.
Stelseladministrateurs hoef nie meer ontplooiingskode te verstaan nie. Al wat van hulle vereis word vir 'n suksesvolle ontplooiing, is om die lêers van omgewingsveranderlikes in te vul.
Letterkunde
Skrywer
Kalyuzhny Denis Alexandrovich
Bron: will.com