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

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

хуки гита ? или у ансибла тоже есть ? о_О

прощу прощения, не хуки, а таски pre_tasks и post_tasks https://www.packtpub.com/mapt/book/networking_and_servers/9781784398293/2/ch02lvl1sec22/adding-pre-tasks-and-post-tasks-to-playbooks

немного кривовато, но на них у меня получилось сделать внешнее хранилище фактов

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

Проблема в одном что у них нет поддержки для кеша etcd, и вопрос как они хранят это в ансиблем, я думаю так спец ключи и это можно мержить будет скриптами между друг другом

Делая локал экшен до и посмле плейбука и все

Делая локал экшен до и посмле плейбука и все

да, примерно так у меня и работает кривовато конечно https://hastebin.com/adozawocoq.cs вот мой tasks/env.yml

а вот так я его использую: gather_facts: false pre_tasks: - include: tasks/env.yml action=load post_tasks: - include: tasks/env.yml action=save

в конкретно этом случае - backend redis, перед которым стоит openresty (через lua достает json из редиса и отдает по http) - такое себе

мне приходится использовать конвенцию специальную, все переменные с префиском redisfact_ складываются в json и заливаются в хранилище. это не очень удобно таким образом, делая посреди плейбуки set_fact: redisfact_k8s_endpoint: blahblabhlbh добавляю в post_tasks его в redis {% set redisfact = {} %} {% for key in vars %} {% if key | match('^redisfact_') %} {% set _unused=redisfact.__setitem__(key, vars[key]) %} {% endif %} {% endfor %} {{ redisfact | to_json }}

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

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

да, спасибо

https://docs.ansible.com/ansible/latest/plugins/cache/redis.html

Там разные префиксы с разных хостов можно делать а потом мержить в остальные, но тут надо подумать конечно что бы не поломать данные

Мне кажется это самый простой вариант

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

Мне кажется это самый простой вариант

да, все верно, только хочется все таки etcd (с перламутровыми пуговицам) я видел такое https://docs.ansible.com/ansible/2.5/plugins/lookup/etcd.html сделанное через lookup

при этом, если я правильно понимаю, эта проблема решена в saltstack из коробки

может быть я не использовал пока что солт

ну и там агенты там такой проблемы быть не может

кстати

агенты мне архитектурно не подходят но там не обязательно агенты нужны, salt может менеджить ноду без агента, по простому ssh

они пулят изменения и в любом случае они будут в 1 состоянии

А ну может быть, я о нем очень мало знаю

я тоже только рядом стоял

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

кстати, я тут в CI добавил проверку на ansible-lint, немного ощутил боли, но мои плейбуки стали выглядеть более опрятно советую https://github.com/willthames/ansible-lint в нем как раз логика есть по стетейтам

либо самому написать

я его и так использую ?

он у меня для ci плейбуков

да. полезный инструмент.

и ролей но он часто ругается на нужные мне вещи в ролях по этой причине я его только на плейбуки натравливаю

а для ролей руками

а так 90% проблем мне vscode решает с нужными плагинами

Корявые, но нужные места можно оверрайдить, чтобы линтер не ругался

Корявые, но нужные места можно оверрайдить, чтобы линтер не ругался

да, приходится

и ролей но он часто ругается на нужные мне вещи в ролях по этой причине я его только на плейбуки натравливаю

к сожалению, надо что бы ansible-galaxy при приеме нового релиза роли прогоняло по роли ansible-lint ;-)

А я в гелакси не деплою, у меня для этого gitlab :)

Так что жизнь я не попорчу никому ;)

как решилось дело: добавил динамический inventory - down_hosts, который по api ходит в мониторинг и спрашивает список всех хостов которые не доступны и добавляет их в ansible group: down_hosts ansible запускаю так: ansible-playbook ... --limit 'all:!down_hosts' ....

http://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html

притом что dynamic inventory для хостов в оффлайне - это онлайнер. curl -sG -X GET -vvvv 'observer0:9080/gw/livestatus' --data-urlencode "q=GET hosts\nColumns: name\nFilter: stat e != 0" | jq '{"down_hosts": { "hosts": [ .[][0] ] }}'

Ansible Tower сейчас ставится на 18.04?

(чистая установка с нуля, не обновление)

Ansible Tower сейчас ставится на 18.04?

а какая разница, если у него есть возможность ставиться в виде docker контейнеров?

я, видимо, пропустил

а давно такая возможность появилась?

а давно такая возможность появилась?

Помойму спустя месяц или два после первого из релиза. Документация в репозитории

awx или тавер?

вряд ли именно тауэр поддерживается на убутне, но awx - это пожалуйста

вы меня смущаете) а в чём разница между ними?

О, прошу прощения. Я про awx толкую

бабло

http://docs.ansible.com/ansible-tower/latest/html/installandreference/release_notes.html#ansible-tower-version-3-2-4

я про вот это

я про вот это

Про tower ничего не могу сказать

вы меня смущаете) а в чём разница между ними?

https://www.ansible.com/products/awx-project/faq

Насколько я знаю, тауер поддерживается только на 16.04

(убунту)

Проверял недавно , с 1.5-2 мес. назад

то есть awx и Tower это как Fedora и RHEL?

yep

а Tower это некая версия awx + какие-то патчи сверху? или это просто awx просто переименованная?

патчи

как решилось дело: добавил динамический inventory - down_hosts, который по api ходит в мониторинг и спрашивает список всех хостов которые не доступны и добавляет их в ansible group: down_hosts ansible запускаю так: ansible-playbook ... --limit 'all:!down_hosts' ....

FYI паттерны в --limit не работают в 2.4.3 (от слова никак) в 2.5.2 поломан yaml инвентори в 2.5.0 - все хорошо

FYI паттерны в --limit не работают в 2.4.3 (от слова никак) в 2.5.2 поломан yaml инвентори в 2.5.0 - все хорошо

в 2.5.0 сломан consul, grafana

в 2.5.0 сломан consul, grafana

Понял. Не аффектит

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

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

я это победил так, делаю контейнер base image с ansible нужной версии от него наследую ansible-envname куда запиихивается inventory и все прочее необходимое далее каждая плейбука наследуется от ansible-envname:latest очень удобно в плане деливери. но если я изменяю первый base image с ansible, мне приходится в CI пересобирать все что от него наследуется и все что наследуется от наследуемого и т.д.

однако..........

ты, видимо, какие-то хитрые модули пользуешь?

однако..........

хм, вполне обычная практика

я это победил так, делаю контейнер base image с ansible нужной версии от него наследую ansible-envname куда запиихивается inventory и все прочее необходимое далее каждая плейбука наследуется от ansible-envname:latest очень удобно в плане деливери. но если я изменяю первый base image с ansible, мне приходится в CI пересобирать все что от него наследуется и все что наследуется от наследуемого и т.д.

а можно пример докерфайла для плейбуки? выглядит достаточно интересно

а можно пример докерфайла для плейбуки? выглядит достаточно интересно

да, все достаточно прозрачно: Базовый image: https://hastebin.com/fihezaboro.nginx От него наследуется image для определенного окружения: https://hastebin.com/zilotahiba.bash И от него наследуется уже docker image с нужной мне плейбукой: https://hastebin.com/ojowomekup.sql завернуто в CI который билдит первый image так: docker build -t ansible:2.5.0.0 .второй image с данными об окружении: docker build --build-arg BASE_IMAGE=ansible:2.5.0.0 -t ansible-env:latest .и третий с плейбукой docker build --build-arg BASE_IMAGE=ansible-env:latest -t foobar-playbook:latest

если у вас внедрен и работает CI/CD процесс, то оно пересобирается само, если например поменять первый image

но не проще ли подсовывать inventory вольюмом?

но не проще ли подсовывать inventory вольюмом?

инвентори для окружений (в том числе и динамические) я храню в докер образах (и в гите соответственно), для фиксации окружения для плейбуков которые запускаются поверх я подозреваю что это место можно улучшить, но CI решает за меня часть проблем и мне пока норм.

инвентори для окружений (в том числе и динамические) я храню в докер образах (и в гите соответственно), для фиксации окружения для плейбуков которые запускаются поверх я подозреваю что это место можно улучшить, но CI решает за меня часть проблем и мне пока норм.

а, ну разве что если там чистая динамика - тогда имеет смысл, да

статические инвентори я бы скорее подсовывал при запуске контейнера (но опять же, я сильно пристрастился к AWX)

а, ну разве что если там чистая динамика - тогда имеет смысл, да

Да. Всего 5 инвентори, один yml и четыре динамики

а, ну разве что если там чистая динамика - тогда имеет смысл, да

У меня ещё богатые group/host vars. И запихивая их в контейнер с плейбуками я гарантирую совместимость между переменными и самими тасками

У меня ещё богатые group/host vars. И запихивая их в контейнер с плейбуками я гарантирую совместимость между переменными и самими тасками

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

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

Все правильно, версия ансибла у меня в базовом контейнере, когда я делаю изменение происходит CI который делает check syntax, оно конечно все не покрывает, но пару раз, в том числе и сегодня с 2.5.2.0 спасало

Все правильно, версия ансибла у меня в базовом контейнере, когда я делаю изменение происходит CI который делает check syntax, оно конечно все не покрывает, но пару раз, в том числе и сегодня с 2.5.2.0 спасало

хмм, интересная идея

хмм, интересная идея

Время на внесение изменений увеличивается, но компенсируется довольно большим процентом успешных деплойментов окружения. Все плюсы и минусы CI/CD

+ довольно хорошо вырисовывается workflow для ваших окружений и пресловутый life cycle management Впрочем это уже наверное здесь оффтопик

Я думаю интересно для любого кто думал про business continuity

Тут бывает что даже через год восстановить рабочее окружение тяжело. То pip ушатают, то ориджины протухнут

А вендрить докером или галакси уже религиозный вопрос. Докером оно удобнее)

А вендрить докером или галакси уже религиозный вопрос. Докером оно удобнее)

в общем случае, стандартом де фатко, деливерить нужно workload'ы, а не артефакты в виде ansible ролей с нужным pin коммитом или других исходников. Кастомеру требуется экспретиза как их правильно применять на своих окружениях.