Получается как заголовок первого уровня. и далее заголовки второго уровня

Когда ансибл читает плейбук, он должен хоть куда-то подцепиться, на локалхост или удаленно

Возникла проблема)) Есть контейнер (williamyeh/ansible:centos7) в нем запускается плейбек. На 2х из 3х серверов из инвентори плейбук выполняется, на 3ем же проблема с подключением по ssh. Однако на хост-машине и в контейнере ssh подключение создается. В какую сторону копать. На всякий случай отладка debug1: Next authentication method: publickey debug1: Offering RSA public key: .ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering RSA public key: /builds/*****/******/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Возникла проблема)) Есть контейнер (williamyeh/ansible:centos7) в нем запускается плейбек. На 2х из 3х серверов из инвентори плейбук выполняется, на 3ем же проблема с подключением по ssh. Однако на хост-машине и в контейнере ssh подключение создается. В какую сторону копать. На всякий случай отладка debug1: Next authentication method: publickey debug1: Offering RSA public key: .ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering RSA public key: /builds/*****/******/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Ни кто не сталкивался с таким/подобным поведением?

Короч, трабла с ключами, хотя не понятно какая... Аутентификация на логин/пароль работает

Короч, трабла с ключами, хотя не понятно какая... Аутентификация на логин/пароль работает

Смотри на содержимое .ssh/authorized_keys, а также на права на этот файл - должны быть 0600

Смотри на содержимое .ssh/authorized_keys, а также на права на этот файл - должны быть 0600

На целевой машине?

Да

Добрый день! Извините за нубский вопрос... Подскажите плиз как оформить в один таск код вида: - name: Copy private key copy: src: ssl/private.key dest: /etc/nginx/ssl/ccc.com.key when: ansible_facts['os_family'] == "Debian" - name: Copy private key copy: src: ssl/private.key dest: /usr/local/etc/nginx/ssl/ccc.com.key when: ansible_facts['os_family'] == "FreeBSD"

никак

никак

так же уродливый плейбук получится...

так не используйте фрибсд

так не используйте фрибсд

Спасибо

Добрый день! Извините за нубский вопрос... Подскажите плиз как оформить в один таск код вида: - name: Copy private key copy: src: ssl/private.key dest: /etc/nginx/ssl/ccc.com.key when: ansible_facts['os_family'] == "Debian" - name: Copy private key copy: src: ssl/private.key dest: /usr/local/etc/nginx/ssl/ccc.com.key when: ansible_facts['os_family'] == "FreeBSD"

Инклудать разные переменные и таски в зависимости от фактов, а таски делать параметризованными

Инклудать разные переменные и таски в зависимости от фактов, а таски делать параметризованными

Спасибо

Как пример: - name: Load a variable file based on the OS include_vars: '{{ platform }}' with_first_found: - '{{ ansible_os_family }}.yml' - default.yml loop_control: loop_var: platform

Этот вариант лучше )

В директории vars будут лежать файлы вида Debian.yml, FreeBSD.yml и т.п. со своим набором переменных

В директории vars будут лежать файлы вида Debian.yml, FreeBSD.yml и т.п. со своим набором переменных

все понял, спасибо

В зависимости от определенной OS ансибл будет подхватывать нужный набор переменных

Если нужного набора не встретится, будет использоваться набор из default.yml

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

Короч, трабла с ключами, хотя не понятно какая... Аутентификация на логин/пароль работает

Вернулся на аутентификацию по ключу, теперь работает. Что было хз. Группа администрирования не признается

failed_when: почему то не остонавливает

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

failed_when

failed_when: почему то не остонавливает

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

failed_when

shell: /sbin/sysctl net.ipv4.conf.all.forwarding | awk '{ print $3 }' register: sysctl_result failed_when: "sysctl_result == 0"

там или 0 или 1, при 0 должно стопнуться, но он пролетает как будто все норм

Кавычки убираем

Кавычки убираем

сча проверю..неужели только из за них 0.о

И там не саму переменную нужно вызывать

Добавьте дебаг вида: - debug: var: sysctl_result

а что?

И покажите, что он выводит у вас

Добавьте дебаг вида: - debug: var: sysctl_result

"sysctl_result": { 11:35:21 "changed": true, 11:35:21 "cmd": "/sbin/sysctl net.ipv4.conf.all.forwarding | awk '{ print $3 }'", 11:35:21 "delta": "0:00:00.009452", 11:35:21 "end": "2019-01-18 08:35:20.961875", 11:35:21 "failed": false, 11:35:21 "rc": 0, 11:35:21 "start": "2019-01-18 08:35:20.952423", 11:35:21 "stderr": "", 11:35:21 "stderr_lines": [], 11:35:21 "stdout": "0", 11:35:21 "stdout_lines": [ 11:35:21 "0"

Понятно

У вас в коде должно быть так: failed_when: not sysctl_result.rc

Проверьте

Понятно

спс. чекаю..

Работает?

Работает?

нет...в обоих случаях ошибка)

нет...в обоих случаях ошибка)

Какая?

Какая?

fatal: [localhost]: FAILED! => {"changed": true, "cmd": "/sbin/sysctl net.ipv4.conf.all.forwarding | awk '{ print $3 }'", "delta": "0:00:00.009553", "end": "2019-01-18 09:10:17.279295", "failed_when_result": true, "rc": 0, "start": "2019-01-18 09:10:17.269742", "stderr": "", "stderr_lines": [], "stdout": "1", "stdout_lines": ["1"]}

fatal: [localhost]: FAILED! => {"changed": true, "cmd": "/sbin/sysctl net.ipv4.conf.all.forwarding | awk '{ print $3 }'", "delta": "0:00:00.009553", "end": "2019-01-18 09:10:17.279295", "failed_when_result": true, "rc": 0, "start": "2019-01-18 09:10:17.269742", "stderr": "", "stderr_lines": [], "stdout": "1", "stdout_lines": ["1"]}

Ну, так все как и должно быть

Результат rc = 0

По условию это фейл

>там или 0 или 1, при 0 должно стопнуться вот как было в начальном условии

Все так и есть. При 0 все останавливается

Что не так-то?

но у меня сейчас 1, и все равно падает на ошибку

Выхлоп покажите

А, понял

Вы не в rc результат выводите, который отслеживать хотите, а в stdout?

вроде да, я еще только начинающий)

shell: /sbin/sysctl net.ipv4.conf.all.forwarding | awk '{ print $3 }' register: sysctl_result failed_when: sysctl_result.stdout == 0 если так делаю, то в любом случае без ошибок проходит) хотя должно опять же на 0 стопаться

А так? failed_when: not sysctl_result.stdout

Коллеги, а кто-нибудь знает как вытащить из playbook'а параметр hosts? Пишу роль для кластера rabbitmq. В конфиге надо указывать все хосты, которые участвуют в кластере. Пока реализовал через ansible_play_hosts, но если запускать ansible-playbook с параметром —limit, то мы теряем хосты из конфига rabbitmq Пока решил проблему так: --- - name: Install and confugure RabbitMQ hosts: "{{ rabbitmq_cluster_group }}" become: yes vars: rabbitmq_cluster_group: dev-rabbitmq И работаю уже с переменной rabbitmq_cluster_group

Коллеги, а кто-нибудь знает как вытащить из playbook'а параметр hosts? Пишу роль для кластера rabbitmq. В конфиге надо указывать все хосты, которые участвуют в кластере. Пока реализовал через ansible_play_hosts, но если запускать ansible-playbook с параметром —limit, то мы теряем хосты из конфига rabbitmq Пока решил проблему так: --- - name: Install and confugure RabbitMQ hosts: "{{ rabbitmq_cluster_group }}" become: yes vars: rabbitmq_cluster_group: dev-rabbitmq И работаю уже с переменной rabbitmq_cluster_group

Зачем hosts вытаскивать из плейбука? Это все в инвентори должно быть

Зачем hosts вытаскивать из плейбука? Это все в инвентори должно быть

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

Или нельзя... Вот поэтому и вопрос =)

Все можно. Непонятно, что именно вы хотите?

Опишите задачу детальнее

Хорошо Имеется группа серверов, на которые устанавливается rabbitmq. У rabbitmq один из вариантов кластеризации предпологает, что в файле /etc/rabbitmq/rabbitmq.conf будут указаны все участники кластера. Генерировал я этот список сейчас следующим образом: {% for host in ansible_play_hosts %}cluster_formation.classic_config.nodes.{{ loop.index }} = rabbit@{{ hostvars[host].inventory_hostname }} {% endfor %} И когда я запускал playbook с опцией —limit, в этот цикл попадали только хосты, на которых в данный момент выполняется роль Сейчас я заменил переменную ansible_play_hosts на rabbitmq_server_cluser_group, и цикл стал выглядеть следующим образом: {% for host in rabbitmq_server_cluser_group %}cluster_formation.classic_config.nodes.{{ loop.index }} = rabbit@{{ hostvars[host].inventory_hostname }} {% endfor %} В переменную rabbitmq_server_cluser_group я записываю группу хостов, которые должны входить в кластер, т.е. ту же самую группу, что и используется в параметре hosts в playbook.yml. Поэтому сейчас playbook выглядит так: --- - name: Install and confugure RabbitMQ hosts: "{{ rabbitmq_server_cluster_group }}" become: yes vars: rabbitmq_server_cluster: True rabbitmq_server_cluster_type: classic_config rabbitmq_server_cluster_group: dev-rabbitmq roles: - software.rabbitmq Хотелось бы обойтись без переменной rabbitmq_server_cluster_group, использовав значение hosts

Опишите задачу детальнее

Попытался достаточно подробно =)

Что такое "значение hosts" в вашем понимании?

И как сейчас инвентори у вас выглядит?

Если в группу dev-rabbitmq входят все нужные хосты, то в чем вообще проблема?

Что мешает использовать эту группу напрямую?

Вот так почему не сделать просто? {% for host in groups['dev-rabbitmq'] %} cluster_formation.classic_config.nodes.{{ loop.index }} = rabbit@{{ hostvars[host].inventory_hostname }} {% endfor %}

И плейбуку вызывать аналогично: --- - name: Install and confugure RabbitMQ hosts: dev-rabbitmq become: yes vars: rabbitmq_server_cluster: True rabbitmq_server_cluster_type: classic_config roles: - software.rabbitmq

Вот так почему не сделать просто? {% for host in groups['dev-rabbitmq'] %} cluster_formation.classic_config.nodes.{{ loop.index }} = rabbit@{{ hostvars[host].inventory_hostname }} {% endfor %}

Проблема в том, что в hosts файле может быть несколько кластеров. К примеру, файл может выглядеть так: [dev-rabbitmq] rabbitmq-01.dev rabbitmq-02.dev [testing-rabbitmq] rabbitmq-01.testing rabbitmq-02.testing [preprod-rabbitmq] rabbitmq-01.preprod rabbitmq-02.preprod

Так, и?

Так, и?

Поэтому в шаблоне генерации конфига целесообразнее использовать переменную

Чтобы меняя имя группы в переменной мы могли использовать роль для разных групп

Проблема в том, что в hosts файле может быть несколько кластеров. К примеру, файл может выглядеть так: [dev-rabbitmq] rabbitmq-01.dev rabbitmq-02.dev [testing-rabbitmq] rabbitmq-01.testing rabbitmq-02.testing [preprod-rabbitmq] rabbitmq-01.preprod rabbitmq-02.preprod

Это плохой феншуй, держать энвы разных стейджей в одном инвентаре

Не проще сделать разные файлы: dev, test и preprod c одинаковыми названиями группы rabbitmq?

И выбор делать - подкладывая нужный инвентарь в плей

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

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

Как вариант. Но сейчас у нас единый hosts файл со всеми нашими серверами