Это расшифровка выступления на DevopsConf 2019-10-01 и SPbLUG 2019-09-25. Это история проекта, на котором использовалась самописная система управления конфигурациями и почему переезд на Ansible затянулся на 18 месяцев.  Изначально инфраструктура представляла собой множество отдельно стоящих хостов под управлением Hyper-V. Создание виртуальной машины требовало множество действий: положить диски в нужное место, прописать DNS, зарезервировать DHCP, положить конфигурацию ВМ в git репозиторий. Этот процесс был частично механизирован, но например ВМ распределялись между хостами руками. Но, например, разработчики могли поправив конфигурацию ВМ в git применить её перезагрузив ВМ.  Изначальная идею, подозреваю, задумывали как IaC: множество stateless ВМ, которые при перезагрузке обнуляли своё состояние. Что из себя представляло управление конфигурациями ВМ? Схематично выглядит просто:  У этого решения было множество очевидных проблем: Что бы применить конфигурацию ВМ необходимо ее перезагрузить, но она могла не перезагрузиться. Вроде очевидная проблема, но персистентных дисков нет — логи сохранять некуда. Ну ок, давайте попробуем добавить опции загрузка ядра что бы логи пересылали. Но нет, как это сложно всё.  Это была обычная разработческая инфраструктура: jenkins, тестовые окружения, мониторинги, registry. CoreOS задумывалась для хостинга k8s кластеров, т.е. проблема была в том, как использовалась CoreOS. Первым шагом был выбор стэка. Мы остановились на:  Когда был понятен стэк, началась подготовка к переезду. Фиксирование существующих договоренностей в виде кода (Agreements as Code!). Переход ручной труд -> механизация -> автоматизация.  Ansible отлично справляется с этой задачей. С минимум телодвижений можно взять под управление конфигурациями ВМ: Первый процесс готов. Договорённости зафиксированы.  Здесь все не очень удобно было. Из линукс не очень удобно создавать ВМ на Hyper-V. Одной из попыток механизировать это процесс было:  Здесь не стали ничего изобретать — взяли packer. Как работает эта связка:  Зафиксировать договоренности в коде может быть недостаточно. Ведь если в подноготной процессе ты захочешь что-то поменять — ты можешь что-то сломать. Поэтому в случае инфраструктуру появляется тестирование этой самой инфраструктуры. Что бы синхронизировать знания в рамках команды стали тестировать Ansible роли. Не буду углублять т.к. есть статья описывающие события в тот момент времени Протестируй меня если сможешь или мечтают ли YML программисты о тестирование ansible?(спойлер это был не финальный вариант и позже все стало сложнее Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек). Надо понимать, что процесс внесения инфраструктуры был не единственным и были побочные подпроекты. Например, пришел запрос на запуск нашего приложения в openshift и это вылилось в исследования не на одну неделю Запускаем приложение в Openshift и сравниваем существующий инструментарий что затормозило процесс переезда. Итогом оказалось, что openshift не закрывает всех потребностей, необходимо реальное железо, ну или хотя бы возможность играться с ядром.  Hyper-V не очень дружелюбен, SCVMM не делает его сильно лучше. Но есть такая штука Windows Azure Pack, которая является надстройкой над SCVMM и мимикрирует под Azure. Но в реальности продукт выглядит заброшенным: документация с битыми ссылками и весьма скудная. Но в рамках исследования вариантов упрощения жизни нашего облака смотрели и на него тоже.  Windows Azure Pack выглядел многообещающим, но было решено не привносить WAP c его сложностями в систему ради ненужных фич и остались на SCVMM.  Только спустя год была готова платформа куда переезжать и начался процесс переезда. Для этого была поставлена S.M.A.R.T. задача. Выписали все ВМ и начали по одной разбираться с конфигурацией, описывать ее на Ansible, покрывать тестами.  Сам процесс не интересен. Он рутинен, можно отметить, что большинство конфигураций были относительно простыми или изоморфными и по принципу Парето 80% конфигураций вм потребовало 20% времени. По тому же принципу 80% времени ушло на подготовку переезда и только 20% на сам переезд.   Что же произошло за 18 месяцев? Software Architect