Comments 17
А по каким критериям выбирался именно Hyper-V?
Почему не взяли VirtIO/OpenStack/просто libvirt?
Как насчёт Proxmox VE?
там не было выбора hyper-v или нет, но справделивости ради отмечу потом спустя годик переехали на vmware. это тоже целая история была, например что бы автоматизация состоялась понадобилось написать модуль vmware_content_deploy_ovf_template для Ansible https://github.com/ansible-collections/vmware/pull/114
Вообще я писал два разных вопроса :)
С гипервизором понятно — частое явление.
А вот с оркестровкой непонятно. Можно было использовать их штатный cloud-config. Для OpenStack'а есть Heat, чтобы вообще штатно всем рулить. А чтобы рулить через libvirt анзиблю даже не потребовалось бы PS запускать. Можно было бы вообще без Ansible.
Мне просто интересно для личного опыта как вы выбирали способ решения задачи и что сделали бы сейчас иначе.
ах… про оркестровку с просони упустил. Смотрели разные варианты. В мире 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, но тут есть опасения получить совсем монстрообразное что-то.
Процесс живой, изменяется, адаптируясь под реалии / лицензии/ запросы. Но глобальный план это построить частное облако не слома существующие договоренности/процессы, что бы команды разработки могли сами автоматизировать свои процессы с минимальной головной болью
на винде ansible не подходит т.к. Pull Режима нет
Как нет? Или он по каким-то причинам на форточках не работает?
Кстати, а зачем именно Pull-режим? Чем обычный неустроил?
Есть мысли в направление перевести процессы внутрь k8s интеграцию с котором завезли в vmware, но тут есть опасения получить совсем монстрообразное что-то.
За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими. Т.к. используют docker-machine на деплоймент, то можно модуль легко даже самим написать. Мы взяли и допилили модуль для себя на Proxmox VE.
Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.
Интересно мнение ваше на этот счет.
Как нет? Или он по каким-то причинам на форточках не работает?
а он на windows работает? нет и не может. Pull Режим это грубо оно чекаутит репу и запускает ansible -c local. На винде у меня ansible работал условно на wsl но ооооочень медленно, вкупе с ненативностью этого метода от него отказались.
Кстати, а зачем именно Pull-режим? Чем обычный неустроил?
философский вопрос. у нас пара тройка сотен вм под управлением ansible. если катить всё махом то получается долго. очень долго. разговор на часы заходит. мы пробовали такой кейс — в мастер попал код или добавилась тачка новая, пробежали тесты и если тесты ок, то катим инфру. это оказалось неудобно из-за времени. подробили инфру на плэйбуки, каждый плэйбук отвечает за кусок инфры, примерно до 100вм. переход на pull гипотетически решит эту проблему, но пока живем на Push.
За k8s попробуйте посмотреть на Rancher: у них неплохая интеграция с VMWare и прочими.
да спасибо, посмотримс, еще в планах nomad. это не быстро всё.
Ну и ещё посмотрите RancherOS ISO. Образ под себя тоже довольно просто собрать. Есть образ для hyper-v.
мы не vmware уже, hyper-v осталась пара физ хостов может. как закончим с миграция на vmware будет уплотнять утилизацию ресурсов за счет перехода от виртуалок к контейнерам(уже есть предпосылки к этому и наработки)
RancherOS под vmware тоже есть.
Не совсем понял суть вашего кейса, из-за которого вам быстрее pull, но дело хозяйское.
Ни linux на push сидим. Но начинаем испытывать не критичные неудобства с тем что прокатить всю инфру долго, с пулом оно равномернее должно размазаться и configuration drift меньше(в теории конечно, цифр мало у меня пока)
Ну вам равномерность придётся контролировать чем-то? Где-то консистентностью придётся пожертвовать, когда один сервер уже обновился, а другой запустился позже. Если в один поток запускать, то это действительно долго. Запустить в 100 потоков можно (там память нужна). Не вижу просто вообще никаких профитов от pull, кроме ресурсов на запуск.
мы не vmware уже, hyper-v осталась пара физ хостов может. как закончим с миграция на vmware будет уплотнять утилизацию ресурсов за счет перехода от виртуалок к контейнерам(уже есть предпосылки к этому и наработки)
следующим шагом будет такое — https://www.youtube.com/watch?v=FBKSk22xBK4
Остается только решить вопрос с долговременным хранилищем данных. В остальном — контейнеризация и кубернетес потихоньку отъедают долю от legacy мира с необходимостью таскать SCM'ы. При этом, конечно, возникает куча технических проблем из серии запихнуть невпихуемое в кубик
А финансовую сторону как оценивали?
В аспекте покупки лицензий, поддержки, дальнейшего развития.
Про VMware особенно интересно .
а вот и Английская версия появилась
Ansible: Миграция конфигурации 120 VM c CoreOS на CentOS за 18 месяцев