System approach sa mga variable sa Ansible

ansible devops codestyle

Hoy! Ang pangalan ko ay Denis Kalyuzhny Nagtatrabaho ako bilang isang engineer sa development process automation department. Araw-araw, inilalabas ang mga bagong application build sa daan-daang mga server ng campaign. At sa artikulong ito, ibinabahagi ko ang aking karanasan sa paggamit ng Ansible para sa mga layuning ito.

Nag-aalok ang gabay na ito ng paraan upang ayusin ang mga variable sa isang deployment. Idinisenyo ang gabay na ito para sa mga gumagamit na ng mga tungkulin sa kanilang mga playbook at nagbabasa Pinakamahusay na kasanayanngunit tumatakbo sa mga katulad na problema:

• Ang pagkakaroon ng natagpuan ang isang variable sa code, imposibleng agad na maunawaan kung ano ang responsable para sa;
• Mayroong ilang mga tungkulin, at ang mga variable ay kailangang iugnay sa isang halaga, ngunit hindi ito gumagana;
• Nahihirapang ipaliwanag sa iba kung paano gumagana ang lohika ng mga variable sa iyong mga playbook

Nakatagpo namin ang mga problemang ito sa mga proyekto sa aming kumpanya, bilang isang resulta kung saan nakarating kami sa mga patakaran para sa pag-format ng mga variable sa aming mga playbook, na sa ilang sukat ay nalutas ang mga problemang ito.

Mga variable sa mga tungkulin

Ang Tungkulin ay isang hiwalay na Deployment System Object. Tulad ng anumang bagay ng system, dapat itong magkaroon ng interface para sa pakikipag-ugnayan sa iba pang bahagi ng system. Ang mga variable ng tungkulin ay isang interface.

Kunin, halimbawa, ang papel api, na nag-i-install ng Java application sa server. Anong mga variable mayroon ito?

Ang mga variable ng tungkulin ay maaaring nahahati sa 2 uri ayon sa uri:

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

Mga katangian ng variable ay mga variable na tumutukoy sa pag-uugali ng isang tungkulin.

Mga Variable ng Query ay mga variable na ang halaga ay ginagamit upang magtalaga ng mga mapagkukunang panlabas sa tungkulin.

Mga variable na tagapakinig ay mga variable na ang halaga ay ginagamit upang bumuo ng mga variable ng query.

Sa kabilang banda, ang 1a, 2a, 2b ay mga variable na hindi nakasalalay sa kapaligiran (bakal, panlabas na mapagkukunan, atbp.) at maaaring punan ng mga default na halaga sa mga default na papel. Gayunpaman, ang mga variable tulad ng 1.b at 2.c ay hindi maaaring punan ng mga halaga maliban sa 'halimbawa', dahil sila ay magbabago mula sa stand hanggang sa stand depende sa kapaligiran.

estilo ng code

• Ang pangalan ng variable ay dapat magsimula sa pangalan ng tungkulin. Ito ay magiging madali upang malaman sa hinaharap kung saan ang papel ay mula sa variable at kung ano ito ay responsable para sa.
• Kapag gumagamit ng mga variable sa mga tungkulin, dapat mong tiyaking sundin ang prinsipyo ng encapsulation at gumamit ng mga variable na tinukoy alinman sa mismong tungkulin o sa mga tungkulin kung saan nakasalalay ang kasalukuyang.

• Iwasang gumamit ng mga diksyunaryo para sa mga variable. Hindi ka pinapayagan ng Ansible na maginhawang i-override ang mga indibidwal na halaga sa isang diksyunaryo.

  Isang halimbawa ng masamang variable:

  myrole_user:
      login: admin
      password: admin

  Dito, ang pag-login ay ang median variable, at ang password ay ang dependent variable. Pero
  dahil pinagsama ang mga ito sa isang diksyunaryo, kakailanganin mong tukuyin ito nang buo
  Laging. Na napaka-inconvenient. Mas mabuti sa ganitong paraan:

  myrole_user_login: admin
  myrole_user_password: admin

Mga variable sa deployment playbook

Kapag nag-compile ng deployment playbook (mula rito ay tinutukoy bilang isang playbook), sinusunod namin ang panuntunan na dapat itong ilagay sa isang hiwalay na repository. Tulad ng mga tungkulin: bawat isa sa sarili nitong git repository. Nagbibigay-daan ito sa iyong mapagtanto na ang mga tungkulin at ang playbook ay magkaibang mga independiyenteng bagay ng deployment system, at ang mga pagbabago sa isang bagay ay hindi dapat makaapekto sa pagpapatakbo ng isa pa. Ito ay nakakamit sa pamamagitan ng pagbabago ng mga default na halaga ng mga variable.

Kapag nag-compile ng playbook, bilang pagbubuod, posibleng i-override ang mga default na halaga ng mga variable ng tungkulin sa dalawang lugar: sa mga variable ng playbook at sa mga variable ng imbentaryo.

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

* - Mga Variable at Vault

Ang pagkakaiba ay ang mga variable ng playbook ay palaging ginagamit kapag tumatawag sa mga playbook na matatagpuan sa parehong antas dito. Nangangahulugan ito na ang mga variable na ito ay mahusay para sa pagbabago ng mga default na halaga ng mga variable na hindi nakasalalay sa kapaligiran. Sa kabaligtaran, ang mga variable ng imbentaryo ay gagamitin lamang para sa isang partikular na kapaligiran, na perpekto para sa mga variable na partikular sa kapaligiran.

Mahalagang tandaan na hindi ka papayagan ng variable precedence na muling tukuyin ang mga variable sa mga variable ng playbook at pagkatapos ay hiwalay sa parehong imbentaryo.

Nangangahulugan ito na nasa yugto na ito kailangan mong magpasya kung ang variable ay nakadepende sa kapaligiran o hindi at ilagay ito sa tamang lugar.

Halimbawa, sa isang proyekto, ang variable na responsable para sa pagpapagana ng SSL ay nakadepende sa kapaligiran sa loob ng mahabang panahon, dahil hindi namin ma-enable ang SSL sa mga kadahilanang hindi namin kontrolado sa isa sa mga stand. Pagkatapos naming ayusin ang isyung ito, naging medium independent ito at inilipat sa mga variable ng playbook.

Mga Variable ng Ari-arian para sa Mga Grupo

Palawakin natin ang ating modelo sa Figure 1 sa pamamagitan ng pagdaragdag ng 2 grupo ng mga server na may ibang Java application, ngunit may iba't ibang setting.

Isipin kung ano ang magiging hitsura ng playbook sa kasong ito:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Mayroon kaming tatlong grupo sa playbook, kaya inirerekomenda na gumawa ng kasing dami ng mga file ng pangkat sa mga variable ng imbentaryo ng group_vars at mga variable ng playbook nang sabay-sabay. Ang isang pangkat na file sa kasong ito ay ang paglalarawan ng isang bahagi ng iyong aplikasyon sa playbook. Kapag binuksan mo ang file ng pangkat sa mga variable ng playbook, makikita mo kaagad ang lahat ng pagkakaiba mula sa default na gawi ng mga tungkuling itinalaga sa pangkat. Sa mga variable ng imbentaryo: mga pagkakaiba sa gawi ng grupo mula sa booth hanggang sa booth.

Estilo ng Code

• Subukang huwag gumamit ng mga variable ng host_vars, dahil hindi nila inilalarawan ang system, ngunit isang espesyal na kaso lamang, na sa katagalan ay hahantong sa mga tanong: "Bakit naiiba ang host na ito sa iba?", Ang sagot kung saan ay hindi laging madaling mahanap.

Mga variable ng link

Gayunpaman, iyon ay tungkol sa mga variable ng ari-arian, ngunit paano ang tungkol sa mga variable ng link?
Ang kanilang pagkakaiba ay dapat silang magkaroon ng parehong halaga sa iba't ibang grupo.

Sa simula meron ideya gumamit ng napakalaking pagbuo ng form:
hostvars[groups['bbauth'][0]]['auth_bind_port'], ngunit agad itong iniwan
dahil ito ay may mga pagkukulang. Una, ang bulkiness. Pangalawa, pagdepende sa isang partikular na host sa grupo. Pangatlo, kinakailangan upang mangolekta ng mga katotohanan mula sa lahat ng mga host bago simulan ang pag-deploy, kung hindi namin nais na makakuha ng hindi natukoy na variable na error.

Bilang resulta, napagpasyahan na gumamit ng mga variable ng link.

Mga variable ng link ay mga variable na nabibilang sa playbook at kinakailangan upang i-link ang mga object ng system.

Ang mga variable ng link ay na-populate sa mga pangkalahatang variable ng system group_vars/all/vars at nabuo sa pamamagitan ng pag-alis ng lahat ng mga variable ng listener mula sa bawat pangkat, at pagdaragdag ng pangalan ng pangkat kung saan inalis ang tagapakinig sa simula ng variable.

Kaya, ang pagkakapareho at hindi intersection ng mga pangalan ay sinisiguro.

Subukan nating i-bind ang mga variable mula sa halimbawa sa itaas:

Isipin na mayroon tayong mga variable na nakadepende sa isa't isa:

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

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

Ilagay natin ito sa mga karaniwang variable group_vars/all/vars lahat ng mga tagapakinig, at idagdag ang pangalan ng grupo sa pangalan:

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

Ngayon, sa pamamagitan ng pagbabago ng halaga ng connector, makatitiyak kami na mapupunta ang kahilingan sa parehong port.

Estilo ng Code

• Dahil magkaibang object ng system ang mga tungkulin at grupo, kailangan nilang magkaroon ng iba't ibang pangalan upang tumpak na ipakita ng mga variable ng link na kabilang sila sa isang partikular na pangkat ng server, at hindi sa isang tungkulin sa system.

Mga file sa kapaligiran

Ang mga tungkulin ay maaaring gumamit ng mga file na naiiba sa bawat kapaligiran.

Ang mga SSL certificate ay isang halimbawa ng mga naturang file. I-store ang mga ito bilang text
sa isang variable ay hindi masyadong maginhawa. Ngunit ito ay maginhawa upang iimbak ang landas sa kanila sa loob ng isang variable.

Halimbawa, ginagamit namin ang variable api_ssl_key_file: "/path/to/file".

Dahil malinaw na ang pangunahing sertipiko ay magbabago mula sa kapaligiran patungo sa kapaligiran, ito ay isang variable na umaasa sa kapaligiran, na nangangahulugang dapat itong matatagpuan sa file
group_vars/myapi/vars imbentaryo ng mga variable, at naglalaman ng value na 'halimbawa'.

Ang pinaka-maginhawang paraan sa kasong ito ay ilagay ang key file sa playbook repository kasama ang landas
files/prod/certs/myapi.key, kung gayon ang halaga ng variable ay magiging:
api_ssl_key_file: "prod/certs/myapi.key". Ang kaginhawahan ay nakasalalay sa katotohanan na ang mga taong responsable para sa pag-deploy ng system sa isang partikular na stand ay mayroon ding sariling nakalaang lugar sa repository upang mag-imbak ng kanilang mga file. Kasabay nito, nananatiling posible na tukuyin ang ganap na landas sa sertipiko sa server, kung sakaling ang mga sertipiko ay ibinibigay ng ibang sistema.

Maramihang nakatayo sa isang kapaligiran

Kadalasan mayroong pangangailangan na mag-deploy ng ilang halos magkaparehong stand sa parehong kapaligiran na may kaunting pagkakaiba. Sa kasong ito, hinahati namin ang mga variable na umaasa sa kapaligiran sa mga hindi nagbabago sa loob ng kapaligirang ito at sa mga nagbabago. At dinadala namin ang huli nang direkta sa mga file ng imbentaryo mismo. Pagkatapos ng pagmamanipula na ito, nagiging posible na lumikha ng isa pang imbentaryo nang direkta sa direktoryo ng kapaligiran.

Muli nitong gagamitin ang imbentaryo ng group_vars at magagawang muling tukuyin ang ilang mga variable nang direkta para sa sarili nito.

Ang panghuling istraktura ng direktoryo para sa proyekto sa pag-deploy:

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

Summing up

Pagkatapos ayusin ang mga variable alinsunod sa artikulo: ang bawat file na may mga variable ay may pananagutan para sa isang partikular na gawain. At dahil ang file ay may ilang mga gawain, naging posible na magtalaga ng isang taong responsable para sa kawastuhan ng bawat file. Halimbawa, nagiging responsable ang developer ng deployment ng system para sa tamang pagpuno ng mga variable ng playbook, habang ang administrator, na ang paninindigan ay inilarawan sa imbentaryo, ay direktang responsable para sa pagpuno sa imbentaryo ng mga variable.

Ang mga tungkulin ay naging isang self-contained na yunit ng pag-unlad na may sariling interface, na nagpapahintulot sa developer ng tungkulin na bumuo ng mga tampok sa halip na iangkop ang tungkulin upang umangkop sa system. Ang isyung ito ay totoo lalo na para sa mga karaniwang tungkulin para sa lahat ng system sa isang campaign.

Hindi na kailangang maunawaan ng mga administrator ng system ang deployment code. Ang kailangan lang sa kanila para sa isang matagumpay na pag-deploy ay punan ang mga file ng mga variable ng kapaligiran.

Panitikan

1. Records

May-akda

Kalyuzhny Denis Alexandrovich

Pinagmulan: www.habr.com