🥇Ansible: Миграция на конфигурация на 120 ВМ от CoreOS на CentOS за 18 месеца

Това е разшифровка на изказването на DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

Това е историята на проекта, в който се използваше самостоятелна система за управление на конфигурации и защо миграцията към Ansible се проточи 18 месеца.

Ден № -ХХХ: Преди началото

Първоначално инфраструктурата беше множество самостоятелни хостове, управлявани от Hyper-V. Създаването на виртуална машина изискваше множество действия: поставяне на дискове на определени места, записване на DNS, резервиране на DHCP, поставяне на конфигурацията на ВМ в git репозиторий. Този процес беше частично механизиран, но например ВМ се разпределяха между хостовете ръчно. Например, разработчиците можеха, коригирайки конфигурацията на ВМ в git, да я приложат, рестартирайки ВМ.

Custom Configuration Management Solution

Първоначалната идея, подозирам, беше замислена като IaC: множество stateless ВМ, които при рестартиране нулираха своето състояние. Какво представляваше управлението на конфигурации на ВМ? Схемата изглежда просто:

За ВМ се задаваше статичен MAC.
Към ВМ се свързваше ISO с CoreOS и стартиращ диск.
CoreOS стартира скрипт за кастомизация, изтегляйки го от уеб сървър на основание на своя IP.
Скриптът изтегля конфигурацията на ВМ чрез SCP, базирайки се на IP адреса.
Стартира серия от файлове systemd unit и поредица от bash скриптове.

Това решение имаше много очевидни проблеми:

ISO в CoreOS беше deprecated.
Множество сложно автоматизирани действия и магия при миграцията/създаването на ВМ.
Сложността при обновяването и когато е необходимо софтуер с определена версия. Още по-забавно с модулите на ядрото.
ВМ не бяха толкова без данни, т.е. се появиха ВМ, на които бяха монтирани дискове с потребителски данни допълнително.
Постоянно някой грешеше със зависимостите на systemd unit и при рестартиране CoreOS спираше. С наличните средства в CoreOS, улавянето на това беше проблематично.
Управление на секретите.
CM практически не съществуваше. Имаше bash и YML конфиги на CoreOS.

За да приложите конфигурацията на ВМ, е необходимо тя да се рестартира, но тя можеше да не се рестартира. Изглежда очевиден проблем, но постоянни дискове няма — нямаше къде да се съхраняват логовете. Добре, да опитаме да добавим опции за зареждане на ядрото, за да се прехвърлят логовете. Но не, всичко е толкова сложно.

Ден №0: Признание на проблема

Това беше обичайна разработваческа инфраструктура: jenkins, тестови средища, мониторинги, registry. CoreOS беше проектиран за хостинг на k8s клъстери, т.е. проблема беше как се използваше CoreOS. Първата стъпка беше изборът на стек. Ние избрахме:

CentOS като базов дистрибутив, тъй като е най-близкият дистрибутив до production среди.
Ansible за управление на конфигурациите, тъй като имаше обширна експертиза по него.
Jenkins като фреймворк за автоматизация на съществуващите процеси, тъй като вече активно се използваше за процесите на разработка.
Hyper-V като платформа за виртуализация. Има редица причини, които излизат извън разказа, но накратко - не можем да използваме облаци, трябва да използваме нашето оборудване.

Ден №30: Фиксираме съществуващите договорености — Agreements as Code

Когато стекът беше ясен, започна подготовката за преместване. Фиксиране на съществуващите договорености под формата на код (Agreements as Code!). Преход ръчната работа -> механизация -> автоматизация.

1. Конфигуриране на ВМ

Ansible се справя отлично с тази задача. С минимум усилия можем да управляваме конфигурациите на ВМ:

Създаваме git репозиторий.
Прибираме списъка с ВМ в инвентар, конфигурациите в плейбуци и роли.
Настройваме специален jenkins slave, от който можем да стартираме ansible.
Създаваме job, настройваме Jenkins.

Първият процес е готов. Договореностите са фиксирани.

2. Създаване на нова ВМ

Тук всичко не беше много удобно. От линукс не е много удобно да се създават ВМ на Hyper-V. Една от опитите да механизираме този процес беше:

Ansible се свързва чрез WinRM с windows хост.
Ansible стартира powershell скрипт.
Powershell скриптът създава нова ВМ.
Със средствата на Hyper-V/ScVMM при създаване на ВМ в гостовата ОС се настройва hostname.
ВМ при актуализиране на DHCP lease изпраща своя hostname.
Стандартната интеграция ddns & dhcp на страна на Domain Controller настройва DNS записа.
Можем да добавим ВМ в инвентара и да я настроим с Ansible.

3. Създаване на шаблон за ВМ

Тук не сме изобретявали нищо — използвахме packer.

В git репозитория прибираме конфигурацията на packer, kickstart.
Настройваме специален jenkins slave с hyper-v и Packer.
Създаваме job, настройваме Jenkins.

Как работи тази връзка:

Packer създава празна ВМ, свързва ISO.
ВМ се зарежда, Packer въвежда в зареждача команда да използва нашия kickstart файл от флопи или http.
Стартир изчаква anaconda с нашата конфигурация, прави началната настройка на ОС.
Packer изчаква достъпността на ВМ.
Packer вътре в ВМ стартира ansible в локален режим.
Ansible използва същите роли, както в стъпка №1.
Packer експортира шаблон на виртуална машина.

Ден №75: Рефакториране на уговорките без счупвания = Тест на ansible + Testkitchen

Само записването на уговорките в кода може да не е достатъчно. Ако в хода на процеса решиш нещо да промениш, можеш да счупиш нещо. Затова в инфраструктурата се появява тестовото проверяване на самата инфраструктура. За да синхронизираме знанията в екипа, започнахме да тестваме Ansible ролите. Няма да задълбочавам, тъй като има статия, описваща събитията в този момент. Тествай ме, ако можеш, или мечтаят ли YML програмистите за тестове на ansible?(спойлер, това не беше финалният вариант и по-късно всичко стана по-сложно) Как да започнем да тестваме Ansible, да рефакторим проект за година и да не се изхвърлим.).

Ден №130: А може би CentOS+ansible не е нужен? Може би openshift?

Трябва да се разбере, че процесът на въвеждане на инфраструктурата не беше единствен и имаше странични подпроекти. Например, получихме запитване за стартиране на нашето приложение в 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: Ядем слона на парчета.

Само след година платформата, към която да се преместим, беше готова и започна процесът на преместване. За това беше поставена S.M.A.R.T. задача. Записахме всички ВМ и започнахме по една да разглеждаме конфигурацията, да я описваме на Ansible, да я покриваме с тестове.

Ден №450: Каква система се получи?

Самият процес не е интересен. Той е рутинен, може да се отбележи, че повечето конфигурации бяха относително прости или изоморфни и по принципа на Парето 80% от конфигурациите изискваха 20% от времето. По същия принцип 80% от времето отиде за подготовка на преместването и само 20% за самото преместване.