@pro_ansible - страница 765

George

Для чистого try-catch-finally кажется подходит вот это https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#id2

Похоже

Павел П.

Для чистого try-catch-finally кажется подходит вот это https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html#id2

о, спасибо! block использую с when. А rescue потестю

Artur

А вдруг apt не y/n спрашивает, а нужно ли конфиг файлы переписать

apt я как пример привёл. не над к нему привязываться. скрипт запрашивает строку из stdin. и похоже лучший вариант это пропатчить эт скрипт перед запуском ( т.к. берётся он из исходника)

Timur

Вечер добрый. Вопрос про try-catch-except-pass, или нет) Есть набор систем, где сервис стартует либо через init.d, либо супервизором. Как правильно определять как его, например, рестартовать? Устанавливать факт и потом when, или есть в ямле синтаксис типа try module supervisor - catch exceptin - pass - try module service ?

Зачем такие сложности? Модуль service работает как с init.d, так и с systemd

Timur

Просто работайте с сервисом через него - он сам будет вызывать нужные низкоуровневые команды

Павел П.

Зачем такие сложности? Модуль service работает как с init.d, так и с systemd

с супервизором не сработал

Timur

с супервизором не сработал

Для супервизора есть отдельный модуль

Павел П.

я о том и пишу

Timur

А, понял

Timur

Момент

Timur

Супервизор, вроде, не входит в список встроенных init systems

Timur

Или я не прав?

Timur

Т.е. через факты его просто так не получится задетектить

Timur

Или у вас сервис менеджер задается отдельно специальным параметром?

John

Вы ждали от меня идиотизма? а я его при(в)нёс :D local_action: command ansible-galaxy install {{ item }} --roles-path ./roles become: no with_items: - "{{ ansible_roles_list }}" - local_action: command ansible-playbook --inventory ./inventory/testinv.yml prometheus.yml --limit test-prom0 become: no И в консоле тишина) там наверняка ставится прометеус выкаченный только что предыдущей задачей)))

Timur

Павел П.

он не задается - он есть) На самом деле сам не знаю почти ничего про СИ. знаю только что есть старые системы с инит.д и поновее с супервизором.

Timur

Супервизор - это отдельная приблуда

John

Timur

Это не встроенный сервис

Павел П.

Это не встроенный сервис

самом собой. я о том что не знаю откуда берется

Timur

Т.е. сначала надо решить задачу - как корректно определять - каким сервис-менеджером пользоваться

Павел П.

парсить вывод ls -l /proc/1/exe можно...

John

Вы ждали от меня идиотизма? а я его при(в)нёс :D local_action: command ansible-galaxy install {{ item }} --roles-path ./roles become: no with_items: - "{{ ansible_roles_list }}" - local_action: command ansible-playbook --inventory ./inventory/testinv.yml prometheus.yml --limit test-prom0 become: no И в консоле тишина) там наверняка ставится прометеус выкаченный только что предыдущей задачей)))

Поставился) и даже работает))

Timur

Поставился) и даже работает))

Вызов ансибла ансиблом

Timur

Тонкий троллинг

Timur

парсить вывод ls -l /proc/1/exe можно...

Зачем?

Павел П.

проедемте.

John

Тонкий троллинг

я долго бился) и наконец полностью автоматизировал))) А потом посмотрел на то что получилось и подумал "Ну ты и мудак" (обращаясь к себе естественно :D цитата из к/ф "о чем говорят мужчины"))

Timur

парсить вывод ls -l /proc/1/exe можно...

Для systemd систем там, скорее всего, будет systemd

Timur

А не супервизор

Timur

Даже если он стоит

Павел П.

да, так

Павел П.

так сработало

Timur

Более того - супервизор обычно сам через systemd запускается :)

George

Более того - супервизор обычно сам через systemd запускается :)

Есть одна мудрость

George

supervisord нахрен не нужен в системах с systemd

Timur

supervisord нахрен не нужен в системах с systemd

Это другой вопрос. Есть кейсы, когда он позволяет сделать то, что с systemd сделать значительно сложнее

George

Это не означает, что systemd идеален, нет. Но тащить лишние компоненты - это мощь. А осилить нужно всего лишь юнитонаписание

George

Это другой вопрос. Есть кейсы, когда он позволяет сделать то, что с systemd сделать значительно сложнее

Можешь навскидку вспомнить, или это теория?

Timur

Можешь навскидку вспомнить, или это теория?

Да, могу. Например, управлять набором определенных сервисов, доступных исключительно одному непривилегированному юзеру. Без прав sudo

George

Да, могу. Например, управлять набором определенных сервисов, доступных исключительно одному непривилегированному юзеру. Без прав sudo

Не конкретно. Т.е. разрешить юзеру стартовать/останавливать сервис? Или что-то более сложное ?

Timur

Не конкретно. Т.е. разрешить юзеру стартовать/останавливать сервис? Или что-то более сложное ?

И стартовать, и останавливать, и создавать. И сервисы все должны ранаться исключительно под этим юзером

Timur

Без повышения привилегий

George

И стартовать, и останавливать, и создавать. И сервисы все должны ранаться исключительно под этим юзером

Эм, ну, да, наверное, соглашусь, но в системди тоже решаемо

Timur

Эм, ну, да, наверное, соглашусь, но в системди тоже решаемо

Стандартными путями - нет. Все systemctl процессы требуют рутовых привилегий для запуска, даже если дочерние процессы запускаются под другим юзером

Timur

так сработало

Такой вариант хорош только, если вариантов не более двух

Timur

Иначе получается малочитабельная многоуровневая портянка

Павел П.

Такой вариант хорош только, если вариантов не более двух

конечно. Их два, потому и) Иначе как обычно - when'ы

Timur

конечно. Их два, потому и) Иначе как обычно - when'ы

Есть другой способ

Timur

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

Timur

Можно сделать инклуд по условию с вызовом файла с именем, равным соответствующему значению параметра.

Павел П.

конкретно это скрипт собирающий инвентори не обрабатывает

Павел П.

но можно будет заморочиться, да) Спасибо

Timur

Как вариант для выбора тасков, специфичных для конктретной версии OS: - name: "Choose platform based task " include_tasks: "{{ platform }}" with_first_found: - "setup-{{ ansible_os_family }}.yml" - "not-supported.yml" loop_control: loop_var: platform

Timur

Работает даже, если запускать на нескольких разных дистрибутивах Linux и Windows

Павел П.

куль. в закладки унес

Timur

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

Timur

В случае, если такой файл не найден, вызывается дефолтный файл с тасками not-supported.yml

Timur

Этот же подход работает и с любым другим параметром, который может принимать несколько различных значений

Александр

Господа, есть каталог, внутри плейбук и vars, в плейбуке include ./vars/file но vars в gitinore. Как бы подставить внешний путь к vars через параметры при вызове ansible-playbook?

Timur

Господа, есть каталог, внутри плейбук и vars, в плейбуке include ./vars/file но vars в gitinore. Как бы подставить внешний путь к vars через параметры при вызове ansible-playbook?

А можно как-то понятнее задачу сформулировать?

Timur

Я нифига не понял, кто на ком стоял

Timur

И при чем тут вообще gitignore

Александр

И при чем тут вообще gitignore

Есть проект в git для деплоя. На моей локальной машине есть каталог vars, который исключен с главного репозитария на центральном сервере с помощью gitignore. Есть сборочный конвейер, который стягивает репу с центрального сервера, очищая предварительно рабочий каталог. И запускает плейбуки.

Александр

Проблема в том, что если я создам на сборочной машине vars, то со следующим обновлением репозитария vars будет удалён.

Александр

Поэтому надо указать размещение vars_files в плейбуке или передать его.