ProHoster > Blog > Administrimi > Qasja sistemike ndaj variablave në Ansible

Qasja sistemike ndaj variablave në Ansible

ansible devops codestyle

PĂ«rshĂ«ndetje! UnĂ« quhem Denis Kalujnyj Punoj si inxhiner nĂ« departamentin e automatizimit tĂ« proceseve tĂ« zhvillimit. Çdo ditĂ«, ndĂ«rtimet e reja tĂ« aplikacioneve shpĂ«rndahen nĂ« qindra serverĂ« tĂ« kompanisĂ«. Dhe nĂ« kĂ«tĂ« artikull, ndaja pĂ«rvojĂ«n time nĂ« pĂ«rdorimin e Ansible pĂ«r kĂ«to qĂ«llime.

Ky udhëzues ofron një mënyrë për organizimin e variablave në shpërndarje. Ky udhëzues është i orientuar për ata që tashmë po përdorin role në skenarët e tyre dhe kanë lexuar BestPractices, por përballen me probleme të ngjashme:

  • Kur gjej njĂ« variabĂ«l nĂ« kod, Ă«shtĂ« e pamundur tĂ« kuptoj menjĂ«herĂ« pĂ«r çfarĂ« Ă«shtĂ« ajo;
  • Ka disa role dhe variablave duhet t'u lidhim njĂ« vlerĂ«, por nuk po arrijmĂ« dot;
  • Kemi vĂ«shtirĂ«si pĂ«r tĂ« shpjeguar tĂ« tjerĂ«ve se si Ă«shtĂ« logjika e variablave nĂ« skenarĂ«t e tuaja.

Me këto probleme u përballëm në projektet në kompaninë tonë, çka na çoi në rregullat e organizimit të variablave në skenarët tanë, të cilat në një farë mënyre zgjidhen këto çështje.

Qasja sistemike ndaj variablave në Ansible

Variablat në role

Roli është një objekt i veçantë i sistemit të shpërndarjes. Ashtu si çdo objekt në sistem, ai duhet të ketë një ndërfaqe për të komunikuar me sistemin e mbetur. Kjo ndërfaqe janë variablat e rolit.

Le të marrim për shembull rolin api, i cili instalon një aplikacion Java në server. Cilat variabla mund të ketë?

Qasja sistemike ndaj variablave në Ansible

Variablat e rolit mund të ndahen në 2 lloje sipas tipit:

1. Pronat
    a) të pavarura nga mjedisi
    b) të varura nga mjedisi
2. Lidhjet
    a) dëgjuesit 
    b) kërkesat brenda sistemit
    c) kërkesat në mjedis

Variablat e pronave janë variablat që përcaktojnë sjelljen e rolit.

Variablat e kërkesës janë variablat, vlera e të cilave përdoret për të treguar burimet jashtë rolit.

Variablat dëgjues janë variablat, vlera e të cilave përdoret për të formuar variablat e kërkësës.

Nga ana tjetĂ«r, 1a, 2a, 2b — kĂ«to janĂ« variablat qĂ« nuk varen nga mjedisi (hardueri, burimet e jashtme, etj.) dhe mund tĂ« plotĂ«sohen me vlera default nĂ« defaults tĂ« rolit. MegjithatĂ«, variablat e tipit 1b dhe 2c mund tĂ« plotĂ«sohen tjetĂ«r veçse me 'example' pasi ato do tĂ« ndryshojnĂ« nga qĂ«ndra nĂ« qĂ«ndĂ«r nĂ« varĂ«si tĂ« mjedisit.

Stili i kodit

  • Emri i variablĂ«s duhet tĂ« fillojĂ« me emrin e rolit. Kjo do tĂ« lejojĂ« qĂ« mĂ« vonĂ« tĂ« kuptohet lehtĂ« se nga cili rol vjen variabla dhe pĂ«r çfarĂ« Ă«shtĂ« ajo.
  • Kur pĂ«rdorni variabla nĂ« role, ju duhet patjetĂ«r tĂ« ndiqni parimin e inkapsulimit dhe tĂ« pĂ«rdorni variabla tĂ« caktuara ose nĂ« rolin e vet, ose nĂ« rolet nga tĂ« cilat varet aktuali.

  • Merrni pĂ«r tĂ« shmangur pĂ«rdorimin e fjalorĂ«ve pĂ«r variabla. Ansible nuk lejon tĂ« ripĂ«rdoren lehtĂ«sisht vlerat individuale tĂ« njĂ« fjalori.

    Shembulli i një variabël të keqe:

    myrole_user:
    login: admin
    password: admin

    Këtu login është një variabël që nuk varet nga mjedisi, ndërsa password është e varur. Por
    në masë që ato janë të bashkuara në një fjalor, do t'ju duhet t'i caktoni gjithmonë atë plotësisht,
    çka është shumë e pakëndshme. Më mirë është kështu:

    myrole_user_login: admin
myrole_user_password: admin

Variablat në skenarët e shpërndarjes

NĂ« pĂ«rgatitjen e skenarit tĂ« shpĂ«rndarjes (mĂ« pas skenari), ne ndjekim rregullin se ai duhet tĂ« vendoset nĂ« njĂ« depo tĂ« veçantĂ«. Ashtu si rolet: secila nĂ« depo tĂ« saj git. Kjo lejon tĂ« kuptohet qĂ« rolet dhe skenari — janĂ« objekte tĂ« ndryshme tĂ« pavarura tĂ« sistemit tĂ« shpĂ«rndarjes, dhe ndryshimet nĂ« njĂ« objekt nuk duhet tĂ« ndikojnĂ« nĂ« funksionimin e tjetrit. Kjo arrihet duke ndryshuar vlerat default tĂ« variablave.

Kur përgatitni skenarin, nëse është e përgjithshme, ekziston mundësia për të ripërcaktuar vlerat default të variablave të rolit në dy vende: në variablat e skenarit dhe në variablat e inventarit.

mydeploy                        # Katalogu i shpërndarjes
├── deploy.yml                  # Skenari i shpĂ«rndarjes
├── group_vars                  # Katalogu i variablave tĂ« skenarit
│   ├── all.yml                 # Skedari pĂ«r variablat lidhĂ«s tĂ« gjithĂ« sistemit
│   └── myapi.yml               # Skedari i variablave tĂ« pronĂ«s tĂ« grupit myapi
└── inventories                 #
    └── prod                    # Katalogu i mjedisit prod
      ├── prod.ini            # Skedari i inventarit
      └── group_vars          # Katalogu pĂ«r variablat e inventarit
          └── myapi           #
          ├── vars.yml       # Variablat e varura tĂ« grupit myapi
          └── vault.yml      # Sekretet (tĂ« gjitha janĂ« tĂ« varura) *

* — Variablat dhe Vaults

Dallimi qëndron në faktin se variablat e skenarit përdoren gjithmonë gjatë thirrjeve të skenarëve, të vendosur me të në të njëjtin nivel. Kështu, këto variabla janë të përshtatshme për të ndryshuar vlerat default të variablave që nuk varen nga mjedisi. Dhe, përkundrazi, variablat e inventarit do të përdoren vetëm për një mjedis të veçantë, që është ideale për variablat që varen nga mjedisi.

ËshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se prioriteti i variablave nuk do t'ju lejojĂ« tĂ« ribĂ«ni variablat pĂ«rpara nĂ« variablat e playbook-ut dhe pastaj veçmas nĂ« njĂ« inventar.

Kjo do të thotë se edhe në këtë fazë duhet të vendosni nëse variabli është me varësi mjedisi apo jo dhe ta vendosni atë në vendin e duhur.

Për shembull, në një projekt, variabli që përcakton aktivizimin e SSL ishte për një kohë të gjatë me varësi mjedisi, pasi nuk mundëm të aktivizojmë SSL për arsye që nuk varen nga ne në një nga ambientet. Pasi e zgjidhëm këtë çështje, ai u bë pa varësi mjedisi dhe u zhvendos në variablat e playbook-ut.

Variablat e pronave për grupe

Të zgjeromë modelin tonë në figurën 1, duke shtuar 2 grupe serverësh me një aplikacion tjetër Java, por me cilësime të ndryshme.

Qasja sistemike ndaj variablave në Ansible

Le të imagjinojmë si do të duket playbook-u në këtë rast:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Kemi tre grupe në playbook, prandaj është e rekomanduar të krijoni njësoj kaq shumë skedarë grupesh në group_vars të variablave të inventarit, dhe në variablat e playbook-ut. Një skedar grupi në këtë rast, është përshkrimi i një komponenti të lartë të aplikacionit në playbook. Duke hapur skedarin e grupit në variablat e playbook-ut, shihni menjëherë të gjitha ndryshimet nga sjellja standarde e roleve të instaluara në grup. Në variablat e inventarit: ndryshimet e sjelljes së grupit nga ambienti në ambient.

Stili i Kodit

  • PĂ«rpiquni tĂ« mos pĂ«rdorni fare variablat host_vars, pasi ato nuk pĂ«rshkruajnĂ« sistemin, por vetĂ«m njĂ« rast tĂ« veçantĂ«, qĂ« nĂ« perspektivĂ« do tĂ« çojĂ« nĂ« pyetje: "Pse ky host Ă«shtĂ« ndryshe nga tĂ« tjerĂ«t?", pĂ«rgjigjja e tĂ« cilĂ«s nuk Ă«shtĂ« gjithmonĂ« e lehtĂ« tĂ« gjendet.

Variablat e lidhjes

Sidoqoftë, ky është rasti me variablat e pronave, por si të veprojmë me variablat e lidhjes?
Dallimi i tyre është se ato duhet të kenë të njëjtin vlerë në grupe të ndryshme.

Fillimisht ishte ideja përdorimi i një strukture monstruoze si:
hostvars[groups['bbauth'][0]]['auth_bind_port'], por u hoq menjëherë
pasi ka disavantazhe. E para, janë të vështira. E dyta, varen nga një host i caktuar në grup. E treta, ne duhet të mbledhim faktet nga të gjithë hostet para se të fillojmë depon nëse nuk duam të marrim një gabim të variablit të paqëruar.

Si përfundim, u vendos të përdoren variablat e lidhjes.

Variablat e lidhjes ÇfarĂ« janĂ« variablat e lidhjes? Ato janĂ« variablat qĂ« i pĂ«rkasin playbook-ut dhe janĂ« tĂ« nevojshme pĂ«r lidhjen e objekteve tĂ« sistemit.

Variablat e lidhjes plotësohen në variablat e zakonshme të sistemit group_vars/all/vars dhe krijohen duke nxjerrë të gjitha variablat e dëgjuesve nga çdo grup dhe duke shtuar në fillim të variablës emrin e grupit nga i cili dëgjuesi është nxjerrë.

Kështu sigurohet njëllojshmëri dhe mos përputhje emrash.

Le të tentojmë të lidhim variablat nga shembulli më sipër:

Qasja sistemike ndaj variablave në Ansible

Le të imagjinojmë se kemi variablat që varen nga njëri-tjetri:

# roles/api/defaults:
# ĐŸĐ”Ń€Đ”ĐŒĐ”ĐœĐœĐ°Ń Đ·Đ°ĐżŃ€ĐŸŃĐ°
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# ĐŸĐ”Ń€Đ”ĐŒĐ”ĐœĐœĐ°Ń ŃĐ»ŃƒŃˆĐ°Ń‚Đ”Đ»ŃŒ
auth_bind_port: "20000"

Nxjerrim në variablat e zakonshme group_vars/all/vars të gjithë dëgjuesit dhe shtojmë në emrin e grupit:

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

Tani, duke ndryshuar vlerën e lidhësit, do të jemi të sigurt se kërkesa do të drejtohet aty ku ndodhet porta.

Stili i Kodit

  • Duke qenĂ« se rolet dhe grupet janĂ« objekte tĂ« ndryshme tĂ« sistemit, ato duhet tĂ« kenĂ« emra tĂ« ndryshĂ«m, kĂ«shtu qĂ« variablat e lidhjes do tĂ« tregojnĂ« me siguri se ata i pĂ«rkasin njĂ« grupi tĂ« caktuar serverĂ«sh dhe jo rolit nĂ« sistem.

Skedarët me varësi mjedisi

Në role mund të përdoren skedarë që ndryshojnë nga mjedisi në mjedis.

Një shembull i tillë skedari mund të jenë certifikatat SSL. Ruajtja e tyre në format tekstual
në variabël nuk është shumë e lehtë. Megjithatë, është e lehtë të ruash rrugën për to brenda variablës.

Për shembull, përdorim variablën api_ssl_key_file: "/path/to/file".

Duke qenë se është evidente se certifikata e çelësit do të ndryshojë nga një mjedis në tjetrin, atëherë kjo është një variabël me varësi mjedisi, prandaj ajo duhet të vendoset në skedarin
group_vars/myapi/vars tĂ« variablave tĂ« inventarit dhe tĂ« pĂ«rmbajĂ« vlerĂ«n ‘pĂ«r shembull’.

Më e lehta është në këtë rast të vendosni skedarin e çelësit në depozitën e playbook-ut në rrugën
files/prod/certs/myapi.key, atëherë vlera e variablës do të jetë:
api_ssl_key_file: "prod/certs/myapi.key". Lehtësia qëndron në faktin se njerëzit që janë përgjegjës për shpërndarjen e sistemit në ambientin e caktuar, gjithashtu kanë vendin e tyre të dedikuar në depo për ruajtjen e skedarëve të tyre. Në të njëjtën kohë, mbetet mundësia për të specifikuar një rrugë absolute për certifikatën në server, në rast se certifikatat furnizohen nga një sistem tjetër.

Disa ambiente në një mjedis

Shpesh lind nevoja për të vendosur disa stande pothuajse identike në një mjedis me ndryshime minimale. Në këtë rast, ne i ndajmë variablat në vargje që nuk ndryshojnë brenda këtij mjedisi dhe ato që ndryshojnë. Dhe i nxjerrim të fundit direkt në skedarët e inventarit. Pas kësaj manipulative, bëhet e mundur të krijohet një inventar tjetër direkt në katalogun e mjedisit.

Ai do të ripërdorë grupin e inventarit group_vars, si dhe do të ketë mundësinë për të anuluar disa variabla direkt për veten e tij.

Struktura përfundimtare e katalogëve për projektin e vendosjes:

mydeploy                        # Katalogu i vendosjes
├── deploy.yml                  # Plani i vendosjes
├── files                       # Katalogu pĂ«r skedarĂ«t e vendosjes
│   ├── prod                    # Katalogu pĂ«r skedarĂ«t e vargjeve prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Katalogu pĂ«r skedarĂ«t e vargjeve test1
├── group_vars                  # Katalogu i variablave tĂ« planit
│   ├── all.yml                 # Skedari pĂ«r variablat e sistemit tĂ« gjithĂ«
│   ├── myapi.yml               # Skedari i variablave tĂ« grupit myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Katalogu i mjedisit prod
    │   ├── group_vars          # Katalogu pĂ«r variablat e inventarit
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Variablat e vargjeve tĂ« grupit myapi
    │   │   │   └── vault.yml   # Sekretet (pĂ«rherĂ« tĂ« vargjeve)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Inventari i standit prod
    └── test                    # Katalogu i mjedisit test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Inventari i standit test1 nĂ« mjedisin test
        └── test2.ini           # Inventari i standit test2 nĂ« mjedisin test

PĂ«rmbledhje

Pas organizimit të variablave në përputhje me artikullin: çdo skedar me variabla është përgjegjës për një detyrë të caktuar. Dhe që skedari ka detyra të caktuara, bëhet e mundur të caktohet personi përgjegjës për saktësinë e çdo skedari. Për shembull, personi përgjegjës për saktësinë e plotësimit të variablave të planit bëhet zhvilluesi i sistemit të vendosjes, ndërsa për plotësimin e variablave të inventarit përgjigjet drejtpërdrejt administratori, stendi i të cilit përshkruhet në inventar.

Rolat janë bërë një njësi e pavarur zhvillimi me një ndërfaqe të vetë, duke lejuar zhvilluesin e rolit të zhvillojë mundësi, në vend që të përshtatë rolin me sistemin. Kjo problematikë ka prekur veçanërisht rolet e zakonshme për të gjitha sistemet në kompani.

Administratoret e sistemeve nuk kanë më nevojë të merren me kodin e vendosjes. E gjithë çfarë kërkohet prej tyre për një vendosje të suksesshme është të plotesojnë skedarët e variablave të vargjeve.

Literatura

  1. Dokumentacioni

Autor

Kalyuzhny Denis Aleksandrovich

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster