Наближаваше Нова година. Децата от цялата страна вече бяха изпратили писма до Дядо Коледа или направиха подаръци за себе си, а основният им изпълнител, един от големите търговци на дребно, се готви за апотеоза на продажбите. През декември натоварването на центъра за данни се увеличава няколко пъти. Затова компанията реши да модернизира центъра за данни и да пусне в експлоатация няколко десетки нови сървъра вместо оборудване, което беше на изчерпване. Това приключва приказката на фона на въртящи се снежинки и започва трилърът.
Оборудването пристигна на обекта няколко месеца преди пика на продажбите. Оперативната услуга, разбира се, знае как и какво да конфигурира на сървърите, за да ги пренесе в производствената среда. Но трябваше да автоматизираме това и да премахнем човешкия фактор. В допълнение, сървърите бяха заменени преди миграцията на набор от SAP системи, които бяха критични за компанията.
Въвеждането в експлоатация на нови сървъри беше строго обвързано с краен срок. И преместването му означаваше да застраши както изпращането на един милиард подаръци, така и миграцията на системи. Дори екип, състоящ се от Дядо Фрост и Дядо Коледа, не можа да промени датата - можете да прехвърлите SAP системата за управление на склад само веднъж годишно. От 31 декември до 1 януари огромните складове на търговеца, общо с размерите на 20 футболни игрища, спират работа за 15 часа. И това е единственият период от време за преместване на системата. Нямахме място за грешки при въвеждането на сървъри.
Нека бъда ясен: моята история отразява инструментите и процеса на управление на конфигурацията, които нашият екип използва.
Комплексът за управление на конфигурацията се състои от няколко нива. Ключовият компонент е CMS системата. При промишлена експлоатация липсата на едно от нивата неминуемо би довело до неприятни чудеса.
Управление на инсталацията на ОС
Първото ниво е система за управление на инсталирането на операционни системи на физически и виртуални сървъри. Създава основни конфигурации на ОС, елиминирайки човешкия фактор.
Използвайки тази система, получихме стандартни сървърни екземпляри с операционна система, подходяща за по-нататъшна автоматизация. По време на „изливането“ те получиха минимален набор от локални потребители и публични SSH ключове, както и последователна конфигурация на операционната система. Можем да бъдем гарантирани, че управляваме сървърите чрез CMS и бяхме сигурни, че няма изненади „долу“ на ниво ОС.
„Максималната“ задача на системата за управление на инсталацията е автоматично да конфигурира сървърите от ниво BIOS/фърмуер до операционната система. Тук много зависи от оборудването и задачите за настройка. За разнородно оборудване можете да помислите . Ако целият хардуер е от един доставчик, тогава често е по-удобно да използвате готови инструменти за управление (например HP ILO Amplifier, DELL OpenManage и др.).
За да инсталираме операционната система на физически сървъри, използвахме добре познатия Cobbler, който дефинира набор от инсталационни профили, съгласувани с услугата за експлоатация. При добавяне на нов сървър към инфраструктурата, инженерът свързва MAC адреса на сървъра с необходимия профил в Cobbler. При първото зареждане по мрежата сървърът получи временен адрес и нова ОС. След това беше прехвърлен към целевата VLAN/IP адресация и продължи работата си там. Да, промяната на VLAN отнема време и изисква координация, но осигурява допълнителна защита срещу случайно инсталиране на сървъра в производствена среда.
Създадохме виртуални сървъри на базата на шаблони, изготвени с HashiСorp Packer. Причината беше същата: да се предотвратят възможни човешки грешки при инсталиране на операционната система. Но за разлика от физическите сървъри, Packer елиминира нуждата от PXE, мрежово зареждане и промени във VLAN. Това улесни и опрости създаването на виртуални сървъри.
Ориз. 1. Управление на инсталирането на операционни системи.
Управление на тайни
Всяка система за управление на конфигурацията съдържа данни, които трябва да бъдат скрити от обикновените потребители, но са необходими за подготовка на системи. Това са пароли за локални потребители и акаунти за услуги, ключове за сертификати, различни API токени и т.н. Те обикновено се наричат „тайни“.
Ако не определите от самото начало къде и как да съхранявате тези тайни, тогава, в зависимост от тежестта на изискванията за сигурност на информацията, вероятно са следните методи за съхранение:
- директно в контролния код на конфигурацията или във файлове в хранилището;
- в специализирани инструменти за управление на конфигурацията (например Ansible Vault);
- в CI/CD системи (Jenkins/TeamCity/GitLab/и др.) или в системи за управление на конфигурацията (Ansible Tower/Ansible AWX);
- тайните могат да се прехвърлят и „ръчно“. Например, те са разположени на определено място и след това се използват от системи за управление на конфигурацията;
- различни комбинации от горните.
Всеки метод има своите недостатъци. Основната е липсата на политики за достъп до тайни: невъзможно е или трудно е да се определи кой може да използва определени тайни. Друг недостатък е липсата на одит на достъпа и пълен жизнен цикъл. Как бързо да замените, например, публичен ключ, който е записан в кода и в редица свързани системи?
Използвахме централизираното тайно хранилище HashiCorp Vault. Това ни позволи:
- пази тайните. Те са криптирани и дори ако някой получи достъп до базата данни на Vault (например, като я възстанови от резервно копие), той няма да може да прочете съхранените там тайни;
- организира политики за достъп до тайни. Само „разпределените“ за тях тайни са достъпни за потребителите и приложенията;
- одитен достъп до тайни. Всички действия с тайни се записват в журнала за проверка на Vault;
- организирайте пълноценен „жизнен цикъл“ на работа с тайни. Могат да се създават, отменят, задават дата на изтичане и т.н.
- лесен за интегриране с други системи, които се нуждаят от достъп до тайни;
- и също така използвайте криптиране от край до край, еднократни пароли за операционната система и базата данни, сертификати на оторизирани центрове и др.
Сега нека да преминем към централната система за удостоверяване и оторизация. Беше възможно да се направи без него, но администрирането на потребители в много свързани системи е твърде нетривиално. Конфигурирахме удостоверяване и оторизация чрез услугата LDAP. В противен случай Vault ще трябва непрекъснато да издава и следи токени за удостоверяване за потребителите. И изтриването и добавянето на потребители ще се превърне в мисия „Създадох/изтрих ли този потребителски акаунт навсякъде?“
Добавяме още едно ниво към нашата система: управление на тайни и централно удостоверяване/упълномощаване:
Ориз. 2. Управление на тайни.
Управление на конфигурацията
Стигнахме до същината – CMS системата. В нашия случай това е комбинация от Ansible и Red Hat Ansible AWX.
Вместо Ansible могат да се използват Chef, Puppet, SaltStack. Избрахме Ansible въз основа на няколко критерия.
- Първо, това е универсалност. Комплект готови модули за управление . И ако нямате достатъчно от него, можете да търсите в GitHub и Galaxy.
- Второ, няма нужда да инсталирате и поддържате агенти на управлявано оборудване, да докажете, че те не пречат на натоварването и да потвърдите липсата на „отметки“.
- Трето, Ansible има ниска бариера за навлизане. Компетентен инженер ще напише работеща книга буквално в първия ден от работата с продукта.
Но Ansible сам в производствена среда не беше достатъчен за нас. В противен случай биха възникнали много проблеми с ограничаването на достъпа и одита на действията на администраторите. Как да ограничим достъпа? В края на краищата, беше необходимо всеки отдел да управлява (да се чете: да изпълнява книгата на Ansible) „свой собствен“ набор от сървъри. Как да позволите само на определени служители да изпълняват конкретни Ansible playbooks? Или как да проследите кой е пуснал книгата за игра, без да създавате много локални знания за сървъри и оборудване, работещи с Ansible?
Лъвският дял от подобни проблеми се решава от Red Hat , или неговия проект с отворен код нагоре по веригата . Затова го предпочетохме за клиента.
И още един щрих към портрета на нашата CMS система. Ansible playbook трябва да се съхранява в системи за управление на хранилища за кодове. Имаме го .
И така, самите конфигурации се управляват от комбинация от Ansible/Ansible AWX/GitLab (виж Фиг. 3). Разбира се, AWX/GitLab е интегриран с единна система за удостоверяване, а Ansible playbook е интегриран с HashiCorp Vault. Конфигурациите влизат в производствената среда само чрез Ansible AWX, в който са посочени всички „правила на играта“: кой какво може да конфигурира, къде да вземе кода за управление на конфигурацията за CMS и т.н.
Ориз. 3. Управление на конфигурацията.
Управление на тестовете
Нашата конфигурация е представена под формата на код. Следователно ние сме принудени да играем по същите правила като разработчиците на софтуер. Трябваше да организираме процесите на разработка, непрекъснато тестване, доставка и прилагане на конфигурационен код към производствени сървъри.
Ако това не бъде направено незабавно, тогава ролите, записани за конфигурацията, или ще спрат да се поддържат и модифицират, или ще спрат да се стартират в производство. Лекът за тази болка е известен и се е доказал в този проект:
- всяка роля е покрита от модулни тестове;
- тестовете се изпълняват автоматично, когато има някаква промяна в кода, който управлява конфигурациите;
- промените в кода за управление на конфигурацията се пускат в производствената среда само след успешно преминаване на всички тестове и преглед на кода.
Разработването на код и управлението на конфигурацията станаха по-спокойни и по-предвидими. За да организираме непрекъснато тестване, използвахме инструментариума GitLab CI/CD и взехме .
Всеки път, когато има промяна в кода за управление на конфигурацията, GitLab CI/CD извиква Molecule:
- той проверява синтаксиса на кода,
- повдига контейнера на Docker,
- прилага модифицирания код към създадения контейнер,
- проверява ролята за идемпотентност и изпълнява тестове за този код (детайлността тук е на ниво ansible роля, вижте фиг. 4).
Доставихме конфигурации на производствената среда с помощта на Ansible AWX. Оперативните инженери приложиха промени в конфигурацията чрез предварително зададени шаблони. AWX независимо „поиска“ най-новата версия на кода от главния клон на GitLab всеки път, когато се използва. По този начин изключихме използването на нетестван или остарял код в производствената среда. Естествено, кодът влезе в главния клон само след тестване, преглед и одобрение.
Ориз. 4. Автоматично тестване на роли в GitLab CI/CD.
Съществува и проблем, свързан с работата на производствените системи. В реалния живот е много трудно да се правят промени в конфигурацията само чрез CMS код. Възникват извънредни ситуации, когато инженерът трябва да промени конфигурацията „тук и сега“, без да чака редактиране на кода, тестване, одобрение и т.н.
В резултат на това, поради ръчни промени, се появяват несъответствия в конфигурацията на един и същ тип оборудване (например настройките на sysctl са конфигурирани по различен начин в HA клъстерни възли). Или действителната конфигурация на оборудването се различава от посочената в CMS кода.
Следователно, в допълнение към непрекъснатото тестване, ние проверяваме производствените среди за несъответствия в конфигурацията. Избрахме най-простия вариант: стартиране на конфигурационния код на CMS в режим „суха работа“, тоест без прилагане на промени, но с известие за всички несъответствия между планираната и действителната конфигурация. Реализирахме това чрез периодично стартиране на всички Ansible playbooks с опцията „—проверка“ на производствени сървъри. Както винаги, Ansible AWX е отговорен за стартирането и поддържането на книгата за игра актуална (вижте фиг. 5):
Ориз. 5. Проверява за несъответствия в конфигурацията в Ansible AWX.
След проверките AWX изпраща доклад за несъответствие на администраторите. Те изучават проблемната конфигурация и след това я коригират чрез коригирани книги за игра. Така поддържаме конфигурацията в производствената среда и CMS е винаги актуална и синхронизирана. Това елиминира неприятните „чудеса“, когато CMS кодът се използва на „производствени“ сървъри.
Сега имаме важен слой за тестване, състоящ се от Ansible AWX/GitLab/Molecule (Фигура 6).
Ориз. 6. Управление на тестовете.
Труден? не споря. Но такъв комплекс от управление на конфигурацията се превърна в изчерпателен отговор на много въпроси, свързани с автоматизацията на конфигурацията на сървъра. Сега стандартните сървъри на търговците винаги имат строго дефинирана конфигурация. CMS, за разлика от инженера, няма да забрави да добави необходимите настройки, да създаде потребители и да извърши десетки или стотици необходими настройки.
Днес няма „тайно знание“ в настройките на сървърите и средите. Всички необходими функции са отразени в книгата. Без повече креативност и неясни инструкции: “Инсталирайте го като обикновен Oracle, но трябва да зададете няколко sysctl настройки и да добавите потребители с необходимия UID. Питайте момчетата в експлоатация, те знаят".
Способността за откриване на несъответствия в конфигурацията и коригирането им проактивно осигурява спокойствие. Без система за управление на конфигурацията това обикновено изглежда различно. Проблемите се натрупват, докато един ден не се „стрелят“ в производството. След това се извършва дебрифинг, конфигурациите се проверяват и коригират. И цикълът се повтаря отново
И разбира се, ускорихме пускането на сървърите в експлоатация от няколко дни до часове.
Е, в самата новогодишна нощ, когато децата радостно разопаковаха подаръци, а възрастните си правеха желания, докато камбаните биеха, нашите инженери мигрираха системата SAP към нови сървъри. Дори Дядо Коледа ще каже, че най-хубавите чудеса са тези, които са добре приготвени.
PS Нашият екип често се сблъсква с факта, че клиентите искат да решат проблемите с управлението на конфигурацията възможно най-просто. В идеалния случай, като на магия - с един инструмент. Но в живота всичко е по-сложно (да, сребърните куршуми не бяха доставени отново): трябва да създадете цял процес, като използвате инструменти, които са удобни за екипа на клиента.
Автор: Сергей Артемов, архитект на отдела "Джет Инфосистеми"
Източник: www.habr.com