No package matching 'containerd.io' is available

странно, то что я раньше этот плейбук использовал, и ошибок не было, прошло 2 месяца, ни чего не обновлял и сыпаться начало

- name: Set the stable docker repository apt_repository: repo: deb [arch=amd64] https://download.docker.com/linux/ubuntu \ bionic \ stable" state: present update_cache: yes

На моей памяти, он менялся когда-то, как и адрес репы

Коллеги! Прошу совета вашего. Есть задача развернуть 2 разных сайта (конфига nginx) из одного шаблона. Но в этом шаблоне порядка 12 переменных, которые для этих двух сайтов различаются. Так как прописывать по 12 переменных 2 раза в роли мне категорически не нравится, то я все эти переменные объединил в словарик, разделив их для сайтов ключами словаря: site1: var1: value11 var2: value12 ... site2: var1: value21 var2: value22 ... Внутри template я их использую в виде site.var1 и т.д. При вызове темплате я site определяю нужным мне образом: - name: site1 template: ... vars: site: "{{ site1 }}" - name: site2 template: ... vars: site: "{{ site2 }}" Всё это работает конечно, но меня не покидает ощущение, что я псих и это решается по другому. Подскажите best practice на этот счёт, please.

Коллеги! Прошу совета вашего. Есть задача развернуть 2 разных сайта (конфига nginx) из одного шаблона. Но в этом шаблоне порядка 12 переменных, которые для этих двух сайтов различаются. Так как прописывать по 12 переменных 2 раза в роли мне категорически не нравится, то я все эти переменные объединил в словарик, разделив их для сайтов ключами словаря: site1: var1: value11 var2: value12 ... site2: var1: value21 var2: value22 ... Внутри template я их использую в виде site.var1 и т.д. При вызове темплате я site определяю нужным мне образом: - name: site1 template: ... vars: site: "{{ site1 }}" - name: site2 template: ... vars: site: "{{ site2 }}" Всё это работает конечно, но меня не покидает ощущение, что я псих и это решается по другому. Подскажите best practice на этот счёт, please.

Коллеги! Прошу совета вашего. Есть задача развернуть 2 разных сайта (конфига nginx) из одного шаблона. Но в этом шаблоне порядка 12 переменных, которые для этих двух сайтов различаются. Так как прописывать по 12 переменных 2 раза в роли мне категорически не нравится, то я все эти переменные объединил в словарик, разделив их для сайтов ключами словаря: site1: var1: value11 var2: value12 ... site2: var1: value21 var2: value22 ... Внутри template я их использую в виде site.var1 и т.д. При вызове темплате я site определяю нужным мне образом: - name: site1 template: ... vars: site: "{{ site1 }}" - name: site2 template: ... vars: site: "{{ site2 }}" Всё это работает конечно, но меня не покидает ощущение, что я псих и это решается по другому. Подскажите best practice на этот счёт, please.

На одной машине надо поднять два конфига?

Да, Жень

Одна роль, которая конфиг из шаблона генерит. И параметризуйте её извне, через {role: rolename, vars:...}

Тогда получится куча мелких ролей. Тоже не true

Тогда лучше как-то так мне кажется - https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html

Проблема не в циклическом вызове одного и того же. А в том, что надо передавать кучу переменных разных для каждого вызова, а хочется это делать скопом.

2 сайта из одного шаблона? Откуда тут много ролей? Или у вас таких сайтов вагон?

Коллеги! Прошу совета вашего. Есть задача развернуть 2 разных сайта (конфига nginx) из одного шаблона. Но в этом шаблоне порядка 12 переменных, которые для этих двух сайтов различаются. Так как прописывать по 12 переменных 2 раза в роли мне категорически не нравится, то я все эти переменные объединил в словарик, разделив их для сайтов ключами словаря: site1: var1: value11 var2: value12 ... site2: var1: value21 var2: value22 ... Внутри template я их использую в виде site.var1 и т.д. При вызове темплате я site определяю нужным мне образом: - name: site1 template: ... vars: site: "{{ site1 }}" - name: site2 template: ... vars: site: "{{ site2 }}" Всё это работает конечно, но меня не покидает ощущение, что я псих и это решается по другому. Подскажите best practice на этот счёт, please.

омагад

Все равно два набора простыней не избежать

Все равно два набора простыней не избежать

Два чая этому господину.

Коллеги! Прошу совета вашего. Есть задача развернуть 2 разных сайта (конфига nginx) из одного шаблона. Но в этом шаблоне порядка 12 переменных, которые для этих двух сайтов различаются. Так как прописывать по 12 переменных 2 раза в роли мне категорически не нравится, то я все эти переменные объединил в словарик, разделив их для сайтов ключами словаря: site1: var1: value11 var2: value12 ... site2: var1: value21 var2: value22 ... Внутри template я их использую в виде site.var1 и т.д. При вызове темплате я site определяю нужным мне образом: - name: site1 template: ... vars: site: "{{ site1 }}" - name: site2 template: ... vars: site: "{{ site2 }}" Всё это работает конечно, но меня не покидает ощущение, что я псих и это решается по другому. Подскажите best practice на этот счёт, please.

Посмотри https://github.com/k0ste/ansible-role-systemd_helper/blob/master/tasks/deploy_tmpfiles.yml

Посмотри https://github.com/k0ste/ansible-role-systemd_helper/blob/master/tasks/deploy_tmpfiles.yml

Проблема не в циклическом вызове одного и того же. А в том, что надо передавать кучу переменных разных для каждого вызова, а хочется это делать скопом.

loop: "{{ hostvars[inventory_hostname]['systemd_tmpfiles'] | Вот за такое нужно бить толстий-толстий проволока

А как правильней?

В зависимости от того, какая задача решается

В данном конкретном примере - получить список переменных хоста из определённого списка.

Зачем их получать? Они и так есть у хоста

И к ним надо обратиться. Посмотри шаблон и README у репозитория.

Вариант со словарем - норм. Только передавать корневой ключ словаря лучше не на уровне тасков, а на уровне ролей при повторном вызове, как выше сказали

И к ним надо обратиться. Посмотри шаблон и README у репозитория.

Трэш и угар, согласен с Тимуром.

Критикуешь - предлагай.

всё равно в чате дофига упоминаний hostvars[inventory_hostname]

Согласен. И все - про bad practice, ибо это - antipattern.

Не вижу упомнинаний best practice

Обращение к переменным описано в доке.

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

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

Для очевидных вещей инструкции не пишутся.

Это молодежный девиз что ли? "что не запрещено, то разрешено"? Голову тоже иногда стоит напрягать :) hostvars используются для доступа к фактам/переменным других хостов. Чтобы обратиться к фактам/переменным текущего хоста (inventory_hostname) использовать hostvars не нужно! Эти переменные и так доступны, без hostvars[inventory_hostname]! Поэтому эта конструкция и выглядит так криво. Перечитайте доки: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html https://docs.ansible.com/ansible/latest/user_guide/playbooks_vars_facts.html

Ну так почему б и не использовать, если есть возможность?) И никто не говорит, почему так поступать плохо.

почему так делать плохо?

как минимум это излишество, и как уже говорили - привязывает роль к инвентори, что херня, простите

Так в моём случае роль привязана к конкретной структуре конфигурации (читай хост/груп_варс)

.... .... .... .... .... .... .... ....

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

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

И каким образом роль в этом случае прибивается к окружению? Чтобы я мог ей воспользоваться, мне достаточно склонировать её из гитхаба, написать конфигурацию под хост, выполнить плей с этой ролью. Всё, я настроил на хосте systemd.