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

Това е стенограма на речта DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

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

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

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

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

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

1. Статичен MAC беше закован за VM.
2. ISO с CoreOS и диск за зареждане бяха свързани към VM.
3. CoreOS стартира скрипта за персонализиране, като го изтегля от WEB сървъра въз основа на неговия IP адрес.
4. Скриптът изтегля VM конфигурацията чрез SCP въз основа на IP адреса.
5. Стартират се обвивката на файловете на системния модул и обвивката на bash скриптовете.

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

1. CoreOS ISO е отхвърлен.
2. Много сложни автоматизирани действия и магия при мигриране/създаване на виртуални машини.
3. Трудности с актуализирането и когато е необходима определена версия на софтуера. Още по-забавно с модулите на ядрото.
4. VM не са получени така без данни, т.е. Виртуалните машини се появиха с диск с монтирани допълнителни потребителски данни.
5. Някой непрекъснато прецакваше зависимостите на системния модул и CoreOS замръзваше при рестартиране. Беше трудно да се улови това с помощта на наличните инструменти в CoreOS.
6. Управление на тайните.
7. Нямаше CM. Имаше bash и YML конфигурации за CoreOS.

За да приложите конфигурацията на VM, трябва да го рестартирате, но може да не се рестартира. Изглежда като очевиден проблем, но няма постоянни дискове - няма къде да се записват регистрационни файлове. Е, добре, нека опитаме да добавим опцията за зареждане на ядрото, така че регистрационните файлове да бъдат изпратени. Но не, колко сложно е всичко.

Ден #0: Разпознайте проблема

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

1. CentOS като базово разпределение, т.к Това е най-близкото разпространение до производствените среди.
2. Ansible за управление на конфигурацията, т.к имаше задълбочена проверка по него.
3. Дженкинс като рамка за автоматизиране на съществуващи процеси, т.к вече е активно използван за процеси на развитие
4. Hyper-V като платформа за виртуализация. Има редица причини, които надхвърлят обхвата на историята, но накратко – не можем да използваме облаците, трябва да използваме собствения си хардуер.

Ден № 30: Коригиране на съществуващи споразумения - Споразуменията като код

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

1. Конфигурирайте виртуални машини

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

1. Създайте git хранилище.
2. Поставяме списъка с виртуални машини в инвентара, конфигурациите в книгите и ролите.
3. Създаваме специален подчинен Jenkins, от който можете да стартирате Ansible.
4. Създаваме работа и конфигурираме Jenkins.

Първият процес е готов. Споразуменията са фиксирани.

2. Създайте нов VM

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

1. Ansbile се свързва чрез WinRM към хоста на Windows.
2. Ansible изпълнява скрипт на powershell.
3. Скриптът Powershell създава нова виртуална машина.
4. Използвайки Hyper-V/ScVMM, когато създавате виртуална машина в операционната система за гости, името на хоста се конфигурира.
5. При актуализиране на DHCP наема, VM изпраща своето име на хост.
6. Стандартната ddns & dhcp интеграция от страната на домейн контролера конфигурира DNS записа.
7. Можете да добавите VM към вашия инвентар и да го конфигурирате с Ansible.

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

Тук не са измислили нищо - взеха опаковка.

1. Добавете пакета, конфигурацията на kickstart към git хранилището.
2. Настройване на специален подчинен Jenkins с hyper-v и Packer.
3. Създаваме работа и конфигурираме Jenkins.

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

1. Packer създава празна виртуална машина и взима ISO.
2. VM стартира, Packer въвежда командата в буутлоудъра, за да използва нашия kickstart файл от флопи диск или http.
3. Anaconda се стартира с нашата конфигурация и първоначалната конфигурация на ОС е готова.
4. Packer изчаква виртуалната машина да стане достъпна.
5. Packer вътре във VM работи ansible в локален режим.
6. Ansible използва точно същите роли, които работи в стъпка #1.
7. Packer експортира VM шаблона.

Ден #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: Изяждане на слона парче по парче

Само година по-късно платформата за преместване е готова и преместването започва. За целта беше зададена SMART задача. Проверихме всички виртуални машини и започнахме да измисляме конфигурацията една по една, описахме я в Ansible и я покрихме с тестове.

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

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

Ден #540: Финал

Какво се случи за 18 месеца?

1. Споразуменията се превърнаха в кодекс.
2. Ръчен труд -> Механизация -> Автоматизация.

Връзки

• Английска версия
• Кръстосана публикация от личен блог
• пързалки
• Как да започнете да тествате Ansible, да преработите проекта за една година и да не полудеете
• Научени поуки от тестването на над 200 000 реда от Инфраструктурния кодекс
• Нека внедрим в openshift
• Как да тествате собствената си дистрибуция на ОС
• Тествай ме, ако можеш. Разработчиците на YML мечтаят ли да тестват ansible?

Източник: www.habr.com