Ближила се Нова година. Деца широм земље су већ слала писма Деда Мразу или правила поклоне за себе, а њихов главни извршилац, један од највећих трговаца, припремао се за апотеозу продаје. У децембру се оптерећење његовог дата центра повећава неколико пута. Због тога је компанија одлучила да модернизује дата центар и пусти у рад неколико десетина нових сервера уместо опреме која је била на крају свог радног века. Овим се прича завршава на позадини усковитланих пахуља и почиње трилер.

Опрема је стигла на локацију неколико месеци пре врхунца продаје. Оперативна служба, наравно, зна како и шта да конфигурише на серверима како би их увела у производно окружење. Али морали смо да аутоматизујемо ово и елиминишемо људски фактор. Поред тога, сервери су замењени пре миграције скупа САП система који су били критични за компанију.

Пуштање у рад нових сервера било је строго везано за рок. А његово померање значило је угрозити и испоруку милијарду поклона и миграцију система. Чак ни тим који чине Деда Мраз и Деда Мраз није могао да промени датум - можете да пренесете САП систем за управљање складиштем само једном годишње. Од 31. децембра до 1. јануара, огромна складишта малопродаје, укупне величине 20 фудбалских терена, престају са радом на 15 сати. И ово је једини временски период за померање система. Нисмо имали места за грешке приликом увођења сервера.

Да будем јасан: моја прича одражава алате и процес управљања конфигурацијом које наш тим користи.

Комплекс за управљање конфигурацијом састоји се од неколико нивоа. Кључна компонента је ЦМС систем. У индустријском раду, одсуство једног од нивоа неминовно би довело до непријатних чуда.

Управљање инсталацијом ОС

Први ниво је систем за управљање инсталацијом оперативних система на физичким и виртуелним серверима. Он креира основне конфигурације ОС-а, елиминишући људски фактор.

Користећи овај систем, добили смо стандардне серверске инстанце са ОС погодним за даљу аутоматизацију. Током „пресипања“ добили су минималан скуп локалних корисника и јавних ССХ кључева, као и конзистентну конфигурацију ОС-а. Могли смо бити гарантовани да управљамо серверима преко ЦМС-а и били смо сигурни да нема изненађења „доле“ на нивоу ОС.

„Максимални“ задатак за систем за управљање инсталацијом је да аутоматски конфигурише сервере од нивоа БИОС-а/фирмвера до ОС-а. Овде много зависи од опреме и задатака подешавања. За хетерогену опрему, можете размотрити РЕДФИСХ АПИ. Ако је сав хардвер од једног произвођача, онда је често згодније користити готове алате за управљање (на пример, ХП ИЛО Амплифиер, ДЕЛЛ ОпенМанаге, итд.).

За инсталацију ОС-а на физичке сервере користили смо добро познати Цобблер, који дефинише скуп инсталационих профила договорених са услугом рада. Приликом додавања новог сервера у инфраструктуру, инжењер је везао МАЦ адресу сервера са потребним профилом у Цобблер-у. Приликом првог покретања преко мреже, сервер је добио привремену адресу и нови ОС. Затим је пребачен на циљно ВЛАН/ИП адресирање и тамо је настављен рад. Да, промена ВЛАН-а захтева време и координацију, али пружа додатну заштиту од случајне инсталације сервера у производном окружењу.

Направили смо виртуелне сервере на основу шаблона припремљених помоћу ХасхиЦорп Пацкер-а. Разлог је био исти: да би се спречиле могуће људске грешке приликом инсталирања ОС-а. Али, за разлику од физичких сервера, Пацкер елиминише потребу за ПКСЕ, покретањем мреже и променама ВЛАН-а. Ово је учинило лакшим и једноставнијим креирање виртуелних сервера.

Пиринач. 1. Управљање инсталацијом оперативних система.

Управљање тајнама

Сваки систем за управљање конфигурацијом садржи податке које треба сакрити од обичних корисника, али су потребни за припрему система. То су лозинке за локалне кориснике и налоге услуга, кључеви сертификата, разни АПИ токени, итд. Обично се називају „тајне“.

Ако од самог почетка не одредите где и како да чувате ове тајне, онда су, у зависности од озбиљности захтева за безбедност информација, вероватно следеће методе складиштења:

• директно у контролном коду конфигурације или у фајловима у спремишту;
• у специјализованим алатима за управљање конфигурацијом (на пример, Ансибле Ваулт);
• у ЦИ/ЦД системима (Јенкинс/ТеамЦити/ГитЛаб/итд.) или у системима за управљање конфигурацијом (Ансибле Товер/Ансибле АВКС);
• тајне се такође могу пренети „ручно“. На пример, они су постављени на одређеној локацији, а затим их користе системи за управљање конфигурацијом;
• разне комбинације горе наведеног.

Свака метода има своје недостатке. Главни је недостатак политике приступа тајнама: немогуће је или тешко одредити ко може користити одређене тајне. Још један недостатак је недостатак ревизије приступа и пуног животног циклуса. Како брзо заменити, на пример, јавни кључ који је написан у коду и у низу повезаних система?

Користили смо централизовано тајно складиште ХасхиЦорп Ваулт. Ово нам је омогућило:

• чувај тајне. Они су шифровани, па чак и ако неко добије приступ бази података Трезора (на пример, враћањем из резервне копије), неће моћи да прочита тајне које се тамо чувају;
• организују политике за приступ тајнама. Корисницима и апликацијама доступне су само тајне које су им „додељене“;
• ревизијски приступ тајнама. Све радње са тајнама се бележе у дневник ревизије трезора;
• организују пуноправни „животни циклус“ рада са тајнама. Могу се креирати, опозвати, поставити датум истека итд.
• лако се интегрише са другим системима којима је потребан приступ тајнама;
• а такође користите енд-то-енд енкрипцију, једнократне лозинке за ОС и базу података, сертификате овлашћених центара итд.

Сада пређимо на централни систем аутентификације и ауторизације. Било је могуће без тога, али администрирање корисника у многим сродним системима је превише нетривијално. Конфигурисали смо аутентификацију и ауторизацију преко ЛДАП услуге. У супротном, Ваулт би морао континуирано да издаје и прати токене за аутентификацију за кориснике. А брисање и додавање корисника претворило би се у потрагу „да ли сам свуда креирао/избрисао овај кориснички налог?“

Додали смо још један ниво нашем систему: управљање тајнама и централна аутентификација/ауторизација:

Пиринач. 2. Управљање тајнама.

Управљање конфигурацијом

Дошли смо до сржи - ЦМС система. У нашем случају, ово је комбинација Ансибле и Ред Хат Ансибле АВКС.

Уместо Ансибле-а, могу се користити Цхеф, Пуппет, СалтСтацк. Изабрали смо Ансибле на основу неколико критеријума.

• Прво, то је свестраност. Сет готових модула за контролу то је импресивно. А ако га немате довољно, можете претраживати на ГитХуб-у и Галаки-у.
• Друго, нема потребе да инсталирате и подржавате агенте на управљаној опреми, доказујете да они не ометају оптерећење и потврђују одсуство „обележивача“.
• Треће, Ансибле има ниску баријеру за улазак. Компетентни инжењер ће написати радну књигу буквално првог дана рада са производом.

Али сам Ансибле у производном окружењу није нам био довољан. У супротном би се појавили многи проблеми са ограничавањем приступа и ревизијом поступања администратора. Како ограничити приступ? На крају крајева, било је неопходно да свако одељење управља (читај: покреће Ансибле плаибоок) „својим“ скупом сервера. Како дозволити само одређеним запосленима да покрећу одређене Ансибле плаибоокс? Или како пратити ко је покренуо приручник без постављања пуно локалног знања о серверима и опреми која покреће Ансибле?

Лавовски део таквих питања решава Ред Хат Ансибле Товер, или његов упстреам пројекат отвореног кода Ансибле АВКС. Зато смо то преферирали за купца.

И још један додир портрету нашег ЦМС система. Ансибле плаибоок треба да се складишти у системима за управљање репозиторијумом кода. Ми имамо ГитЛаб ЦЕ.

Дакле, самим конфигурацијама се управља комбинацијом Ансибле/Ансибле АВКС/ГитЛаб (види слику 3). Наравно, АВКС/ГитЛаб је интегрисан са једним системом за аутентификацију, а Ансибле плаибоок је интегрисан са ХасхиЦорп трезором. Конфигурације улазе у производно окружење само преко Ансибле АВКС-а, у којем су наведена сва „правила игре“: ко шта може да конфигурише, где да добије код за управљање конфигурацијом за ЦМС, итд.

Пиринач. 3. Управљање конфигурацијом.

Управљање тестом

Наша конфигурација је представљена у облику кода. Стога смо приморани да играмо по истим правилима као и програмери софтвера. Требало је да организујемо процесе развоја, континуираног тестирања, испоруке и примене конфигурационог кода на производне сервере.

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

• свака улога је покривена јединичним тестовима;
• тестови се покрећу аутоматски кад год дође до било какве промене у коду који управља конфигурацијама;
• промене у коду за управљање конфигурацијом се пуштају у производно окружење тек након успешног проласка свих тестова и прегледа кода.

Развој кода и управљање конфигурацијом постали су мирнији и предвидљивији. Да бисмо организовали континуирано тестирање, користили смо ГитЛаб ЦИ/ЦД комплет алата и узели Ансибле Молецуле.

Кад год дође до промене кода за управљање конфигурацијом, ГитЛаб ЦИ/ЦД позива Молецуле:

• проверава синтаксу кода,
• подиже Доцкер контејнер,
• примењује измењени код на креирани контејнер,
• проверава улогу идемпотенције и покреће тестове за овај код (грануларност је овде на нивоу улоге ансибле, видети слику 4).

Испоручили смо конфигурације у производно окружење користећи Ансибле АВКС. Оперативни инжењери су применили промене конфигурације путем унапред дефинисаних шаблона. АВКС је независно „затражио“ најновију верзију кода од ГитЛаб мастер гране сваки пут када је коришћен. На овај начин смо искључили употребу непровереног или застарелог кода у производном окружењу. Наравно, код је ушао у главну грану тек након тестирања, прегледа и одобрења.

Пиринач. 4. Аутоматско тестирање улога у ГитЛаб ЦИ/ЦД.

Постоји и проблем везан за рад производних система. У стварном животу, веома је тешко извршити промене у конфигурацији само помоћу ЦМС кода. Хитне ситуације настају када инжењер мора да промени конфигурацију „овде и сада“, без чекања на уређивање кода, тестирање, одобрење итд.

Као резултат тога, услед ручних промена, појављују се неслагања у конфигурацији на истој врсти опреме (на пример, сисцтл подешавања су различито конфигурисана на чворовима ХА кластера). Или се стварна конфигурација на опреми разликује од оне наведене у ЦМС коду.

Због тога, поред континуираног тестирања, проверавамо производна окружења на одступања у конфигурацији. Изабрали смо најједноставнију опцију: покретање ЦМС конфигурационог кода у „дри рун“ режиму, односно без примене промена, али уз обавештење о свим неслагањима између планиране и стварне конфигурације. Ово смо имплементирали тако што смо повремено покретали све Ансибле плаибоокове са опцијом „—цхецк“ на производним серверима. Као и увек, Ансибле АВКС је одговоран за покретање и ажурирање приручника (погледајте слику 5):

Пиринач. 5. Проверава одступања у конфигурацији у Ансибле АВКС.

Након провере, АВКС шаље извештај о неслагању администраторима. Они проучавају проблематичну конфигурацију, а затим је поправљају кроз прилагођене приручнике. На овај начин одржавамо конфигурацију у производном окружењу, а ЦМС је увек ажуриран и синхронизован. Ово елиминише непријатна „чуда“ када се ЦМС код користи на „производним“ серверима.

Сада имамо важан слој за тестирање који се састоји од Ансибле АВКС/ГитЛаб/Молецуле (слика 6).

Пиринач. 6. Управљање тестом.

Тешко? не расправљам се. Али такав комплекс управљања конфигурацијом постао је свеобухватан одговор на многа питања везана за аутоматизацију конфигурације сервера. Сада стандардни сервери продавца увек имају строго дефинисану конфигурацију. ЦМС, за разлику од инжењера, неће заборавити да дода потребна подешавања, креира кориснике и изврши десетине или стотине потребних подешавања.

Данас нема „тајног знања“ у подешавањима сервера и окружења. Све потребне карактеристике су приказане у књизи. Нема више креативности и нејасних упутстава: „Инсталирајте га као обичан Орацле, али морате да наведете неколико сисцтл подешавања и додате кориснике са потребним УИД-ом. Питајте момке који раде, они знају'.

Способност откривања конфигурацијских неслагања и проактивног исправљања пружа безбрижност. Без система за управљање конфигурацијом, ово обично изгледа другачије. Проблеми се гомилају све док једног дана не „пуцају” у производњу. Затим се врши дебрифинг, конфигурације се проверавају и исправљају. И циклус се поново понавља

И наравно, убрзали смо пуштање сервера у рад са неколико дана на неколико сати.

Па, на саму новогодишњу ноћ, када су деца радосно одмотавала поклоне, а одрасли замишљали жеље док су звона ударала, наши инжењери су мигрирали САП систем на нове сервере. Чак ће и Деда Мраз рећи да су најбоља чуда она која су добро припремљена.

ПС Наш тим се често сусреће са чињеницом да корисници желе да реше проблеме управљања конфигурацијом што је једноставније могуће. Идеално, као магијом - са једним алатом. Али у животу је све компликованије (да, сребрни меци нису поново испоручени): морате да креирате цео процес користећи алате који су погодни за тим купца.

Аутор: Сергеј Артемов, архитекта одељења ДевОпс решења "Јет Инфосистеми"

Извор: ввв.хабр.цом