Kerfisnálgun á breytum í Ansible

ansible devops kóðastíl

Hæ! Ég heiti Denis Kalyuzhny Ég starfa sem verkfræðingur í sjálfvirkni þróunarferlisins. Á hverjum degi eru ný forritasmíðar sendar út á hundruð herferðaþjóna. Og í þessari grein deili ég reynslu minni af því að nota Ansible í þessum tilgangi.

Þessi handbók býður upp á leið til að skipuleggja breytur í dreifingu. Þessi handbók er hönnuð fyrir þá sem þegar nota hlutverk í leikbókum sínum og lesa Bestu starfsvenjuren lendir í svipuðum vandamálum:

• Eftir að hafa fundið breytu í kóðanum er ómögulegt að skilja strax hvað það er ábyrgt fyrir;
• Það eru nokkur hlutverk og breyturnar þurfa að vera tengdar við eitt gildi, en það virkar ekki;
• Á erfitt með að útskýra fyrir öðrum hvernig rökfræði breytanna í leikbókunum þínum virkar

Við lentum í þessum vandamálum í verkefnum í fyrirtækinu okkar, sem leiddi til þess að við komum að reglum um snið breytu í leikbókum okkar, sem leystu þessi vandamál að einhverju leyti.

Breytur í hlutverkum

Hlutverk er sérstakur dreifingarkerfishlutur. Eins og allir hlutir kerfisins verður það að hafa viðmót til að hafa samskipti við restina af kerfinu. Hlutverkabreytur eru slíkt viðmót.

Tökum sem dæmi hlutverkið api, sem setur upp Java forrit á þjóninum. Hvaða breytur hefur það?

Hlutverkabreytum má skipta í 2 gerðir eftir tegundum:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

Breytilegir eiginleikar eru breytur sem skilgreina hegðun hlutverks.

Fyrirspurnarbreytur eru breytur þar sem gildi þeirra er notað til að tilgreina auðlindir utan hlutverksins.

Breytilegir hlustendur eru breytur þar sem gildi þeirra er notað til að mynda fyrirspurnarbreytur.

Aftur á móti eru 1a, 2a, 2b breytur sem eru ekki háðar umhverfinu (járn, ytri auðlindir osfrv.) og hægt er að fylla þær með sjálfgefnum gildum í sjálfgefnu hlutverki. Hins vegar er ekki hægt að fylla breytur eins og 1.b og 2.c með öðrum gildum en 'dæmi', þar sem þær munu breytast frá standi til standi eftir umhverfinu.

kóða stíl

• Nafn breytunnar verður að byrja á nafni hlutverksins. Þetta mun gera það auðvelt að átta sig á í framtíðinni hvaða hlutverki breytan er og hverju hún ber ábyrgð á.
• Þegar þú notar breytur í hlutverkum verður þú að vera viss um að fylgja meginreglunni um encapsulation og nota breytur sem eru skilgreindar annað hvort í hlutverkinu sjálfu eða í hlutverkunum sem núverandi er háð.

• Forðastu að nota orðabækur fyrir breytur. Ansible leyfir þér ekki að hnekkja einstökum gildum á þægilegan hátt í orðabók.

  Dæmi um slæma breytu:

  myrole_user:
      login: admin
      password: admin

  Hér er innskráning miðgildi breytan og lykilorð er háða breytan. En
  þar sem þau eru sameinuð í orðabók verður þú að tilgreina hana í heild sinni
  Alltaf. Sem er mjög óþægilegt. Betra svona:

  myrole_user_login: admin
  myrole_user_password: admin

Breytur í dreifingarleikbókum

Við samantekt á dreifingarleikbók (hér eftir nefnd leikbók) höldum við reglunni um að hún skuli sett í sérstakt geymsla. Rétt eins og hlutverk: hvert í sinni git geymslu. Þetta gerir þér kleift að átta þig á því að hlutverkin og leikbókin eru ólíkir sjálfstæðir hlutir dreifingarkerfisins og breytingar á einum hlut ættu ekki að hafa áhrif á virkni hins. Þetta er náð með því að breyta sjálfgefnum gildum breytanna.

Þegar leikbók er sett saman, til að draga saman, er hægt að hnekkja sjálfgefnum gildum hlutverkabreyta á tveimur stöðum: í leikbókarbreytum og í birgðabreytum.

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - Breytur og hvelfingar

Munurinn er sá að leikbókabreytur eru alltaf notaðar þegar hringt er í leikbækur sem eru staðsettar á sama stigi með henni. Þetta þýðir að þessar breytur eru frábærar til að breyta sjálfgefnum gildum breytna sem eru ekki háðar umhverfinu. Aftur á móti verða birgðabreytur aðeins notaðar fyrir tiltekið umhverfi, sem er tilvalið fyrir umhverfissértækar breytur.

Það er mikilvægt að hafa í huga að forgang breytu mun ekki leyfa þér að endurskilgreina breytur fyrst í leikbókarbreytum og síðan sérstaklega í sömu birgðum.

Þetta þýðir að þegar á þessu stigi þarf að ákveða hvort breytan sé umhverfisháð eða ekki og setja hana á réttan stað.

Til dæmis, í einu verkefni, var breytan sem bar ábyrgð á því að virkja SSL umhverfisháð í langan tíma, þar sem við gátum ekki virkjað SSL af ástæðum sem eru óviðráðanlegar á einum básnum. Eftir að við laguðum þetta mál varð það miðlungsóháð og færðist yfir í leikbókarbreytur.

Eignabreytur fyrir hópa

Við skulum auka líkanið okkar á mynd 1 með því að bæta við 2 hópum af netþjónum með öðru Java forriti, en með mismunandi stillingum.

Ímyndaðu þér hvernig leikbókin mun líta út í þessu tilfelli:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Við erum með þrjá hópa í leikbókinni, svo það er mælt með því að búa til eins margar hópskrár í group_vars birgðabreytum og leikbókarbreytum í einu. Ein hópskrá í þessu tilviki er lýsingin á einum hluta umsóknarinnar þinnar í leikbókinni. Þegar þú opnar hópskrána í leikbókarbreytunum sérðu strax allan muninn frá sjálfgefna hegðun þeirra hlutverka sem hópnum er úthlutað. Í birgðabreytum: munur á hóphegðun frá bás til búðar.

Kóðastíll

• Reyndu að nota alls ekki host_vars breytur, þar sem þær lýsa ekki kerfinu, heldur aðeins sérstöku tilviki, sem til lengri tíma litið mun leiða til spurninga: "Hvers vegna er þessi gestgjafi öðruvísi en hinir?", Svarið við því er ekki alltaf auðvelt að finna.

Tengja breytur

Hins vegar snýst þetta um eignabreytur, en hvað með tengibreytur?
Munur þeirra er sá að þeir verða að hafa sama gildi í mismunandi hópum.

Í upphafi var hugmynd notaðu voðalega smíði formsins:
hostvars[groups['bbauth'][0]]['auth_bind_port'], en það var strax yfirgefið
vegna þess að það hefur galla. Í fyrsta lagi umfangið. Í öðru lagi, háð ákveðnum gestgjafa í hópnum. Í þriðja lagi er nauðsynlegt að safna staðreyndum frá öllum vélum áður en byrjað er á dreifingunni, ef við viljum ekki fá óskilgreinda breytuvillu.

Í kjölfarið var ákveðið að nota tengibreytur.

Tengja breytur eru breytur sem tilheyra leikbókinni og eru nauðsynlegar til að tengja kerfishluti.

Tengibreytur eru fylltar út í almennar kerfisbreytur group_vars/all/vars og eru mynduð með því að fjarlægja allar hlustunarbreytur úr hverjum hópi og bæta nafni hópsins sem hlustandinn var fjarlægður úr við upphaf breytunnar.

Þannig er einsleitni og mislæg nafna tryggð.

Við skulum reyna að binda breytur úr dæminu hér að ofan:

Ímyndaðu þér að við höfum breytur sem eru háðar hver annarri:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

Við skulum setja það í algengar breytur group_vars/all/vars allir hlustendur og bættu nafni hópsins við nafnið:

# 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 }}"

Nú, með því að breyta gildi tengisins, munum við vera viss um að beiðnin fari á sama stað og tengið er staðsett.

Kóðastíll

• Þar sem hlutverk og hópar eru ólíkir hlutir í kerfinu þarftu að hafa mismunandi nöfn á þá, þá munu tengibreyturnar sýna nákvæmlega að þær tilheyra ákveðnum hópi netþjóna, en ekki hlutverki í kerfinu.

Umhverfisskrár

Hlutverk geta notað skrár sem eru mismunandi eftir umhverfi.

SSL vottorð eru dæmi um slíkar skrár. Geymdu þær sem texta
í breytu er ekki mjög þægilegt. En það er þægilegt að geyma leiðina að þeim inni í breytu.

Til dæmis notum við breytuna api_ssl_key_file: "/path/to/file".

Þar sem það er augljóst að lykilskírteinið mun breytast frá umhverfi til umhverfis er þetta umhverfisháð breyta, sem þýðir að hún ætti að vera staðsett í skránni
group_vars/myapi/vars skrá yfir breytur, og innihalda gildið 'til dæmis'.

Þægilegasta leiðin í þessu tilfelli er að setja lykilskrána í leikbókageymsluna meðfram leiðinni
files/prod/certs/myapi.key, þá verður gildi breytunnar:
api_ssl_key_file: "prod/certs/myapi.key". Þægindin eru fólgin í þeirri staðreynd að fólkið sem ber ábyrgð á að dreifa kerfinu á tilteknum standi hefur einnig sinn sérstaka stað í geymslunni til að geyma skrárnar sínar. Á sama tíma er áfram hægt að tilgreina algjöra slóð að vottorðinu á þjóninum, ef skírteinin eru afhent af öðru kerfi.

Margir standar í einu umhverfi

Oft er þörf á að dreifa nokkrum næstum eins standum í sama umhverfi með lágmarks mun. Í þessu tilviki skiptum við umhverfisháðum breytum í þær sem breytast ekki í þessu umhverfi og þær sem breytast. Og við tökum það síðarnefnda beint út í birgðaskrárnar sjálfar. Eftir þessa meðhöndlun verður hægt að búa til aðra birgðaskrá beint í umhverfisskránni.

Það mun endurnota group_vars birgðina og einnig geta endurskilgreint sumar breytur beint fyrir sig.

Endanleg möppuuppbygging fyrir dreifingarverkefnið:

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 в среде test

Leggja saman

Eftir að hafa skipulagt breyturnar í samræmi við greinina: hver skrá með breytum ber ábyrgð á ákveðnu verkefni. Og þar sem skráin hefur ákveðin verkefni varð hægt að úthluta aðila sem ber ábyrgð á réttmæti hverrar skráar. Til dæmis verður þróunaraðili kerfisuppfærslunnar ábyrgur fyrir réttri fyllingu leikbókarbreytanna, en stjórnandinn, sem lýst er stöðu hans í skránni, ber beina ábyrgð á því að fylla út birgðaskrána.

Hlutverk urðu að sjálfstæðri þróunareiningu með sitt eigið viðmót, sem gerir hlutverkaframleiðandanum kleift að þróa eiginleika frekar en að sníða hlutverkið að kerfinu. Þetta mál átti sérstaklega við um sameiginleg hlutverk allra kerfa í herferð.

Kerfisstjórar þurfa ekki lengur að skilja dreifingarkóða. Allt sem þarf af þeim fyrir árangursríka dreifingu er að fylla út skrár umhverfisbreyta.

Bókmenntir

1. Skjöl

Höfundur

Kalyuzhny Denis Alexandrovich

Heimild: www.habr.com