ansible devops codestyle
Aupa! Nire izena da Garapen prozesuen automatizazio sailean ingeniari gisa lan egiten dut. Egunero, aplikazioen eraikuntza berriak kanpainaren ehunka zerbitzaritara zabaltzen dira. Eta artikulu honetan, Ansible helburu hauetarako erabiltzearen esperientzia partekatzen dut.
Gida honek inplementazio batean aldagaiak antolatzeko modua eskaintzen du. Gida hau jolas-liburuetan rolak erabiltzen eta irakurtzen dituztenentzat diseinatuta dago baina antzeko arazoekin topo egitea:
- Kodean aldagai bat aurkituta, ezinezkoa da berehala ulertzea zertaz arduratzen den;
- Hainbat rol daude, eta aldagaiak balio batekin lotu behar dira, baina ez du funtzionatzen;
- Zailtasunak izatea besteei zure liburuko aldagaien logikak nola funtzionatzen duen azaltzeko
Arazo hauek gure enpresan proiektuetan topatu genituen, eta horren ondorioz gure liburuko aldagaiak formateatzeko arauetara iritsi ginen, eta neurri batean arazo hauek konpondu zituzten.
Roletan aldagaiak
Rol bat inplementazio-sistemaren objektu bereizia da. Sistemaren edozein objektu bezala, gainerako sistemarekin elkarreragiteko interfaze bat izan behar du. Rol-aldagaiak halako interfaze bat dira.
Hartu, adibidez, rola api, zerbitzarian Java aplikazio bat instalatzen duena. Zein aldagai ditu?
Rol-aldagaiak 2 motatan bana daitezke motaren arabera:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Propietate aldakorrak rol baten portaera definitzen duten aldagaiak dira.
Kontsulta aldagaiak rolaren kanpoko baliabideak izendatzeko balio duten aldagaiak dira.
Entzule aldakorrak kontsulta-aldagaiak osatzeko balio duten aldagaiak dira.
Bestalde, 1a, 2a, 2b ingurunearen araberakoak ez diren aldagaiak dira (burdina, kanpoko baliabideak, etab.) eta balio lehenetsiekin bete daitezke lehenetsitako roletan. Hala ere, 1.b eta 2.c bezalako aldagaiak ezin dira "adibidea" ez den balioekin bete, ingurunearen arabera stand batetik bestera aldatuko baitira.
kode estiloa
- Aldagaiaren izena rolaren izenetik hasi behar da. Horri esker, etorkizunean erraza izango da aldagaia zein rol zein den eta zein ardura duen.
- Roletan aldagaiak erabiltzean, enkapsulazio-printzipioa jarraitzen duzula ziurtatu behar duzu eta rolan bertan edo egungoaren menpe dagoen roletan definitutako aldagaiak erabili behar dituzu.
-
Saihestu aldagaietarako hiztegiak erabiltzea. Ansiblek ez dizu aukera ematen hiztegi batean balio indibidualak modu egokian gainidazteko.
Aldagai txar baten adibidea:
myrole_user: login: admin password: adminHemen, saioa hasteko aldagai mediana da, eta pasahitza menpeko aldagaia. Baina
hiztegi batean batzen direnez, osorik zehaztu beharko duzu
Beti. Oso deserosoa dena. Hobe horrela:myrole_user_login: admin myrole_user_password: admin
Inplementazio-liburuetako aldagaiak
Inplementazio-liburua (aurrerantzean, jolas-liburua) osatzerakoan, biltegi bereizi batean jarri behar den araua betetzen dugu. Rolak bezala: bakoitza bere git biltegian. Horri esker, konturatzen zara rolak eta playbook-a hedapen-sistemaren objektu independente desberdinak direla, eta objektu baten aldaketek ez lukete bestearen funtzionamenduan eragin behar. Hau aldagaien balio lehenetsiak aldatuz lortzen da.
Jokalari bat osatzerakoan, laburbiltzeko, rol-aldagaien balio lehenetsiak bi lekutan gainidaztea posible da: playbook-en aldagaietan eta inbentario-aldagaietan.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Aldea da jolas-liburuko aldagaiak beti erabiltzen direla beraren maila berean dauden playbook-ak deitzean. Horrek esan nahi du aldagai hauek ingurunearen araberakoak ez diren aldagaien balio lehenetsiak aldatzeko bikainak direla. Aitzitik, inbentario-aldagaiak ingurune jakin baterako bakarrik erabiliko dira, hau da, inguruneko aldagai zehatzetarako aproposa.
Garrantzitsua da kontuan izan aldagaien lehentasunak ez duela aukera emango aldagaiak lehenik playbook aldagaietan eta ondoren bereizita inbentario berean.
Horrek esan nahi du fase honetan jada aldagaia ingurunearen menpe dagoen edo ez erabaki behar duzula eta leku egokian kokatu.
Adibidez, proiektu batean, SSL gaitzeaz arduratzen den aldagaia ingurunearen menpe egon zen denbora luzez, ezin izan baikenuen SSL gaitu stand batean gure esku ez dauden arrazoiengatik. Arazo hau konpondu ondoren, ertain independente bihurtu zen eta playbook aldagaietara pasatu zen.
Taldeentzako propietate-aldagaiak
Zabal ditzagun gure eredua 1. irudian, Java aplikazio ezberdin batekin 2 zerbitzari talde gehituz, baina ezarpen ezberdinekin.
Imajinatu nolakoa izango den playbook kasu honetan:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authJokalari liburuan hiru talde ditugu, beraz, talde_vars inbentario-aldagaietan eta playbook-en aldagaietan aldi berean talde-fitxategi asko sortzea gomendatzen da. Kasu honetan, talde-fitxategi bat zure aplikazioaren osagai baten deskribapena da playbook-ean. Jolas-liburuko aldagaietan taldeko fitxategia irekitzen duzunean, berehala ikusiko dituzu taldeari esleitutako rolen portaera lehenetsiarekiko desberdintasun guztiak. Inbentario-aldagaietan: taldeen portaeran dauden aldeak txosna batetik bestera.
kode estiloa
- Saiatu host_vars aldagaiak batere ez erabiltzen, ez baitute sistema deskribatzen, kasu berezi bat baizik, epe luzera galderak sortuko dituena: "Zergatik da ezberdina ostalari hau gainerakoetatik?", horren erantzuna da. ez da beti erraza aurkitzea.
Lotura aldagaiak
Hala ere, jabetza-aldagaiei buruzkoa da, baina zer gertatzen da lotura-aldagaiekin?
Beraien aldea da talde ezberdinetan balio bera izan behar dutela.
Hasieran zegoen erabili formako eraikuntza ikaragarri bat:
hostvars[groups['bbauth'][0]]['auth_bind_port'], baina berehala abandonatu zuten
akatsak dituelako. Lehenik eta behin, handitasuna. Bigarrenik, taldeko ostalari zehatz baten menpekotasuna. Hirugarrenik, beharrezkoa da ostalari guztien datuak biltzea hedapena hasi aurretik, ez badugu zehaztu gabeko aldagai-errorerik lortu nahi.
Ondorioz, lotura-aldagaiak erabiltzea erabaki zen.
Lotura aldagaiak playbookari dagozkion eta sistemako objektuak lotzeko beharrezkoak diren aldagaiak dira.
Esteka-aldagaiak sistema-aldagai orokorretan biltzen dira group_vars/all/vars eta talde bakoitzeko entzule-aldagai guztiak kenduz eta entzulea kendu den taldearen izena aldagaiaren hasieran gehituz osatzen dira.
Horrela, izenen uniformetasuna eta elkargurutzerik eza bermatzen da.
Saia gaitezen goiko adibideko aldagaiak lotzen:
Imajinatu bata bestearen menpe dauden aldagaiak ditugula:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Jar dezagun aldagai komunetan group_vars/all/vars entzule guztiak, eta gehitu taldearen izena izenari:
# 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 }}"Orain, konektorearen balioa aldatuz gero, eskaera ataka berera joango dela ziurtatuko dugu.
kode estiloa
- Rolak eta taldeak sisteman objektu desberdinak direnez, izen desberdinak izan behar dituzu haientzat, orduan esteka-aldagaiek zerbitzari talde zehatz batekoak direla zehatz-mehatz erakutsiko dute, eta ez sistemako rol batekoak.
Inguruneko fitxategiak
Rolak ingurune batetik bestera desberdinak diren fitxategiak erabil ditzakete.
SSL ziurtagiriak fitxategi horien adibide dira. Gorde itzazu testu gisa
aldagai batean ez da oso erosoa. Baina komenigarria da haietarako bidea aldagai baten barruan gordetzea.
Adibidez, aldagaia erabiltzen dugu api_ssl_key_file: "/path/to/file".
Argi dagoenez gako-ziurtagiria ingurune batetik bestera aldatuko dela, hau ingurunearen menpeko aldagaia da, hau da, fitxategian kokatu behar da.
group_vars/myapi/vars aldagaien inbentarioa, eta 'adibidez' balioa dauka.
Modurik erosoena kasu honetan gako-fitxategia playbook biltegian bidetik jartzea da
files/prod/certs/myapi.key, orduan aldagaiaren balioa hau izango da:
api_ssl_key_file: "prod/certs/myapi.key". Erosotasuna stand jakin batean sistema zabaltzeaz arduratzen diren pertsonek ere beren fitxategiak gordetzeko toki propioa edukitzea biltegian datza. Aldi berean, zerbitzarian ziurtagiriaren bide absolutua zehaztea posible izaten jarraitzen du, ziurtagiriak beste sistema batek ematen baditu.
Hainbat stand ingurune batean
Askotan ingurune berean hainbat stand ia berdinak ezberdintasun minimoekin zabaldu beharra dago. Kasu honetan, ingurunearen menpeko aldagaiak ingurune honen barruan aldatzen ez direnak eta aldatzen direnak bereizten ditugu. Eta azken hauek zuzenean ateratzen ditugu inbentario-fitxategietan bertan. Manipulazio honen ondoren, posible da beste inbentario bat sortzea zuzenean inguruneko direktorioa.
group_vars inbentarioa berrerabiliko du eta aldagai batzuk zuzenean berdefinitzeko gai izango da.
Hedapen-proiektuaren azken direktorio-egitura:
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 в среде testLaburbilduz
Aldagaiak artikuluaren arabera antolatu ondoren: aldagaiak dituen fitxategi bakoitza zeregin zehatz baten arduraduna da. Eta fitxategiak zeregin jakin batzuk dituenez, fitxategi bakoitzaren zuzentasunaren arduradun bat esleitzea posible egin zen. Esate baterako, sistemaren hedapenaren garatzailea playbook aldagaiak behar bezala betetzearen arduraduna bihurtzen da, eta administratzailea, inbentarioan deskribatzen den standa, aldagaien inbentarioa betetzeaz zuzenean arduratzen da.
Rolak bere interfaze propioa duen garapen-unitate autonomo bihurtu zen, rol-garatzaileari funtzioak garatzea ahalbidetzen zion rola sistemara egokitu beharrean. Arazo hau bereziki egia zen kanpaina bateko sistema guztien rol komunetarako.
Sistema-administratzaileek jada ez dute inplementazio kodea ulertu behar. Inplementazio arrakastatsu baterako eskatzen zaien guztia ingurune-aldagaien fitxategiak betetzea da.
Literatura
Egilea
Kalyuzhny Denis Alexandrovich
Iturria: www.habr.com