🥇Ansible | дахь хувьсагчдад системчилсэн хандлага ProHoster

ansible devops codestyle

Хөөе! Миний нэр Денис Калюжный Би хөгжлийн процессын автоматжуулалтын хэлтэст инженерээр ажилладаг. Өдөр бүр олон зуун кампанит ажлын серверүүд дээр шинэ програм хангамжууд гарч ирдэг. Мөн энэ нийтлэлд би Ansible-г эдгээр зорилгоор ашиглах туршлагаа хуваалцаж байна.

Энэхүү гарын авлага нь байршуулалт дахь хувьсагчдыг зохион байгуулах арга замыг санал болгож байна. Энэхүү гарын авлага нь тоглоомын номондоо дүрүүдийг ашиглаж, уншсан хүмүүст зориулагдсан болно Шилдэг туршлагууд, гэхдээ ижил төстэй асуудлуудтай тулгардаг:

Код дахь хувьсагчийг олсны дараа энэ нь юу хариуцаж байгааг шууд ойлгох боломжгүй юм;
Хэд хэдэн үүрэг байдаг бөгөөд хувьсагчдыг нэг утгатай холбох шаардлагатай боловч энэ нь зүгээр л ажиллахгүй байна;
Тоглоомын дэвтэрт байгаа хувьсагчдын логик хэрхэн ажилладагийг бусдад тайлбарлахад хүндрэлтэй байна

Манай компаний төслүүд дээр бид эдгээр асуудлуудтай тулгарсан бөгөөд үүний үр дүнд бид тоглоомын номондоо хувьсагчдыг төлөвлөх дүрэмтэй болсон бөгөөд энэ нь эдгээр асуудлыг тодорхой хэмжээгээр шийдсэн.

Үүрэг дэх хувьсагчид

Үүрэг нь байршуулах системийн тусдаа объект юм. Аливаа системийн объектын нэгэн адил энэ нь системийн бусад хэсгүүдтэй харилцах интерфейстэй байх ёстой. Ийм интерфэйс нь дүрийн хувьсагч юм.

Жишээлбэл, дүрийг авч үзье api, сервер дээр Java програм суулгадаг. Үүнд ямар хувьсагч байж болох вэ?

Хувьсах үүргийг төрлөөр нь 2 төрөлд хувааж болно.

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

Хувьсах шинж чанарууд нь дүрийн зан төлөвийг тодорхойлдог хувьсагч юм.

Хувьсагчдыг асуулга - эдгээр нь дүрд хамаарах гадаад нөөцийг тодорхойлоход утгыг ашигладаг хувьсагч юм.

Хувьсах сонсогчид - эдгээр нь хүсэлтийн хувьсагчийг бүрдүүлэхэд утгыг нь ашигладаг хувьсагчид юм.

Нөгөө талаас, 1a, 2a, 2b нь хүрээлэн буй орчноос (техник хангамж, гадаад нөөц гэх мэт) хамаардаггүй хувьсагч бөгөөд анхдагч дүрд анхдагч утгуудаар дүүргэж болно. Гэсэн хэдий ч 1.b ба 2.c төрлийн хувьсагчдыг "жишээ" -ээс өөр утгуудаар дүүргэх боломжгүй, учир нь тэдгээр нь хүрээлэн буй орчноос хамааран стендээс стенд болгон өөрчлөгддөг.

Кодын хэв маяг

Хувьсагчийн нэр нь дүрийн нэрээр эхлэх ёстой. Энэ нь ирээдүйд хувьсагч ямар үүрэг гүйцэтгэдэг, ямар үүрэгтэйг тодорхойлоход хялбар болгоно.
Хувьсагчдыг дүрд ашиглахдаа та дүрд хуваах зарчмыг баримталж, дүрд эсвэл одоогийн дүрд тодорхойлогдсон хувьсагчдыг ашиглах ёстой.
Хувьсагчдад зориулсан толь бичиг ашиглахаас зайлсхий. Ansible нь толь бичигт хувь хүний утгыг хялбархан дарж бичихийг зөвшөөрдөггүй.

Муу хувьсагчийн жишээ:
```
myrole_user:
    login: admin
    password: admin
```
Энд login нь бие даасан хувьсагч, нууц үг нь хамааралтай хувьсагч юм. Гэхдээ
Тэдгээрийг толь бичигт нэгтгэсэн тул та үүнийг бүрэн зааж өгөх хэрэгтэй болно
Үргэлж. Энэ нь маш эвгүй юм. Ингэж илүү сайн:
```
myrole_user_login: admin
myrole_user_password: admin
```

Байршуулах тоглоомын дэвтэр дэх хувьсагч

Байршуулах тоглоомын дэвтэр (цаашид тоглоомын дэвтэр гэх) эмхэтгэхдээ бид үүнийг тусдаа хадгалах газарт байрлуулах дүрмийг баримталдаг. Дүртэй адил: тус бүр өөрийн git репозитортой. Энэ нь үүрэг, тоглоомын дэвтэр нь байршуулах системийн өөр өөр бие даасан объектууд бөгөөд нэг объектын өөрчлөлт нь нөгөө объектын үйл ажиллагаанд нөлөөлөх ёсгүй гэдгийг ойлгох боломжийг танд олгоно. Энэ нь хувьсагчдын анхдагч утгыг өөрчлөх замаар хийгддэг.

Тоглуулах номыг эмхэтгэхдээ нэгтгэн дүгнэвэл, дүрийн хувьсагчийн үндсэн утгыг хоёр газар дарж болно: тоглоомын номын хувьсагчид болон бараа материалын хувьсагчид.

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

* - Хувьсагч ба хадгалалт

Ялгаа нь үүнтэй ижил түвшинд байрлах тоглоомын номыг дуудахдаа тоглуулах номын хувьсагчдыг үргэлж ашигладаг. Энэ нь эдгээр хувьсагч нь орчноос хамааралгүй хувьсагчдын анхдагч утгыг өөрчлөхөд тохиромжтой гэсэн үг юм. Үүний эсрэгээр, бараа материалын хувьсагчдыг зөвхөн тодорхой орчинд ашиглах бөгөөд энэ нь хүрээлэн буй орчны өвөрмөц хувьсагчдад тохиромжтой.

Хувьсагчийн тэргүүлэх чиглэл нь эхлээд тоглоомын номын хувьсагчид, дараа нь нэг бүртгэлд тусад нь хувьсагчдыг хүчингүй болгохыг зөвшөөрөхгүй гэдгийг анхаарах нь чухал юм.

Энэ нь аль хэдийн энэ үе шатанд хувьсагч нь хүрээлэн буй орчноос хамааралтай эсэхийг шийдэж, зохих газарт нь байрлуулах шаардлагатай гэсэн үг юм.

Жишээлбэл, нэг төсөлд SSL-г идэвхжүүлэх үүрэгтэй хувьсагч нь хүрээлэн буй орчноос удаан хугацааны туршид хамааралтай байсан, учир нь бид аль нэг стенд дээр биднээс үл хамаарах шалтгаанаар SSL-г идэвхжүүлж чадаагүй. Бид энэ асуудлыг зассаны дараа энэ нь орчноос хамааралгүй болж, тоглоомын номын хувьсагч руу шилжсэн.

Бүлэгт зориулсан өмчийн хувьсагч

Өөр Java програмтай, гэхдээ өөр өөр тохиргоотой 1 бүлэг серверүүдийг нэмж Зураг 2-т загвараа өргөжүүлье.

Энэ тохиолдолд тоглоомын дэвтэр ямар харагдахыг төсөөлөөд үз дээ:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Бид тоглоомын номонд гурван бүлэгтэй тул group_vars бараа материалын хувьсагч болон тоглуулах номын хувьсагчид ижил тооны бүлгийн файл үүсгэхийг нэн даруй зөвлөж байна. Энэ тохиолдолд нэг бүлгийн файл нь тоглоомын дэвтэр дээрх дээрх програмын нэг бүрэлдэхүүн хэсгийн тайлбар юм. Тоглуулах номын хувьсагчид бүлгийн файлыг нээх үед та бүлэгт суулгасан дүрүүдийн үндсэн үйлдлээс бүх ялгааг шууд харах болно. Бараа материалын хувьсагчид: бүлгийн зан байдлын ялгаа.

Кодын хэв маяг

Host_vars хувьсагчдыг огт ашиглахгүй байхыг хичээгээрэй, учир нь тэдгээр нь системийг дүрсэлдэггүй, гэхдээ зөвхөн онцгой тохиолдол байдаг бөгөөд энэ нь ирээдүйд "Яагаад энэ хост бусдаас ялгаатай вэ?" Гэсэн асуултад хүргэх бөгөөд хариулт нь тийм биш юм. үргэлж олоход хялбар байдаг.

Харилцааны хувьсагчид

Гэсэн хэдий ч, энэ нь өмчийн хувьсагчдад хамаатай зүйл юм, гэхдээ харилцааны хувьсагчийн талаар юу хэлэх вэ?
Тэдний ялгаа нь өөр өөр бүлгүүдэд ижил утгатай байх ёстой.

Эхэндээ тийм байсан санаа гэх мэт аймшигт бүтээн байгуулалтыг ашигла:
hostvars[groups['bbauth'][0]]['auth_bind_port'], гэхдээ тэд шууд татгалзсан
учир нь энэ нь сул талуудтай. Нэгдүгээрт, том байдал. Хоёрдугаарт, бүлгийн тодорхой хостоос хамааралтай байх. Гуравдугаарт, байрлуулж эхлэхээсээ өмнө тодорхойгүй хувьсагчийн алдаа авахыг хүсэхгүй байгаа бол бүх хостуудаас баримт цуглуулах шаардлагатай.

Үүний үр дүнд харилцааны хувьсагчдыг ашиглахаар шийдсэн.

Харилцааны хувьсагчид - эдгээр нь тоглоомын дэвтэрт хамаарах хувьсагч бөгөөд системийн объектуудыг холбоход шаардлагатай байдаг.

Харилцаа холбооны хувьсагчдыг системийн ерөнхий хувьсагчдад оруулсан болно group_vars/all/vars ба бүлэг тус бүрээс бүх сонсогчийн хувьсагчийг хасч, хувьсагчийн эхэнд сонсогч хасагдсан бүлгийн нэрийг нэмэх замаар үүсдэг.

Энэ нь нэрсийн нэгдмэл байдал, давхцалгүй байдлыг баталгаажуулдаг.

Дээрх жишээн дээрх хувьсагчдыг холбохыг оролдъё:

Бид бие биенээсээ хамааралтай хувьсагчтай гэж төсөөлөөд үз дээ:

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

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

Үүнийг нийтлэг хувьсагчдад оруулъя group_vars/all/vars бүх сонсогч, бүлгийн нэрийг гарчигт нэмнэ үү:

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

Одоо холбогчийн утгыг өөрчилснөөр хүсэлт нь порт байрладаг газар руу очих болно гэдэгт итгэлтэй байх болно.

Кодын хэв маяг

Гүйцэтгэх үүрэг, бүлгүүд нь өөр өөр системийн объектууд тул өөр өөр нэртэй байх шаардлагатай тул холбоосын хувьсагч нь тэдгээр нь систем дэх үүрэг биш харин тодорхой сервер бүлэгт харьяалагддаг болохыг үнэн зөв харуулах болно.

Байгаль орчны хамааралтай файлууд

Үүрэг нь орчноос хүрээлэн буй орчинд өөр өөр файлуудыг ашиглаж болно.

Ийм файлуудын жишээ бол SSL сертификат юм. Тэдгээрийг текст хэлбэрээр хадгална уу
хувьсагчийн хувьд тийм ч тохиромжтой биш юм. Гэхдээ хувьсагчийн дотор тэдэнд хүрэх замыг хадгалах нь тохиромжтой.

Жишээлбэл, бид хувьсагчийг ашигладаг api_ssl_key_file: "/path/to/file".

Түлхүүр гэрчилгээ нь орчноос хүрээлэн буй орчинд өөрчлөгдөх нь тодорхой тул энэ нь хүрээлэн буй орчноос хамааралтай хувьсагч бөгөөд энэ нь файлд байрлах ёстой гэсэн үг юм.
group_vars/myapi/vars хувьсагчдын тооллого, "жишээ нь" гэсэн утгыг агуулна.

Энэ тохиолдолд хамгийн тохиромжтой арга бол түлхүүр файлыг тоглоомын номын санд зам дагуу байрлуулах явдал юм
files/prod/certs/myapi.key, тэгвэл хувьсагчийн утга нь:
api_ssl_key_file: "prod/certs/myapi.key". Тохиромжтой тал нь системийг тодорхой суурин дээр байрлуулах үүрэгтэй хүмүүс хадгалах санд файлаа хадгалах зориулалтын зайтай байдагт оршино. Үүний зэрэгцээ, гэрчилгээг өөр системээр хангасан тохиолдолд сервер дээрх гэрчилгээний үнэмлэхүй замыг зааж өгөх боломжтой хэвээр байна.

Нэг орчинд олон зогсоол

Ихэнхдээ ижил орчинд хамгийн бага ялгаа бүхий хэд хэдэн бараг ижил тавиуруудыг байрлуулах шаардлагатай байдаг. Энэ тохиолдолд бид орчноос хамааралтай хувьсагчдыг энэ орчинд өөрчлөгддөггүй, өөрчлөгддөг гэж хуваадаг. Мөн бид сүүлчийнх нь бараа материалын файл руу шууд шилжүүлдэг. Энэхүү заль мэхийг хийсний дараа хүрээлэн буй орчны лавлах хэсэгт шууд өөр бараа материал үүсгэх боломжтой болно.

Энэ нь group_vars тооллогыг дахин ашиглахаас гадна зарим хувьсагчдыг өөртөө шууд дахин тодорхойлох боломжтой болно.

Байршуулах төслийн эцсийн лавлах бүтэц:

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

Дүгнэх

Өгүүллийн дагуу хувьсагчдыг зохион байгуулсны дараа: хувьсагчийн файл бүр тодорхой ажлыг хариуцдаг. Файл нь тодорхой даалгавартай тул файл бүрийн зөв байдлыг хариуцах хүнийг томилох боломжтой болсон. Жишээлбэл, системийн байршуулалтыг хөгжүүлэгч нь тоглоомын номын хувьсагчдыг зөв бөглөхийг хариуцдаг бол бараа материалын жагсаалтад байгаа администратор нь хувьсагчийн бүртгэлийг бөглөх үүрэгтэй.

Дүрүүд нь өөрийн гэсэн интерфэйстэй хөгжлийн нэгж болж, үүрэг гүйцэтгэгчид дүрийг системд тохируулахаас илүүтэйгээр чадвараа хөгжүүлэх боломжийг олгосон. Энэ асуудал нь ялангуяа кампанит ажлын бүх системүүдийн нийтлэг үүрэг хариуцлагатай холбоотой байв.

Системийн администраторууд байршуулалтын кодыг ойлгох шаардлагагүй болсон. Амжилттай байршуулахын тулд тэднээс шаардлагатай бүх зүйл бол орчноос хамааралтай хувьсагчийн файлуудыг бөглөх явдал юм.

Уран зохиол

Баримт бичиг

зохиогч

Калюжный Денис Александрович

Эх сурвалж: www.habr.com

Ansible дахь хувьсагчдад системийн хандлага

Үүрэг дэх хувьсагчид

Кодын хэв маяг

Байршуулах тоглоомын дэвтэр дэх хувьсагч

Бүлэгт зориулсан өмчийн хувьсагч

Кодын хэв маяг

Харилцааны хувьсагчид

Кодын хэв маяг

Байгаль орчны хамааралтай файлууд

Нэг орчинд олон зогсоол

Байршуулах төслийн эцсийн лавлах бүтэц:

Дүгнэх

Уран зохиол

зохиогч

сэтгэгдэл нэмэх хариу цуцлах