мне он не нужен =)

да там несложо

у меня на там только дженкинс живет))) спокойно)

но дело говоришь

а дженкинс роли есть какие-нибудь адекватные? хочется его тоже в расходный материал превратить, вместе со всеми воркерами

ну я педалил на днях с плагинами, кредами и юзерами + dsl для джобов

но оно все такое хреновое... половина сделана через url POST

т.к. я не захотел морочить голову с кастом плагинами для ансибла

если апи постоянное, тогда почему и нет. скорее всего, те плагины делают то же самое

вот щас делаю создание квм через либвирт и попутное добавление воркера

угу

я так до конца и не понял, как настроить плагин из коробки

приходится руками тыкать после пробежки ансиблом

до вторника надо допилить))))))

может, есть какой-нибудь интерфейс у самого дженкинса, эмулирующий кнопкодав. например, какой нибудь рест апи или как его там.

ну да, я как раз через рест и делаю

находил скрипты на груви написанные

но там столько кастома - хрень разберешь

поищи методы, покопайся в коде плагина, вдруг он чего туда экспортирует

и попробуй подёргать за ниточки

получается ты скармливаешь json и делаешь post в api

угу

хм, а я как раз подобное нашел что-то

подскажите как лучше извратнуться: надо тестить плейбук на федоре и центос но есть только 4 гига оперативы - ВМ тяжело поднимать, вот думаю если в докере их поднять они же идентичны будут "железной установке"?

подскажите как лучше извратнуться: надо тестить плейбук на федоре и центос но есть только 4 гига оперативы - ВМ тяжело поднимать, вот думаю если в докере их поднять они же идентичны будут "железной установке"?

нет, будут отличие в том как инит скриптах 4 гига вполне позволят поднять федору и центос в headless-mode

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

кроме совсем уж критичных вариантов. И инит с системд нормально работает относительно

systemd будет работать с CAP_ADMIN, а вот кернел будет хостовый

зависит от плейбуки

что она делает, если ставит пакеты и правит файлики - то вполне

и еще вопрос, видел плейбуки где чуть ли не под все дистрибутивы сервис развертывают (deb/rpm/etc) это вообще нормальная практика? это же долго отлаживать и сложно такую разношерстную инфраструктуру поддерживать

Нормальная, если такая задача

Таким образом относительно легко мигрировать на новый дистрибутив, например

и еще вопрос, видел плейбуки где чуть ли не под все дистрибутивы сервис развертывают (deb/rpm/etc) это вообще нормальная практика? это же долго отлаживать и сложно такую разношерстную инфраструктуру поддерживать

Я такие роли делаю, нормально всё отлаживается. Не долго, но чуть сложнее чем на один дистр.

Дистры в докере поднимаются и там отлаживается, нагрузка не оч большая. Но вот матрицы тестов быстро не прогнать без ресурсов. Поэтому ci/cd для ролей дольше проходит из-за тестов

Регрес тесты полюбил

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

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

Нужно не всегда, но если нормально написано то и юзать нормально, а крос дистриб в коде заложены.

Меньше делать, меньше думать

переписываю playbook на loop, заодно выношу список пакетов для установки в переменные (вместо with_items) вопрос: можно ли в один модуль package засунуть несколько списков в зависимости от условий? пример: ставим список пакетов "basic_list", если определна переменная "admin" добавляем к нему список "admin_list"

1. списки ты можешь складывать 2. тебе не нужна вспомогательная переменная: прибавляй admin_list | default ([])

смысл то такой был - если это рабочая станция разработчика, вот тебе еще пачка пакетов, а обычному юзеру ставим базовый набор

и чтобы два раза модуль не вызывать хотел в одну задачу засунуть с условиями

nixos такое делается из коробки

ну да. для разработчика в host_vars будет определён список доппакетов.

ну да. для разработчика в host_vars будет определён список доппакетов.

точна!, спасибо

и чтобы два раза модуль не вызывать хотел в одну задачу засунуть с условиями

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

Подскажите, делаю так: tasks: - set_fact: pkgn="httpd" when: ansible_os_family == "Redhat" - set_fact: pkgn="apache2" when: ansible_os_family == "Debian" - name: start apache service: name="{{ pkgn }}" state=started Но ругает меня непутёвого Ansible, говорит что не определена переменная: The task includes an option with an undefined variable. The error was: 'pkgn' is undefined Пробовал: service: name="{{ pkgn }}"...... service: name=pkgn .... service: name={{ pkgn }} .... ЧЯДНТ?

pkgn: "apache2"

В set_fact

ansible_os_family вроде неправильно стоит

Лучше when: if pkgn is defined

Лучше when: if pkgn is defined

У него в зависимости от ОС pkgn разное значение должна принимать

pkgn: "apache2"

tasks: - set_fact: pkgn: "httpd" when: ansible_os_family == "Redhat" - set_fact: pkgn: "apache2" when: ansible_os_family == "Debian"Тот же эффект)

У него в зависимости от ОС pkgn разное значение должна принимать

Ну да, но если запустить на раче?

сейчас проверю, спасибо

И os family лучше проверить - оно вроде RedHat

tasks: - set_fact: pkgn: "httpd" when: ansible_os_family == "Redhat" - set_fact: pkgn: "apache2" when: ansible_os_family == "Debian"Тот же эффект)

А ОС-то совпадает с той, которую ищешь? 😅

И os family лучше проверить - оно вроде RedHat

+++

да)

все есть, проверял ad-hoc

есть что-то типа области видимости?

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

и apache установлен, но не запущен

tasks: - set_fact: pkgn: "httpd" when: ansible_os_family == "Redhat" register: pkgn - set_fact: pkgn: "apache2" when: ansible_os_family == "Debian" register: pkgn - debug: var: pkgnTASK [debug] ************************************************************************************************************************** ok: [194.222.98.28] => { "pkgn": { "changed": false, "skip_reason": "Conditional result was False", "skipped": true } }

верно сделал ли я?

Да, он тебе явно говорит, что переменная не определена, потому что условие не сработало

И register: pkgn - лишнее, ты её определяешь через set_fact и так

- debug: var: ansible_os_familyTASK [debug] ************ ok: [194.222.98.28] => { "ansible_os_family": "RedHat" }

- debug: var: ansible_os_familyTASK [debug] ************ ok: [194.222.98.28] => { "ansible_os_family": "RedHat" }

Ну вот об этом тебе и писал @vrutkovs

И register: pkgn - лишнее, ты её определяешь через set_fact и так

точно)) сорян уже просто плыву тут ;D

И os family лучше проверить - оно вроде RedHat

блааа))

case-sens)))

попался))

ахахха

case-sens)))

Yep

спасибо всем!!