Ansible'da o'zgaruvchilarga tizimli yondashuv

ansible devops kod uslubi

Hey! Ismim Denis Kalyujniy Men ishlab chiqish jarayonlarini avtomatlashtirish bo'limida muhandis bo'lib ishlayman. Har kuni yangi ilovalar tuzilmalari yuzlab kampaniya serverlarida chiqariladi. Va ushbu maqolada men ushbu maqsadlar uchun Ansible-dan foydalanish tajribam bilan o'rtoqlashaman.

Ushbu qo'llanma tarqatishda o'zgaruvchilarni tashkil qilish usulini taklif qiladi. Ushbu qo'llanma o'yin kitoblarida rollardan foydalangan va o'qiganlar uchun mo'ljallangan Eng yaxshi amaliyotlar, lekin shunga o'xshash muammolarga duch keladi:

  • Kodda o'zgaruvchini topib, u nima uchun javobgar ekanligini darhol anglab bo'lmaydi;
  • Bir nechta rollar mavjud va o'zgaruvchilar bitta qiymat bilan bog'lanishi kerak, lekin u ishlamaydi;
  • O'yin kitoblaringizdagi o'zgaruvchilar mantig'i qanday ishlashini boshqalarga tushuntirishda qiynalayapsiz

Biz kompaniyamizdagi loyihalarda bunday muammolarga duch keldik, natijada biz o'yin kitoblarida o'zgaruvchilarni loyihalash qoidalariga keldik, bu esa ma'lum darajada ushbu muammolarni hal qildi.

Ansible'da o'zgaruvchilarga tizimli yondashuv

Rollardagi o'zgaruvchilar

Rol joylashtirish tizimining alohida ob'ektidir. Har qanday tizim ob'ekti singari, u tizimning qolgan qismi bilan o'zaro aloqa qilish uchun interfeysga ega bo'lishi kerak. Bunday interfeys rol o'zgaruvchilari hisoblanadi.

Masalan, rolni olaylik api, bu serverda Java dasturini o'rnatadi. U qanday o'zgaruvchilarga ega bo'lishi mumkin?

Ansible'da o'zgaruvchilarga tizimli yondashuv

Turiga ko'ra o'zgaruvchan rollarni 2 turga bo'lish mumkin:

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

O'zgaruvchan xususiyatlar rolning harakatini belgilaydigan o'zgaruvchilardir.

So'rov o'zgaruvchilari - bu o'zgaruvchilar, ularning qiymati rolga tashqi resurslarni belgilash uchun ishlatiladi.

O'zgaruvchan tinglovchilar - bular qiymati so'rov o'zgaruvchilarni shakllantirish uchun ishlatiladigan o'zgaruvchilar.

Boshqa tomondan, 1a, 2a, 2b atrof-muhitga (apparat, tashqi resurslar va boshqalar) bog'liq bo'lmagan o'zgaruvchilardir va standart rolda standart qiymatlar bilan to'ldirilishi mumkin. Biroq, 1.b va 2.c tipidagi o'zgaruvchilarni "misol" dan boshqa qiymatlar bilan to'ldirish mumkin emas, chunki ular atrof-muhitga qarab stenddan stendga o'zgaradi.

Kod uslubi

  • O'zgaruvchi nomi rol nomi bilan boshlanishi kerak. Bu kelajakda o'zgaruvchining qanday rolga ega ekanligini va u nima uchun javobgar ekanligini aniqlashni osonlashtiradi.
  • Rollarda o'zgaruvchilardan foydalanganda, siz inkapsulyatsiya printsipiga rioya qilishingiz va rolning o'zida yoki joriy rolga bog'liq bo'lgan rollarda aniqlangan o'zgaruvchilardan foydalanishingiz kerak.
  • O'zgaruvchilar uchun lug'atlardan foydalanishdan saqlaning. Ansible lug'atdagi individual qiymatlarni qulay tarzda bekor qilishga imkon bermaydi.

    Yomon o'zgaruvchiga misol:

    myrole_user:
        login: admin
        password: admin

    Bu erda login mustaqil o'zgaruvchi, parol esa qaram o'zgaruvchidir. Lekin
    chunki ular lug'atga birlashtirilgan, siz uni to'liq ko'rsatishingiz kerak bo'ladi
    Har doim. Bu juda noqulay. Shu tarzda yaxshiroq:

    myrole_user_login: admin
    myrole_user_password: admin

Joylashtirish o'yin kitoblaridagi o'zgaruvchilar

O'rnatish kitobini (bundan buyon matnda o'yin kitobi deb yuritiladi) tuzishda biz uni alohida omborga joylashtirish qoidasiga amal qilamiz. Rollar bilan bir xil: har biri o'z git omborida. Bu sizga rollar va o'yin kitobi joylashtirish tizimining turli xil mustaqil ob'ektlari ekanligini tushunish imkonini beradi va bir ob'ektdagi o'zgarishlar ikkinchisining ishlashiga ta'sir qilmasligi kerak. Bunga o'zgaruvchilarning standart qiymatlarini o'zgartirish orqali erishiladi.

Xulosa qilib aytganda, o'yin kitobini tuzishda rol o'zgaruvchilarining standart qiymatlarini ikki joyda bekor qilish mumkin: o'yin kitobi o'zgaruvchilari va inventar o'zgaruvchilari.

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

* - O'zgaruvchilar va omborlar

Farqi shundaki, o'yin kitobi o'zgaruvchilari doimo u bilan bir xil darajada joylashgan o'yin kitoblarini chaqirishda ishlatiladi. Bu shuni anglatadiki, bu o'zgaruvchilar atrof-muhitga bog'liq bo'lmagan o'zgaruvchilarning standart qiymatlarini o'zgartirish uchun juda yaxshi. Aksincha, inventar o'zgaruvchilari faqat atrof-muhitga xos o'zgaruvchilar uchun ideal bo'lgan ma'lum bir muhit uchun ishlatiladi.

Shuni ta'kidlash kerakki, o'zgaruvchilar ustuvorligi o'zgaruvchilarni birinchi navbatda o'yin kitobidagi o'zgaruvchilarni, keyin esa bitta inventarda alohida belgilashga imkon bermaydi.

Bu shuni anglatadiki, ushbu bosqichda o'zgaruvchining atrof-muhitga bog'liqmi yoki yo'qligini hal qilish va uni tegishli joyga joylashtirish kerak.

Misol uchun, bitta loyihada SSL-ni yoqish uchun mas'ul bo'lgan o'zgaruvchi uzoq vaqt davomida atrof-muhitga bog'liq edi, chunki biz stendlardan birida o'zimizga bog'liq bo'lmagan sabablarga ko'ra SSL-ni faollashtira olmadik. Ushbu muammoni hal qilganimizdan so'ng, u muhitdan mustaqil bo'lib, o'yin kitobi o'zgaruvchilariga o'tdi.

Guruhlar uchun xossa oʻzgaruvchilari

Keling, 1-rasmdagi modelimizni boshqa Java ilovasi bo'lgan, lekin boshqa sozlamalarga ega bo'lgan 2 ta server guruhini qo'shish orqali kengaytiramiz.

Ansible'da o'zgaruvchilarga tizimli yondashuv

Keling, bu holda o'yin kitobi qanday ko'rinishini tasavvur qilaylik:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

O'yin kitobida bizda uchta guruh bor, shuning uchun darhol group_vars inventar o'zgaruvchilari va o'yin kitobi o'zgaruvchilarida bir xil miqdordagi guruh fayllarini yaratish tavsiya etiladi. Bu holda bitta guruh fayli o'yin kitobidagi yuqoridagi ilovaning bir komponentining tavsifi. O'yin kitobi o'zgaruvchilarida guruh faylini ochganingizda, siz darhol guruhga o'rnatilgan rollarning standart xatti-harakatlaridan barcha farqlarni ko'rasiz. Inventar o'zgaruvchilarda: stenddan stendgacha guruh xatti-harakatlaridagi farqlar.

Kod uslubi

  • host_vars o'zgaruvchilaridan umuman foydalanmaslikka harakat qiling, chunki ular tizimni tavsiflamaydi, faqat maxsus holat, bu kelajakda savollarga olib keladi: "Nima uchun bu xost boshqalardan farq qiladi?", javobi yo'q. har doim topish oson.

Aloqa o'zgaruvchilari

Biroq, bu xususiyat o'zgaruvchilari haqida, lekin aloqa o'zgaruvchilari haqida nima deyish mumkin?
Ularning farqi shundaki, ular turli guruhlarda bir xil ma'noga ega bo'lishi kerak.

Avvaliga shunday edi fikr kabi dahshatli qurilishdan foydalaning:
hostvars[groups['bbauth'][0]]['auth_bind_port'], lekin ular darhol rad etishdi
chunki uning kamchiliklari bor. Birinchidan, kattalik. Ikkinchidan, guruhdagi ma'lum bir xostga bog'liqlik. Uchinchidan, joylashtirishni boshlashdan oldin, agar biz aniqlanmagan o'zgaruvchining xatosini olishni istamasak, barcha xostlardan faktlarni to'plashimiz kerak.

Natijada, aloqa o'zgaruvchilardan foydalanishga qaror qilindi.

Aloqa o'zgaruvchilari - bular o'yin kitobiga tegishli bo'lgan va tizim ob'ektlarini ulash uchun zarur bo'lgan o'zgaruvchilar.

Aloqa o'zgaruvchilari umumiy tizim o'zgaruvchilari bilan to'ldirilgan group_vars/all/vars va har bir guruhdan barcha tinglovchi oʻzgaruvchilarni olib tashlash va oʻzgaruvchining boshiga tinglovchi olib tashlangan guruh nomini qoʻshish orqali hosil boʻladi.

Bu nomlarning bir xilligini va bir-biriga mos kelmasligini ta'minlaydi.

Keling, yuqoridagi misoldagi o'zgaruvchilarni bog'lashga harakat qilaylik:

Ansible'da o'zgaruvchilarga tizimli yondashuv

Tasavvur qilaylik, bizda bir-biriga bog'liq bo'lgan o'zgaruvchilar bor:

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

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

Keling, uni umumiy o'zgaruvchilarga kiritamiz group_vars/all/vars barcha tinglovchilar va guruh nomini sarlavhaga qo'shing:

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

Endi ulagichning qiymatini o'zgartirib, so'rov port joylashgan joyga o'tishiga ishonch hosil qilamiz.

Kod uslubi

  • Rollar va guruhlar turli xil tizim ob'ektlari bo'lganligi sababli, ular turli nomlarga ega bo'lishi kerak, keyin havola o'zgaruvchilari tizimdagi rolga emas, balki ma'lum bir serverlar guruhiga tegishli ekanligini aniq ko'rsatadi.

Atrof muhitga bog'liq fayllar

Rollar muhitdan muhitga farq qiluvchi fayllardan foydalanishi mumkin.

Bunday fayllarga SSL sertifikatlari misol bo'la oladi. Ularni matn shaklida saqlang
o'zgaruvchida unchalik qulay emas. Ammo ularga yo'lni o'zgaruvchida saqlash qulay.

Masalan, biz o'zgaruvchidan foydalanamiz api_ssl_key_file: "/path/to/file".

Kalit sertifikati muhitdan muhitga o'zgarishi aniq bo'lgani uchun, bu atrof-muhitga bog'liq o'zgaruvchidir, ya'ni u faylda joylashgan bo'lishi kerak.
group_vars/myapi/vars o'zgaruvchilar inventarizatsiyasi va "masalan," qiymatini o'z ichiga oladi.

Bu holda eng qulay usul kalit faylni yo'l bo'ylab o'yin kitobi omboriga qo'yishdir
files/prod/certs/myapi.key, keyin o'zgaruvchining qiymati quyidagicha bo'ladi:
api_ssl_key_file: "prod/certs/myapi.key". Qulaylik shundan iboratki, tizimni ma'lum bir stendda joylashtirish uchun mas'ul bo'lgan odamlar o'z fayllarini saqlash uchun omborda o'zlarining maxsus joylariga ega. Shu bilan birga, agar sertifikatlar boshqa tizim tomonidan taqdim etilgan bo'lsa, serverda sertifikatga mutlaq yo'lni belgilash mumkin bo'ladi.

Bir muhitda bir nechta stendlar

Ko'pincha bir xil muhitda bir nechta deyarli bir xil stendlarni minimal farqlar bilan joylashtirishga ehtiyoj bor. Bunday holda, biz muhitga bog'liq o'zgaruvchilarni ushbu muhit ichida o'zgarmaydigan va o'zgaruvchanlarga ajratamiz. Va biz ikkinchisini to'g'ridan-to'g'ri inventar fayllariga o'tkazamiz. Ushbu manipulyatsiyadan so'ng, to'g'ridan-to'g'ri atrof-muhit katalogida boshqa inventarni yaratish mumkin bo'ladi.

U group_vars inventarini qayta ishlatadi va ba'zi o'zgaruvchilarni to'g'ridan-to'g'ri o'zi uchun qayta aniqlay oladi.

Joylashtirish loyihasi uchun yakuniy katalog tuzilishi:

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

Xulosa qilish

Maqolaga muvofiq o'zgaruvchilarni tashkil qilgandan so'ng: har bir o'zgaruvchan fayl ma'lum bir vazifa uchun javobgardir. Va fayl ma'lum vazifalarga ega bo'lganligi sababli, har bir faylning to'g'riligi uchun mas'ul shaxsni tayinlash mumkin bo'ldi. Masalan, tizimni o'rnatishni ishlab chiquvchi o'yin kitobi o'zgaruvchilarini to'g'ri to'ldirish uchun javobgar bo'ladi, inventarda tavsiflangan ma'mur esa o'zgaruvchilar inventarini to'ldirish uchun bevosita javobgardir.

Rollar o'zlarining interfeysi bilan o'zlarining ishlab chiqish birligiga aylandi, bu rolni ishlab chiquvchiga rolni tizimga moslashtirmasdan, qobiliyatlarni rivojlantirishga imkon beradi. Bu muammo, ayniqsa, kampaniyadagi barcha tizimlar uchun umumiy rollarga tegishli edi.

Tizim ma'murlari endi tarqatish kodini tushunishlari shart emas. Muvaffaqiyatli joylashtirish uchun ulardan talab qilinadigan narsa atrof-muhitga bog'liq o'zgaruvchilar fayllarini to'ldirishdir.

adabiyot

  1. hujjatlar

muallif

Kalyujniy Denis Aleksandrovich

Manba: www.habr.com

a Izoh qo'shish