Comments 7
Планируется ли открыть исходный код вашей CMDB ?
Благодарю.
Из личного опыта: несмотря на исторически преобладающий C# код, управление и тестирование инфраструктуры тоже на Python — больше доступных библиотек, проще вносить изменения и тестировать.
Выглядит огненно, вопросы из зала
- оркестрацию используете (условная задача "выполнить действие ХХ на подмножестве серверов YY")
- есть ли изменения конфигурации серверов в процессе их жизни? Т.е. что я имею в виду — как выглядит процесс изменения конфигурации — через переналивку-пересоздание сервера? Или по ходу жизни? Нет ли configuration drift, как с ним боретесь?
- почему ansible + awx, а не, скажем, puppet/chef/salt? Просто я себе вижу, что последние более интересны именно в ключе создания "живой" инфраструктуры ) т.к. недостаточно просто применять плейбуки в нужном порядке, а реально нужно реагировать на события в инфре.
Копирование серверов из “золотого образа” – зло!
Эм, тема нераскрыта, вообще же у нас это работает
Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
очень верный совет!
Используйте override файлы для редактирования systemd юнитов.
жму руку!
оркестрацию используете (условная задача «выполнить действие ХХ на подмножестве серверов YY»)
Оркестрацию используем — тут чистый ansible.
есть ли изменения конфигурации серверов в процессе их жизни? Т.е. что я имею в виду — как выглядит процесс изменения конфигурации — через переналивку-пересоздание сервера? Или по ходу жизни? Нет ли configuration drift, как с ним боретесь?
В процессе жизни на серверах может много чего меняться. Как я писал, после запуска движка тестирования было исправлено около 70000 мисконфигураций. Исправляли в процессе жизни — как правило делили изменения по уровню критичности и прокатывали соответственную роль на сервера группами.
С configuration drift боремся тестированием конфигураций — ежедневно все сервера тестируются на соответствие с эталоном в гите и генерируются отчёты с расхождениями, которые мы берём в работу.
почему ansible + awx, а не, скажем, puppet/chef/salt?
И не только ansible + AWX, ещё и Tower! Нам больше подошёл ansible, т.к. он стал единым выбором всей компании — как прикладные администраторы, так и DevOps команды в последнее время пишут деплои именно на нём. И не только для nix, но и для Windows. Без агентов, с низким порогом вхождения и Push стратегией. Плюс скорость развития и размер сообщества. А ещё мы любим python :)
По образам — под идеологию инфраструктура как код, лучше подходит голый образ, а не золотой, уже полностью пролитый. В этом случае, не нужно держать в голове, что конкретно сейчас зашито в образе, проще создавать новые. А если ферм виртуализации много, они не связаны между собой или, например, разных вендоров, а кроме виртуальных нужно готовить физические сервера, это становится головной болью. А так, в образе VM минимальная инсталляция ОС, а дальше ansible, физику через Cobbler аналогично и ansible, однообразие.
под идеологию инфраструктура как код, лучше подходит голый образ, а не золотой, уже полностью пролитый.
кмк, зависит от количества вариаций. Условно, если у Вас инфра состоит из 5 вида кирпичиков — поддержка 5 "золотых" образов с разными конфигами не выглядит большой проблемой. Зато релизный цикл понятный. Вышло обновление — пересоздали образ, перекатили сервер (с сохранением данных, ес-но) — все круто, прям как с контейнерами докер. Если же вариацией сильно больше — действительно проще лить пустой образ, а далее его доконфигурировать
И не только для nix, но и для Windows. Без агентов, с низким порогом вхождения и Push стратегией.
очень спорно плюсы это или минусы — смотря как повернуть )
без агентов — а варианта с агентом нет (минус)
низкий пород вхождения — провоцирует "башсибл"
push стратегия — нет пулла, а он может быть нужен (ansible-pull не вспоминайте)
В любом случае рад, что Вам удалось достичь взаимопонимания с другими отделами — это существенно более важно, чем та технология, которая была выбрана ) Люди — они важнее этих… технологий )
А ещё мы любим python :)
мы тоже, поэтому "топим" за salt — он тоже на пайтоне ))))
С configuration drift боремся тестированием конфигураций — ежедневно все сервера тестируются на соответствие с эталоном в гите и генерируются отчёты с расхождениями, которые мы берём в работу.
тестирование это круто. Но вот что делать с таким — мы применили какую-то роль, она что-то насоздавала, потом в следующей версии роли мы уже эти файлы не создаем, и поэтому мы их и не очищаем (!) — в результате — заканчиваем с мусором в системе, который мы не можем увидеть (потому что он не под управлением конфигурацией) и который мы не вычищаем (потому что в следующей версии роли мы его не чистим, хотя это было бы логично) — это реальный пример из ролей в open-source.
кмк, зависит от количества вариаций
Согласен, тут действительно разговор о том, как мы видели свою реализацию на нашей инфраструктуре. Ваш пример отлично подойдёт при небольшом количестве кирпичиков.
В любом случае рад, что Вам удалось достичь взаимопонимания с другими отделами — это существенно более важно, чем та технология, которая была выбрана ) Люди — они важнее этих… технологий )
Полностью согласен, у инструментов есть преимущества и недостатки, но главное всё же люди и единые рельсы.
Но вот что делать с таким — мы применили какую-то роль, она что-то насоздавала, потом в следующей версии роли мы уже эти файлы не создаем, и поэтому мы их и не очищаем
Тут сложно найти золотую пулю, ведь файлы могут создать так же другие люди, возможно они даже нужны.
Свои роли мы пишем только сами, и есть некоторый порядок применения коммита в мастер ветку создания серверов. На этом этапе проверяется сам код, код тестирования и доставка фикса на существующие сервера. Разумеется, это скорее административный контроль, но даже если на сервере осталась пара .bak файлов на несколько килобайт, не вижу в этом особых проблем.
От “стартапа” до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры