HimeraSearchDB
Carding_EbayThief
triada
CrackerTuch
d-shop
HimeraSearchDB

НОВОСТИ Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев

Bonnie
Оффлайн

Bonnie

Регистрация
12.04.17
Сообщения
19.095
Реакции
107
Репутация
0
rpxip6ta10wnto0hc9fo6pmxq-w.png



Это расшифровка выступления на
You must be registered for see links
и
You must be registered for see links
.


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


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



aksh9ql8degiy4gnhthrqwtip_c.png



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

Custom Configuration Managamnet Solution



jkeqnu8f0e2bkd4j4w1eagtmdne.png



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

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


wue0nx3egy-jwwgphi9vggq_4xa.png



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

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


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

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



rpxip6ta10wnto0hc9fo6pmxq-w.png



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

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

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



c2a_vm_mgmt_workflow_2.png



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

1. Configure VMs



vs749qnzfphkw2djxrzxkk3lyjq.png



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

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


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

2. Create new VM



fubpdpqbk7dany70c5908c9zye8.png



Здесь все не очень удобно было. Из линукс не очень удобно создавать ВМ на 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



2tloapdonz_tuey-lctv3iwd5nq.png



Здесь не стали ничего изобретать — взяли 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



cjtbwgo4xb1j7umm75vvpjph8wk.png



Зафиксировать договоренности в коде может быть недостаточно. Ведь если в подноготной процессе ты захочешь что-то поменять — ты можешь что-то сломать. Поэтому в случае инфраструктуру появляется тестирование этой самой инфраструктуры. Что бы синхронизировать знания в рамках команды стали тестировать Ansible роли. Не буду углублять т.к. есть статья описывающие события в тот момент времени
You must be registered for see links
(спойлер это был не финальный вариант и позже все стало сложнее
You must be registered for see links
).

День №130: А может centos+ansible не нужен? может openshift?



Надо понимать, что процесс внесения инфраструктуры был не единственным и были побочные подпроекты. Например, пришел запрос на запуск нашего приложения в openshift и это вылилось в исследования не на одну неделю
You must be registered for see links
что затормозило процесс переезда. Итогом оказалось, что openshift не закрывает всех потребностей, необходимо реальное железо, ну или хотя бы возможность играться с ядром.

День №170: Openshift не подходит, рискнем с Windows Azure Pack?



oqgmtbimoupgcv-mzkm27yncqjc.png



Hyper-V не очень дружелюбен, SCVMM не делает его сильно лучше. Но есть такая штука Windows Azure Pack, которая является надстройкой над SCVMM и мимикрирует под Azure. Но в реальности продукт выглядит заброшенным: документация с битыми ссылками и весьма скудная. Но в рамках исследования как жить рассматривали этот вариант и на него тоже.

День №250: Windows Azure Pack не очень. Остаемся на SCVMM



c2a_cloud_scvmm.png



Windows Azure Pack выглядел многообещающим, но было решено его не привносить сложность в систему ради ненужных фич и решили остаться на SCVMM.

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



7fdi4x_wemv-fkm8_t0a93erpxw.png



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

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



tm-pareto-principle.png



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

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



u0abmbip_1aa-djjnwnlbgpeov4.png



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

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

Links


  • You must be registered for see links
  • You must be registered for see links
  • You must be registered for see links
  • You must be registered for see links
  • You must be registered for see links
  • You must be registered for see links
  • You must be registered for see links
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу