)

не знаю на сколько вы закопались в rundeck, но по идеи awx вам больше подходит

не особо закопались, так на пол шишки )

просто когда закапывались, awx помоему только появился

тогда не плодите сучностей, посмотрите в сторону awx

так и будет

видимо

а куда копать, соориентируй пожалуйста)

нужно в template подставлят не hostvars[m] - что является dict из всех возможных свойств хоста m нужно подставлять hostvars[m].inventory_hostname или где у вас там ойпишник сидит

Jenkins

bebebe похоже, что ipv4[0] - это "фича" для macos

ну собственно как я уже говорил выше. большой боли я с ним не испытываю, не все конфигурится из коробки через HTTP, надо уметь найти и полезть поправить конфиги если что, а так вполне себе рабочая лошадь. tool agnostic, хочешь ансибл прикручивай хочешь шелл скрипты, хочешь что угодно

плагины есть, формы с параметрами есть, rest есть описание api на сайте, можно ~грабить корованы~

под капотом жаба

Вам в @devops_ru

bebebe похоже, что ipv4[0] - это "фича" для macos

а вы откуда факты собирали с macos или с linux машины? попробовали собрать факты об osx с машины на linux?

по идеи это баг.

а вы откуда факты собирали с macos или с linux машины? попробовали собрать факты об osx с машины на linux?

Попробую не забыть завтра проверить 4 варианта

Попробую не забыть завтра проверить 4 варианта

я "лайтово" гуглил, ничего такого не нашел...

я "лайтово" гуглил, ничего такого не нашел...

Я тоже

Есть. Разрабы люто довольны.

С октября полёт нормальный.

С октября полёт нормальный.

но октябрь ведь только через 25 дней??/

Ну с прошлого так-то

😉

😉

редкий случай - так толсто, что аж тонко 😊

С октября полёт нормальный.

интересно. А сколько примерно билдов\запусков в день?

интересно. А сколько примерно билдов\запусков в день?

Сами билды у меня были на дженкинсе, а запуски ансибла - именно из рандека. По-разному бывает, может до десяти доходить, а бвыает, что и пару дней никто ничего не релизит. Мозг эта штука не ест вообще, ибо джава. Полиси настраиваются в YaML, им же можно вгрузить джобы и выгрузить, ну и REST API. Авторизация - через LDAP, с поддержкой групп. В общем, этот кусок стека причинял хлопот меньше всего.

Ясно, спасибо

Ну и до кучи есть плагин чудесный - с ним рандек внезапно начинает уметь в ансибловый инвентори (https://github.com/Batix/rundeck-ansible-plugin), читать факты с хостов и гонять на них баш-команды, модули с параметрами, а также плейбуки целиком.

{% for host in host_group %} как здесь порядковый номер итерации вывести? {% endfor %}

loop.index?

http://jinja.pocoo.org/docs/2.10/templates/#for

да, loop.index

tyvm

только там с loop.index0 начинается

Ломаю голову над тем, как намутить правильный git flow с репозиторием, когда в инвентаре несколько сред

Если есть кто не спит, подкиньте пару вводных мыслей

роли нормально под git flow подходят, но как быть с инвентарем, групповыми переменными и прочими вещами

а в чем проблема то?

а в чем проблема то?

Что происходит с тем, что находится в environment? оно перетаскивается по всем средам?

тогда зачем нам держать dev в ветке stg?

все равно не понятно, Мне даже не очень понятно почему вообще роли отличаются? Зачем вообще это куда-то переносить? Роли для того и придумали чтоб переиспользовать их многократно без копирования

речь идет о git flow

когда мы деплоим dev, потом говорим что все хорошо и промоутим дальше

все равно не понятно, Мне даже не очень понятно почему вообще роли отличаются? Зачем вообще это куда-то переносить? Роли для того и придумали чтоб переиспользовать их многократно без копирования

Роли отличаются только во времени (версии). то что в деве когда-то будет в проде

Ломаю голову над тем, как намутить правильный git flow с репозиторием, когда в инвентаре несколько сред

Может не стоит хранить несколько инвентарей в одной ветке?

Может не стоит хранить несколько инвентарей в одной ветке?

Ну вот это ближе к делу. разделить по веткам как вариант

но тогда вопрос первый - как делать изменения к инвентарю... По идее можно дслетьа feature-branch, и с него потом сливать в среду. например dev-add-mysql

но тогда не понятно как будет выглядеть добавление mysql с нуля

1. git checkout dev && git checkout -b dev-add-mysql 2. Create PR, Merge PR 3. ???

Я ничего в гитфлоу не понимаю, но мы так и делали - stage-do-foo

Я ничего в гитфлоу не понимаю, но мы так и делали - stage-do-foo

Ну это базовый и урезаный гит флоу, когда мы последовательно мигрируем из dev в prod по веткам

Если есть кто не спит, подкиньте пару вводных мыслей

Принимаешь ещё мысли?

Принимаешь ещё мысли?

Всегда

(от тебя))

Спасибо, приятно.

Расскажу, что делал и что успешно взлетело.

Я готов🍿

Гит флоу - это в первую очередь для разработчиков, ибо их много, у них много веток и всего такого. Сработавший в тех ситуациях, которые я видел и делал, кейс - это отдельная репа, где лежат все роли и инвентори (структура проекта по бест практис из доки ансибла).

Код собирается в артефакты, которые грузятся в репозиторий.

Гит флоу - это в первую очередь для разработчиков, ибо их много, у них много веток и всего такого. Сработавший в тех ситуациях, которые я видел и делал, кейс - это отдельная репа, где лежат все роли и инвентори (структура проекта по бест практис из доки ансибла).

У меня так (см. мини-диаграмму)

Код собирается в артефакты, которые грузятся в репозиторий.

ок, с кодом приложений понятно

Правильно ли я понимаю, что ты хочешь опистаь процесс для случая нескольких веток именно девопс-репозитория для вновь запиливаемых ролей?

Правильно ли я понимаю, что ты хочешь опистаь процесс для случая нескольких веток именно девопс-репозитория для вновь запиливаемых ролей?

точно. То есть сейчас легаси вариант когда все среды в одной ветке. Я хочу промоутить изменения из дева в прод. Например сменил шаблончик jinja, задеплоил в дев - понравилось, сделал PR dev->stg, смержил, оно само поехало в stg

Ты сразу налипаешь на неприятные эффекты. Вот смотри. IaaC предполагает, что где-то в репе у тебя запинены точные версии компонентов, и почти в каждый момент времени эти версии соответствуют действительности. Еслы деплоить из некоей ветки (условно - devel), то номера версий могут быть закоммичены именно в неё, а не в master, из которого всё ставится. Это боль.

Иными словами, статус "single source of truth" с devops-репозитория автомагически слетает.

Иными словами, статус "single source of truth" с devops-репозитория автомагически слетает.

Я хочу source of truth

😄

Миграция параметров сводится к перемещению/обновлению их между каталогами с инвентори. В этом случае у тебя _все_ ветки работают с одними и теми же параметрами. В моей практике это ок - намного чаще меняется содержание роли, чем параметры окружения.

Но может потребоваться несколько специфическая организация этих параметров.

Миграция параметров сводится к перемещению/обновлению их между каталогами с инвентори. В этом случае у тебя _все_ ветки работают с одними и теми же параметрами. В моей практике это ок - намного чаще меняется содержание роли, чем параметры окружения.

Ну вот тогда мы возвращаемся к соcтоянию где в одной ветке все окружения...

Ну вот тогда мы возвращаемся к соcтоянию где в одной ветке все окружения...

Не совсем. Ты же хочешь дев -> стейдж -> продакшн?

да

плюс тесты, а-ля dev-perf, dev-perf-vasya как вариант

В дев-ветке у тебя этот параметр будет только для дев-инвентори, в стейдже - и в дев-инвентори, и в стейдж-инвентори, в продакшне - в дев-, стейдж- и продакшн-инвентори. Опять же - речь только о названии параметра. Значения, разумеется, могут отличаться.

@vrutkovs А как ты думал про управление изменениями параметров а-ля group_vars? Какой порядок действий?

В дев-ветке у тебя этот параметр будет только для дев-инвентори, в стейдже - и в дев-инвентори, и в стейдж-инвентори, в продакшне - в дев-, стейдж- и продакшн-инвентори. Опять же - речь только о названии параметра. Значения, разумеется, могут отличаться.

Пока что представляю что миграция параметров это отдельный процесс...

и merge по определенным путям между dev/stg/prod не возможен

(типа inventory/* )

Не понятно как это. "все работают с одноми и теми же параметрами"