ansible devops -koodityyli
Hei! Nimeni on Työskentelen insinöörinä kehitysprosessien automaatioosastolla. Joka päivä uusia sovellusversioita otetaan käyttöön sadoille kampanjapalvelimille. Ja tässä artikkelissa jaan kokemukseni Ansiblen käytöstä näihin tarkoituksiin.
Tämä opas tarjoaa tavan järjestää muuttujat käyttöönotossa. Tämä opas on tarkoitettu niille, jotka jo käyttävät rooleja leikkikirjoissaan ja lukevat mutta kohtaa samankaltaisia ongelmia:
- Kun koodista on löydetty muuttuja, on mahdotonta ymmärtää heti, mistä se on vastuussa;
- Rooleja on useita, ja muuttujat on liitettävä yhteen arvoon, mutta se ei toimi.
- Sinun on vaikea selittää muille, kuinka pelikirjojen muuttujien logiikka toimii
Kohtasimme näitä ongelmia yrityksemme projekteissa, minkä seurauksena pääsimme pelikirjojen muuttujien muotoilun sääntöihin, jotka jossain määrin ratkaisivat nämä ongelmat.
Muuttujat rooleissa
Rooli on erillinen käyttöönottojärjestelmäobjekti. Kuten missä tahansa järjestelmän objektissa, sillä on oltava käyttöliittymä vuorovaikutusta varten muun järjestelmän kanssa. Roolimuuttujat ovat tällainen käyttöliittymä.
Otetaan esimerkiksi rooli api, joka asentaa Java-sovelluksen palvelimelle. Mitä muuttujia siinä on?
Roolimuuttujat voidaan jakaa kahteen tyyppiin tyypin mukaan:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Muuttuvat ominaisuudet ovat muuttujia, jotka määrittelevät roolin käyttäytymisen.
Kyselymuuttujat ovat muuttujia, joiden arvoa käytetään roolin ulkopuolisten resurssien osoittamiseen.
Vaihtelevat kuuntelijat ovat muuttujia, joiden arvoa käytetään kyselymuuttujien muodostamiseen.
Toisaalta 1a, 2a, 2b ovat muuttujia, jotka eivät riipu ympäristöstä (rauta, ulkoiset resurssit jne.) ja jotka voidaan täyttää oletusarvoilla oletusroolissa. Muuttujia, kuten 1.b ja 2.c, ei kuitenkaan voida täyttää muilla arvoilla kuin 'esimerkki', koska ne vaihtelevat jalustasta riippuen ympäristöstä.
koodi tyyli
- Muuttujan nimen tulee alkaa roolin nimellä. Näin on tulevaisuudessa helppo selvittää, mistä roolista muuttuja on ja mistä se vastaa.
- Käyttäessäsi muuttujia rooleissa tulee muistaa noudattaa kapseloinnin periaatetta ja käyttää muuttujia, jotka on määritelty joko itse roolissa tai niissä rooleissa, joista nykyinen riippuu.
-
Vältä käyttämästä muuttujia sanakirjoja. Ansible ei salli sinun ohittaa kätevästi yksittäisiä arvoja sanakirjassa.
Esimerkki huonosta muuttujasta:
myrole_user: login: admin password: adminTässä sisäänkirjautuminen on mediaanimuuttuja ja salasana on riippuvainen muuttuja. Mutta
koska ne on yhdistetty sanakirjaksi, sinun on määritettävä se kokonaan
Aina. Mikä on erittäin epämukavaa. Parempi näin:myrole_user_login: admin myrole_user_password: admin
Muuttujat käyttöönoton ohjekirjoissa
Käyttöönottoohjekirjaa (jäljempänä playbook) laadittaessa noudatamme sääntöä, että se tulee sijoittaa erilliseen arkistoon. Aivan kuten roolit: jokainen omassa git-varastossaan. Tämän avulla voit ymmärtää, että roolit ja pelikirja ovat erilaisia käyttöönottojärjestelmän itsenäisiä objekteja, ja yhden objektin muutosten ei pitäisi vaikuttaa toisen toimintaan. Tämä saavutetaan muuttamalla muuttujien oletusarvoja.
Pelikirjaa kootessa, yhteenvetona, on mahdollista ohittaa roolimuuttujien oletusarvot kahdessa paikassa: pelikirjan muuttujissa ja varastomuuttujissa.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Erona on, että pelikirjamuuttujia käytetään aina, kun kutsutaan sen kanssa samalla tasolla olevia pelikirjoja. Tämä tarkoittaa, että nämä muuttujat sopivat erinomaisesti ympäristöstä riippumattomien muuttujien oletusarvojen muuttamiseksi. Toisaalta varastomuuttujia käytetään vain tietyssä ympäristössä, mikä on ihanteellinen ympäristökohtaisille muuttujille.
On tärkeää huomata, että muuttujien ensisijaisuus ei salli muuttujien uudelleenmäärittelyä ensin pelikirjan muuttujissa ja sitten erikseen samassa luettelossa.
Tämä tarkoittaa, että jo tässä vaiheessa on päätettävä, onko muuttuja ympäristöriippuvainen vai ei ja sijoitettava se oikeaan paikkaan.
Esimerkiksi yhdessä projektissa SSL:n käyttöönotosta vastaava muuttuja oli pitkään ympäristöriippuvainen, koska emme voineet ottaa SSL:ää käyttöön meistä riippumattomista syistä yhdellä osastolla. Kun korjasimme tämän ongelman, siitä tuli keskitasoa riippumaton ja se siirtyi pelikirjan muuttujiin.
Ominaisuusmuuttujat ryhmille
Laajennamme kuvan 1 malliamme lisäämällä 2 palvelinryhmää, joissa on eri Java-sovellus, mutta eri asetuksilla.
Kuvittele, miltä pelikirja näyttää tässä tapauksessa:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authMeillä on ohjekirjassa kolme ryhmää, joten on suositeltavaa luoda yhtä monta ryhmätiedostoa group_vars-varastomuuttujiin ja pelikirjan muuttujiin kerralla. Yksi ryhmätiedosto on tässä tapauksessa kuvaus sovelluksesi yhdestä komponentista ohjekirjassa. Kun avaat ryhmätiedoston pelikirjan muuttujissa, näet välittömästi kaikki erot ryhmälle määritettyjen roolien oletuskäyttäytymisestä. Varastomuuttujissa: erot ryhmien käyttäytymisessä osastoittain.
Koodityyli
- Yritä olla käyttämättä host_vars-muuttujia ollenkaan, koska ne eivät kuvaa järjestelmää, vaan vain erikoistapausta, joka johtaa pitkällä aikavälillä kysymyksiin: "Miksi tämä isäntä on erilainen kuin muut?", johon vastaus on ei ole aina helppo löytää.
Linkitä muuttujat
Kyse on kuitenkin ominaisuusmuuttujista, mutta entä linkkimuuttujat?
Niiden ero on, että niillä on oltava sama arvo eri ryhmissä.
Alussa oli käytä hirvittävää muodon rakennetta:
hostvars[groups['bbauth'][0]]['auth_bind_port'], mutta se hylättiin välittömästi
koska siinä on puutteita. Ensinnäkin tilavuus. Toiseksi, riippuvuus tietystä isännästä ryhmässä. Kolmanneksi on tarpeen kerätä faktat kaikilta isänniltä ennen käyttöönoton aloittamista, jos emme halua saada määrittelemätöntä muuttujavirhettä.
Tämän seurauksena päätettiin käyttää linkkimuuttujia.
Linkitä muuttujat ovat muuttujia, jotka kuuluvat pelikirjaan ja joita tarvitaan järjestelmäobjektien linkittämiseen.
Linkkimuuttujat täytetään yleisissä järjestelmämuuttujissa group_vars/all/vars ja muodostetaan poistamalla kaikki kuuntelijamuuttujat kustakin ryhmästä ja lisäämällä sen ryhmän nimi, josta kuuntelija poistettiin, muuttujan alkuun.
Näin varmistetaan nimien yhtenäisyys ja ei-leikkaukset.
Yritetään sitoa muuttujat yllä olevasta esimerkistä:
Kuvittele, että meillä on muuttujia, jotka riippuvat toisistaan:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Laitetaan se yhteisiin muuttujiin group_vars/all/vars kaikki kuuntelijat ja lisää ryhmän nimi nimeen:
# 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 }}"Nyt muuttamalla liittimen arvoa varmistamme, että pyyntö menee samaan porttiin.
Koodityyli
- Koska roolit ja ryhmät ovat eri järjestelmäobjekteja, niillä on oltava eri nimet, jotta linkkimuuttujat osoittavat tarkasti, että ne kuuluvat tiettyyn palvelinryhmään, eivät järjestelmän rooliin.
Ympäristötiedostot
Roolit voivat käyttää tiedostoja, jotka vaihtelevat ympäristöstä toiseen.
SSL-sertifikaatit ovat esimerkki tällaisista tiedostoista. Tallenna ne tekstinä
muuttujassa ei ole kovin kätevää. Mutta on kätevää tallentaa polku niihin muuttujan sisään.
Käytämme esimerkiksi muuttujaa api_ssl_key_file: "/path/to/file".
Koska on selvää, että avainvarmenne muuttuu ympäristöstä toiseen, tämä on ympäristöstä riippuvainen muuttuja, mikä tarkoittaa, että sen tulee sijaita tiedostossa
group_vars/myapi/vars muuttujien luettelo ja sisältävät arvon "esimerkiksi".
Kätevin tapa tässä tapauksessa on laittaa avaintiedosto playbook-arkistoon polun varrella
files/prod/certs/myapi.key, niin muuttujan arvo on:
api_ssl_key_file: "prod/certs/myapi.key". Mukavuus piilee siinä, että tietyllä osastolla järjestelmän käyttöönotosta vastaavilla henkilöillä on myös oma paikkansa arkistossa tiedostojensa tallentamista varten. Samalla on edelleen mahdollista määrittää palvelimella olevan varmenteen absoluuttinen polku, mikäli varmenteet toimitetaan toisesta järjestelmästä.
Useita telineitä yhdessä ympäristössä
Usein on tarve sijoittaa useita lähes identtisiä osastoja samaan ympäristöön minimaalisilla eroilla. Tässä tapauksessa jaamme ympäristöstä riippuvat muuttujat niihin, jotka eivät muutu tässä ympäristössä, ja niihin, jotka muuttuvat. Ja otamme jälkimmäisen suoraan itse inventaariotiedostoihin. Tämän käsittelyn jälkeen on mahdollista luoda toinen varasto suoraan ympäristöhakemistoon.
Se käyttää uudelleen group_vars-varastoa ja voi myös määrittää uudelleen joitain muuttujia suoraan itselleen.
Käyttöönottoprojektin lopullinen hakemistorakenne:
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 в среде testYhteenvetona
Kun muuttujat on järjestetty artikkelin mukaisesti: jokainen muuttujia sisältävä tiedosto vastaa tietystä tehtävästä. Ja koska tiedostolla on tiettyjä tehtäviä, tuli mahdolliseksi nimetä henkilö, joka vastaa kunkin tiedoston oikeellisuudesta. Esimerkiksi järjestelmän käyttöönoton kehittäjä on vastuussa pelikirjan muuttujien oikeasta täyttämisestä, kun taas ylläpitäjä, jonka osasto on kuvattu luettelossa, on suoraan vastuussa muuttujien luettelon täyttämisestä.
Roleista tuli itsenäinen kehitysyksikkö, jolla oli oma käyttöliittymä, jolloin roolin kehittäjä voi kehittää ominaisuuksia sen sijaan, että räätälöiisi roolia järjestelmään sopivaksi. Tämä ongelma koski erityisesti yhteisiä rooleja kaikissa kampanjan järjestelmissä.
Järjestelmänvalvojien ei enää tarvitse ymmärtää käyttöönottokoodia. Ainoa mitä heiltä vaaditaan onnistuneen käyttöönoton kannalta, on täyttää ympäristömuuttujien tiedostot.
Kirjallisuus
Kirjoittaja
Kaljužni Denis Aleksandrovitš
Lähde: will.com