Ansible-ში ცვლადებისადმი სისტემური მიდგომა

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

  აქ შესვლა არის დამოუკიდებელი ცვლადი, ხოლო პაროლი არის დამოკიდებული ცვლადი. მაგრამ
  რადგან ისინი გაერთიანებულია ლექსიკონში, თქვენ მოგიწევთ მისი სრულად დაზუსტება
  ყოველთვის. რაც ძალიან მოუხერხებელია. ასე ჯობია:

  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-ს ერთ-ერთ სტენდზე ჩვენი კონტროლის მიღმა მიზეზების გამო. მას შემდეგ რაც ეს პრობლემა მოვაგვარეთ, ის გარემოდან დამოუკიდებელი გახდა და გადავიდა სათამაშო წიგნის ცვლადებზე.

თვისებების ცვლადები ჯგუფებისთვის

მოდით გავაფართოვოთ ჩვენი მოდელი სურათზე 1, სერვერების 2 ჯგუფის დამატებით Java აპლიკაციით, მაგრამ განსხვავებული პარამეტრებით.

წარმოვიდგინოთ, როგორი იქნება სათამაშო წიგნი ამ შემთხვევაში:

- 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

შეჯამება

სტატიის შესაბამისად ცვლადების ორგანიზების შემდეგ: თითოეული ცვლადის ფაილი პასუხისმგებელია კონკრეტულ ამოცანაზე. და რადგან ფაილს აქვს გარკვეული დავალებები, შესაძლებელი გახდა თითოეული ფაილის სისწორეზე პასუხისმგებელი პირის დანიშვნა. მაგალითად, სისტემის განლაგების დეველოპერი პასუხისმგებელი ხდება სათამაშო წიგნის ცვლადების სწორად შევსებაზე, ხოლო ადმინისტრატორი, რომლის სტენდი აღწერილია ინვენტარში, პირდაპირ პასუხისმგებელია ცვლადების ინვენტარის შევსებაზე.

როლები გახდა მათი განვითარების ერთეული საკუთარი ინტერფეისით, რაც როლის შემქმნელს საშუალებას აძლევდა განავითაროს შესაძლებლობები და არა როლი სისტემაზე მორგებული. ეს პრობლემა განსაკუთრებით ეხებოდა კამპანიაში ყველა სისტემის საერთო როლებს.

სისტემის ადმინისტრატორებს აღარ სჭირდებათ განლაგების კოდის გაგება. ყველაფერი, რაც მათგან არის საჭირო წარმატებული განლაგებისთვის, არის გარემოზე დამოკიდებული ცვლადების ფაილების შევსება.

ლიტერატურა

1. დოკუმენტაცია

ავტორი

კალუჟნი დენის ალექსანდროვიჩი

წყარო: www.habr.com