Согласен, тут действительно разговор о том, как мы видели свою реализацию на нашей инфраструктуре. Ваш пример отлично подойдёт при небольшом количестве кирпичиков.
В любом случае рад, что Вам удалось достичь взаимопонимания с другими отделами — это существенно более важно, чем та технология, которая была выбрана ) Люди — они важнее этих… технологий )
Полностью согласен, у инструментов есть преимущества и недостатки, но главное всё же люди и единые рельсы.
Но вот что делать с таким — мы применили какую-то роль, она что-то насоздавала, потом в следующей версии роли мы уже эти файлы не создаем, и поэтому мы их и не очищаем
Тут сложно найти золотую пулю, ведь файлы могут создать так же другие люди, возможно они даже нужны.
Свои роли мы пишем только сами, и есть некоторый порядок применения коммита в мастер ветку создания серверов. На этом этапе проверяется сам код, код тестирования и доставка фикса на существующие сервера. Разумеется, это скорее административный контроль, но даже если на сервере осталась пара .bak файлов на несколько килобайт, не вижу в этом особых проблем.
оркестрацию используете (условная задача «выполнить действие ХХ на подмножестве серверов 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, однообразие.
Не планировали. На мой взгляд, если нужен именно учёт, — можно поискать готовые решения, а если хочется под себя, то рано или поздно нужно будет делать своё. Мы пошли в собственную разработку ради кастомных интеграций, которые вряд ли будут интересны широкому кругу.
Согласен, тут действительно разговор о том, как мы видели свою реализацию на нашей инфраструктуре. Ваш пример отлично подойдёт при небольшом количестве кирпичиков.
Полностью согласен, у инструментов есть преимущества и недостатки, но главное всё же люди и единые рельсы.
Тут сложно найти золотую пулю, ведь файлы могут создать так же другие люди, возможно они даже нужны.
Свои роли мы пишем только сами, и есть некоторый порядок применения коммита в мастер ветку создания серверов. На этом этапе проверяется сам код, код тестирования и доставка фикса на существующие сервера. Разумеется, это скорее административный контроль, но даже если на сервере осталась пара .bak файлов на несколько килобайт, не вижу в этом особых проблем.
Оркестрацию используем — тут чистый ansible.
В процессе жизни на серверах может много чего меняться. Как я писал, после запуска движка тестирования было исправлено около 70000 мисконфигураций. Исправляли в процессе жизни — как правило делили изменения по уровню критичности и прокатывали соответственную роль на сервера группами.
С configuration drift боремся тестированием конфигураций — ежедневно все сервера тестируются на соответствие с эталоном в гите и генерируются отчёты с расхождениями, которые мы берём в работу.
И не только ansible + AWX, ещё и Tower! Нам больше подошёл ansible, т.к. он стал единым выбором всей компании — как прикладные администраторы, так и DevOps команды в последнее время пишут деплои именно на нём. И не только для nix, но и для Windows. Без агентов, с низким порогом вхождения и Push стратегией. Плюс скорость развития и размер сообщества. А ещё мы любим python :)
По образам — под идеологию инфраструктура как код, лучше подходит голый образ, а не золотой, уже полностью пролитый. В этом случае, не нужно держать в голове, что конкретно сейчас зашито в образе, проще создавать новые. А если ферм виртуализации много, они не связаны между собой или, например, разных вендоров, а кроме виртуальных нужно готовить физические сервера, это становится головной болью. А так, в образе VM минимальная инсталляция ОС, а дальше ansible, физику через Cobbler аналогично и ansible, однообразие.