Ця стаття є шостою у циклі статей «Як взяти мережеву інфраструктуру під свій контроль». Зміст усіх статей циклу та посилання можна знайти .
Залишивши кілька тем позаду, я вирішив почати новий розділ.
До безпеки повернуся трохи згодом. Тут я хочу обговорити один простий, але ефективний підхід, який, певен, у тому чи іншому вигляді, може стати у нагоді багатьом. Це скоріше коротка історія про те, як автоматизація може змінити життя інженера. Йтиметься про використання темлейтів. Наприкінці наводиться список моїх проектів, де можна подивитися, як усе описане тут працює.
DevOps для мережі
Створення конфігурації скриптом, використання GIT для контролю змін IT інфраструктури, віддалена «заливка» — ці ідеї приходять в першу чергу, коли ви думаєте про технічну реалізацію DevOps підходу. Плюси очевидні. Але є, на жаль, і мінуси.
Коли понад 5 років тому наші розробники прийшли до нас, до мережевиків, з цими пропозиціями, ми не були в захваті.
Треба сказати, що у спадок нам дісталася досить строката мережа, що складається з обладнання близько 10 різних вендорів. Щось було зручно конфігурувати через наш улюблений cli, але десь ми воліли використовувати GUI. До того ж довга робота на «живому» обладнанні привчили до реал-тайму контролю. Я, наприклад, здійснюючи зміни, набагато комфортніше почуваюся, працюючи безпосередньо через cli. Так я можу швидко побачити, що щось пішло не так і відкотити зміни. Все це знаходилося в певній суперечності з їхніми ідеями.
Виникають інші питання, наприклад, від версії до версії софта інтерфейс може трохи змінюватися. Це призведе до того, що ваш скрипт буде створювати неправильний «конфіг». Не хотілося б використовувати production для обкатки.
Або як зрозуміти, що конфігураційні команди застосовувалися коректно і що робити, у разі помилки?
Не хочу сказати, що всі ці питання не вирішуються. Просто сказавши "A", напевно, розумно сказати і "В" і, якщо ви хочете використовувати ті ж процеси для контролю змін, що і в розробці, то потрібно мати крім production також dev і staging середовища. Тоді цей підхід виглядає завершеним. Але скільки це коштуватиме?
Але є одна ситуація, коли мінуси практично нівелюються, і залишаються лише плюси. Я говорю про проектні роботи.
Проект
Останні два роки я беру участь у проекті з будівництва дата-центру для одного великого провайдера. Я відповідаю у цьому проекті за F5 та Palo Alto. З погляду Cisco це "3rd party equipment".
Особисто для мене є дві яскраво виражені стадії у цьому проекті.
перша стадія
Перший рік я був нескінченно зайнятий, я працював ночами та у вихідні. Я не міг підвести голови. Тиск з боку менеджменту та замовника був сильним та безперервним. У постійній рутині я не міг навіть спробувати оптимізувати процес. Це було не тільки і навіть не так конфігурування обладнання, як складання проектної документації.
Ось почалися перші тести, і я б вражений, скільки дрібних помилок та неточностей було допущено. Звичайно, все працювало, але там пропущено букву в назві, тут пропущено рядок у команді… Тести тривали і тривали, і я вже перебував у постійній, щоденній боротьбі з помилками, тестами та документацією.
Так тривало рік. Проект, наскільки я розумію, був непростим для всіх, але поступово клієнт ставав все більш задоволеним, і це дало можливість взяти додаткових інженерів, які змогли взяти частину рутини на себе.
Тепер можна було трохи озирнутися.
І це був початок другого етапу.
друга стадія
Я вирішив автоматизувати процес.
Що я зрозумів з тогочасного спілкування з розробниками (і треба віддати належне, у нас була сильна команда), так це те, що текстовий формат, хоча, і здається на перший погляд чимось із світу операційної системи DOS, але має низку цінних властивостей .
Так, наприклад, текстовий формат буде корисним, якщо ви хочете повною мірою використовувати переваги GIT та всіх його похідних. А я хотів.
Ну, здавалося б, можна просто зберігати конфігуруацію або список команд, але змінювати при цьому досить незручно. До того ж, при проектуванні стоїть ще одне важливе завдання. У вас має бути документація, що описує ваш дизайн загалом (Low Level Design) та конкретна імплементація (Network Implementation Plan). І в даному випадку використання темплейтів виглядає дуже слушним варіантом.
Так, при використанні YAML і Jinja2, YAML файл з параметрами конфігурації, такими як IP адреси, номери BGP AS, ... відмінно виконує роль NIP, в той час як Jinja2 темплейти включають синтаксис відповідний дизайну, тобто по суті є відображенням LLD.
На вивчення мов YAML та Jinja2 пішло два дні. Щоб зрозуміти, як це працює достатньо кількох добрих прикладів. Далі близько двох тижнів пішло на те, щоб створити всі темплейти, що відповідають нашому дизайну: тиждень для Palo Alto і ще тиждень для F5. Все це було викладено на корпоративний githab.
Тепер процес змін виглядав так:
- змінив YAML файл
- створив за допомогою шаблону (Jinja2) конфігураційний файл
- зберіг у віддаленому репозиторії
- залив створену конфігурацію обладнання
- побачив помилку
- змінив YAML файл або Jinja2 темплейт
- створив за допомогою шаблону (Jinja2) конфігураційний файл
- ...
Зрозуміло, що спочатку багато часу йшло на правки, але через тиждень-два це вже стало скоріше рідкістю.
Гарною перевіркою та можливістю все налагодити стало бажання клієнта змінити naming convention. Хто працював з F5 розуміє пікантність ситуації. Але для мене все було просто. Я змінив імена в YAML файлі, видалив всю конфігурацію з обладнання, згенерував нову та залив. На все, з урахуванням правок багів, пішло чотири дні: по два дні на кожну технологію. Після цього я був готовий до наступного етапу, а саме створення DEV та Staging дата-центрів.
Dev та Staging
Staging фактично повністю повторює виробництво. Dev - сильно урізана та побудована в основному на віртуальному обладнанні копія. Ідеальна ситуація до застосування нового підходу. Якщо із загального процесу вичленувати витрачений мною час, то роботи, гадаю, зайняли не більше 2-х тижнів. Основний час — це час очікування іншої сторони та спільні пошуки проблем. Імплементація 3rd party пройшла майже непомітно для оточуючих. З'явився навіть час щось повчити та написати пару статей на Хабрі 🙂
Підведемо підсумок
Отже, що я маю у сухому залишку?
- все, що потрібно мені для зміни конфігурації, — змінити простий, чітко структурований YAML файл із конфігураційними параметрами. Я ніколи не змінюю python скрипт і дуже рідко (тільки якщо є помилка) міняю Jinja2 теплейт
- з погляду документації виходить майже ідеальна ситуація. Ви змінюєте документацію (YAML файли виконують роль NIP) та заливаєте цю конфігурацію на обладнання. Таким чином, ваша документація завжди актуальна
Все це призвело до того, що
- відсоток помилок знизився практично до 0
- пішло 90 відсотків рутини
- у рази збільшилася швидкість впровадження
PAY, F5Y, ACY
Я казав, що кілька прикладів достатньо, щоб зрозуміти, як це працює.
Тут коротка (і, звичайно, видозмінена) версія того, що було створено в процесі моєї роботи.
= deployment PАло Alto from Yaml = Palo Alto від Yaml
= deployment F5 від Yaml = F5 від Yaml (скоро буде)
= deployment ACя з Yaml = F5 від Yмолодший
Додам кілька слів про ACY (не плутати з ACI).
Ті, хто працював з ACI знають, що це диво (і в хорошому сенсі теж) було створено точно не сітківцями :). Забудьте все що ви знали про мережу - це вам не знадобиться!
Трохи перебільшено, але приблизно передає те відчуття, яке я постійно, ось уже 3 роки, відчуваю, працюючи з ACI.
І в даному випадку ACY - це не тільки можливість побудувати процес контролю змін (що особливо важливо у випадку ACI, тому що передбачається, що це центральна і найбільш критична частина дата-центру), але також дає вам дружній інтерфейс для створення конфігурації.
Інженери в даному проекті для конфігурування ACI замість YAML для точності тієї ж мети використовують Excel. У використанні Excel, звичайно, є плюси:
- ваш NIP в одному файлі
- гарні таблички, на які приємно дивитися клієнту
- ви можете використовувати деякі інструменти Excel
Але є один мінус, і він, на мій погляд, переважує плюси. Контролювати зміни та узгоджувати роботу команди стає набагато складніше.
ACY – це фактично застосування тих самих підходів, що я використав для 3rd party, для конфігурування ACI.
Джерело: habr.com