🥇 Համակարգված մոտեցում փոփոխականներին 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   # Секреты (всегда средозависимы) *

* - Փոփոխականներ և պահոցներ

Տարբերությունն այն է, որ playbook փոփոխականները միշտ օգտագործվում են այն ժամանակ, երբ զանգում են խաղատետրեր, որոնք գտնվում են դրա հետ նույն մակարդակում: Սա նշանակում է, որ այս փոփոխականները հիանալի են շրջակա միջավայրից չկախված փոփոխականների լռելյայն արժեքները փոխելու համար: Ընդհակառակը, գույքագրման փոփոխականները կօգտագործվեն միայն որոշակի միջավայրի համար, որն իդեալական է շրջակա միջավայրին հատուկ փոփոխականների համար:

Կարևոր է նշել, որ փոփոխականների գերակայությունը ձեզ թույլ չի տա վերորոշել փոփոխականները սկզբում խաղատախտակի փոփոխականներում, ապա առանձին՝ նույն գույքագրում:

Սա նշանակում է, որ արդեն այս փուլում դուք պետք է որոշեք՝ փոփոխականը կախված է շրջակա միջավայրից, թե ոչ և տեղադրեք այն ճիշտ տեղում։

Օրինակ, մեկ նախագծում SSL-ի միացման համար պատասխանատու փոփոխականը երկար ժամանակ կախված էր շրջակա միջավայրից, քանի որ մենք չէինք կարող միացնել SSL-ը կանգառներից մեկում մեր վերահսկողությունից անկախ պատճառներով: Այն բանից հետո, երբ մենք շտկեցինք այս խնդիրը, այն դարձավ միջին անկախ և տեղափոխվեց «Playbook» փոփոխականներ:

Հատկությունների փոփոխականներ խմբերի համար

Եկեք ընդլայնենք մեր մոդելը Նկար 1-ում` ավելացնելով սերվերների 2 խումբ տարբեր Java հավելվածով, բայց տարբեր կարգավորումներով:

Պատկերացրեք, թե ինչպիսին կլինի խաղագիրքը այս դեպքում.

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Մենք ունենք երեք խումբ playbook-ում, ուստի խորհուրդ է տրվում ստեղծել նույնքան խմբային ֆայլեր group_vars գույքագրման փոփոխականներում և playbook փոփոխականներում: Այս դեպքում խմբային ֆայլերից մեկը ձեր հավելվածի մեկ բաղադրիչի նկարագրությունն է խաղագրքում: Երբ բացում եք խմբային ֆայլը playbook փոփոխականներում, դուք անմիջապես տեսնում եք խմբին հատկացված դերերի լռելյայն վարքագծի բոլոր տարբերությունները: Գույքագրման փոփոխականներում. խմբային վարքագծի տարբերությունները տաղավարից տաղավար:

կոդի ոճը

Փորձեք ընդհանրապես չօգտագործել 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 փոփոխականների գույքագրում և պարունակում է «օրինակ» արժեքը:

Այս դեպքում ամենահարմար միջոցը բանալի ֆայլը playbook-ի պահոցում դնելն է ճանապարհի երկայնքով
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

Ամփոփելով

Փոփոխականները հոդվածին համապատասխան կազմակերպելուց հետո՝ փոփոխականներով յուրաքանչյուր ֆայլ պատասխանատու է որոշակի առաջադրանքի համար։ Եվ քանի որ ֆայլը որոշակի առաջադրանքներ ունի, հնարավոր է դարձել յուրաքանչյուր ֆայլի կոռեկտության համար պատասխանատու նշանակել։ Օրինակ, համակարգի տեղակայման մշակողը պատասխանատու է դառնում խաղային գրքույկի փոփոխականների ճիշտ լրացման համար, մինչդեռ ադմինիստրատորը, որի դիրքը նկարագրված է գույքագրում, ուղղակիորեն պատասխանատու է փոփոխականների գույքագրումը լրացնելու համար:

Դերերը դարձան ինքնուրույն մշակման միավոր՝ իրենց սեփական ինտերֆեյսով, որը թույլ էր տալիս դեր մշակողին զարգացնել առանձնահատկությունները, այլ ոչ թե դերը հարմարեցնել համակարգին: Այս խնդիրը հատկապես ճիշտ էր քարոզարշավում բոլոր համակարգերի ընդհանուր դերերի համար:

Համակարգի ադմինիստրատորներն այլևս կարիք չունեն հասկանալու տեղակայման կոդը: Հաջող տեղակայման համար նրանցից պահանջվում է միայն շրջակա միջավայրի փոփոխականների ֆայլերը լրացնելը:

Գրականություն

Փաստաթղթերով հիմնավորում

Հեղինակ

Կալյուժնի Դենիս Ալեքսանդրովիչ

Source: www.habr.com

Համակարգային մոտեցում փոփոխականներին Ansible-ում

Փոփոխականներ դերերում

կոդի ոճը

Փոփոխականներ տեղակայման գրքույկներում

Հատկությունների փոփոխականներ խմբերի համար

կոդի ոճը

Կապել փոփոխականները

կոդի ոճը

Շրջակա միջավայրի ֆայլեր

Բազմաթիվ ստենդեր մեկ միջավայրում

Տեղակայման նախագծի վերջնական գրացուցակի կառուցվածքը.

Ամփոփելով

Գրականություն

Հեղինակ

Добавить комментарий Չեղարկել պատասխանել