ansible devops kodstilo
Hej! Mia nomo estas Mi laboras kiel inĝeniero en la fako pri aŭtomatiga procezo de disvolviĝo. Ĉiutage, novaj aplikaĵkonstruaĵoj estas lanĉitaj al centoj da kampanjaj serviloj. Kaj en ĉi tiu artikolo, mi dividas mian sperton uzi Ansible por ĉi tiuj celoj.
Ĉi tiu gvidilo ofertas manieron organizi variablojn en deplojo. Ĉi tiu gvidilo estas desegnita por tiuj, kiuj jam uzas rolojn en siaj ludlibroj kaj legas sed renkontas similajn problemojn:
- Trovinte variablon en la kodo, estas neeble tuj kompreni, pri kio ĝi respondecas;
- Estas pluraj roloj, kaj la variabloj devas esti asociitaj kun unu valoro, sed ĝi ne funkcias;
- Havante malfacilecon klarigi al aliaj kiel funkcias la logiko de la variabloj en viaj ludlibroj
Ni renkontis ĉi tiujn problemojn pri projektoj en nia kompanio, rezulte de kiuj ni venis al la reguloj por formatado de variabloj en niaj ludlibroj, kiuj iagrade solvis ĉi tiujn problemojn.
Variabloj en roloj
Rolo estas aparta Deploja Sistemo-Objekto. Kiel ĉiu objekto de la sistemo, ĝi devas havi interfacon por interagi kun la resto de la sistemo. Rolvariabloj estas tia interfaco.
Prenu, ekzemple, la rolon api, kiu instalas Java-aplikaĵon sur la servilo. Kiajn variablojn ĝi havas?
Rolvariabloj povas esti dividitaj en 2 tipojn laŭ tipo:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Variaj propraĵoj estas variabloj kiuj difinas la konduton de rolo.
Demandaj Variabloj estas variabloj, kies valoro estas uzata por indiki resursojn eksterajn al la rolo.
Variaj Aŭskultantoj estas variabloj, kies valoro estas uzata por formi demandajn variablojn.
Aliflanke, 1a, 2a, 2b estas variabloj, kiuj ne dependas de la medio (fero, eksteraj rimedoj, ktp.) kaj povas esti plenigitaj per defaŭltaj valoroj en la defaŭlta rolo. Tamen, variabloj kiel 1.b kaj 2.c ne povas esti plenigitaj per valoroj krom "ekzemplo", ĉar ili ŝanĝiĝos de stando al stando depende de la medio.
kodstilo
- La nomo de la variablo devas komenciĝi per la nomo de la rolo. Ĉi tio faciligos estonte ekscii, de kiu rolo estas la variablo kaj pri kio ĝi respondecas.
- Kiam vi uzas variablojn en roloj, vi devas esti certa sekvi la principon de enkapsuligo kaj uzi variablojn difinitajn aŭ en la rolo mem aŭ en la roloj de kiuj dependas la nuna.
-
Evitu uzi vortarojn por variabloj. Ansible ne permesas vin komforte superregi individuajn valorojn en vortaro.
Ekzemplo de malbona variablo:
myrole_user: login: admin password: adminĈi tie, ensaluto estas la meza variablo, kaj pasvorto estas la dependa variablo. Sed
ĉar ili estas kombinitaj en vortaron, vi devos specifi ĝin tute
Ĉiam. Kio estas tre maloportuna. Pli bone tiamaniere:myrole_user_login: admin myrole_user_password: admin
Variabloj en deplojludlibroj
Dum kompilado de deploja ludlibro (ĉi-poste nomata ludlibro), ni aliĝas al la regulo, ke ĝi estu metita en apartan deponejon. Same kiel roloj: ĉiu en sia propra git-deponejo. Ĉi tio permesas al vi rimarki, ke la roloj kaj la ludlibro estas malsamaj sendependaj objektoj de la deplojsistemo, kaj ŝanĝoj en unu objekto ne devus influi la funkciadon de la alia. Ĉi tio estas atingita ŝanĝante la defaŭltajn valorojn de la variabloj.
Kompilante ludlibron, por resumi, eblas superregi la defaŭltajn valorojn de rolvariabloj en du lokoj: en ludlibro-variabloj kaj en inventarvariabloj.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
La diferenco estas, ke ludlibrovariabloj ĉiam estas uzataj kiam oni vokas ludlibrojn situantajn samnivele kun ĝi. Ĉi tio signifas, ke ĉi tiuj variabloj estas bonegaj por ŝanĝi la defaŭltajn valorojn de variabloj, kiuj ne dependas de la medio. Male, stokregistraj variabloj nur estos uzataj por aparta medio, kiu estas ideala por medio-specifaj variabloj.
Gravas noti, ke varia prioritato ne permesos vin redifini variablojn unue en ludlibrovariabloj kaj poste aparte en la sama inventaro.
Ĉi tio signifas, ke jam en ĉi tiu etapo vi devas decidi ĉu la variablo dependas de la medio aŭ ne kaj meti ĝin en la ĝustan lokon.
Ekzemple, en unu projekto, la variablo respondeca por ebligi SSL longe dependis de la medio, ĉar ni ne povis ebligi SSL pro kialoj ekster nia kontrolo ĉe unu el la standoj. Post kiam ni riparis ĉi tiun problemon, ĝi fariĝis meze sendependa kaj moviĝis al ludlibro-variabloj.
Propraj Variabloj por Grupoj
Ni vastigu nian modelon en Figuro 1 aldonante 2 grupojn de serviloj kun malsama Java-apliko, sed kun malsamaj agordoj.
Imagu kiel aspektos la ludlibro en ĉi tiu kazo:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authNi havas tri grupojn en la ludlibro, do rekomendas krei tiom da grupdosieroj en group_vars-inventaro variabloj kaj ludlibro variabloj samtempe. Unu grupdosiero ĉi-kaze estas la priskribo de unu komponanto de via aplikaĵo en la ludlibro. Kiam vi malfermas la grupan dosieron en la ludlibro-variabloj, vi tuj vidas ĉiujn diferencojn de la defaŭlta konduto de la roloj asignitaj al la grupo. En stokregistraj variabloj: diferencoj en grupkonduto de budo al budo.
kodstilo
- Provu tute ne uzi host_vars-variablojn, ĉar ili ne priskribas la sistemon, sed nur specialan kazon, kiu longtempe kondukos al demandoj: "Kial ĉi tiu gastiganto diferencas de la ceteraj?", La respondo al kiu estas ne ĉiam facile trovebla.
Ligi variabloj
Tamen, temas pri proprietaj variabloj, sed kio pri ligaj variabloj?
Ilia diferenco estas, ke ili devas havi la saman valoron en malsamaj grupoj.
Komence estis uzu monstran konstruon de la formo:
hostvars[groups['bbauth'][0]]['auth_bind_port'], sed ĝi tuj estis forlasita
ĉar ĝi havas mankojn. Unue, la dikeco. Due, dependeco de specifa gastiganto en la grupo. Trie, necesas kolekti faktojn de ĉiuj gastigantoj antaŭ ol komenci la deplojon, se ni ne volas ricevi nedifinitan varian eraron.
Kiel rezulto, oni decidis uzi ligajn variablojn.
Ligi variabloj estas variabloj kiuj apartenas al la ludlibro kaj estas bezonataj por ligi sistemajn objektojn.
Ligvariabloj estas popolitaj en ĝeneralaj sistemvariabloj group_vars/all/vars kaj estas formitaj forigante ĉiujn aŭskultantajn variablojn de ĉiu grupo, kaj aldonante la nomon de la grupo de kiu la aŭskultanto estis forigita al la komenco de la variablo.
Tiel, la unuformeco kaj ne-intersekco de nomoj estas certigitaj.
Ni provu ligi variablojn de la supra ekzemplo:
Imagu, ke ni havas variablojn kiuj dependas unu de la alia:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Ni metu ĝin en komunajn variablojn group_vars/all/vars ĉiuj aŭskultantoj, kaj aldonu la nomon de la grupo al la nomo:
# 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 }}"Nun, ŝanĝante la valoron de la konektilo, ni estos certaj, ke la peto iros al la sama haveno.
kodstilo
- Ĉar roloj kaj grupoj estas malsamaj sistemaj objektoj, ili devas havi malsamajn nomojn por ke la ligaj variabloj precize montros, ke ili apartenas al specifa servila grupo, kaj ne al rolo en la sistemo.
Medio dosieroj
Roloj povas uzi dosierojn kiuj diferencas de medio al medio.
SSL-atestiloj estas ekzemplo de tiaj dosieroj. Konservu ilin kiel tekston
en variablo ne estas tre oportuna. Sed estas oportune konservi la vojon al ili ene de variablo.
Ekzemple, ni uzas la variablon api_ssl_key_file: "/path/to/file".
Ĉar estas evidente, ke la ŝlosila atestilo ŝanĝiĝos de medio al medio, ĉi tio estas medio-dependa variablo, kio signifas, ke ĝi devas esti lokita en la dosiero.
group_vars/myapi/vars inventaro de variabloj, kaj enhavas la valoron 'ekzemple'.
La plej oportuna maniero en ĉi tiu kazo estas meti la ŝlosilan dosieron en la ludlibron laŭ la vojo
files/prod/certs/myapi.key, tiam la valoro de la variablo estos:
api_ssl_key_file: "prod/certs/myapi.key". La oportuno kuŝas en la fakto, ke la homoj respondecaj pri deplojado de la sistemo sur aparta stando ankaŭ havas sian propran dediĉitan lokon en la deponejo por stoki siajn dosierojn. Samtempe, restas eble specifi la absolutan vojon al la atestilo sur la servilo, se la atestiloj estas liveritaj de alia sistemo.
Multoblaj standoj en unu medio
Ofte necesas disfaldi plurajn preskaŭ identajn standojn en la sama medio kun minimumaj diferencoj. En ĉi tiu kazo, ni dividas medio-dependajn variablojn en tiujn kiuj ne ŝanĝiĝas ene de ĉi tiu medio kaj tiujn kiuj faras. Kaj ni elprenas ĉi-lastan rekte en la inventarajn dosierojn mem. Post ĉi tiu manipulado, iĝas eble krei alian inventaron rekte en la medio-dosierujo.
Ĝi reuzos la inventaron group_vars kaj ankaŭ povos redifini iujn variablojn rekte por si.
La fina adresarostrukturo por la deploja projekto:
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 в среде testResumante
Post organizado de la variabloj laŭ la artikolo: ĉiu dosiero kun variabloj respondecas pri specifa tasko. Kaj ĉar la dosiero havas certajn taskojn, eblis atribui personon respondecan pri la ĝusteco de ĉiu dosiero. Ekzemple, la programisto de la sistema deplojo iĝas respondeca pri la ĝusta plenigo de la ludlibro-variabloj, dum la administranto, kies stando estas priskribita en la inventaro, estas rekte respondeca pri plenigo de la inventaro de variabloj.
Roloj iĝis memstara evoluunuo kun sia propra interfaco, permesante al la rolellaboranto evoluigi ecojn prefere ol tajlado de la rolo por konveni la sistemon. Ĉi tiu afero estis precipe vera por oftaj roloj por ĉiuj sistemoj en kampanjo.
Sistemadministrantoj ne plu bezonas kompreni deplojan kodon. Ĉio, kio estas postulata de ili por sukcesa deplojo, estas plenigi la dosierojn de mediaj variabloj.
Literaturo
aŭtoro
Kalyuzhny Denis Aleksandroviĉ
fonto: www.habr.com