подскажите по best-practices - разделять ли на разные роли first-run задачи и переконфигурацию или хранить вместе? сейчас они у меня вместе и перед, например, include_tasks: firstrun.yml у меня стоит пачка разных чеков, что да, мы действительно делаем эту задачу в первый раз и всё необходимое для того, чтобы firstrun.yml отработал штатно у меня есть. Вдруг это антипаттерн, не знаю :)

Why is it a first run? Does it mean you can't run it? Or simply you don't want to run it twice because other reasons?

некоторые задачи дважды запускать банально нельзя: например - загрузку дампа БД из бэкапа. Эта операция не идемпотентная, поэтому приходится обвешивать её дополнительными проверками

Для этого есть проверки и when

да, но судо без пароля - дыра в инфре :(

да, но судо без пароля - дыра в инфре :(

да, но судо без пароля - дыра в инфре :(

а sudo с паролем, но с рутовыми доступами сильно безопасносней? Защищаемся, от того кто получит доступ к этому юзеру, но не знает его пароля? Сделай просто через sudo разрешения запускать только то, что требуется для бэкапа, но без пароля.

даже sudo с паролем, если ручки кривые, тоже дыра.

бред

Но include_tasks это обычно анти патерн.. Засуньте в роль, и пусть всегда бежит, хотя скипатса будет

Никакой не антипаттерн

Господа, есть возможность получить IP в переменную второго сервера из группы, указанной в инвентори

Обратитесь к hostvars["srv2"]...?

Вопрос по разработке модулей. У меня робот ругается на "undefined-label: undefined label: ip_link_set_module (if the link has no caption the label must precede a section header)" - и я не имею ни малейшего представления что ему хочется от меня. Помогите, пожалуйста, кто с модулями в апстриме уже разбирался.

Коллеги вопрос, есть стейджинг есть прод, стейджингов очень много и немного общего, прод совсем рпазный. Вопрос как правильно делать - делать каждый стейджинг отдельным envirements либо делать условный enviremetns/staging а дальше через include_vars для каждого стенда - что мне кажеться немного странным

а малекула, это про тесты ролей?

Да

это не Ansible, это Sphinx.

Подскажите, сталкивался ли кто с такой проблемой: пытаюсь запустить compose файл через модуль docker_compose, но почему-то переменная с тэгом не подставляет services: image: "website/stage:${CI_COMMIT_SHORT_SHA}"

А ты видишь что у тебя фигурной скобки не хватает?

Подскажите, сталкивался ли кто с такой проблемой: пытаюсь запустить compose файл через модуль docker_compose, но почему-то переменная с тэгом не подставляет services: image: "website/stage:${CI_COMMIT_SHORT_SHA}"

что делаю не так ? переменная находится в all.yml

В темплейте что?

terraform приходит! terraform приходит! terraform приходит! terraform приходит! Веселье приносит yaml бодрящий, для ansible он всегда настоящий!

Господа, а какой сейчас бестпрактис по связке энсибл+докер-компоуз? Есть старый проект на докер-компоузе (5контейнеров с init.sh для генерации ссл сертов) и хочется его подсунуть в энсибл правильно, поэтому вопрос как лучше сделать, через модуль или тупо через sh

Беспрактис - выкинуть докер композ если есть ансибл

Согласен. Без компоста прозрачнее. Но писать ямла придётся больше

Ну собственно то, что написал в композе переписываешь на таски docker_container в том же в общем-то объёме

так все очень просто, компоуз уже есть, а энсибл писать надо

10 минут воспроизвести композ ямл с 5ю сервисами

Зато может например развернуть 2 сервиса на одну машину, 2 на другую, 1 на третью

Подскажите пожалуйста, есть такая простая таска: - name: Install package yum: name: - {{ package }} state: present Пакет с одним и тем же названием находится в двух репах, как мне указать репозиторий из которого его ставить?