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


    Это расшифровка выступления на DevopsConf 2019-10-01 и SPbLUG 2019-09-25.


    Это история проекта, на котором использовалась самописная система управления конфигурациями и почему переезд на Ansible затянулся на 18 месяцев.


    День № -ХХХ: Before the beginning



    Изначально инфраструктура представляла собой множество отдельно стоящих хостов под управлением Hyper-V. Создание виртуальной машины требовало множество действий: положить диски в нужное место, прописать DNS, зарезервировать DHCP, положить конфигурацию ВМ в git репозиторий. Этот процесс был частично механизирован, но например ВМ распределялись между хостами руками. Но, например, разработчики могли поправив конфигурацию ВМ в git применить её перезагрузив ВМ.


    Custom Configuration Management Solution



    Изначальная идею, подозреваю, задумывали как IaC: множество stateless ВМ, которые при перезагрузке обнуляли своё состояние. Что из себя представляло управление конфигурациями ВМ? Схематично выглядит просто:


    1. Для ВМ прибивали статический MAC.
    2. К ВМ подключали ISO с CoreOS и загрузочный диск.
    3. CoreOS запускает скрипт кастомизации скачав его с WEB сервера на основании своего IP.
    4. Скрипт выкачивает через SCP конфигурацию ВМ основываясь на IP адресе.
    5. Запускается портянка systemd unit файлов и портянка bash скриптов.


    У этого решения было множество очевидных проблем:


    1. ISO в CoreOS было deprecated.
    2. Множество сложно автоматизированных действий и магии при миграции/создании ВМ.
    3. Сложность с обновлением и когда необходимо ПО какой-то версии. Еще веселее с модулями ядра.
    4. ВМ не такие уж без данных получались, т.е. появились ВМ у которых смонтирован диск с пользовательскими данными дополнительно.
    5. Постоянно кто-то косячил с зависимостями systemd unit и при перезагрузке CoreOS зависала. Имеющимися средствами в CoreOS отловить это было проблемно.
    6. Управление секретами.
    7. CM не было считай. Был bash и YML конфиги CoreOS.

    Что бы применить конфигурацию ВМ необходимо ее перезагрузить, но она могла не перезагрузиться. Вроде очевидная проблема, но персистентных дисков нет — логи сохранять некуда. Ну ок, давайте попробуем добавить опции загрузка ядра что бы логи пересылали. Но нет, как это сложно всё.


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



    Это была обычная разработческая инфраструктура: jenkins, тестовые окружения, мониторинги, registry. CoreOS задумывалась для хостинга k8s кластеров, т.е. проблема была в том, как использовалась CoreOS. Первым шагом был выбор стэка. Мы остановились на:


    1. CentOS как базовый дистрибутив, т.к. это наиболее близкий дистрибутив к production окружениям.
    2. Ansible для управления конфигурациями, т.к. по нему была обширная экспертиза.
    3. Jenkins как фрэймворк автоматизации существующих процессов, т.к. он уже активно использовался для процессов разработки
    4. Hyper-V как платформа виртуализации. Есть ряд причин, выходящих за рамки рассказа, но если кратко — мы не можем использовать облака, должны использовать своё железо.

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



    Когда был понятен стэк, началась подготовка к переезду. Фиксирование существующих договоренностей в виде кода (Agreements as Code!). Переход ручной труд -> механизация -> автоматизация.


    1. Configure VMs



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


    1. Создаем git репозиторий.
    2. Складываем список ВМ в inventory, конфигурации в плэйбуки и роли.
    3. Настраиваем специальный jenkins slave с которого можно будет запускать ansible.
    4. Создаем job, настраиваем Jenkins.

    Первый процесс готов. Договорённости зафиксированы.


    2. Create new VM



    Здесь все не очень удобно было. Из линукс не очень удобно создавать ВМ на Hyper-V. Одной из попыток механизировать это процесс было:


    1. Ansbile подключается через WinRM к windows хосту.
    2. Ansible запускает powershell скрипт.
    3. Powershell скрипт создает новую ВМ.
    4. Средствами Hyper-V/ScVMM при создании вм в гостевой ОС настраивается hostname.
    5. ВМ при обновление DHCP lease отсылает свой hostname.
    6. Штатная интеграция ddns & dhcp на стороне Domain Controller настраивает DNS запись.
    7. Можно добавлять ВМ в инвентори и настраивать ее Ansible.

    3. Create VM template



    Здесь не стали ничего изобретать — взяли packer.


    1. В git репозиторий складываем конфиг packer, kickstart.
    2. Настраиваем специальный jenkins slave с hyper-v и Packer.
    3. Создаем job, настраиваем Jenkins.

    Как работает эта связка:


    1. Packer создает пустую ВМ, подцепляет ISO.
    2. ВМ загружается, Packer вводит в загрзучик команду использовать наш kickstart файл с дискеты или http.
    3. Запускается anaconda с нашим конфигом, делается первичная настройка ОС.
    4. Packer дожидается доступности ВМ.
    5. Packer внутри ВМ запускает ansible в локальном режиме.
    6. Ansible используя ровно те же роли что в шаге №1 отрабатывает.
    7. 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 c его сложностями в систему ради ненужных фич и остались на SCVMM.


    День №360: Едим слона по частям



    Только спустя год была готова платформа куда переезжать и начался процесс переезда. Для этого была поставлена S.M.A.R.T. задача. Выписали все ВМ и начали по одной разбираться с конфигурацией, описывать ее на Ansible, покрывать тестами.


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



    Сам процесс не интересен. Он рутинен, можно отметить, что большинство конфигураций были относительно простыми или изоморфными и по принципу Парето 80% конфигураций вм потребовало 20% времени. По тому же принципу 80% времени ушло на подготовку переезда и только 20% на сам переезд.


    День №540: Финал



    Что же произошло за 18 месяцев?


    1. Договоренности стали кодом.
    2. Ручной труд -> Механизация -> Автоматизация.


    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      0

      А по каким критериям выбирался именно Hyper-V?
      Почему не взяли VirtIO/OpenStack/просто libvirt?
      Как насчёт Proxmox VE?

        +1

        там не было выбора hyper-v или нет, но справделивости ради отмечу потом спустя годик переехали на vmware. это тоже целая история была, например что бы автоматизация состоялась понадобилось написать модуль vmware_content_deploy_ovf_template для Ansible https://github.com/ansible-collections/vmware/pull/114

          0

          Вообще я писал два разных вопроса :)
          С гипервизором понятно — частое явление.
          А вот с оркестровкой непонятно. Можно было использовать их штатный cloud-config. Для OpenStack'а есть Heat, чтобы вообще штатно всем рулить. А чтобы рулить через libvirt анзиблю даже не потребовалось бы PS запускать. Можно было бы вообще без Ansible.
          Мне просто интересно для личного опыта как вы выбирали способ решения задачи и что сделали бы сейчас иначе.

            0

            ах… про оркестровку с просони упустил. Смотрели разные варианты. В мире windows:


            • system center automation — Нативное решение для винды, но в гетрогенной инфре не очень.
            • windows azure pack — Надстройка над vmm, которая предоставляет подписки(subscription для распределения ресурсов), http rest api

            ко всему этому делу можно прикрутить штатную механизмы автоматизации через run book + tfs + dsc, но связка показалась не очень на гетерогенной инфре, хотя может мы ее готовить не умеем.


            В данный момент, мигрируем на vmware и прощупываем vRealize для автоматизации процессов. там можно делать blue print и отдавать пользователям ответственность, идея в том, что бы уменьшить кол-во велосипедов, но у нас гетерогенная инфра, куча кастомных конфигураций/сценариев:


            • windows коллеги смотрят dsc / chef / puppet / saltstack / ansible для замены групповых политик и saltstack выглядит реалистичней всего
            • linux автоматизируем jenkins + ansible, но сказывается нехватка Pull режима т.к. для нескольких сотен хостов все становится медленно, для отдельных групп хостов в 80 шт используя митоген ускорились 28 -> 7 минут но это все равно долго и configuration drift растет.

            Как итог не определенность: на винде ansible не подходит т.к. Pull Режима нет и, наверно, будет saltstack, на linux для клиентских инсталляций используется ansible из-за push, но в разработческой инфре когда много хостов ansible становится не удобным из-за скорости работы.


            Есть мысли в направление перевести процессы внутрь k8s интеграцию с котором завезли в vmware, но тут есть опасения получить совсем монстрообразное что-то.


            Процесс живой, изменяется, адаптируясь под реалии / лицензии/ запросы. Но глобальный план это построить частное облако не слома существующие договоренности/процессы, что бы команды разработки могли сами автоматизировать свои процессы с минимальной головной болью

              0
              на винде ansible не подходит т.к. Pull Режима нет

              Как нет? Или он по каким-то причинам на форточках не работает?
              Кстати, а зачем именно Pull-режим? Чем обычный неустроил?


              Есть мысли в направление перевести процессы внутрь k8s интеграцию с котором завезли в vmware, но тут есть опасения получить совсем монстрообразное что-то.

              За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими. Т.к. используют docker-machine на деплоймент, то можно модуль легко даже самим написать. Мы взяли и допилили модуль для себя на Proxmox VE.
              Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.


              Интересно мнение ваше на этот счет.

                0
                Как нет? Или он по каким-то причинам на форточках не работает?

                а он на windows работает? нет и не может. Pull Режим это грубо оно чекаутит репу и запускает ansible -c local. На винде у меня ansible работал условно на wsl но ооооочень медленно, вкупе с ненативностью этого метода от него отказались.


                Кстати, а зачем именно Pull-режим? Чем обычный неустроил?

                философский вопрос. у нас пара тройка сотен вм под управлением ansible. если катить всё махом то получается долго. очень долго. разговор на часы заходит. мы пробовали такой кейс — в мастер попал код или добавилась тачка новая, пробежали тесты и если тесты ок, то катим инфру. это оказалось неудобно из-за времени. подробили инфру на плэйбуки, каждый плэйбук отвечает за кусок инфры, примерно до 100вм. переход на pull гипотетически решит эту проблему, но пока живем на Push.


                За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими.

                да спасибо, посмотримс, еще в планах nomad. это не быстро всё.


                Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.

                мы не vmware уже, hyper-v осталась пара физ хостов может. как закончим с миграция на vmware будет уплотнять утилизацию ресурсов за счет перехода от виртуалок к контейнерам(уже есть предпосылки к этому и наработки)

                  0

                  RancherOS под vmware тоже есть.
                  Не совсем понял суть вашего кейса, из-за которого вам быстрее pull, но дело хозяйское.

                    0

                    Ни linux на push сидим. Но начинаем испытывать не критичные неудобства с тем что прокатить всю инфру долго, с пулом оно равномернее должно размазаться и configuration drift меньше(в теории конечно, цифр мало у меня пока)

                      0

                      Ну вам равномерность придётся контролировать чем-то? Где-то консистентностью придётся пожертвовать, когда один сервер уже обновился, а другой запустился позже. Если в один поток запускать, то это действительно долго. Запустить в 100 потоков можно (там память нужна). Не вижу просто вообще никаких профитов от pull, кроме ресурсов на запуск.

                        0

                        Отсутсвие консистентности в течение приемлимого времени это норм в нашем кейсе. В целом не топлю за пулл, просто описываю текущие болячки

                      • UFO just landed and posted this here
                      0
                      мы не vmware уже, hyper-v осталась пара физ хостов может. как закончим с миграция на vmware будет уплотнять утилизацию ресурсов за счет перехода от виртуалок к контейнерам(уже есть предпосылки к этому и наработки)

                      следующим шагом будет такое — https://www.youtube.com/watch?v=FBKSk22xBK4
                      Остается только решить вопрос с долговременным хранилищем данных. В остальном — контейнеризация и кубернетес потихоньку отъедают долю от legacy мира с необходимостью таскать SCM'ы. При этом, конечно, возникает куча технических проблем из серии запихнуть невпихуемое в кубик

                    0
                    У ansible pull режим есть, но он выглядит, как третья нога с боку.
                      0

                      pull есть. но на винде он не работает. да и вопросы с секретами есть.

                      0

                      А финансовую сторону как оценивали?
                      В аспекте покупки лицензий, поддержки, дальнейшего развития.
                      Про VMware особенно интересно .

                        +1

                        это не совсем моя вотчина была. но Vmware оказалась дешевле в итоге

                +1

                а вот и Английская версия появилась

                Only users with full accounts can post comments. Log in, please.