Если коллеги не разобрались со статическим и динамическим включением переменных - надо им подсказать как лучше это сделать. Если не в состоянии это сделать - отдай ревью другому.
Теги предполагают императивный подход к организации кода вместо декларативного. Использование тегов легко скатывается в подход «быстро и грязно». Вместо того чтобы задуматься над хорошей структурой ролей и плейбуков, правильно разделить код на осмысленные части и логически их включать в нужные места в соответствии с задачей, мы просто обвешиваемся тегами, а потом пытаемся получить предсказуемый результат, запуская их в неком произвольном сочетании.
теги не несут императивности. Императивность провоцирует необдуманное использование кучи локальных скриптов и плэйбуков. Использование идемпотентного кода (в любых сочетаниях) предполагает предсказуемый результат. Это достигается кровью и потом соблюдением правил (относится как к ролям так и к плэйбукам):
роль должна проходить в dryrun (check_mode) перед установкой полностью, а после установки, с использованием любого из тегов.
роль с использованием любого сочетания тегов или без них должна приводить к идемпотентному выполнению без тегов (полностью).
в целом поддерживаю мнение. но надо всё-таки предоставлять возможность провалиться в кишки роли. например, зачем каждый раз дергать архив инсталлятора, если нужно поменять сертификаты или дополнить конфиг? Если теги не ломают идемпотентность (после работы с тегами прогон без тегов пройдет идемпотентно) - это сэкономит кучу времени.
При разработке метода обновления мы придерживались подхода, где обновление только обновляет (но не исправляет и не переконфигурирует СУБД и компоненты).
при обновлении пакетов ОС (кастомные конфиги сформированные ansible при таких манипуляциях перетираются значениями по умолчанию из пакета)?
На вкус и цвет все фломастеры разные. При выборе из этих двух модулей я ориентируюсь на то что было написано до меня, стараясь писать понятные условия-проверки.
Да. Именно версионирование я и исповедую. Поменялся урл - в новой версии инвентаря - задам новый. Хранить вечно - избыточно, но иметь возможность отката - необходимо.
Например, в ходе установки какого-то ПО понадобилось включить ip_forward. На первый раз решил включить руками
Один раз включаю руками, второй отлаживаю плэйбук, третий качу новой версией роли. Любой чих должен быть описан - так документируется инфраструктура как код.
Например, вам необходимо установить ПО, которое деплоится только через Docker Compose
Значит ставим Compose как зависимость. Вызывать тегами отдельную роль - для меня странно. Я придерживаюсь подхода в котором в любой роли теги имеют одинаковое именование. При вашем подходе, вместо изолированного конфигурирования роли А ( тег config) я пройдусь по по всему кластеру.
Про мультироли наверное самый яркий пример - установка отказоустойчивого кластера postgres. В некоторых случаях наверное это более понятная концепция, нежели вязать через CI/tower последовательный деплой.
Кстати, я обычно делаю versionlock для пакета - это прям про идемпотентность, если на тачке пасётся ещё кто нибудь с котом кроме меня. При управляемом обновлении поконтурно указываю новую.
Я бы не стал так делать. Когда на инфру иду - прогоняю роль драйраном - о том что кто-то, когда-то пакет удалял таской или скипом - я не знаю. А значит - неожиданные изменения в выводе, паника, ругань, проклятия в адрес того кто руками работает.
Во первых речь зашла о запуске двух разных версий роли на инфраструктуру.
Во вторых если речь о вспомогальном пакете- библиотеке, напрямую не влияющием на функционал ПО из роли (например jq) - я бы грохнул, без зазрения совести. Если же речь о пакете - зависимости, то либо он не нужен, так как меняется версия, устанавливаемого ПО (а значит меняются переменные - версии и ни о какой идемпотентности после запусков не может быть речи), либо в новой версии у нас появился пересобранный deb пакет без зависимости. А если другим ролям всё таки этот пакет нужен - то смотри пункт про проверку зависимостей. И пошагово:
Роль А версии 1 установила зависимость.
Роль Б подтвердила наличие зависимости.
Роль А версии 2 удалила зависимость при apt install -y.
Роль Б установила зависимость.
Роль А версии 2 не внесла изменений при apt install -y.
Добрый день. Подскажите пожалуйста - может быть есть в планах внедрить формулы из данной утилиты в бандо инсталлятора Pangolin?
Если коллеги не разобрались со статическим и динамическим включением переменных - надо им подсказать как лучше это сделать. Если не в состоянии это сделать - отдай ревью другому.
Я тут порефлексировал перечитывая статью. Очень хочется пожелать автору и всем читателям пореже сталкиваться с описанной в статье легаси-дичью
ознакомился. спасибо за мнение
теги не несут императивности. Императивность провоцирует необдуманное использование кучи локальных скриптов и плэйбуков.
Использование идемпотентного кода (в любых сочетаниях) предполагает предсказуемый результат. Это достигается
кровью и потомсоблюдением правил (относится как к ролям так и к плэйбукам):роль должна проходить в dryrun (check_mode) перед установкой полностью, а после установки, с использованием любого из тегов.
роль с использованием любого сочетания тегов или без них должна приводить к идемпотентному выполнению без тегов (полностью).
поддерживаю. но там тоже надо понимать, что и как применяется.
при таком исполнении с использованием тега
varsигра провалится в плэйбук pre_task, но выполнит только таски помеченные тегомvarsа зачем использовать непротестированное? тестируйте - на то есть молекула и код ревью при мерже
в целом поддерживаю мнение. но надо всё-таки предоставлять возможность провалиться в кишки роли. например, зачем каждый раз дергать архив инсталлятора, если нужно поменять сертификаты или дополнить конфиг? Если теги не ломают идемпотентность (после работы с тегами прогон без тегов пройдет идемпотентно) - это сэкономит кучу времени.
Второй вопрос - как вы реализовали
при обновлении пакетов ОС (кастомные конфиги сформированные ansible при таких манипуляциях перетираются значениями по умолчанию из пакета)?
Добрый день. Спасибо за статью.
Такой вопрос - что Вы имели ввиду написав ?
С удовольствием ознакомлюсь. Я считаю, что правильно построенная структура тегов сильно ускоряет и упрощает рутину.
На вкус и цвет все фломастеры разные. При выборе из этих двух модулей я ориентируюсь на то что было написано до меня, стараясь писать понятные условия-проверки.
Учёл. Исправил.
Можно использовать переменные
Меняем на деве - радуемся. На проде можно в CI проверку вставить.
Роль не знает ничего об окружении и других ролях. Про вспомогательный пакет я уже писал. apt yum dnf rmp не удаляют "чужие" используемые зависимости.
Да. Именно версионирование я и исповедую. Поменялся урл - в новой версии инвентаря - задам новый. Хранить вечно - избыточно, но иметь возможность отката - необходимо.
Кстати, спасибо за идею.
С рутом
Опять по порядку, на основании собственно опыта.
Например, в ходе установки какого-то ПО понадобилось включить ip_forward. На первый раз решил включить руками
Один раз включаю руками, второй отлаживаю плэйбук, третий качу новой версией роли. Любой чих должен быть описан - так документируется инфраструктура как код.
Например, вам необходимо установить ПО, которое деплоится только через Docker Compose
Значит ставим Compose как зависимость. Вызывать тегами отдельную роль - для меня странно. Я придерживаюсь подхода в котором в любой роли теги имеют одинаковое именование. При вашем подходе, вместо изолированного конфигурирования роли А ( тег config) я пройдусь по по всему кластеру.
Про мультироли наверное самый яркий пример - установка отказоустойчивого кластера postgres. В некоторых случаях наверное это более понятная концепция, нежели вязать через CI/tower последовательный деплой.
Кстати, я обычно делаю versionlock для пакета - это прям про идемпотентность, если на тачке пасётся ещё кто нибудь с котом кроме меня. При управляемом обновлении поконтурно указываю новую.
Я бы не стал так делать. Когда на инфру иду - прогоняю роль драйраном - о том что кто-то, когда-то пакет удалял таской или скипом - я не знаю. А значит - неожиданные изменения в выводе, паника, ругань, проклятия в адрес того кто руками работает.
Давайте разберемся.
Во первых речь зашла о запуске двух разных версий роли на инфраструктуру.
Во вторых если речь о вспомогальном пакете- библиотеке, напрямую не влияющием на функционал ПО из роли (например jq) - я бы грохнул, без зазрения совести. Если же речь о пакете - зависимости, то либо он не нужен, так как меняется версия, устанавливаемого ПО (а значит меняются переменные - версии и ни о какой идемпотентности после запусков не может быть речи), либо в новой версии у нас появился пересобранный deb пакет без зависимости. А если другим ролям всё таки этот пакет нужен - то смотри пункт про проверку зависимостей. И пошагово:
Роль А версии 1 установила зависимость.
Роль Б подтвердила наличие зависимости.
Роль А версии 2 удалила зависимость при apt install -y.
Роль Б установила зависимость.
Роль А версии 2 не внесла изменений при apt install -y.