Се наближуваше Нова Година. Децата ширум земјата веќе испратија писма до Дедо Мраз или направија подароци за себе, а нивниот главен извршител, еден од најголемите трговци на мало, се подготвуваше за апотеоза на продажбата. Во декември, оптоварувањето на неговиот центар за податоци се зголемува неколку пати. Поради тоа, компанијата одлучи да го модернизира центарот за податоци и да пушти во функција неколку десетици нови сервери наместо опрема што го доближуваше својот век на траење. Ова ја завршува приказната на позадината на вртливите снегулки и започнува трилерот.
Опремата пристигна на локацијата неколку месеци пред врвот на продажбата. Оперативната услуга, се разбира, знае како и што да конфигурира на серверите за да ги внесе во производствената средина. Но, требаше да го автоматизираме ова и да го елиминираме човечкиот фактор. Дополнително, серверите беа заменети пред миграцијата на сет SAP системи кои беа критични за компанијата.
Пуштањето во употреба на новите сервери беше строго поврзано со краен рок. А неговото преместување значеше загрозување и на испораката на милијарда подароци и на миграцијата на системите. Дури и тимот составен од отец Фрост и Дедо Мраз не можеше да го промени датумот - можете да го префрлите системот SAP за управување со складиште само еднаш годишно. Од 31 декември до 1 јануари, огромните магацини на трговецот на мало, вкупно со големина од 20 фудбалски игралишта, престануваат со работа на 15 часа. И ова е единствениот временски период за поместување на системот. Немавме простор за грешка при воведувањето на серверите.
Дозволете ми да бидам јасен: мојата приказна ги одразува алатките и процесот на управување со конфигурацијата што ги користи нашиот тим.
Комплексот за управување со конфигурации се состои од неколку нивоа. Клучната компонента е CMS системот. Во индустриското работење, отсуството на едно од нивоата неизбежно би довело до непријатни чуда.
Управување со инсталацијата на ОС
Првото ниво е систем за управување со инсталација на оперативни системи на физички и виртуелни сервери. Создава основни конфигурации на ОС, елиминирајќи го човечкиот фактор.
Користејќи го овој систем, добивме стандардни примероци на сервер со оперативен систем погоден за понатамошна автоматизација. За време на „истурањето“ тие добија минимален сет на локални корисници и јавни SSH клучеви, како и конзистентна конфигурација на ОС. Можевме да гарантираме дека ќе управуваме со серверите преку CMS и бевме сигурни дека нема изненадувања „долу“ на ниво на ОС.
„Максималната“ задача за системот за управување со инсталацијата е автоматски да ги конфигурира серверите од ниво на BIOS/Firmware до ОС. Многу тука зависи од опремата и задачите за поставување. За хетерогена опрема, можете да размислите . Ако целиот хардвер е од еден продавач, тогаш често е попогодно да се користат готови алатки за управување (на пример, 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, може да се користат Шеф, Кукла, SaltStack. Го избравме Ansible врз основа на неколку критериуми.
- Прво, тоа е разноврсност. Збир на готови модули за контрола . И ако немате доволно од тоа, можете да пребарувате на GitHub и Galaxy.
- Второ, нема потреба да се инсталираат и поддржуваат агенти на управувана опрема, да се докажува дека тие не се мешаат во оптоварувањето и да се потврди отсуството на „обележувачи“.
- Трето, Ansible има ниска бариера за влез. Компетентен инженер ќе напише работна книга за игри буквално на првиот ден од работата со производот.
Но, само Ансибл во производствена средина не ни беше доволен. Во спротивно, би се појавиле многу проблеми со ограничување на пристапот и ревизија на активностите на администраторите. Како да го ограничите пристапот? На крајот на краиштата, беше неопходно секој оддел да управува (читај: стартувај ја Playbook 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:
- ја проверува синтаксата на кодот,
- го крева контејнерот Докер,
- го применува изменетиот код на креираниот контејнер,
- ја проверува улогата за идемпотенција и извршува тестови за овој код (грануларноста овде е на ниво на одговорна улога, видете на слика 4).
Ние испорачавме конфигурации во производствената средина користејќи Ansible AWX. Оперативните инженери применија промени во конфигурацијата преку претходно дефинирани шаблони. AWX независно ја „бараше“ најновата верзија на кодот од главната гранка на GitLab секогаш кога се користеше. На овој начин ја исклучивме употребата на непроверен или застарен код во производната средина. Секако, кодот влезе во главната гранка само по тестирање, преглед и одобрување.
Ориз. 4. Автоматско тестирање на улоги во GitLab CI/CD.
Има и проблем поврзан со работата на производните системи. Во реалниот живот, многу е тешко да се направат промени во конфигурацијата само преку CMS код. Итни ситуации се јавуваат кога инженерот мора да ја промени конфигурацијата „овде и сега“, без да чека за уредување на кодот, тестирање, одобрување итн.
Како резултат на тоа, поради рачните промени, се појавуваат несовпаѓања во конфигурацијата на истиот тип на опрема (на пример, поставките на sysctl се конфигурирани поинаку на јазлите на кластерот HA). Или вистинската конфигурација на опремата се разликува од онаа наведена во кодот CMS.
Затоа, покрај континуираното тестирање, ги проверуваме производните средини за несовпаѓања во конфигурацијата. Ја избравме наједноставната опција: извршување на кодот за конфигурација CMS во режим „суво извршување“, односно без примена на промени, но со известување за сите несовпаѓања помеѓу планираната и вистинската конфигурација. Ова го имплементиравме со периодично вклучување на сите книги за играње Ansible со опцијата „—check“ на производствените сервери. Како и секогаш, Ansible AWX е одговорен за стартување и ажурирање на книгата за игри (види слика 5):
Ориз. 5. Проверува дали има несовпаѓања во конфигурацијата во Ansible AWX.
По проверките, AWX испраќа извештај за несовпаѓање до администраторите. Тие ја проучуваат проблематичната конфигурација и потоа ја поправаат преку прилагодени книги за играње. Така ја одржуваме конфигурацијата во производствената средина и CMS е секогаш ажуриран и синхронизиран. Ова ги елиминира непријатните „чуда“ кога CMS кодот се користи на „производствените“ сервери.
Сега имаме важен слој за тестирање кој се состои од Ansible AWX/GitLab/Molecule (Слика 6).
Ориз. 6. Управување со тестови.
Тешко? Јас не се расправам. Но, таков комплекс на управување со конфигурации стана сеопфатен одговор на многу прашања поврзани со автоматизацијата на конфигурацијата на серверот. Сега стандардните сервери на трговците на мало секогаш имаат строго дефинирана конфигурација. CMS, за разлика од инженерот, нема да заборави да ги додаде потребните поставки, да креира корисници и да изврши десетици или стотици потребни поставки.
Денес нема „тајно знаење“ во поставките на серверите и околините. Сите потребни карактеристики се рефлектираат во книгата за игри. Нема повеќе креативност и нејасни упатства: “Инсталирајте го како обичен Oracle, но треба да наведете неколку поставки за sysctl и да додадете корисници со потребниот UID. Прашајте ги момците во операција, тие знаат".
Способноста да се детектираат несовпаѓања во конфигурацијата и да се коригираат проактивно, обезбедува мир на умот. Без систем за управување со конфигурации, ова обично изгледа поинаку. Проблемите се акумулираат додека еден ден не „пукаат“ во производство. Потоа се врши дебрифинг, се проверуваат и коригираат конфигурациите. И циклусот се повторува повторно
И секако, го забрзавме пуштањето во функција на серверите од неколку дена до часови.
Па, на самата новогодишна ноќ, кога децата радосно ги одвиткуваа подароците, а возрасните си правеа желби додека се слушаа ѕвончињата, нашите инженери го префрлија системот SAP на нови сервери. Дури и Дедо Мраз ќе каже дека најдобри чуда се оние што се добро подготвени.
П.С Нашиот тим често се среќава со фактот дека клиентите сакаат да ги решат проблемите со управувањето со конфигурацијата што е можно поедноставно. Идеално, како со магија - со една алатка. Но, во животот сè е покомплицирано (да, сребрените куршуми не беа испорачани повторно): треба да креирате цел процес користејќи алатки што се погодни за тимот на клиентите.
Автор: Сергеј Артемов, одделенски архитект „Jet Infosystems“
Извор: www.habr.com