Случаят достигна края на Нова година. Децата от цялата страна вече изпратиха писма до Дядо Коледа или пожелаха подаръци за себе си, а главният им изпълнител — един от големите ритейлъри — се подготвяше за апогея на продажбите. През декември натоварването на неговия дата център нараства многократно. Затова компанията реши да модернизира дата центъра и да пусне в експлоатация няколко десетки нови сървъри вместо оборудването, чийто срок на експлоатация бе изтекъл. На това хоро на фона на въртящите се снежинки свършва и започва трилърът.

Оборудването пристигна на мястото няколко месеца преди пика на продажбите. Службата за експлоатация, разбира се, знае как и какво да настрои на сървърите, за да бъдат пуснати в продукционно обкръжение. Но трябваше да автоматизираме този процес и да изключим човешкия фактор. Освен това сървърите заменяха системи SAP, критично важни за компанията, преди миграцията.

Въвеждането на новите сървъри беше строго привързано към крайния срок. И преместването му означаваше да изложим на риск как отгрузката на милиарда подаръци, така и миграцията на системите. Датата не можеше да бъде променена дори от екипа на Дядо Коледа или Свети Николай — преместването на системата SAP за управление на склада може да се прави само веднъж годишно. От 31 декември до 1 януари огромните складове на ритейлъра, обхващащи колкото 20 футболни игрища, спират работа за 15 часа. И това е единственият промеждутък от време за прехвърляне на системата. Нямаше право на грешка при внедряването на сървърите.

Ще обясня веднага: моят разказ отразява такъв инструментариум и процеса на управление на конфигурации, които прилага нашият екип.

Комплексът за управление на конфигурации се състои от няколко нива. Ключовият компонент е CMS-системата. При индустриалната експлоатация отсъствието на едно от нивата неизбежно би довело до неприятни изненади.

Управление на инсталирането на ОС

Първото ниво е система за управление на инсталирането на операционни системи на физически и виртуални сървъри. Тя създава основни конфигурации на ОС, избавяйки от човешкия фактор.

С тази система ние получавахме стандартни и пригодни за последваща автоматизация екземпляри на сървъри с операционна система. При „разливането“ те получаваха минимален набор от локални потребители и публични SSH ключове, както и съгласувана конфигурация на операционната система. Можехме със сигурност да управляваме сървърите чрез CMS и бяхме уверени, че „отдолу“, на ниво операционна система, няма изненади.

Задачата „максимум“ за системата за управление на инсталирането е автоматичното конфигуриране на сървъри от ниво BIOS/Firmware до операционна система. Много от това зависи от оборудването и задачите за конфигуриране. За хетерогенно оборудване може да се разгледа REDFISH API. Ако всичкото „железо“ е от един и същ производител, то често е по-удобно да се използват готови средства за управление (например, HP ILO Amplifier, DELL OpenManage и т.н.).

За инсталацията на операционни системи на физически сървъри използвахме добре познатия на всички Cobbler, в който е определен набор от съгласувани с експлоатационната служба профили за инсталиране. При добавяне на нов сървър в инфраструктурата инженерът свързва MAC адреса на сървъра с необходимия профил в Cobbler. При първоначално зареждане по мрежата сървърът получава временен адрес и нова операционна система. След това той се прехвърля в целевата VLAN/IP адресация и продължава работа там. Да, смяната на VLAN отнема време и изисква съгласуване, но за сметка на това осигурява допълнителна защита от случайна инсталация на сървъра в production среда.

Виртуалните сървъри създавахме въз основа на шаблони, подготвени с помощта на HashiCorp Packer. Причината беше същата: да се предотвратят възможни човешки грешки при инсталацията на операционната система. Но, за разлика от физическите сървъри, Packer позволява да не се използва PXE, мрежово зареждане и смяна на VLAN. Това улесни и опрости създаването на виртуални сървъри.

Рис. 1. Управление на инсталацията на операционни системи.

Управление на секрети

Всяка система за управление на конфигурации съдържа данни, които трябва да бъдат скрити от обикновените потребители, но са необходими за подготовката на системите. Това са пароли на локални потребители и сервисни акаунти, ключове на сертификати, всевъзможни API Tokens и др. Обикновено ги наричат „секрети“.

Ако от самото начало не се определи къде и как да се съхраняват тези секрети, то, в зависимост от строгостта на изискванията по информационна безопасност, е вероятно да се използват следните методи за съхранение:

• директно в кода за управление конфигурацията или във файловете в репозитория;
• в специализирани инструменти за управление на конфигурации (например, Ansible Vault);
• в системи CI/CD (Jenkins/TeamCity/GitLab и др.) или в системи за управление на конфигурации (Ansible Tower/Ansible AWX);
• също така, секрети могат да се предават и на 'ръчно управление'. Например, поставят се на определено място и след това се използват от системи за управление на конфигурации;
• различни комбинации от гореописаното.

Всяка от методите има свои недостатъци. Главният от тях е липсата на политики за достъп до секретите: трудно може да се определи кой може да използва определени тайни. Още един минус е липсата на аудит на достъпа и пълен жизнен цикъл. Как бързо да заменим, например, публичния ключ, който е написан в кода и в редица свързани системи?

Ние използвахме централизирано хранилище на секрети HashiCorp Vault. Това ни позволи:

• да съхраняваме секрети безопасно. Те са криптирани, и дори ако някой получи достъп до базата данни на хранилището Vault (например, възстановявайки я от резервно копие), не може да прочете съхраняваните там тайни;
• да организираме политики за достъп до секретите. На потребителите и приложенията са достъпни само 'определени' им секрети;
• да провеждаме аудит на достъпа до секретите. Всякакви действия със секретите се записват в журнала на аудита Vault;
• да организираме пълен 'жизнен цикъл' на работа със секретите. Можем да ги създаваме, отзоваваме, задаваме срок на валидност и т.н.
• лесно да се интегрираме с други системи, които изискват достъп до секрети;
• освен това да прилагаме end-to-end криптиране, еднократни пароли за операционни системи и бази данни, удостоверителни сертификати и т.н.

Сега да преминем към централната система за удостоверяване и авторизация. Можехме да се справим и без нея, но администрирането на потребители в множество съпътстващи системи е прекалено сложно. Настроихме удостоверяване и авторизация чрез LDAP услуга. В противен случай в същия Vault щеше да се наложи непрекъснато издаване и поддържане на учет на удостоверителни токени за потребителите. А премахването и добавянето на потребители щеше да се превърне в квест 'създал/изтривал ли съм тази УЗ навсякъде?'

Добавяме още един слой в нашата система: управление на секретите и централна удостоверяване/авторизация:

Рис. 2. Управление на секретите.

Управление конфигурации

Стигнахме до сърцето - до CMS системата. В нашия случай това е връзката Ansible и Red Hat Ansible AWX.

Вместо Ansible могат да се използват Chef, Puppet, SaltStack. Избрахме Ansible по няколко критерия.

• На първо място, това е универсалността. Наборът от готови модули за управление прави впечатление. А ако не достигат, може да се потърсят на GitHub и Galaxy.
• На второ място, не е нужно да инсталирате и поддържате агенти на управляваното оборудване, да доказвате, че те не пречат на натоварването и да потвърждавате отсъствието на "включвания".
• На трето място, Ansible има нисък праг на влизане. Подготвен инженер ще напише работен playbook буквално в първия ден работа с продукта.

Но само Ansible в промишлено обкръжение не беше достатъчен за нас. В противен случай биха възникнали много проблеми с ограничаването на достъпа и одита на действията на администраторите. Как да се раздели достъпа? Нуждаехме се от всяко звено да управлява (чети - стартира Ansible playbook) "своите" набори от сървъри. Как да разрешим стартирането на конкретни Ansible playbook само на определени служители? Или как да проследим кой е стартирал playbook, без да създаваме множество локални потребителски акаунти на сървърите и оборудването, управлявани от Ansible?

Голяма част от подобни въпроси решава Red Hat Ansible Tower, или неговият open-source upstream проект Ansible AWX. Затова го предпочетохме за клиента.

И още един щрих към портрета на нашата CMS система. Ansible playbook трябва да се съхранява в системи за управление на кодови репозитории. При нас това е GitLab CE.

Така конфигурациите се управляват от връзката Ansible/Ansible AWX/GitLab (вж. Рис. 3). Разбира се, AWX/GitLab са интегрирани в единна система за удостоверяване, а Ansible playbook - с HashiCorp Vault. Конфигурациите влизат в продукционната среда само чрез Ansible AWX, в който са зададени всички 'правила на играта': кой и какво може да конфигурира, откъде да взема кода за управление на конфигурациите за CMS и т.н.

Рис. 3. Управление на конфигурациите.

Управление на тестовете

Нашата конфигурация е представена под формата на код. Затова сме принудени да следваме същите правила, както и разработчиците на софтуер. Необходимо беше да организираме процесите на разработка, непрекъснато тестване, доставка и прилагане на конфигурационния код на продукционни сървъри.

Ако това не бъде направено веднага, написаните роли за конфигурация или ще престанат да се поддържат и променят, или ще спрат да се пускат в продукция. Лекът за тази болка е известен и се е оправдал в този проект:

• всяка роля е покрита с модулни тестове;
• тестовете се изпълняват автоматично при всяка промяна в кода, управляващ конфигурациите;
• промените в кода за управление на конфигурациите влизат в продуктовата среда само след успешно преминаване на всички тестове и преглед на кода.

Разработката на кода и управлението на конфигурациите стана по-спокойно и предсказуемо. За организация на непрекъснатото тестване използвахме инструмента GitLab CI/CD, а за фреймворк за организиране на тестовете избрахме Ansible Molecule.

При всяка промяна в кода за управление на конфигурациите GitLab CI/CD извиква Molecule:

• това проверява синтаксиса на кода,
• създава Docker-контейнер,
• прилага променения код в създадения контейнер,
• проверява ролята за идемпотентност и изпълнява тестовете за този код (грануларността тук е на ниво ansible role, вижте Рис. 4).

Конфигурациите в продуктовата среда доставяме чрез Ansible AWX. Отговорните инженери за експлоатация прилагат промени в конфигурацията чрез предварително определени шаблони. AWX самостоятелно при всяко приложение "заявява" последната версия на кода от основната клонка на GitLab. По този начин изключвахме употребата на непроверен или остарял код в продуктивната среда. Естествено, кодът попада в основната клонка само след тестване, преглед и одобрение.

Рис. 4. Автоматично тестване на ролите в GitLab CI/CD.

Има още един проблем, свързан с експлоатацията на продукционни системи. В реалния живот е много трудно да се внасят промени в конфигурацията само чрез кода на CMS. Възникват извънредни ситуации, когато инженерът трябва да промени конфигурацията "тук и сега", без да чака корекция на кода, тестване, одобрение и т.н.

В резултат на ръчни промени се появяват разминавания в конфигурацията на еднотипно оборудване (например, на възли на HA-кластера различна конфигурация на настройките sysctl). Или реалната конфигурация на оборудването се различава от тази, която е зададена в кода на CMS.

Следовательно, в допълнение към непрекъснатото тестване, проверяваме production средите за несъответствия в конфигурацията. Избрахме най-простия вариант: изпълнение на кода на конфигурацията на CMS в режим „dry run“, тоест без прилагане на промени, но с уведомление за всички несъответствия между планираната и реалната конфигурация. Реализирахме това с периодични изпълнения на всички Ansible playbook с опцията „—check“ на производствените сървъри. За изпълнението и актуалността на playbook отговаря, както винаги, Ansible AWX (вж. Рис. 5):

Рис. 5. Проверка на несъответствия в конфигурацията в Ansible AWX.

След проверките AWX изпраща доклад за несъответствията на администраторите. Те изучават проблемната конфигурация и след това я коригират чрез коригирани playbook. По този начин поддържаме конфигурацията в производствена среда и CMS винаги остава актуална и синхронизирана. Това ни спестява неприятни „чудеса“, когато кодът на CMS се прилага на „боеви“ сървъри.

Сега имаме важен ниво на тестване, състоящо се от Ansible AWX/GitLab/Molecule (Рис. 6).

Рис. 6. Управление на тестването.

Трудно ли е? Не оспорвам. Но този комплекс от управление на конфигурации стана изчерпателен отговор на множество въпроси, свързани с автоматизацията на настройките на сървърите. Сега ритейлърът на стандартни сървъри винаги има строго определена конфигурация. CMS, за разлика от инженера, никога не забравя да добави необходимите настройки, да създаде потребители и да изпълни десетки или стотици необходими настройки.

В настройките на сървърите и средите днес липсват „тайни знания“. Всички необходимите характеристики са отразени в playbook. Без повече творчество и неясни инструкции: „инсталирайте като обикновен Oracle, но трябва да добавите няколко настройки в sysctl и да създадете потребители с нужния UID. Попитайте момчетата от експлоатацията, те знаят.».

Възможността за откриване на несъответствия в конфигурацията и предварителното им коригиране придава спокойствие. Без система за управление на конфигурацията обикновено изглежда по друг начин. Проблемите се натрупват, докато един ден не „взривят“ в production. После се провеждат разбори, проверяват и коригират конфигурациите. И цикълът се повтаря отново.

И, разбира се, ускорихме въвеждането на сървърите в експлоатация от няколко дни до часове.

А в самата новогодна нощ, когато децата радостно разпаковаха подаръците, а възрастните си пожелаваха желания под звука на часовника, нашите инженери мигрираха SAP системата на нови сървъри. Дори Дядо Коледа би казал, че най-добрите чудеса са добре подготвени.

P.S. Нашият екип често се сблъсква с това, че клиентите искат да решат задачата за управление на конфигурации възможно най-просто. В идеалния случай, сякаш с омагьосване — с един инструмент. Но в живота всичко е по-сложно (да, отново не пристигнаха сребърните куршуми): налага се да създаваме цял процес с помощта на удобни за екипа на клиента инструменти.

Автор: Сергей Артемов, архитект на отдела DevOps решения «Инфосистеми Джет»

Източник: habr.com