Давайте абстрагируемся от резервной копии и попробуем на примере ИБ. Разложить и сконфигурить правила фаерволла тогда для вас — IaC? скорее да. Только вы это делаете 1 раз? при разворачивании ОС? — скорее нет. Я не вижу необходимости разворачивать занаво хост после изменения 1 правила в netfilter. IaC — описание и управление инфраструтктурой.
А по поводу «артефакты» — это файл-результат сборки или этапа сборки, деб пакет будет результатом сборки, к примеру, репа с исходниками и debian инструкциями. Не вижу аналогии с сохранением в репозитории ansible-playbook, задача которого — выполнять регулярные задания.
Я, несмотря на ваш последующий минус, и в этот раз вам отвечу, хоть и не вижу в этом смысла. Конструкор этого автобуса — я и водитель — хост, который сам выполняет задачу копирования (исполнение обязательств по доставке пассажиров). Если водитель не выйдет на работу по моей вине, или автобус сломается — я буду оповещен об этом мониторингом и ничего критичного не произойдет, я учту ошибки, исправлю и применю исправление ко всем автобусам, чтобы не повторилась ситуация. Важнее мысль, что не только я могу исправить эти ошибки, а благодоря моей документации (IaC) любой конструктор сможет это сделать и без меня.
В целом, так делать никто не запрещает, но у разработчиков такое называется «протекание абстракций». Лучше когда полезная нагрузка выполняется хостами, без участия Ansible. А Ansible используется только по назначению: изменение конфигурации.
Ansible запускает задачи подготовки копирования и задачи пуша бэкапа. Полезную нагрузку выполняют хосты, а не машина с ansible. Я в данном случае могу контролировать полностью какой архив бэкапа, в каком порядке и на какой скорости ложить в хранилище, а по завершению копирования получить статус по каждой машине. Поясните, что в данном случае является абстракцией и почему она течет?
Секреты, если они критичны, лучше чтобы были хост-персональны. Это, конечно, требует доп. усилий, но тут уж «шашечки или ехать».
нет, но это, что у него получается лучше всего (в packer, например, или в terraform). Иначе у нас извините не иммьютейбл инфра, а черти-знает-что.
Вы как-то все в одну кучу) Причем здесь иммьютейбл, как этот подход связан с IaC? каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?
И еще — ансибл у вас на сколько узлов скейлится — 100-1000-10000?
да на любое количество, под любой тип ОС все верно у ансибл это неплохо получается.
зато отдельная проблема — обеспечить отказоустойчивость этой самой точки + доступ ко всем узлам (они не смогут теперь автономном функционировать) + идемпотентность алгоритма и устойчивость его к перезапускам и локи на повторные запуски на всякий случай.
нет проблемы в отказоустойчивости — нужна любая машина с ansible все. Доступ ко всем узлам с одного узла а не с 1000 машин, не вижу проблем — машина в DMZ. Повторяемость и локи решаются правильным написанием роли. Может я и не прав, так укажите где, в чем это Велосипед? я попытаюсь понять, в чем я не прав. Какой подход использовать?
Лишняя централизация — это зло. На самом деле надо подбирать инструмент под задачи и соответственно — вариант systemd-timer + скрипт, который разливается ансиблом может быть сильно лучше, чем полный бекап в виде отдельного плейбука.
Зачем усложнять крон? В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно. И важный момент у меня шифруется хранилище — ключ в одном месте а не на каждом хосте. Я могу менять свой ключ каждые 2 минуты.
Несомненно. Но тут надо разграничить — мы храним это все как условные настройки в репозитории с кодом IaC, которые разливаются на машины, или мы используем отдельные скрипты вне этого процесса, но в рамках более широкого понимания инфры как живого организма.
IaC это подход для управления и описания инфраструктуры ЦОД через конфигурационные файлы
То есть и управления тоже
Поделюсь болью. В рамках, например, salt это все реализуется при помощи встроенной шины сообщений и встроенных примитивов для этого, но сложность их отладки и проверки на порядок выше, чем просто «давайте накатим плейбук или стейт» и «посмотрим молекулой или кухней, что там получилось» — т.к. надо либо писать юнит-тесты, либо поднимать полную копию инфру и на ней отлаживать эту событийную модель :-/
Может тут как раз неверно выбран инструмент? если нельзя мокать или тестить без моков хотя бы часть функционала, то эти конфиги превратятся в legacy скорее — к ним все будут бояться подойти и тем более изменить. но это мое мнение
Мое мнение — ансибл прекрасен для первоначальной настройки или использования в пайпах. Управлять же им флотом машин, изменениями в конфигурации. Брррр
Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки? зачем тогда ансибл? пишите файлы-ответы! как управлять парком в 50 серверов без централицазии? я могу получить состояние обновление всего парка в течении 10 минут. А вы?
Вы же ведь наверняка не используете AWX / Tower? Или пускалкой бекапов становится Дженкинс?
Использую AWX, командная строка чаще, иммел проблемы при его обновлении — руками приходилось править миграции он свободный сейчас лучше чем раньше
Я отвечу как большинство отвечает, тут публикующихся) я не готов выложить в открытый доступ, но подготовлю часть кода и опубликую обязательно. Спасибо за ответы!
Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.
Ну в моем конкретном примере есть какой-то простой инструмент для создания ежедневной копии (к примеру borg), и я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки. Плюсы: секрет в одном месте и простая конфигурация из одной точки. В какую парадигму это вписать, это скорее филосовский вопрос, но пока что мне не пришлось использовать модули со сложной логикой, все максимально просто.
Спасибо за статью! Molecule это очень большое спасение для всех нас при тестировании ролей Ansible. У меня вопрос. Все роли у вас выполняют конфигурацию конечных хостов? то есть тестирование = запуск ВМ и раскатка ролей последовательно, зависимо от типа ОС накатывая конфиги и все что требуется для работы хоста я так понял? теперь вопрос — представьте я решил написать роль для автоматизации задачи «ежедневного резервного копирования» и разумеется моя роль/роли перед элементарным копированием бэкапа на хост-назначение выполнятет на хосте-целе куда я травлю свою роль задачи по подготовке к резервному копированию (к примеру gitlab-backup create) и на каждом хосте это свои подготовки. Как тестировать через Molecule такую роль? добавить check_mode не вариант же теряется смысл в тестировании. Может есть дельный совет?
А по поводу «артефакты» — это файл-результат сборки или этапа сборки, деб пакет будет результатом сборки, к примеру, репа с исходниками и debian инструкциями. Не вижу аналогии с сохранением в репозитории ansible-playbook, задача которого — выполнять регулярные задания.
Ansible запускает задачи подготовки копирования и задачи пуша бэкапа. Полезную нагрузку выполняют хосты, а не машина с ansible. Я в данном случае могу контролировать полностью какой архив бэкапа, в каком порядке и на какой скорости ложить в хранилище, а по завершению копирования получить статус по каждой машине. Поясните, что в данном случае является абстракцией и почему она течет?
Они хост-персональны, но хранятся не на хостах.
Вы как-то все в одну кучу) Причем здесь иммьютейбл, как этот подход связан с IaC? каждый раз при обновлении к примеру nginx — сносите все и разворачиваете новую инфру с одним измененным компонентом?
да на любое количество, под любой тип ОС все верно у ансибл это неплохо получается.
нет проблемы в отказоустойчивости — нужна любая машина с ansible все. Доступ ко всем узлам с одного узла а не с 1000 машин, не вижу проблем — машина в DMZ. Повторяемость и локи решаются правильным написанием роли. Может я и не прав, так укажите где, в чем это Велосипед? я попытаюсь понять, в чем я не прав. Какой подход использовать?
Зачем усложнять крон? В случае с одной точкой у вас есть сразу результат вашего бэкапа, в случае с отдельными скриптами у вас куча скриптов и наверное в случае фейла вы с каждым хостом будете разбираться отдельно. И важный момент у меня шифруется хранилище — ключ в одном месте а не на каждом хосте. Я могу менять свой ключ каждые 2 минуты.
То есть и управления тоже
Может тут как раз неверно выбран инструмент? если нельзя мокать или тестить без моков хотя бы часть функционала, то эти конфиги превратятся в legacy скорее — к ним все будут бояться подойти и тем более изменить. но это мое мнение
Вы серъезно считаете что ансибл используется ТОЛЬКО для первоначальной настройки? зачем тогда ансибл? пишите файлы-ответы! как управлять парком в 50 серверов без централицазии? я могу получить состояние обновление всего парка в течении 10 минут. А вы?
Использую AWX, командная строка чаще, иммел проблемы при его обновлении — руками приходилось править миграции он свободный сейчас лучше чем раньше
Почему-то все вкладывают в IaC только задачи разворачивания и обновления инфраструктуры. Но в моем понимании у инфраструктуры есть еще и регулярные задачи, которые неплохо бы тоже хранить как код: резервное копирование, обновление правил фаервола, блокировка/изменение пользователей на машинах (там где нет SSO) и т.д.
Ну в моем конкретном примере есть какой-то простой инструмент для создания ежедневной копии (к примеру borg), и я вместо создания на каждом хосте скрипта с кроном решил описать все на ansible и выполнять эту задачу с одной точки. Плюсы: секрет в одном месте и простая конфигурация из одной точки. В какую парадигму это вписать, это скорее филосовский вопрос, но пока что мне не пришлось использовать модули со сложной логикой, все максимально просто.