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

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

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

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

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

Персонализирано решение за управление на конфигурации

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

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

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

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

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

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

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

CentOS като основен дистрибутив, тъй като това е най-близкият дистрибутив до производствените среди.
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. Създаване на VM шаблон

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