Ако вашата ИТ инфраструктура расте твърде бързо, рано или късно ще бъдете изправени пред избор – линейно увеличаване на човешките ресурси, за да я поддържате, или да започнете автоматизация. До някакъв момент живеехме в първата парадигма и след това започна дългото пътуване до инфраструктурата като код.
Разбира се, NSPK не е стартъп, но такава атмосфера цареше в компанията през първите години от нейното съществуване и това бяха много интересни години. Моето име е , поддържам Linux инфраструктура с високи изисквания за достъпност повече от 10 години. Той се присъединява към екипа на NSPK през януари 2016 г. и, за съжаление, не вижда самото начало на съществуването на компанията, но идва в етап на големи промени.
Като цяло можем да кажем, че нашият екип доставя 2 продукта за компанията. Първият е инфраструктурата. Пощата трябва да върви, DNS трябва да работи и домейн контролерите трябва да ви пуснат в сървъри, които не трябва да падат. ИТ пейзажът на компанията е огромен! Това са критични за бизнеса и мисията системи, изискванията за достъпност за някои са 99,999 XNUMX. Вторият продукт са самите сървъри, физически и виртуални. Съществуващите трябва да се наблюдават, а новите да се доставят редовно на клиенти от много отдели. В тази статия искам да се съсредоточа върху това как сме разработили инфраструктурата, която отговаря за жизнения цикъл на сървърите.
Началото на пътуването
В началото на пътуването нашият технологичен стек изглеждаше така:
ОС CentOS 7
FreeIPA домейн контролери
Автоматизация - Ansible(+Tower), Cobbler
Всичко това беше разположено в 3 домейна, разпределени в няколко центъра за данни. В един център за данни - офис системи и тестови площадки, в останалите - PROD.
Създаването на сървъри в даден момент изглеждаше така:
Шаблонът на CentOS VM е минимален и минимумът е правилен /etc/resolv.conf, останалото идва чрез Ansible.
CMDB - Excel.
Ако сървърът е физически, тогава вместо да копира виртуалната машина, операционната система е инсталирана на нея с помощта на Cobbler - MAC адресите на целевия сървър се добавят към конфигурацията на Cobbler, сървърът получава IP адрес чрез DHCP и след това OS се излива.
Първоначално дори се опитахме да направим някакъв вид управление на конфигурацията в Cobbler. Но с течение на времето това започна да създава проблеми с преносимостта на конфигурациите както към други центрове за данни, така и към Ansible кода за подготовка на VM.
Ansible по това време се възприемаше от много от нас като удобно Bash разширение и не спестяваше конструкции, използващи обвивката, sed. Като цяло Bashsible. Това в крайна сметка доведе до факта, че ако книгата с игри по някаква причина не работи на сървъра, беше по-лесно да изтриете сървъра, да поправите книгата с игри и да я пуснете отново. В интерес на истината нямаше версии на скриптове, преносимост на конфигурации също.
Например, искахме да променим някои конфигурации на всички сървъри:
- Променяме конфигурацията на съществуващи сървъри в логическия сегмент / център за данни. Понякога не за един ден - изискванията за наличност и законът за големите числа не ви позволяват да приложите всички промени наведнъж. А някои промени са потенциално разрушителни и изискват рестартиране на всичко - от услугите до самата ОС.
- Фиксиране в Ansible
- Фиксиране в Cobbler
- Повторете N пъти за всеки логически сегмент/център за данни
За да преминат гладко всички промени, трябваше да се вземат предвид много фактори, а промените се случват през цялото време.
- Рефакторинг на анзибилен код, конфигурационни файлове
- Промяна на най-добрите вътрешни практики
- Промени след анализа на инциденти/произшествия
- Промяна на стандартите за сигурност, както вътрешни, така и външни. Например PCI DSS се актуализира с нови изисквания всяка година.
Разрастването на инфраструктурата и началото на пътуването
Броят на сървърите / логическите домейни / центровете за данни нараства, а с тях и броят на грешките в конфигурациите. В един момент стигнахме до три посоки, в посока на които трябва да развием управление на конфигурацията:
- Автоматизация. Доколкото е възможно, човешката грешка при повтарящи се операции трябва да се избягва.
- Повторяемост. Инфраструктурата е много по-лесна за управление, когато е предвидима. Конфигурацията на сървърите и инструментите за тяхната подготовка трябва да бъдат еднакви навсякъде. Това е важно и за продуктовите екипи – след тестване приложението трябва да бъде гарантирано, че ще попадне в продуктивна среда, конфигурирана подобно на тестовата.
- Простота и прозрачност на промените в управлението на конфигурацията.
Остава да добавите няколко инструмента.
Избрахме GitLab CE за наше хранилище на кодове, не на последно място заради вградените CI/CD модули.
Vault of secrets - Hashicorp Vault, вкл. за страхотния API.
Конфигурации за тестване и анзибилни роли - Molecule+Testinfra. Тестовете вървят много по-бързо, ако се свържете с ansible mitogen. Успоредно с това започнахме да пишем собствена CMDB и оркестратор за автоматично внедряване (на снимката над Cobbler), но това е съвсем различна история, за която моят колега и основният разработчик на тези системи ще разкаже в бъдеще.
Нашият избор:
Молекула + Тестинфра
Ansible + Tower + AWX
World of Servers + DITNET (Собствена разработка)
обущар
Gitlab + GitLab runner
Hashicorp Vault
Между другото, за анзибилните роли. Отначало беше сам, след няколко рефакторинга имаше 17. Силно препоръчвам да разбиете монолита на идемпотентни роли, които след това могат да се изпълняват отделно, можете допълнително да добавяте тагове. Разделихме ролите по функционалност - мрежа, логване, пакети, хардуер, молекула и т.н. Като цяло се придържах към стратегията по-долу. Не твърдя, че това е истината в нито един случай, но при нас проработи.
- Копирането на сървъри от златното изображение е зло!От основните недостатъци - не знаете точно в какво състояние са изображенията в момента и че всички промени ще дойдат до всички изображения във всички ферми за виртуализация.
- Сведете до минимум конфигурационните файлове по подразбиране и се съгласете с другите отдели, че вие сте отговорни за основните системни файлове, например:
- Оставете /etc/sysctl.conf празен, настройките трябва да са само в /etc/sysctl.d/. Вашият по подразбиране в един файл, персонализиран за приложението в друг.
- Използвайте файлове за заместване, за да редактирате systemd единици.
- Шаблонирайте всички конфигурации и ги поставете в тяхната цялост, ако е възможно, без sed и неговите аналози в playbooks
- Рефакторинг на кода на системата за управление на конфигурацията:
- Разделете задачите на логически единици и пренапишете монолита на роли
- Използвайте линтери! Ansible-lint, yaml-lint и др
- Променете подхода си! Няма възможност за баш. Опишете състоянието на системата
- За всички роли на Ansible трябва да пишете тестове в молекула и да генерирате отчети веднъж на ден.
- В нашия случай след подготовката на тестовете (от които са повече от 100) бяха открити около 70000 XNUMX грешки. Фиксиран за няколко месеца.
Нашата реализация
И така, анзиблните роли бяха готови, шаблонирани и проверени от линтери. И дори джигитите се отглеждат навсякъде. Но въпросът за надеждното доставяне на код до различни сегменти остава открит. Решихме да синхронизираме със скриптове. изглежда така:
След като промяната пристигне, 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 анзибилни роли за настройка на сървър. Всяка от ролите е предназначена за решаване на отделна логическа задача (регистриране, одит, оторизация на потребителя, мониторинг и др.).
- Ролеви тестове. Молекула + Тест Infra.
- Собствена разработка: CMDB + Orchestrator.
- Времето за създаване на сървъра е ~30 минути, то е автоматизирано и практически не зависи от опашката на задачите.
- Едно и също състояние/именуване на инфраструктурата във всички сегменти – книги за игри, хранилища, елементи за виртуализация.
- Ежедневна проверка на състоянието на сървърите с генериране на отчети за несъответствия със стандарта.
Надявам се, че моята история ще бъде полезна за тези, които са в началото на пътуването. Какъв стек за автоматизация използвате?
Източник: www.habr.com