Но тогда я не понимаю, о чём всё же написано в оф. статье https://docs.ansible.com/ansible/latest/reference_appendices/galaxy.html?highlight=galaxy#dependencies

Что тебе там не ясно ?!

Я уже 100 раз рассказал же

Может кто подсказать - что не так с инвентори в yaml $ cat inventory.yml all: vm: ubuntu-bay10: ansible_ssh_host: 192.168.80.36 ansible_ssh_user: root $ ansible -i inventory.yml -m shell -a 'uname -a' vm [WARNING]: provided hosts list is empty, only localhost is available $ ansible --version ansible 2.1.1.0

файл hosts ...

То есть нет понимания, зачем прописывать зависимости в "meta/main.yml", если ВСЁ-РАВНО придётся запустить ansible-galaxy перед выполнением всего плейбука? Я надеялся, что в этом случае ansible-playbook скачает зависимости по URL сам.

А стоп все верно не то

мета для ansible galaxy а не для ansible playbook

Может кто подсказать - что не так с инвентори в yaml $ cat inventory.yml all: vm: ubuntu-bay10: ansible_ssh_host: 192.168.80.36 ansible_ssh_user: root $ ansible -i inventory.yml -m shell -a 'uname -a' vm [WARNING]: provided hosts list is empty, only localhost is available $ ansible --version ansible 2.1.1.0

https://docs.ansible.com/ansible/2.4/intro_inventory.html

мета для ansible galaxy а не для ansible playbook

Допустим. Запустил я галакси, он прошёл по мете, скачал зависимости, всё ОК. Следом запускаю плейбук и он мне ругается на синтаксис. Что за дичь...

https://docs.ansible.com/ansible/2.4/intro_inventory.html

Спасибо! Понял.

и скидывай на пастбин или что то подобное читать не удобно

То есть нет понимания, зачем прописывать зависимости в "meta/main.yml", если ВСЁ-РАВНО придётся запустить ansible-galaxy перед выполнением всего плейбука? Я надеялся, что в этом случае ansible-playbook скачает зависимости по URL сам.

Мета нужна для Галакси, чтобы он сам выкачал

Я уже писал это ему

А playbook ругается значит там и есть проблема с синтаксисом!

ansible-playbook не читает твой файл МЕТА

Мета нужна для Галакси, чтобы он сам выкачал

Когда не в мете, всё работает. Он из файла requirements.yml берёт и всё выкачивает. А когда в мете. ansible-playbook спотыкается о синтаксис.

ansible-playbook не читает твой файл МЕТА

Как не читает? Он же в роли, которой требуется кластер, так? Значит читает. И запинается.

Не читает ансибл плейбук никакую мету. Нахер надо оно ему?

Не читает ансибл плейбук никакую мету. Нахер надо оно ему?

Мы не правы.

Не читает ансибл плейбук никакую мету. Нахер надо оно ему?

Ну как же не читает? А другие роли я по вашему зависимые как выполняю?

Когда не в мете, всё работает. Он из файла requirements.yml берёт и всё выкачивает. А когда в мете. ansible-playbook спотыкается о синтаксис.

Вот и пропиши все в reqyuirements и не занимайся странным

https://docs.ansible.com/ansible/2.5/user_guide/playbooks_reuse_roles.html#using-roles

Вот и пропиши все в reqyuirements и не занимайся странным

Это не настолько странное, на сколько будущее. Гораздо более удобным выглядит переключение версий кластера, в зависимостях для каждой роли, чем одна версия кластера из requirements.yml на весь плейбук.

Потому как для одной роли в одном и том же плейбуке я хочу поднять одну версию кластера БД, а для других более старую.

Как говорится, PRs are welcome

Потому как для одной роли в одном и том же плейбуке я хочу поднять одну версию кластера БД, а для других более старую.

Переменные и факты же ну

Странные решения рождаются из странных задач

Роль другая получается. Причём тут факты. Это как бы другая версия репозитория. Старая версия MySQL, например.

что-то утомительно как-то, давай начнем с простого

какую проблему вы решаете?

Роль другая получается. Причём тут факты. Это как бы другая версия репозитория. Старая версия MySQL, например.

Requirements можно делать разные

какую проблему вы решаете?

В разных ветках разных головных репозиториев, с плейбуками, использовать вспомогательные репозитории, и желательно разных версий.

Вот пример из оф. доки: dependencies: - src: geerlingguy.ansible - src: git+https://github.com/geerlingguy/ansible-role-composer.git version: 775396299f2da1f519f0d8885022ca2d6ee80ee8 name: composer Который бы меня устроил. Но он не работает.

В разных ветках разных головных репозиториев, с плейбуками, использовать вспомогательные репозитории, и желательно разных версий.

Ну и в разных ветках наверное будут разные requirements?

В разных ветках разных головных репозиториев, с плейбуками, использовать вспомогательные репозитории, и желательно разных версий.

это решается при помощи докер контейнеров, собираете для разных веток, разных репозиториоев контейнеры с разными метками: ansible-env:master ansible-env:stable ansible-env:<COMMIT_ID> запускаете вашу плейбуку так: $ export LABEL=stable $ docker run --rm ansible-env:${STABLE} ansible-playbook /path/to/playbook.yml

артефакты в виде контейнеров вам должен деливерить сам CI

Ну и в разных ветках наверное будут разные requirements?

Не так. Есть большая ветка с плейбуками. В ней есть один, который зависит от роли из другого репозитория.

И что?

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

артефакты в виде контейнеров вам должен деливерить сам CI

Но задача не в этом. А в гибкости синтеза конечного продукта. То етсь основную ветку тестировать со старой версией БД, потом с новой. Потом девелоп ветку со старой, потом с новой. Потом легаси ветку, со старой и новой версией кластера БД. Вот в чём задача.

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

Придётся)

Но задача не в этом. А в гибкости синтеза конечного продукта. То етсь основную ветку тестировать со старой версией БД, потом с новой. Потом девелоп ветку со старой, потом с новой. Потом легаси ветку, со старой и новой версией кластера БД. Вот в чём задача.

это абсолютно ровно и хорошо ложится в мой подход которы я описал вам выше

это абсолютно ровно и хорошо ложится в мой подход которы я описал вам выше

Согласен.

еще раз, на мой взгляд, у вас проблема не совсем ансибла, а подхода к процессу, тут скорее нужен @devops_ru чатик или похожее

Но задача не в этом. А в гибкости синтеза конечного продукта. То етсь основную ветку тестировать со старой версией БД, потом с новой. Потом девелоп ветку со старой, потом с новой. Потом легаси ветку, со старой и новой версией кластера БД. Вот в чём задача.

Роли тестируются сами по себе

Тут у меня лично, только одна проблема. Я лишь правлю плейбуки и запускаю, некоторые из них пишут сами разрабы. И они хотят выбирать сами без CI, какую версию им использовать, например локально.

Но задача не в этом. А в гибкости синтеза конечного продукта. То етсь основную ветку тестировать со старой версией БД, потом с новой. Потом девелоп ветку со старой, потом с новой. Потом легаси ветку, со старой и новой версией кластера БД. Вот в чём задача.

В gitlab ci есть переменные и инваерменты для таких вещей

Где ты можешь указать если из мастера то такое то делать и такие переменные

Вы решаете проблему CI CD через ansible

еще раз, на мой взгляд, у вас проблема не совсем ансибла, а подхода к процессу, тут скорее нужен @devops_ru чатик или похожее

Я изложил кейс, если решения нет, очень жаль. CI решает, но не так гибко.

https://docs.gitlab.com/ee/ci/environments.html

В gitlab ci все достаточно гибко и просто, а про jenkins я не знаю.

Вы решаете проблему CI CD через ansible

Не совсем. Галакси для того и существует.

Но думаю там такое тоже решается

Гелакси

Это как github для git

Вы прослушали час наркомании

Вы прослушали час наркомании

Согласен.

И ничего из этого не почерпнули)))

Зато приятно пообщаться с умными людьми!

Когда ещё такое повторится :)

Господа, такой вопрос возник. Есть кластер с приложением, перед которым стоит nginx в качестве балансировщика. Все ноды кластера прописаны в апстриме. При деплое новой версии приложения надо по одной вытаскивать ноды из апстрима, апдейтить и возвращать обратно. Есть ли какой-нибудь цивилизованный способ это делать?

мне в голову приходит только костыль с shell: 'sed ...."

мне в голову приходит только костыль с shell: 'sed ...."

Может где-то есть глобальный список сервисов? Как-то не хорошо парсить работающую конфигу. А потом, после завершения работ заполнять темплейт.

ERROR: S client not available

Делегировать на хост менять темплейт по ходу я думаю как то так

Может где-то есть глобальный список сервисов? Как-то не хорошо парсить работающую конфигу. А потом, после завершения работ заполнять темплейт.

Для этого нужен consul же

Можно и Консул

подскажите как делать проверку переменной и если её нет то не выполнять блок вот такая конструкция фейлится {% if bgp.network is not undefined %} jfjfjfjfjf {% endif %} такая тоже {% if bgp.network is defined %} jfjfjfjfjf {% endif %}

Можно вообще сделать чтобы nginx через LUA из Консула запрашивал переодически рабочие конфиги сервисов...

пойду посмотрю что есть подходящего в инфре. спасибо.

Можно вообще сделать чтобы nginx через LUA из Консула запрашивал переодически рабочие конфиги сервисов...

покажешь?)

Господа, такой вопрос возник. Есть кластер с приложением, перед которым стоит nginx в качестве балансировщика. Все ноды кластера прописаны в апстриме. При деплое новой версии приложения надо по одной вытаскивать ноды из апстрима, апдейтить и возвращать обратно. Есть ли какой-нибудь цивилизованный способ это делать?

Вынесите файл с списком апстримов в отдельный nginx файл. В основной конфигурации сделайте include В ansible добавьте темплейт для списка апстримов Перед проходом по nginx нодам, генерите файл темплейтом исключая ноду которая обновляется

подскажите как делать проверку переменной и если её нет то не выполнять блок вот такая конструкция фейлится {% if bgp.network is not undefined %} jfjfjfjfjf {% endif %} такая тоже {% if bgp.network is defined %} jfjfjfjfjf {% endif %}

В старых версиях undefined

покажешь?)

https://www.nginx.com/blog/service-discovery-with-nginx-plus-and-consul/

нарисовать на бумаге и я могу

я про луашный код говорю

Вообще у nginx есть health check backend

Можно да и openresty

мне интересно, как consul-template можно заменить lua’шечкой

я про луашный код говорю

https://gist.github.com/gmr/82801bf32c62e5fedb3f держи

благодарствую

покажешь?)

Ты думаешь это оптимальный вариант? Я не знаю, как часто сервисы меняются и т.д. Может лучше будет, чтобы некий вачдог, дёргал nginx с подменой конфигов, через тот же confd. Рекомендую сделать так.

мне интересно, как consul-template можно заменить lua’шечкой

https://github.com/openresty/lua-upstream-nginx-module

ну это всего-лишь апстримы ?

это не удалит и не добавит новые location’ы, в отличии от consule-template'а

это не удалит и не добавит новые location’ы, в отличии от consule-template'а

https://github.com/bungle/lua-resty-route

можно хоть весь роутинг location'ов в базе держать

https://github.com/weibocom/nginx-upsync-module

А не лучше с плагином тогда собрать nginx и юзать

вообщем до сих пор не понятно причем тут ansible

https://github.com/bungle/lua-resty-route

о, прикольно

Доброго времени суток! Подскажите, пожалуйста, есть такая вот хреновина: https://github.com/mobz/elasticsearch-head С помощью Ansible стягиваю на сервер эту репу, Затем его с помощью command: 'npm install' После этого, нужно запустить команду nohup npm run start &. РУчками оно запускается и работает в фоне как надо. Ансибл же не может запустить это, так как привыполнении npm пытается понять, что ж за & такой Ошибка: npm ERR! elasticsearch-head@0.0.0 start: `grunt server \"&\"

https://docs.ansible.com/ansible/latest/modules/npm_module.html

Для npm есть модуль

Доброго времени суток! Подскажите, пожалуйста, есть такая вот хреновина: https://github.com/mobz/elasticsearch-head С помощью Ansible стягиваю на сервер эту репу, Затем его с помощью command: 'npm install' После этого, нужно запустить команду nohup npm run start &. РУчками оно запускается и работает в фоне как надо. Ансибл же не может запустить это, так как привыполнении npm пытается понять, что ж за & такой Ошибка: npm ERR! elasticsearch-head@0.0.0 start: `grunt server \"&\"

потому что символ & - его понимает не ансибл, а баш. а баш - это модуль shell, но не command.