Эгерде сиздин IT инфраструктураңыз өтө тез өссө, сиз эртеби-кечпи тандоого туш болосуз: аны колдоо үчүн адам ресурстарын сызыктуу түрдө көбөйтүү же автоматташтыруу. Кайсы бир учурга чейин биз биринчи парадигмада жашадык, андан кийин Инфраструктура-Кодка карай узак жол башталды.
Албетте, NSPK стартап эмес, бирок мындай атмосфера компаниянын пайда болушунун алгачкы жылдарында өкүм сүргөн жана ал абдан кызыктуу жылдар болгон. Менин атым , Мен 10 жылдан ашык убакыттан бери жогорку жеткиликтүүлүк талаптары бар Linux инфраструктурасын колдоп келем. Ал NSPK командасына 2016-жылдын январында кошулган жана, тилекке каршы, компаниянын пайда болушунун эң башталышын көргөн эмес, бирок чоң өзгөрүүлөрдүн этабында келген.
Жалпысынан биздин коллектив ишканага 2 продукция берет деп айта алабыз. Биринчиси - инфраструктура. Почта иштеши керек, DNS иштеши керек жана домен контроллерлору бузулбашы керек болгон серверлерге кирүүгө уруксат бериши керек. Компаниянын IT пейзажы абдан чоң! Бул бизнес жана миссия үчүн маанилүү системалар, айрымдары үчүн жеткиликтүүлүк талаптары 99,999. Экинчи продукт серверлердин өздөрү, физикалык жана виртуалдык. Бар болгондорго контролдук кылуу керек, ал эми жаңылары көп бөлүмдөрдүн кардарларына үзгүлтүксүз жеткирилиши керек. Бул макалада мен сервердин жашоо циклине жооп берген инфраструктураны кантип иштеп чыкканыбызга токтолгум келет.
жолдун башталган
Саякатыбыздын башында биздин технологиялык стек төмөнкүдөй болгон:
OS CentOS 7
FreeIPA домен контроллерлору
Автоматташтыруу - Ansible(+Tower), Өтүкчү
Мунун баары бир нече маалымат борборлоруна жайылган 3 доменде жайгашкан. Бир маалымат борборунда кеңсе системалары жана тесттик сайттар, калгандарында PROD бар.
Бир учурда серверлерди түзүү төмөнкүдөй болду:
VM шаблонунда CentOS минималдуу жана талап кылынган минимум туура /etc/resolv.conf сыяктуу, калганы Ansible аркылуу келет.
CMDB - Excel.
Эгерде сервер физикалык болсо, анда виртуалдык машинаны көчүрүүнүн ордуна, ОС ага Cobbler аркылуу орнотулган - максаттуу сервердин MAC даректери Cobbler конфигурациясына кошулат, сервер DHCP аркылуу IP дарегин алат, андан кийин ОС кошулат.
Адегенде биз Cobblerде кандайдыр бир конфигурацияны башкарууга аракет кылдык. Бирок, убакыттын өтүшү менен, бул башка маалымат борборлоруна да, VMлерди даярдоо үчүн Ansible кодуна да конфигурациялардын көчүрүлүүсү менен көйгөйлөрдү жаратты.
Ошол убакта көбүбүз Ansibleди Bashтын ыңгайлуу кеңейтүүсү катары кабыл алып, shell жана sedди колдонгон дизайнды колдон чыгарган жокпуз. Жалпысынан Bashsible. Бул акыр аягында оюн китеби кандайдыр бир себептерден улам серверде иштебей калса, серверди жок кылуу, ойнотуу китебин оңдоо жана аны кайра иштетүү оңой болгонуна алып келди. Негизинен скрипттердин версиясы, конфигурациялардын көчүрүү мүмкүнчүлүгү болгон эмес.
Мисалы, биз бардык серверлерде кээ бир конфигурацияларды өзгөрткүбүз келди:
- Логикалык сегментте/маалымат борборунда болгон серверлердеги конфигурацияны өзгөртөбүз. Кээде бир күндө эмес - жеткиликтүүлүк талаптары жана көп сандардын мыйзамы бардык өзгөртүүлөрдү бир эле учурда колдонууга жол бербейт. Ал эми кээ бир өзгөрүүлөр потенциалдуу кыйратуучу жана бир нерсени кайра баштоону талап кылат - кызматтардан ОСтун өзүнө чейин.
- Аны Ansible менен оңдоо
- Биз аны Cobblerде оңдойбуз
- Ар бир логикалык сегмент/маалымат борбору үчүн N жолу кайталаңыз
Бардык өзгөрүүлөр жылмакай жүрүшү үчүн, көптөгөн факторлорду эске алуу зарыл болгон жана өзгөрүүлөр дайыма болуп турат.
- Рефакторинг ansible код, конфигурация файлдары
- Ички мыкты тажрыйбаларды өзгөртүү
- Окуяларды/кырсыктарды талдоонун жыйынтыгы боюнча өзгөртүүлөр
- Ички жана тышкы коопсуздук стандарттарын өзгөртүү. Мисалы, PCI DSS жыл сайын жаңы талаптар менен жаңыртылып турат
Инфраструктуранын өсүшү жана саякаттын башталышы
Серверлердин/логикалык домендердин/маалымат борборлорунун саны өстү жана алар менен конфигурациялардагы каталардын саны өстү. Кайсы бир учурда биз конфигурацияны башкарууну иштеп чыгуу керек болгон үч багытка келдик:
- Автоматташтыруу. Кайталануучу операцияларда адам катасынан мүмкүн болушунча качуу керек.
- Кайталануучулук. Инфраструктураны алдын ала билгенде башкаруу алда канча оңой. Серверлердин конфигурациясы жана аларды даярдоочу куралдар бардык жерде бирдей болушу керек. Бул продукт командалары үчүн да маанилүү - тестирлөөдөн кийин, колдонмо сыноо чөйрөсүнө окшош конфигурацияланган өндүрүш чөйрөсүндө аяктайт деп кепилдик берилиши керек.
- Конфигурацияны башкарууга өзгөртүүлөрдү киргизүүнүн жөнөкөйлүгү жана ачыктыгы.
Бул бир нече куралдарды кошуу үчүн калууда.
Биз GitLab CEди код репозиторийибиз катары тандап алдык, анын ичинде анын орнотулган CI/CD модулдары үчүн.
Сырлар сактагычы - Hashicorp Vault, анын ичинде. улуу API үчүн.
Сыноо конфигурациялары жана маанилүү ролдор – Molecule+Testinfra. Эгер сиз ансибилдүү митогенге кошулсаңыз, тесттер тезирээк өтөт. Ошол эле учурда биз өзүбүздүн CMDB жана автоматтык жайылтуу үчүн оркестрди жаза баштадык (жогорку Cobbler сүрөттө), бирок бул такыр башка окуя, аны менин кесиптешим жана бул системалардын негизги иштеп чыгуучусу келечекте айтып берет.
Биздин тандоо:
Molecule + Testinfra
Ansible + Tower + AWX
Серверлердин дүйнөсү + DITNET (Өздүк өнүктүрүү)
өтүкчү
Gitlab + GitLab жөө күлүк
Hashicorp Vault
Айтмакчы, ансибилдүү ролдор жөнүндө. Башында бир гана болгон, бирок бир нече рефакторингден кийин мен монолитти идемпотенттик ролдорго бөлүүнү катуу сунуштайм, алар дагы өзүнчө ишке киргизилет, сиз тегдерди кошо аласыз. Биз ролдорду функционалдуулук боюнча бөлдүк - тармак, журнал, пакеттер, аппараттык камсыздоо, молекула ж.б. Жалпысынан, биз төмөндөгү стратегияны кармандык. Мен бул жалгыз чындык деп талап кылбайм, бирок ал биз үчүн иштеди.
- Серверлерди "алтын сүрөттөн" көчүрүү - бул жамандык!Негизги кемчилиги - сиз азыр сүрөттөр кандай абалда экенин так билбейсиз жана бардык өзгөртүүлөр бардык виртуалдаштыруу чарбаларында бардык сүрөттөргө келет.
- Демейки конфигурация файлдарын минималдуу колдонуңуз жана негизги тутум файлдары үчүн жооптуу экениңизди башка бөлүмдөр менен макулдаңызМисалы:
- /etc/sysctl.conf дегенди бош калтырыңыз, орнотуулар /etc/sysctl.d/ ичинде гана болушу керек. Сиздин бир файлдагы демейки, башка файлдагы колдонмо үчүн ыңгайлаштырылган.
- Системалык бирдиктерди түзөтүү үчүн жокко чыгаруу файлдарын колдонуңуз.
- Бардык конфигурацияларды калыптаңыз жана мүмкүн болсо, аларды толугу менен киргизиңиз, sed же анын аналогдорун ойнотуу китептерине киргизиңиз;
- Конфигурацияны башкаруу тутумунун кодун рефакторинг:
- Тапшырмаларды логикалык объекттерге бөлүп, монолитти ролдорго кайра жазыңыз
- Линтерлерди колдонуңуз! Ansible-lint, yaml-lint ж.б
- Өзүңүздүн мамилеңизди өзгөртүңүз! Жок. системанын абалын сүрөттөп берүү зарыл
- Бардык Ansible ролдору үчүн сиз молекулада тесттерди жазып, күнүнө бир жолу отчетторду түзүшүңүз керек.
- Биздин учурда, тесттерди даярдагандан кийин (анын 100дөн ашууну бар) 70000 XNUMXге жакын каталар табылган. Аны оңдоого бир нече ай кетти.
Биздин ишке ашыруу
Ошентип, ansible ролдор даяр болгон, шаблондор жана линтерлер тарабынан текшерилген. Ал тургай, бардык жерде гитлер өстүрүлөт. Бирок ар кандай сегменттерге кодду ишенимдүү жеткирүү маселеси ачык бойдон калды. Биз сценарийлер менен синхрондоштурууну чечтик. Ушундай көрүнөт:
Өзгөртүү келгенден кийин, CI ишке киргизилет, сыноо сервери түзүлөт, ролдор чыгарылат жана молекула тарабынан сыналат. Эгер баары жакшы болсо, код өндүрүш тармагына барат. Бирок биз жаңы кодду машинадагы учурдагы серверлерге колдонбойбуз. Бул биздин системалардын жогорку жеткиликтүүлүгү үчүн зарыл болгон бир түрү. Ал эми инфраструктура чоң болуп калганда, көп сандардын мыйзамы ишке кирет - бул өзгөртүү зыянсыз экенине ишенсеңиз да, бул оор кесепеттерге алып келиши мүмкүн.
Ошондой эле серверлерди түзүүнүн көптөгөн варианттары бар. Биз ыңгайлаштырылган Python скрипттерин тандап алдык. Ал эми CI ansible үчүн:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Мына ушундай абалга келдик, система жашап, өнүгүп жатат.
- 17 Серверди орнотуу үчүн маанилүү ролдор. Ролдордун ар бири өзүнчө логикалык тапшырманы чечүү үчүн иштелип чыккан (журналдарды каттоо, текшерүү, колдонуучунун авторизациясы, мониторинг ж.б.).
- Ролду сыноо. Molecule + TestInfra.
- Өздүк өнүктүрүү: CMDB + Оркестр.
- Серверди түзүү убактысы ~30 мүнөт, автоматташтырылган жана иш кезегинде иш жүзүндө көз карандысыз.
- Бардык сегменттерде инфраструктуранын бирдей абалы/аталышы - окуу китептери, репозиторийлер, виртуалдаштыруу элементтери.
- Стандартка туура келбегендиги жөнүндө отчетторду түзүү менен сервердин абалын күн сайын текшерүү.
Менин окуям сапарынын башында тургандарга пайдалуу болот деп ишенем. Сиз кандай автоматташтырылган стек колдоносуз?
Source: www.habr.com