ansible devops код стили
Эй! Менин атым Мен иштеп чыгуу процесстерин автоматташтыруу бөлүмүндө инженер болуп иштейм. Күн сайын жүздөгөн өнөктүк серверлеринде жаңы тиркемелер түзүлөт. Жана бул макалада мен ушул максаттар үчүн Ansible колдонуу тажрыйбам менен бөлүшөм.
Бул колдонмо жайылтууда өзгөрмөлөрдү уюштуруунун жолун сунуш кылат. Бул колдонмо өз китептеринде ролдорду мурунтан эле колдонгон жана окугандар үчүн арналган , бирок окшош көйгөйлөргө дуушар болот:
- Коддо өзгөрмө тапкандан кийин, ал эмне үчүн жооптуу экенин дароо түшүнүү мүмкүн эмес;
- Бир нече ролдор бар, жана өзгөрмөлөр бир мааниге байланыштуу болушу керек, бирок ал иштебейт;
- Оюн китептериңиздеги өзгөрмөлөрдүн логикасы кантип иштээрин башкаларга түшүндүрүп берүү кыйынга турат
Биз бул көйгөйлөргө биздин компаниядагы долбоорлордо туш болдук, натыйжада биз бул көйгөйлөрдү кандайдыр бир деңгээлде чечкен оюн китептерибизде өзгөрмөлөрдү долбоорлоо эрежелерине келдик.
Ролдордогу өзгөрмөлөр
Рол - жайылтуу тутумунун өзүнчө объектиси. Ар кандай система объектиси сыяктуу эле, ал системанын калган бөлүгү менен өз ара аракеттенүү үчүн интерфейске ээ болушу керек. Мындай интерфейс ролдук өзгөрмөлөр болуп саналат.
Мисалы, ролду алалы api, серверге Java тиркемесин орнотот. Ал кандай өзгөрмөлөргө ээ болушу мүмкүн?
Өзгөрмө ролдор түрүнө жараша 2 түргө бөлүнөт:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Өзгөрмө касиеттери ролдун жүрүм-турумун аныктоочу өзгөрмөлөр.
Query Variables - бул ролго тышкы ресурстарды белгилөө үчүн мааниси колдонулган өзгөрмөлөр.
Өзгөрмө угуучулар - бул өзгөрмөлөр, алардын мааниси сурам өзгөрмөлөрүн түзүү үчүн колдонулат.
Башка жагынан алганда, 1a, 2a, 2b чөйрөгө көз каранды эмес өзгөрмөлөр (аппараттык камсыздоо, тышкы ресурстар, ж.б.) жана демейки ролдо демейки маанилер менен толтурулат. Бирок, 1.b жана 2.c түрүндөгү өзгөрмөлөрдү "мисалы" эмес, башка маанилер менен толтуруу мүмкүн эмес, анткени алар айлана-чөйрөгө жараша стендден стендге өзгөрөт.
Код стили
- Өзгөрмө аты роль аты менен башталышы керек. Бул келечекте өзгөрмө кандай роль ойноорун жана ал эмне үчүн жооптуу экенин аныктоону жеңилдетет.
- Ролдордо өзгөрмөлөрдү колдонууда, сиз инкапсуляция принцибине баш ийип, ролдун өзүндө же учурдагы ролдордо аныкталган өзгөрмөлөрдү колдонушуңуз керек.
-
Өзгөрмөлөр үчүн сөздүктөрдү колдонуудан качыңыз. Ansible сөздүктөгү жеке баалуулуктарды оңой эле жокко чыгарууга жол бербейт.
Начар өзгөрмөнүн мисалы:
myrole_user: login: admin password: adminБул жерде логин көз карандысыз өзгөрмө, ал эми сырсөз көз каранды өзгөрмө болуп саналат. Бирок
алар сөздүккө бириктирилгендиктен, аны толугу менен көрсөтүүгө туура келет
Ар дайым. Бул абдан ыңгайсыз. Бул жакшыраак:myrole_user_login: admin myrole_user_password: admin
Жайгаштыруу окуу китептериндеги өзгөрмөлөр
Жайгаштыруу окуу китебин (мындан ары - окуу китеби) түзүүдө биз аны өзүнчө репозиторийге жайгаштыруу керек деген эрежени карманабыз. Ролдор сыяктуу: ар бири өзүнүн гит репозиторийинде. Бул ролдор жана оюн китеби жайгаштыруу тутумунун ар кандай көз карандысыз объектилери экенин түшүнүүгө мүмкүндүк берет жана бир объекттеги өзгөртүүлөр экинчисинин иштешине таасир этпеши керек. Бул өзгөрмөлөрдүн демейки маанилерин өзгөртүү аркылуу жетишилет.
Оюн китебин түзүп жатканда, кыскача айтканда, ролдук өзгөрмөлөрдүн демейки маанилерин эки жерде жокко чыгарууга болот: оюн китебинин өзгөрмөлөрүндө жана инвентарь өзгөрмөлөрүндө.
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-сүрөттөгү моделибизди кеңейтип көрөлү, башка Java тиркемеси бар, бирок башка орнотуулары бар серверлердин 2 тобун кошуу.
Келгиле, бул учурда оюн китеби кандай болорун элестетип көрөлү:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authОюн китебинде бизде үч топ бар, ошондуктан дароо group_vars инвентаризациясынын өзгөрмөлөрүндө жана оюн китебинин өзгөрмөлөрүндө бирдей сандагы топ файлдарын түзүү сунушталат. Бул учурда бир топ файлы - бул оюн китебиндеги жогорудагы тиркеменин бир компонентинин сүрөттөлүшү. Оюн китебинин өзгөрмөлөрүндө топ файлын ачканда, топко орнотулган ролдордун демейки жүрүм-турумунан бардык айырмачылыктарды дароо көрөсүз. Инвентаризация өзгөрмөлөрүндө: стендден стендге топтун жүрүм-турумундагы айырмачылыктар.
код стили
- host_vars өзгөрмөлөрүн такыр колдонбогонго аракет кылыңыз, анткени алар системаны сүрөттөбөйт, бирок келечекте: “Эмне үчүн бул хост башкалардан айырмаланып турат?” деген суроолорго алып келе турган өзгөчө жагдай. табуу ар дайым оңой.
Communication Variables
Бирок, бул касиеттин өзгөрмөлөрү жөнүндө, бирок байланыш өзгөрмөлөрү жөнүндө эмне айтууга болот?
Алардын айырмачылыгы ар кандай топтордо бирдей мааниге ээ болушу керек.
Башында ошондой болгон сыяктуу укмуштуудай курулушту колдонуңуз:
hostvars[groups['bbauth'][0]]['auth_bind_port'], бирок алар дароо четке кагышты
анткени анын кемчиликтери бар. Биринчиден, көлөмдүү. Экинчиден, топтогу белгилүү бир хостко көз карандылык. Үчүнчүдөн, жайылтууну баштоодон мурун, эгерде биз аныкталбаган өзгөрмөнүн катасын алгыбыз келбесе, бардык хосттордон фактыларды чогултуу керек.
Натыйжада, байланыш өзгөрмөлөрүн колдонуу чечими кабыл алынды.
Communication Variables - бул ойноо китебине таандык өзгөрмөлөр жана система объекттерин туташтыруу үчүн зарыл.
Байланыш өзгөрмөлөрү жалпы система өзгөрмөлөрүндө жайгаштырылат 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Жыйынтыктоо
Макалага ылайык өзгөрмөлөрдү уюштургандан кийин: ар бир өзгөрмө файл белгилүү бир тапшырма үчүн жооп берет. Ал эми файлда белгилүү бир тапшырмалар болгондуктан, ар бир файлдын тууралыгы үчүн жооптуу адамды дайындоо мүмкүн болду. Мисалы, системаны жайылтууну иштеп чыгуучу оюн китепчесинин өзгөрмөлөрүнүн туура толтурулушу үчүн жооптуу болот, ал эми стенди инвентаризацияда сүрөттөлгөн администратор өзгөрмөлөрдүн инвентаризациясын толтурууга түздөн-түз жооп берет.
Ролдор өз интерфейси менен өздөрүнүн өнүктүрүү бирдигине айланган, бул ролду иштеп чыгуучуга ролду системага ылайыкташтырбастан, мүмкүнчүлүктөрдү өнүктүрүүгө мүмкүндүк берет. Бул көйгөй өзгөчө кампаниядагы бардык системалар үчүн жалпы ролдорго тиешелүү.
Системалык администраторлор мындан ары жайылтуу кодун түшүнүшү керек эмес. Ийгиликтүү жайылтуу үчүн алардан талап кылынган нерсе - бул айлана-чөйрөгө көз каранды өзгөрмөлөрдүн файлдарын толтуруу.
адабият
жазуучу
Калюжный Денис Александрович
Source: www.habr.com