может

Ну да, у этого человека местами переуплотнённые области. Ну и что тут такого? Уберите его с рельсов и поедем дальше на паровозе.

Еще раз. Что именно вы пытаетесь сказать? Что вам не нравится роль? Ну, ок. Мне тоже не оч. Я иначе пишу. И что?

Я просто пытаюсь понять по каким критериям ты определяешь хорошесть роли с галакси.

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

Мы обычно пишем иначе. Наши роли вы тоже видели, вроде.

И ты такой код возьмёшь с galaxy в свой проект?

Может быть нет. Дай ссылку.

https://galaxy.ansible.com/lean_delivery

https://galaxy.ansible.com/lean_delivery

Где именно?

https://github.com/lean-delivery/ansible-role-aem-dispatcher/blob/48aaaf0788229b48bdf2ab4421c8dfc5eb6928e4/defaults/main.yml#L24

Подскажите, как нормально экранировать команду mongo --host "{{ mongodb_host }}":"{{ mongodb_password }}" --eval 'db.createUser("{{'{'}}" user: "{{ mongodb_user }}", pwd: "{{ mongodb_password }}", roles: ["{{'{'}}"role: "root", db: "admin""{{'}'}}"]"{{'}'}}")'

Это очень локальная роль. Там не все best_practice соблюдены, да

А есть в которой соблюдены, ибо я взял первую попавшуюся и сразу в разрез твоим словам

А есть в которой соблюдены, ибо я взял первую попавшуюся и сразу в разрез твоим словам

Может тебе лучше модуль для монго юзеров?

А есть в которой соблюдены, ибо я взял первую попавшуюся и сразу в разрез твоим словам

Это очень локальная роль. Там не все best_practice соблюдены, да

А рутового юзера тоже создать можно с помощью него? У меня обычные юзеры создаются как раз через монго модуль

Ну, например, вот: https://github.com/lean-delivery/ansible-role-java

В версии апача это нормально, а вот тут вот: https://github.com/lean-delivery/ansible-role-aem-dispatcher/blob/48aaaf0788229b48bdf2ab4421c8dfc5eb6928e4/tasks/installApache.yml#L8: register: installed_packagesА потом у другой роли installed_packages поломаными будут.

А рутового юзера тоже создать можно с помощью него? У меня обычные юзеры создаются как раз через монго модуль

Тоже плохой пример, все префиксы разные https://github.com/lean-delivery/ansible-role-aem-dispatcher/blob/48aaaf0788229b48bdf2ab4421c8dfc5eb6928e4/defaults/main.yml#L18

Не будут. Такие переменные только в register или set_facts используются.

А в чужих ролях? И кто их вычитывает?

https://github.com/lean-delivery/ansible-role-jenkins

Тот, кто использует.

Запускать чужую роль, не читая код - так себе практика

А тут вообще префикс != названию роли

С программами это почему-то работает.

С программами это почему-то работает.

Это неважно. Главное, что он единообразный и соответствует требованиям. Случайно между ролями не перепутаются.

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

Мы используем ансибл как исполнитель сайд-эффектов. Логика вся вынесена в приложения/модули/etc. Вот пример типовой роли у нас: --- - name: Save ssh keys for VM access delegate_to: '{{ hypervisor }}' copy: content: '{{ vm_ssh_key }}' dest: /tmp/{{ inventory_hostname }}.pub mode: '0644' - name: Clone VM image from golden image become: true delegate_to: '{{ hypervisor }}' command: | /usr/bin/qemu-img create \ -F qcow2 -f qcow2 \ -b {{ golden_image_file }} \ '{{ vm_image_file }}' \ {{ vm_image_size }} args: creates: '{{ vm_image_file }}' - name: Create ISO with cloud config become: true delegate_to: '{{ hypervisor }}' command: /usr/bin/create-config-drive --ssh-key /tmp/{{ inventory_hostname }}.pub --hostname {{ vm_name }} {{ vm_config_file }} args: creates: '{{ vm_config_file }}' - name: Define libvirt domain delegate_to: '{{ hypervisor }}' virt: command: define xml: '{{ lookup("template", "domain.xml.j2") }}' - name: Start domain delegate_to: '{{ hypervisor }}' virt: name: '{{ vm_name }}' state: running autostart: true - name: Info debug: msg: 'VM {{ vm_name }}, image {{ vm_image_file }} from {{ golden_image_file }}, IP: {{ ansible_host }}' Тыц, тыц, тыц. Вне проекта смысла не имеет. Никаких сложных when, вычислений и т.д.

Код на баше даже короче выйдет, скорее всего. И с тем же результатом

Мы используем ансибл как исполнитель сайд-эффектов. Логика вся вынесена в приложения/модули/etc. Вот пример типовой роли у нас: --- - name: Save ssh keys for VM access delegate_to: '{{ hypervisor }}' copy: content: '{{ vm_ssh_key }}' dest: /tmp/{{ inventory_hostname }}.pub mode: '0644' - name: Clone VM image from golden image become: true delegate_to: '{{ hypervisor }}' command: | /usr/bin/qemu-img create \ -F qcow2 -f qcow2 \ -b {{ golden_image_file }} \ '{{ vm_image_file }}' \ {{ vm_image_size }} args: creates: '{{ vm_image_file }}' - name: Create ISO with cloud config become: true delegate_to: '{{ hypervisor }}' command: /usr/bin/create-config-drive --ssh-key /tmp/{{ inventory_hostname }}.pub --hostname {{ vm_name }} {{ vm_config_file }} args: creates: '{{ vm_config_file }}' - name: Define libvirt domain delegate_to: '{{ hypervisor }}' virt: command: define xml: '{{ lookup("template", "domain.xml.j2") }}' - name: Start domain delegate_to: '{{ hypervisor }}' virt: name: '{{ vm_name }}' state: running autostart: true - name: Info debug: msg: 'VM {{ vm_name }}, image {{ vm_image_file }} from {{ golden_image_file }}, IP: {{ ansible_host }}' Тыц, тыц, тыц. Вне проекта смысла не имеет. Никаких сложных when, вычислений и т.д.

башсибл :-D

Идемпотетность и удобство в отладке. Сайд-эффекты на ансибле кратно лучше баша.

- name: Clone VM image from golden image become: true delegate_to: '{{ hypervisor }}' command: | /usr/bin/qemu-img create \ -F qcow2 -f qcow2 \ -b {{ golden_image_file }} \ '{{ vm_image_file }}' \ {{ vm_image_size }} args: creates: '{{ vm_image_file }}'Повторый запуск вернёт ok.

Ну а если файл пустой, но существует - тоже ок.

- name: Clone VM image from golden image become: true delegate_to: '{{ hypervisor }}' command: | /usr/bin/qemu-img create \ -F qcow2 -f qcow2 \ -b {{ golden_image_file }} \ '{{ vm_image_file }}' \ {{ vm_image_size }} args: creates: '{{ vm_image_file }}'Повторый запуск вернёт ok.

Так и copy с remote_src то же самое сделает. Вполне поведение для модуля.

Положи порнокартинку в тот путь с тем же именем вместо нужного вам файла - и Ваша роль смело вернёт ОК

Нет

@tgadiev leandelivery/docker-systemd:ubuntu-18.04 20.04 нету?

Например, если apt name=foo, то он не проверяет, что foo установлен, а проверяет, что foo со статусом installed в базе данных apt'а. (Т.е. если на место /bin/foo положили порнокартинку то никто переустанавливать пакет не будет).

А, пересчитывает чексумму, да.

Например, если apt name=foo, то он не проверяет, что foo установлен, а проверяет, что foo со статусом installed в базе данных apt'а. (Т.е. если на место /bin/foo положили порнокартинку то никто переустанавливать пакет не будет).

оу, оу, а как вы бы проверили что софт установлен?

оу, оу, а как вы бы проверили что софт установлен?

Нет, bashsible, это когда повторно нельзя запускать, потому что state безнадёжно испорчен.

Не согласен как автор термина. Башсибл - это про императивность так-то, а не про испорченный стейт.

это что за покемон?

Ну, а, например, copy - это императивно или нет?