угу

да ну...и так из 3, 2 доклада про ансибл было...

да ну...и так из 3, 2 доклада про ансибл было...

ну там не только про ансибл делают

думаю про рутконф, например, все слышали

ну там не только про ансибл делают

я к тому, что пока хватит про ансибл...его ну реаьно много

да ну...и так из 3, 2 доклада про ансибл было...

Как будто это плохо

:-D

думаю про рутконф, например, все слышали

нет, никто. что это?

Как будто это плохо

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

вчера про модули было же

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

в любом случае стоит сходит и поговорить

вчера про модули было же

да? а то я после инфры уехал)))

в любом случае стоит сходит и поговорить

ну это верно

да? а то я после инфры уехал)))

Как раз @tnt4brain про модули и планины рассказывал. Можешь запись глянуть.

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

да? а то я после инфры уехал)))

Да. Я и рассказывал. Попутно башсибл зацепил :-)

Как раз @tnt4brain про модули и планины рассказывал. Можешь запись глянуть.

оке...ссылочку дашь?)

https://www.youtube.com/watch?v=7eP0KOD4zCw

https://www.youtube.com/watch?v=7eP0KOD4zCw

спс

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

Дело вкуса) но я больше про то что у Александра большой опыт в организации

Дело вкуса) но я больше про то что у Александра большой опыт в организации

я хочу на DevOps Pro сходить...судя по докладчикам, будет интересно т.к. там не только из РФ, но и из Европы и Америки т.е. можно узнать как работают другие компании, которые, по сути, находятся в другой среде обитания

Как будто это плохо

они сильно повторяются имхо. Ансибл да молекула, молекула да ансибл, да вот еще тесткитчен

все мпривет

все мпривет

neprivet.ru

нубу не поможете? - name: Remove default block cgi-bin blockinfile: block: "{{ lookup('file', './templates/block.j2') }}" dest: /etc/httpd/conf/httpd.conf marker: "#-- {mark} ANSIBLE MANAGED BLOCK " state: absent block.j2 <Directory "/var/www/cgi-bin"> AllowOverride None Options None Require all granted </Directory> что не так? почему не удоляет?

нубу не поможете? - name: Remove default block cgi-bin blockinfile: block: "{{ lookup('file', './templates/block.j2') }}" dest: /etc/httpd/conf/httpd.conf marker: "#-- {mark} ANSIBLE MANAGED BLOCK " state: absent block.j2 <Directory "/var/www/cgi-bin"> AllowOverride None Options None Require all granted </Directory> что не так? почему не удоляет?

Где выполняется? На локалхосте или на удаленной машине?

на удаленке

главное добаляется без вопросос - по этой же схеме :)

lookup выполняется только на локалхосте

не lookup то на локалке, откуда он тогдабы шаблон для вставки брал

непойму как он сверяет блоки

а маркер в файле есть?

упс

нет

все понял, не тем пытаюсь модулем пользоваться

тогда вопрос - какой модуль использовать чтобы вырезать кусок конфига по шаблону?

хочу в apache вырезать этот кусок <Directory "/var/www/cgi-bin"> AllowOverride None Options None Require all granted </Directory>

хочу в apache вырезать этот кусок <Directory "/var/www/cgi-bin"> AllowOverride None Options None Require all granted </Directory>

и заменить на чтото?

вот на это <Directory "/var/www/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch AddHandler cgi-script .sh Order allow,deny Allow from all </Directory>

просто не сообращу как весь этот кусок выдрать

хочу в apache вырезать этот кусок <Directory "/var/www/cgi-bin"> AllowOverride None Options None Require all granted </Directory>

А почему нельзя сразу зашаблонить весь конфиг?

А почему нельзя сразу зашаблонить весь конфиг?

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

http://linux-notes.org/zamena-strok-slov-v-fajle-cherez-ansible-v-unix-linux/

нет?

это построчно

в моем случае не пойдет построчно - </Directory> достаточно много

я так понял нет подобного модуля, надо писать свой или как все править конфиг целиком (template)

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

Вообще-то апач умеет в конфиги кусками.

Вот пусть другие роли и пишут свои куски.

они сильно повторяются имхо. Ансибл да молекула, молекула да ансибл, да вот еще тесткитчен

у меня тут, ктстати, есть запоздалася расшифровка выступления на sbplug про testkitchen http://www.goncharov.xyz/it/test-ansible-roles-via-testkitchen-inside-hyperv.html с примерами https://github.com/ultral/ansible-role-testing про то как запилили тестирование ролей ansible через testkitchen

Вот пусть другие роли и пишут свои куски.

Ну к этому и пришел. Придется править роль установки и ставить со своим дефолтным конфигом.

Ну к этому и пришел. Придется править роль установки и ставить со своим дефолтным конфигом.

напиши роль которая только ставит апач и дефолтный конфиг валидный для всех, и отдельную роль/роли c конфигами и всем прочим конкретно под твой сервис/сервисы

ERROR: S client not available

напиши роль которая только ставит апач и дефолтный конфиг валидный для всех, и отдельную роль/роли c конфигами и всем прочим конкретно под твой сервис/сервисы

+100500

напиши роль которая только ставит апач и дефолтный конфиг валидный для всех, и отдельную роль/роли c конфигами и всем прочим конкретно под твой сервис/сервисы

В отдельную папочку conf.d отдельными файлами. и править конфиг не придётся

Ну к этому и пришел. Придется править роль установки и ставить со своим дефолтным конфигом.

Можно посмотреть, как в Убунте устроено в апаче

@methodx будет жить. Поприветствуем!

https://github.com/ansible/ansible/issues/32556 Тут пишут что нельзя. Может проще вызвать роль в site.yml на localhost?

Решил через этот хак, если кому-то интересно https://medium.com/opsops/ansible-2-5-delegate-to-and-include-role-20cd7e67008e

Да, я так же переопредялял переменные в процессе сценария. Спасибо.

передаю модулю archive список каталогов некоторых каталогов иногда нет во время работы модуля есть ли красивый способ игнорировать отсутствие файлов?

Господа, а кто, что имеет сказать за handlers vs register? Когда handler-ы оправданы, а когда register? Общие соображения такие (дальше - полотенце, сори): - handler-ы шарятся между ролями, значит, что в случае конфликта имен, сделав nofity в одной роли, можно случайно дернуть handler другой роли, который делает не то, что мы ожидали - по-умолчанию, в случае нескольких сработавших handler-ов, если какой-то один падает, то все остальные не срабатывают - по-умолчанию, без force_handlers, если в одном таске вызвался notify на срабатывание handler-а, а следующий task свалился, то handler не сработает и это может привести к неконсистентному состоянию - при следующем проигрывании изменений не будет -и handler-ы уже не сработают - порядок вызова handler-ов гарантировать нельзя - по сути порядок определяется их порядком следования в файле, где они объявлены, а не порядком вызовов notify - если в play-е, при подключении ролей, одни роли опираются на другие роли и подключаются в определенном порядке, то роли, которые играются позже могут сфейлиться, т.к. таски от notify еще не сработали (они срабатывают в конце play-я) и получается, нужно знать какие handler-ы и в каких ролях живут (инкапсуляция страдает), чтоб разнести такие роли по разным play-ям. - meta: flush_handlers позволяет дернуть все handler-ы, но тогда вопрос, почему одна роль влияет на то, как работают другие роли? пользовалю, который проигрывает плейбук хочется детерминированного поведения и когда он видит, что вроде бы играется одна роль, а потом из-за flush_handlers начинают работать таски других ролей, которых в текущей проигрываемой роли никак быть не могло, то это введет в заблуждение. - в ansible можно играть плейбук пошагово начиная с какого-то таска - с тасками последовательность шагов будет такой, как объявлено в плейбуке и ролях, а в случае handler-ов - не понятно, какой будет порядок выполнения - на handler-ы не распространяется serial —- итого - кажется, что register + отдельный таск постабильнее и понадежнее будут

@vyablokov будет жить. Поприветствуем!

Господа, а кто, что имеет сказать за handlers vs register? Когда handler-ы оправданы, а когда register? Общие соображения такие (дальше - полотенце, сори): - handler-ы шарятся между ролями, значит, что в случае конфликта имен, сделав nofity в одной роли, можно случайно дернуть handler другой роли, который делает не то, что мы ожидали - по-умолчанию, в случае нескольких сработавших handler-ов, если какой-то один падает, то все остальные не срабатывают - по-умолчанию, без force_handlers, если в одном таске вызвался notify на срабатывание handler-а, а следующий task свалился, то handler не сработает и это может привести к неконсистентному состоянию - при следующем проигрывании изменений не будет -и handler-ы уже не сработают - порядок вызова handler-ов гарантировать нельзя - по сути порядок определяется их порядком следования в файле, где они объявлены, а не порядком вызовов notify - если в play-е, при подключении ролей, одни роли опираются на другие роли и подключаются в определенном порядке, то роли, которые играются позже могут сфейлиться, т.к. таски от notify еще не сработали (они срабатывают в конце play-я) и получается, нужно знать какие handler-ы и в каких ролях живут (инкапсуляция страдает), чтоб разнести такие роли по разным play-ям. - meta: flush_handlers позволяет дернуть все handler-ы, но тогда вопрос, почему одна роль влияет на то, как работают другие роли? пользовалю, который проигрывает плейбук хочется детерминированного поведения и когда он видит, что вроде бы играется одна роль, а потом из-за flush_handlers начинают работать таски других ролей, которых в текущей проигрываемой роли никак быть не могло, то это введет в заблуждение. - в ansible можно играть плейбук пошагово начиная с какого-то таска - с тасками последовательность шагов будет такой, как объявлено в плейбуке и ролях, а в случае handler-ов - не понятно, какой будет порядок выполнения - на handler-ы не распространяется serial —- итого - кажется, что register + отдельный таск постабильнее и понадежнее будут

Все становиться проще когда в 1 роль не впихивают все что только в голову пришло. Раздроби все по ролям, сделай их независимыми друг от друга

Пример: надо выкатить nginx, и бекенд к ниму в докере

У тебя будут роли: - установка и настройка докере - установка и настройка nginx - конфиги докер композов для бекенда - конфиги для апстримов nginx

Все роли не зависят друг от друга

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

Последнее конечно лучше примером кода показать но я с телефона (

Как правильно выстроить каталог для буков написано в доке ансибла. Гуглиться что-то типа ansible best practices inveronment

Или на вчерашнем докладе про ансибл было в презенташке

вопрос про handler-ы, а не про декомпозицию задач. когда handler-ы хорошо, а когда - плохо

Все становиться проще когда в 1 роль не впихивают все что только в голову пришло. Раздроби все по ролям, сделай их независимыми друг от друга

я думаю, что он про другое

Дак разные роли разные хендлеры они не пересекаются

Дак разные роли разные хендлеры они не пересекаются

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

Я использую в каждой роли свои хендлеры т.к. у меня роли не связаны друг с другом

Бывают ситуации когда флашить хендлеры нужно это факт

И если изменений в конфигах не будет то после падения и хендлеры не сработают

Я использую в каждой роли свои хендлеры т.к. у меня роли не связаны друг с другом

бывает так что у тебя таски связаны в одной роли и там гораздо проще логику на 1 действие делать с помощью регистри

Но это нужно учитывать при написании и обкатывать роли