Це розшифровка виступу на и .
Це історія проекту, на якому використовувалася самописна система управління конфігураціями, і чому переїзд на Ansible затягнувся на 18 місяців.
День №-ХХХ: Before the beginning
Спочатку інфраструктура являла собою безліч хостів, що окремо стоять, під управлінням Hyper-V. Створення віртуальної машини вимагало безліч дій: покласти диски у потрібне місце, прописати DNS, зарезервувати DHCP, покласти конфігурацію ВМ у git репозиторій. Цей процес був частково механізований, але, наприклад, ВМ розподілялися між хостами руками. Але, наприклад, розробники могли виправивши конфігурацію ВМ в git застосувати її перезавантаживши ВМ.
Custom Configuration Management Solution
Спочатку ідею, підозрюю, задумували як IaC: безліч stateless ВМ, які при перезавантаженні обнуляли свій стан. Що являло собою управління змінами ВМ? Схематично виглядає просто:
- Для ВМ прибивали статичний MAC.
- До ВМ підключали ISO з CoreOS та завантажувальний диск.
- CoreOS запускає скрипт кастомізації, завантаживши його з WEB сервера на підставі свого IP.
- Скрипт викачує через SCP конфігурацію ВМ виходячи з IP адресі.
- Запускається портянка systemd unit файлів і портянка bash скриптів.
У цього рішення було безліч очевидних проблем:
- ISO в CoreOS було deprecated.
- Безліч складно автоматизованих дій та магії при міграції/створенні ВМ.
- Складність з оновленням і коли необхідно програмне забезпечення якоїсь версії. Ще веселіше із модулями ядра.
- ВМ не такі без даних виходили, тобто. з'явилися ВМ у яких змонтований диск з даними користувача додатково.
- Постійно хтось косячив із залежностями systemd unit і при перезавантаженні CoreOS зависала. Наявними засобами CoreOS відловити це було проблемно.
- Управління секретами.
- CM не було рахуй. Були bash та YML конфігі CoreOS.
Щоб застосувати конфігурацію ВМ, необхідно її перезавантажити, але вона могла не перезавантажитися. Начебто очевидна проблема, але персистентних дисків немає – логи зберігати нікуди. Ну ок, давайте спробуємо додати опції завантаження ядра щоб логи пересилали. Але ні, як це складно.
День №0: Визнання проблеми
Це була проста розробна інфраструктура: jenkins, тестові оточення, моніторинги, registre. CoreOS замислювалася для хостингу k8s кластерів, тобто. проблема була у тому, як використовувалася CoreOS. Першим кроком був вибір стеку. Ми зупинилися на:
- CentOS як базовий дистрибутив, т.к. це найбільш близький дистрибутив до production оточення.
- Неможливо керувати змінами, т.к. у ньому була велика експертиза.
- Дженкінс як фреймворк автоматизації існуючих процесів, т.к. він вже активно використовувався для процесів розробки
- Hyper-V як платформа віртуалізації. Є низка причин, що виходять за межі оповідання, але якщо коротко — ми не можемо використовувати хмари, маємо використовувати своє залізо.
День №30: Фіксуємо існуючі домовленості — Agreements as Code
Коли було зрозуміло стек, почалася підготовка до переїзду. Фіксування існуючих домовленостей у вигляді коду (Agreements as Code!). Перехід ручна праця -> механізація -> автоматизація.
1. Configure VMs
Ansible чудово справляється з цим завданням. З мінімум рухів тіла можна взяти під управління конфігураціями ВМ:
- Створюємо git репозиторій.
- Складаємо список ВМ в inventory, конфігурації в плейбуки та ролі.
- Налаштовуємо спеціальний jenkins slave з котрого можна буде запускати ansible.
- Створюємо job, налаштовуємо Jenkins.
Перший процес готовий. Домовленості зафіксовано.
2. Create new VM
Тут усе було не дуже зручно. З лінукс не дуже зручно створювати ВМ на Hyper-V. Однією із спроб механізувати цей процес було:
- Ansbile підключається через WinRM до windows хоста.
- Неможливо запускає потужність скрипта.
- Powershell скрипт створює новий ВМ.
- Засобами Hyper-V/ScVMM при створенні вм в гостьовій ОС налаштовується hostname.
- ВМ під час оновлення DHCP lease відсилає свій hostname.
- Штатна інтеграція ddns & dhcp на стороні Domain Controller налаштовує запис DNS.
- Можна додавати ВМ до інвенторів та налаштовувати її Ansible.
3. Create VM template
Тут нічого не винаходили — взяли packer.
- У git репозиторій складаємо конфіг packer, kickstart.
- Налаштовуємо спеціальний jenkins slave з hyper-v та Packer.
- Створюємо job, налаштовуємо Jenkins.
Як працює ця зв'язка:
- Packer створює порожню ВМ, підчеплює ISO.
- ВМ завантажується, Packer вводить в завантажувач команду використовувати наш kickstart файл з дискети або http.
- Запускається anaconda з нашим конфігом, робиться первинне налаштування ОС.
- Packer чекає на доступність ВМ.
- Packer всередині ВМ запускає ansible в локальному режимі.
- Ansible використовуючи рівно ті самі ролі що на етапі №1 відпрацьовує.
- Packer експортує шаблон ВМ.
День №75: Рефакторим домовленості не ламаючи = Test ansible + Testkitchen
Зафіксувати домовленості у коді може бути недостатньо. Адже якщо в піднаготному процесі ти захочеш щось змінити, то ти можеш щось зламати. Тому у разі інфраструктури з'являється тестування цієї самої інфраструктури. Щоб синхронізувати знання в рамках команди стали тестувати Ansible ролі. Не поглиблюватиму т.к. є стаття, що описує події в той момент часу (Спойлер це був не фінальний варіант і пізніше все стало складніше ).
День №130: А може CentOS+ansible не потрібний? може openshift?
Потрібно розуміти, що процес внесення інфраструктури був не єдиним і були побічні підпроекти. Наприклад, надійшов запит на запуск нашої програми в openshift і це вилилося в дослідження не на один тиждень що загальмувало процес переїзду. Підсумком виявилося, що openshift не закриває всіх потреб, необхідне реальне залізо, чи хоча б можливість грати з ядром.
День №170: Openshift не підходить, ризикнемо з Windows Azure Pack?
Hyper-V не дуже доброзичливий, SCVMM не робить його значно кращим. Але є така штука Windows Azure Pack, яка є надбудовою над SCVMM та мімікрує під Azure. Але насправді продукт виглядає покинутим: документація з битими посиланнями і дуже мізерна. Але в рамках дослідження варіантів спрощення життя нашої хмари дивилися і на неї теж.
День №250: Windows Azure Pack не дуже. Залишаємося на SCVMM
Windows Azure Pack виглядав багатообіцяючим, але було вирішено не привносити WAP з його складнощами в систему заради непотрібних фіч і залишилися на SCVMM.
День №360: Їмо слона частинами
Лише через рік була готова платформа кудись переїжджати і почався процес переїзду. Для цього було поставлено SMART завдання. Виписали всі ВМ і почали по одній розумітися на конфігурації, описувати її на Ansible, покривати тестами.
День №450: Яка система вийшла?
Сам процес не цікавий. Він рутинний, можна відзначити, що більшість конфігурацій були відносно простими або ізоморфними і за принципом Парето 80% конфігурацій вимагало 20% часу. За тим же принципом 80% часу пішло на підготовку переїзду і лише 20% на переїзд.
День №540: Фінал
Що ж сталося за 18 місяців?
- Домовленості стали кодом.
- Ручна праця -> Механізація -> Автоматизація.
зв'язку
Джерело: habr.com