Nêzîkatiya pergalê ji guhêrbarên di Ansible de

ansible devops codestyle

Hey! Navê min Denis Kalyuzhny Ez wekî endezyar di beşa otomasyona pêvajoya pêşkeftinê de dixebitim. Her roj, avakirina serîlêdanên nû li ser bi sedan serverên kampanyayê têne derxistin. Û di vê gotarê de ez ezmûna xwe ya karanîna Ansible ji bo van armancan parve dikim.

Ev rêber rêyek ji bo birêxistinkirina guhêrbaran di bicîhkirinê de pêşkêşî dike. Ev rênîşander ji bo kesên ku berê di lîstikên xwe de rolan bikar tînin û xwendine tê armanc kirin BestPractices, lê bi pirsgirêkên wekhev re rû bi rû ye:

• Gava ku di kodê de guherbarek dît, ne gengaz e ku meriv tavilê fêm bike ka ew ji çi berpirsiyar e;
• Gelek rol hene, û pêdivî ye ku guhêrbar bi yek nirxê re têkildar bin, lê ew tenê naxebite;
• Zehmetiya ku hûn ji yên din re rave bikin ka mantiqa guhêrbarên di pirtûkên lîstika we de çawa dixebite

Em li ser projeyên di pargîdaniya xwe de rastî van pirsgirêkan hatin, di encamê de em gihîştin qaîdeyên ji bo sêwirana guherbaran di pirtûkên lîstika xwe de, ku heya radeyekê ev pirsgirêk çareser kirin.

Guherbarên di rolan de

Rol Objekteyek veqetandî ya pergala belavkirinê ye. Mîna her tiştê pergalê, pêdivî ye ku ew ji bo danûstendina bi pergalên mayî re têkiliyek wê hebe. Navberek wusa guhêrbarên rolê ye.

Werin, wek nimûne, rola api, ku serîlêdana Java-yê li ser serverê saz dike. Dibe ku kîjan guherbarên wê hebin?

Rolên guhêrbar li gorî celeb dikarin li 2 celeban bêne dabeş kirin:

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

Taybetmendiyên guherbar guhêrbar in ku tevgera rolê diyar dikin.

Guherbarên Query - ev guhêrbar in ku nirxa wan ji bo destnîşankirina çavkaniyên derveyî rolê têne bikar anîn.

Guhdarên Variable - ev guhêrbar in ku nirxa wan ji bo avakirina guhêrbarên daxwaznameyê têne bikar anîn.

Ji hêla din ve, 1a, 2a, 2b guhêrbar in ku bi hawîrdorê ve ne girêdayî ne (hardware, çavkaniyên derveyî, hwd.) û dikarin di rola xwerû de bi nirxên xwerû werin dagirtin. Lêbelê, ne mimkûn e ku meriv guhêrbarên celeb 1.b û 2.c bi nirxên din ji bilî 'mînak' tije bike, ji ber ku ew ê li gorî hawîrdorê ji rawestgehê biguherînin.

Şêweya kodê

• Navê guhêrbar divê bi navê rolê dest pê bike. Ev ê di pêşerojê de hêsan bike ku meriv fêhm bike ka guhêrbar ji kîjan rola ye û ji çi berpirsiyar e.
• Dema ku guherbaran di rolan de bikar tînin, pêdivî ye ku hûn pê ewle bin ku prensîba encapsulasyonê bişopînin û guhêrbarên ku di rola xwe de an jî di rolên ku ya heyî pê ve girêdayî ye bikar bînin.

• Ji bo guherbaran ji bikaranîna ferhengan dûr bixin. Ansible rê nade ku hûn bi rehetî nirxên kesane di ferhengekê de derbas bikin.

  Mînak guherbarek xirab:

  myrole_user:
      login: admin
      password: admin

  Li vir têketin guherbara serbixwe ye, û şîfre guhêrbara girêdayî ye. Lebê
  ji ber ku ew di ferhengekê de hatine berhevkirin, divê hûn wê bi tevahî diyar bikin
  Herdem. Ya ku pir nerehet e. Bi vî awayî çêtir e:

  myrole_user_login: admin
  myrole_user_password: admin

Guherbarên di pirtûkên lîstikê yên bicîhkirinê de

Dema berhevkirina pirtûkek lîstikê ya birêkûpêk (ji vir şûnde wekî pirtûka lîstikê tê binav kirin), em li gorî qaîdeyê ku divê ew di depoyek cihêreng de were danîn. Eynî rolan: her yek di depoya git ya xwe de. Ev dihêle hûn fêm bikin ku rol û pirtûka lîstikê tiştên cûda yên serbixwe yên pergala bicîhkirinê ne, û guhertinên di yek tiştan de divê bandorê li xebata ya din neke. Ev bi guheztina nirxên xwerû yên guhêrbaran pêk tê.

Dema berhevkirina pirtûkek lîstikê, bi kurtî, gengaz e ku meriv nirxên xwerû yên guhêrbarên rolê li du cihan biguhezîne: di guherbarên pirtûka lîstikê de û di guhêrbarên depoyê de.

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

* - Variables û Vaults

Cûdahî ev e ku dema ku gazî pirtûkên lîstikê yên ku di heman astê de ne, guhêrbarên pirtûkê têne bikar anîn. Ev tê vê wateyê ku ev guhêrbar ji bo guheztina nirxên xwerû yên guhêrbarên serbixwe yên jîngehê mezin in. Berevajî vê, guhêrbarên tomarkirinê dê tenê ji bo jîngehek taybetî, ku ji bo guhêrbarên taybetî yên jîngehê îdeal e, were bikar anîn.

Girîng e ku bala xwe bidinê ku pêşîniya guhêrbar dê nehêle hûn guhêrbaran pêşî di guhêrbarên pirtûka lîstikê de û dûv re jî di yek envanterê de ji hev veqetînin.

Ev tê wê wateyê ku jixwe di vê qonaxê de pêdivî ye ku meriv biryar bide ka guhêrbar bi hawîrdorê ve girêdayî ye an na û ew li cîhek guncaw bi cîh bike.

Mînakî, di projeyekê de, guhêrbara ku berpirsiyarê çalakkirina SSL-ê ji bo demek dirêj ve girêdayî jîngehê bû, ji ber ku me nekarî SSL-ê ji ber sedemên li derveyî kontrola me li yek ji stantan çalak bike. Piştî ku me ev pirsgirêk rast kir, ew jîngehek serbixwe bû û derbasî guhêrbarên pirtûka lîstikê bû.

Guherbarên Taybetmendiyê ji bo Koman

Werin em modela xwe ya di Figure 1-ê de bi lê zêdekirina 2 komên serverên bi serîlêdanek Java-ya cihê, lê bi mîhengên cihêreng, berfireh bikin.

Ka em bifikirin ka dê di vê rewşê de pirtûka lîstikê çawa xuya bike:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Di pirtûkê de sê komên me hene, ji ber vê yekê yekser tê pêşniyar kirin ku heman hejmar pelên komê di guhêrbarên envanterê yên group_vars û guhêrbarên pirtûkê de biafirînin. Yek pelê komê di vê rewşê de danasîna yek hêmanek serîlêdana jorîn a di pirtûka lîstikê de ye. Gava ku hûn pelek komê di guhêrbarên pirtûka lîstikê de vedikin, hûn tavilê hemî cûdahiyan ji tevgera xwerû ya rolên ku li ser komê hatine saz kirin dibînin. Di guherbarên envanterê de: ciyawaziyên di tevgera komê de ji standê heya standê.

Code Style

• Biceribînin ku qet guhêrbarên host_vars bikar neynin, ji ber ku ew pergalê rave nakin, lê tenê rewşek taybetî ye, ku di pêşerojê de dê bibe sedema pirsan: "Çima ev mêvandar ji yên din cûda ye?", bersiva ku nayê her gav hêsan tê dîtin.

Guherbarên Ragihandinê

Lêbelê, ew e ku guhêrbarên taybetmendiyê hemî li ser wan in, lê di derheqê guhêrbarên ragihandinê de çi ye?
Cûdahiya wan ew e ku divê di komên cûda de heman wateyê hebe.

Di destpêkê de ew bû fikra avahiyek cinawir bikar bînin wekî:
hostvars[groups['bbauth'][0]]['auth_bind_port'], lê wan yekser ew red kir
ji ber ku kêmasiyên wê hene. Pêşîn, mezinahî. Ya duyemîn, girêdayîbûna bi mêvandarek taybetî ya di komê de. Ya sêyemîn, berî destpêkirina bicîhkirinê, ger em nexwazin xeletiyek guhêrbarek nediyar bi dest bixin, pêdivî ye ku em rastiyan ji hemî mêvandaran berhev bikin.

Di encamê de, biryar hate girtin ku guhêrbarên ragihandinê bikar bînin.

Guherbarên Ragihandinê - ev guhêrbar in ku girêdayî lîstika lîstikê ne û ji bo girêdana tiştên pergalê hewce ne.

Guherbarên ragihandinê di guhêrbarên pergalê yên gelemperî de têne bicîh kirin group_vars/all/vars û bi rakirina hemû guhêrbarên guhdaran ji her komê, û lê zêdekirina navê koma ku guhdar jê hatî rakirin li destpêka guhêrbarê têne çêkirin.

Ev yek yekbûn û navên ne-lihevkirî misoger dike.

Ka em hewl bidin ku guhêrbarên ji mînaka li jor girêdin:

Ka em bifikirin ku guhêrbarên me hene ku bi hev ve girêdayî ne:

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

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

Ka em wê têxin nav guhêrbarên hevpar group_vars/all/vars hemî guhdaran, û navê komê li sernavê zêde bikin:

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

Naha, bi guheztina nirxa girêdanê, em ê pê bawer bin ku daxwaz dê biçe heman cîhê ku port lê ye.

Code Style

• Ji ber ku rol û kom hêmanên pergalê yên cihê ne, ew hewce ne ku navên cûda hebin, wê hingê guhêrbarên girêdanê dê rast destnîşan bikin ku ew girêdayî komek taybetî ya pêşkêşkeran in, û ne ji rolek di pergalê de ne.

Pelên girêdayî hawirdorê

Dibe ku rol pelên ku ji hawîrdorê heya jîngehê cûda dibin bikar bînin.

Mînaka pelên weha sertîfîkayên SSL-ê ne. Wan di forma nivîsê de hilînin
di guherbarekê de ne pir rehet e. Lê hêsan e ku meriv riya wan di hundurê guhêrbarek de hilîne.

Mînakî, em guhêrbar bikar tînin api_ssl_key_file: "/path/to/file".

Ji ber ku diyar e ku sertîfîkaya sereke dê ji hawîrdorê ber bi hawîrdorê ve biguheze, ev guhêrbarek girêdayî hawîrdorê ye, ku tê vê wateyê ku divê di pelê de cih bigire.
group_vars/myapi/vars envantera guherbaran, û nirxa 'mînak' dihewîne.

Awayê herî hêsan di vê rewşê de ev e ku hûn pelê mifteyê li depoya pirtûka lîstikê bi rê de bixin
files/prod/certs/myapi.key, wê hingê nirxa guhêrbar dê bibe:
api_ssl_key_file: "prod/certs/myapi.key". Rehetî di vê yekê de ye ku kesên ku berpirsiyar in ku pergalê li cîhek taybetî bicîh bikin di heman demê de cîhê xwe yê veqetandî di depoyê de jî hene ku pelên xwe hilînin. Di heman demê de, heke sertîfîka ji hêla pergalek din ve têne peyda kirin, gengaz e ku meriv riya bêkêmasî ya sertîfîkayê li ser serverê diyar bike.

Gelek rawestgehan di yek jîngehê de

Bi gelemperî hewce ye ku di heman hawîrdorê de bi cûdahiyên hindik re çend stûnên hema hema yekane werin bicîh kirin. Di vê rewşê de, em guhêrbarên girêdayî hawirdorê li yên ku di nav vê hawîrdorê de naguherin û yên ku diguherin dabeş dikin. Û em ya paşîn rasterast di pelên envanterê de bi xwe veguhezînin. Piştî vê manîpulasyonê, mimkun dibe ku rasterast di pelrêça jîngehê de envanterek din were afirandin.

Ew ê depoya group_vars ji nû ve bi kar bîne, û hem jî dê bikaribe rasterast ji bo xwe hin guherbaran ji nû ve pênase bike.

Struktura pelrêça paşîn a ji bo projeya bicîhkirinê:

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

Kurtekirin

Piştî organîzekirina guherbaran li gorî gotarê: her pelê guhêrbar ji karekî taybetî berpirsiyar e. Û ji ber ku pelê hin peywiran hene, mimkun bû ku meriv berpirsiyarê rastbûna her pelê destnîşan bike. Mînakî, pêşdebirê bicîhkirina pergalê berpirsiyarê dagirtina rast a guhêrbarên pirtûka lîstikê dibe, di heman demê de rêveberê ku rawestgeha wî di envanterê de hatî diyar kirin rasterast berpirsiyar e ji dagirtina guhêrbaran.

Role bi navbeynkariya xwe re bûne yekîneya pêşkeftina xwe, ku rê dide pêşdebirê rolê ku li şûna ku rola xwe li gorî pergalê guncan bike, kapasîteyên pêş bixe. Ev pirsgirêk bi taybetî bi rolên hevpar ên hemî pergalên di kampanyayê de têkildar bû.

Rêvebirên pergalê êdî ne hewce ne ku koda bicîhkirinê fam bikin. Tiştê ku ji bo bicîhkirina serketî ji wan tê xwestin ev e ku pelên guhêrbarên girêdayî hawîrdorê tijî bikin.

Wêjeyê

1. Dokumentasyonê

nivîskar

Kalyuzhny Denis Alexandrovich

Source: www.habr.com