Калі ваша IT інфраструктура расце занадта хутка, вы рана ці позна сутыкнецеся з выбарам - лінейна павялічваць людскія рэсурсы на яе падтрымку або пачынаць аўтаматызацыю. Да нейкага моманту мы жылі ў першай парадыгме, а потым пачаўся доўгі шлях да Infrastructure-as-Code.
Зразумела, НСПК - не стартап, але такая атмасфера панавала ў кампаніі ў першыя гады існавання, і гэта былі вельмі цікавыя гады. Мяне клічуць , больш за 10 гадоў я падтрымліваю інфраструктуру Linux з высокімі патрабаваннямі даступнасці. Да каманды НСПК далучыўся ў студзені 2016 года і, на жаль, не заспеў самага пачатку існавання кампаніі, але прыйшоў на этапе вялікіх змен.
У цэлым, можна сказаць, што наша каманда пастаўляе для кампаніі 2 прадукта. Першы - гэта інфраструктура. Пошта павінна хадзіць, DNS працаваць, а кантролеры дамена - пускаць вас на серверы, якія не павінны падаць. IT ландшафт кампаніі велізарны! Гэта business&mission critical сістэмы, патрабаванні па даступнасці некаторых - 99,999. Другі прадукт - самі сервера, фізічныя і віртуальныя. За існуючымі трэба сачыць, а новыя рэгулярна пастаўляць заказчыкам са мноства падраздзяленняў. У гэтым артыкуле я хачу зрабіць акцэнт на тым, як мы развівалі інфраструктуру, якая адказвае за жыццёвы цыкл сервераў.
Пачатак шляху
У пачатку шляху наш стэк тэхналогій выглядаў так:
АС CentOS 7
Кантралёры дамена FreeIPA
Аўтаматызацыя - Ansible (+ Tower), Cobbler
Усё гэта размяшчалася ў 3х даменах, размазаных на некалькіх ЦАДах. У адным ЦАД - офісныя сістэмы і тэставыя палігоны, у астатніх ПРАД.
Стварэнне сервераў у нейкі момант выглядала так:
У шаблоне VM CentOS minimal і неабходны мінімум накшталт карэктнага /etc/resolv.conf, астатняе прыязджае праз Ansible.
CMDB - Excel.
Калі сервер фізічны, то замест капіявання віртуальнай машыны на яго ўсталёўвалася АС з дапамогай Cobbler - у канфіг Cobbler дадаюцца MAC адрасы мэтавага сервера, сервер па DHCP атрымлівае IP адрас, а далей наліваецца АС.
Спачатку мы нават спрабавалі рабіць нейкі configuration management у Cobbler. Але з часам гэта стала прыносіць праблемы з пераноснасцю канфігурацый як у іншыя ЦАД, так і ў Ansible код для падрыхтоўкі VM.
Ansible у той час многія з нас успрымалі як зручнае пашырэнне Bash і не скупіліся на канструкцыі з выкарыстаннем shell, sed. Увогуле Bashsible. Гэта ў выніку прыводзіла да таго, што, калі плэйбук па якой-небудзь прычыне не адпрацоўваў на серверы, прасцей было выдаліць сервер, паправіць плэйбук і пракаціць нанава. Ніякага версіявання скрыптоў у сутнасці не было, пераноснасці канфігурацый таксама.
Напрыклад, мы захацелі змяніць нейкі канфіг на ўсіх серверах:
- Змяняны канфігурацыю на існуючых серверах у лагічным сегменце/ЦАД. Часам не за адзін дзень - патрабаванні да даступнасці і закон вялікіх лікаў не дазваляе ўжываць усе змены зараз. А некаторыя змены патэнцыйна дэструктыўныя і патрабуюць перазапуск чаго-небудзь - ад службаў да самай АС.
- Выпраўляем у Ansible
- Выпраўляем у Cobbler
- Паўтараем N разоў для кожнага лагічнага сегмента/ЦАД
Для таго, каб усе змены праходзілі гладка, неабходна было ўлічваць мноства фактараў, а змены адбываюцца ўвесь час.
- Рэфакторынг ansible кода, канфігурацыйных файлаў
- Змяненне ўнутраных best practice
- Змяненні па выніках разбору інцыдэнтаў/аварый
- Змяненне стандартаў бяспекі, як унутраных, так і знешніх. Напрыклад, PCI DSS кожны год дапаўняецца новымі патрабаваннямі.
Рост інфраструктуры і пачатак шляху
Колькасць сервераў/лагічных даменаў/ЦАД расла, а з імі колькасць памылак у канфігурацыях. У нейкі момант мы дашлі да трох кірункаў, у бок якіх трэба развіваць configuration management:
- Аўтаматызацыя. Наколькі можна, трэба пазбягаць чалавечага фактару ў паўтаральных аперацыях.
- Паўтаральнасць. Кіраваць інфраструктурай нашмат прасцей, калі яна прадказальная. Канфігурацыя сервераў і прылад для іх падрыхтоўкі павінна быць усюды аднолькавай. Гэта так жа важна для прадуктовых каманд - прыкладанне павінна гарантавана пасля тэставання трапляць у прадуктыўнае асяроддзе, наладжанае аналагічна тэставай.
- Прастата і празрыстасць занясення змен у configuration management.
Засталося дадаць пару прылад.
У якасці сховішчы кода мы абралі GitLab CE, не ў апошнюю чаргу за наяўнасць убудаваных модуляў CI/CD.
Сховішча сакрэтаў - Hashicorp Vault, у т.л. за цудоўнае API.
Тэставанне канфігурацый і ansible роляў – Molecule+Testinfra. Тэсты ідуць нашмат хутчэй, калі падключаеце да ansible mitogen. Паралельна мы пачалі пісаць уласную CMDB і аркестратар для аўтаматычнага дэплою (на малюнку над Cobbler), але гэта ўжо зусім іншая гісторыя, пра якую ў будучыні раскажа мой калега і галоўны распрацоўшчык гэтых сістэм.
Наш выбар:
Molecule + Testinfra
Ansible + Tower + AWX
Свет Сервераў + DITNET (Уласная распрацоўка)
Шавец
Gitlab + GitLab runner
Hashicorp Vault
Дарэчы пра ansible ролі. Спачатку яна была адна, пасля некалькіх рэфактарынгу іх стала 17. Катэгарычна рэкамендую разбіваць маналіт на ідэмпатэнтныя ролі, якія можна потым запускаць асобна, дадаткова можна дадаць тэгі. Мы ролі разбілі па функцыянале - network, logging, packages, hardware, molecule etc. А ўвогуле, прытрымліваліся стратэгіі ніжэй. Не настойваю на тым, што гэта праўда ў адзінай інстанцыі, але ў нас спрацавала.
- Капіраванне сервераў з "залатога ладу" - зло!З асноўных недахопаў - вы дакладна не ведаеце, у якім стане вобразы зараз, і што ўсе змены прыйдуць ва ўсе вобразы ва ўсе фермы віртуалізацыі.
- Выкарыстоўвайце дэфолтныя файлы канфігурацыі па мінімуме і дамовіцеся з іншымі падраздзяленнямі, што за асноўныя сістэмныя файлы адказваеце вы, Напрыклад:
- Пакіньце /etc/sysctl.conf пустым, налады павінны ляжаць толькі ў /etc/sysctl.d/. Ваш дэфолт у адзін файл, кастам для прыкладання ў іншы.
- Выкарыстоўвайце override файлы для рэдагавання systemd юнітаў.
- Шабланізуйце ўсе канфігі і падкладайце цалкам, па магчымасці ніякіх sed і яго аналагаў у плэйбуках
- Рэфактар код сістэмы кіравання канфігурацыямі:
- Разбіце задачы на лагічныя сутнасці і перапішыце маналіт на ролі
- Выкарыстоўвайце лінтэры! Ansible-lint, yaml-lint, etc
- Змяняйце падыход! Ніякага bashsible. Трэба апісваць стан сістэмы
- Пад усе Ansible ролі трэба напісаць тэсты ў molecule і штодня генераваць справаздачы.
- У нашым выпадку, пасля падрыхтоўкі тэстаў (якіх больш за 100) знайшлося каля 70000 памылак. Выпраўлялі некалькі месяцаў.
Наша рэалізацыя
Такім чынам, ansible ролі былі гатовыя, шабланізаваны і правераны лінтэрамі. І нават гіты ўсюды паднятыя. Але пытанне надзейнай дастаўкі кода ў розныя сегменты засталося адкрытым. Вырашылі сінхранізаваць скрыптамі. Выглядае так:
Пасля таго, як прыехала змена, запускаецца CI, ствараецца тэставы сервер, пракатваюцца ролі, тэстуюцца малекулай. Калі ўсё ок, код сыходзіць у прад галінку. Але мы не ўжываем новы код на існуючыя сервера ў аўтамаце. Гэта своеасаблівы стопар, які неабходзен для высокай даступнасці нашых сістэм. А калі інфраструктура становіцца велізарнай, у справу ідзе яшчэ закон вялікіх лікаў - нават калі вы ўпэўненыя, што змяненне бяскрыўднае, яно можа прывесці да сумных наступстваў.
Варыянтаў стварэння сервераў таксама шмат. Мы ў выніку выбралі кастамныя скрыпты на пітоне. А для 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 ansible-роляў для наладкі сервера. Кожная з роляў прызначана для вырашэння асобнай лагічнай задачы (лагіраванне, аўдыт, аўтарызацыя карыстальнікаў, маніторынг і г.д.).
- Тэсціраванне роляў. Molecule + TestInfra.
- Уласная распрацоўка: CMDB + Аркестратар.
- Час стварэння сервера ~30 хвілін, аўтаматызавана і практычна не залежыць ад чаргі задач.
- Аднолькавы стан / найменне інфраструктуры ва ўсіх сегментах – плэйбукі, рэпазітары, элементы віртуалізацыі.
- Штодзённая праверка стану сервераў з генерацыяй справаздач аб разыходжаннях з эталонам.
Спадзяюся маё апавяданне будзе карысна тым, хто ў пачатку шляху. А які стэк аўтаматызацыі карыстаецеся вы?
Крыніца: habr.com