?

Миграция параметров сводится к перемещению/обновлению их между каталогами с инвентори. В этом случае у тебя _все_ ветки работают с одними и теми же параметрами. В моей практике это ок - намного чаще меняется содержание роли, чем параметры окружения.

Но может потребоваться несколько специфическая организация этих параметров.

Миграция параметров сводится к перемещению/обновлению их между каталогами с инвентори. В этом случае у тебя _все_ ветки работают с одними и теми же параметрами. В моей практике это ок - намного чаще меняется содержание роли, чем параметры окружения.

Ну вот тогда мы возвращаемся к соcтоянию где в одной ветке все окружения...

Ну вот тогда мы возвращаемся к соcтоянию где в одной ветке все окружения...

Не совсем. Ты же хочешь дев -> стейдж -> продакшн?

да

плюс тесты, а-ля dev-perf, dev-perf-vasya как вариант

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

@vrutkovs А как ты думал про управление изменениями параметров а-ля group_vars? Какой порядок действий?

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

Пока что представляю что миграция параметров это отдельный процесс...

и merge по определенным путям между dev/stg/prod не возможен

(типа inventory/* )

Не понятно как это. "все работают с одноми и теми же параметрами"

или речь идет про название параметра, но не его значение

или речь идет про название параметра, но не его значение

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

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

Да, понятное дело. Но как тогда значения мигрируются?

где они хранятся?

@vrutkovs А как ты думал про управление изменениями параметров а-ля group_vars? Какой порядок действий?

Хранить отдельно, например group_vars/group/dev.yaml

Хранить отдельно, например group_vars/group/dev.yaml

но этот путь ведь все равно подвержен тем же самым движениям по веткам? Мне не хочется чтобыоно было во всех ветках

но этот путь ведь все равно подвержен тем же самым движениям по веткам? Мне не хочется чтобыоно было во всех ветках

Боюсь, ты вводишь дополнительные сущности без необходимости.

Нет большого смысла переменные по веткам таскать.

хорошо, остановимся на следующей модели: roles/*, playbooks полностью переезжают по веткам. параметры окружения, инвентарь залочены в ветке (inventory/, group_vars, host_vars...)

так?

да, вполне. только в этой модели описанный выше вопрос с пином версий плоховато решается.

Как мне общий для ролей файл переменных сделать? Куда его засунуть?

Как мне общий для ролей файл переменных сделать? Куда его засунуть?

group_vars/all/<filename>.yml

group_vars/all/<filename>.yml

Уф, спасибо

Уф, спасибо

Только сразу предупреждаю, что это придётся это для каждого инвентори сделать.

Ну мне пока главное, что для всех ролей сразу

да, вполне. только в этой модели описанный выше вопрос с пином версий плоховато решается.

requirements.yml ведь тоже мигрируют?

requirements.yml ведь тоже мигрируют?

эммммм........... это про что именно? зависимости ролей?

эммммм........... это про что именно? зависимости ролей?

да, пин версий

я пин версий делал в group_vars/all/versions.yml. Тогда у тебя любая группа и любая роль знает, какая версия какого компонента должна быть.

Спасибо. Пойду думать мозгом

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

Светлых мыслей тебе ?

Светлых мыслей тебе ?

? спасибо

кто-то юзает? Давно не смотрел, раньше не было назначения ролей... https://theforeman.org/plugins/foreman_ansible/2.x/index.html

кто-то юзает? Давно не смотрел, раньше не было назначения ролей... https://theforeman.org/plugins/foreman_ansible/2.x/index.html

Не советую.

Не советую.

Почему?

Foreman сам по себе достаточно тяжёл в абстракциях. Он только усложнит простой подход ансибла

Боль переедет в другое место

Как получить списком ip адреса хостов из hosts?

Как получить списком ip адреса хостов из hosts?

- name: parsing /etc/hosts command: awk '!/(^#|^[ ]+?$)/ {print $1}' /etc/hosts register: etc_hosts_output - name: creating list from hosts set_fact: etc_hosts: "{{ etc_hosts_output.stdout.split('\n') }}"

странно, что в фактах такой информации нет об /etc/hosts

странно, что в фактах такой информации нет об /etc/hosts

Нее, сори, я имел ввиду из hosts.yml

Из инвентори файлика

три плети этому господину

какая прелесть

кто-то не получит квартальную премию..

ушла эпоха ансибла

лал

гы - пиздаватизм

Updated Date: 2017-11-16T16:12:16Z Creation Date: 1995-02-03T05:00:00Z Registry Expiry Date: 2022-02-04T05:00:00Z это видимо хостинг протух

Expiry Date: 2022 же

Updated Date: 2017-11-16T16:12:16Z Creation Date: 1995-02-03T05:00:00Z Registry Expiry Date: 2022-02-04T05:00:00Z это видимо хостинг протух

Не вопрос, а доки то где брать ?

в гугле :)

Не вопрос, а доки то где брать ?

https://github.com/jedelman8/ansible-webdocs

https://docs.ansible.com/

у меня работает. основной - нет

https://docs.ansible.com/

спасибо.

хехе, начал искать твиты по этому поводу, и первый что нашел от @vrutkovs 24 секунды назад ?

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

ну, надо сказать что какой-то индус 15 минут назад хайлайтнул @ansible в твитторе с этой проблемой https://twitter.com/sandipb/status/1037615758019162113

ERROR: S client not available

хехе, начал искать твиты по этому поводу, и первый что нашел от @vrutkovs 24 секунды назад ?

Ну короче, не так давно -), а то подумал - может закрыли проект ?

Так https://docs.ansible.com же работает.

Ну короче, не так давно -), а то подумал - может закрыли проект ?

don't panic ? выдерни шнур, выдави стекло ?

Если кто не знает, есть ansible-doc MODULE_NAME -s

На случай если https://docs.ansible.com перестанет работать

We are working through the Hubspot known issue of some webpages loading. http://Ansible.com is affected and we hope it will be resolved quickly.

Ребят, для вывода после исполнения плейбука вконце каких либо результирующих переменных есть какаятт отдельная функция или просто таск неоьхожимо писать?

debug

debug

Разве он для этого?

https://docs.ansible.com/ansible/2.6/modules/debug_module.html им можно все что угодно выводить

нужно в template подставлят не hostvars[m] - что является dict из всех возможных свойств хоста m нужно подставлять hostvars[m].inventory_hostname или где у вас там ойпишник сидит

в общем, не удалось ничего. конечный вид таски: - name: Adding target to prometheus server blockinfile: dest: "/etc/prometheus/prometheus.yml" insertafter: EOF backup: no marker: "#{{inventory_hostname}}" block: |2 - job_name: '{{inventory_hostname}}' static_configs: {%- for m in my_hosts %} - targets: ['{{ansible_ssh_host}}:9100'] {% endfor %} tags: - playhosts получаю в файлике: #secret-hostname - job_name: 'secret-hostname' static_configs: - targets: ['1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.10:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] То есть оно зачем-то мне несколько подставляет, хотя в группе вообще 1 хост

3 дня бьюсь уже

не расстраивайтесь, все получится

Берёшь шаблоны и никакого геморроя

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

в общем, не удалось ничего. конечный вид таски: - name: Adding target to prometheus server blockinfile: dest: "/etc/prometheus/prometheus.yml" insertafter: EOF backup: no marker: "#{{inventory_hostname}}" block: |2 - job_name: '{{inventory_hostname}}' static_configs: {%- for m in my_hosts %} - targets: ['{{ansible_ssh_host}}:9100'] {% endfor %} tags: - playhosts получаю в файлике: #secret-hostname - job_name: 'secret-hostname' static_configs: - targets: ['1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.10:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] То есть оно зачем-то мне несколько подставляет, хотя в группе вообще 1 хост

https://github.com/kwoodson/ansible-role-yedit

за использование blockinfile и lineinfile больше двух раз надо милицию вызывать

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

Что-то что определяет, запущена ли служба

Что-то что определяет, запущена ли служба

ты гений

в общем, не удалось ничего. конечный вид таски: - name: Adding target to prometheus server blockinfile: dest: "/etc/prometheus/prometheus.yml" insertafter: EOF backup: no marker: "#{{inventory_hostname}}" block: |2 - job_name: '{{inventory_hostname}}' static_configs: {%- for m in my_hosts %} - targets: ['{{ansible_ssh_host}}:9100'] {% endfor %} tags: - playhosts получаю в файлике: #secret-hostname - job_name: 'secret-hostname' static_configs: - targets: ['1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.10:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] То есть оно зачем-то мне несколько подставляет, хотя в группе вообще 1 хост

выложите на pastebin оригинальный prometheus.yml, и содержимое переменной my_hosts, и рядом положите тот результат который вы хотите получить в конце я за вас напишу таску, а вы получите зарплату

prometheus.yml https://pastebin.com/ZWRxzAEn cодержимое переменной my_hosts после запуска этого таска - https://pastebin.com/Lyy6q5SX - айпишник хоста из группы. В группе один хост. В конце хочу получить вот это: https://pastebin.com/8e1mwcJc ————————————————— Прошу прощения, но я бы решил эту задачу на руби за 3 минуты. Но просто хочу следовать канонам ансибла, и не пихать модули шелла. Это ещё хуже чем blockinfile использовать. Я не получу никакой зарплаты за это. Это задание - чисто для себя, если хотите - просто интересно, изучаю ансибл. Если вы позволите, я искренне готов отблагодарить вас за помощь как-нибудь материально, на пиво, например)

prometheus.yml https://pastebin.com/ZWRxzAEn cодержимое переменной my_hosts после запуска этого таска - https://pastebin.com/Lyy6q5SX - айпишник хоста из группы. В группе один хост. В конце хочу получить вот это: https://pastebin.com/8e1mwcJc ————————————————— Прошу прощения, но я бы решил эту задачу на руби за 3 минуты. Но просто хочу следовать канонам ансибла, и не пихать модули шелла. Это ещё хуже чем blockinfile использовать. Я не получу никакой зарплаты за это. Это задание - чисто для себя, если хотите - просто интересно, изучаю ансибл. Если вы позволите, я искренне готов отблагодарить вас за помощь как-нибудь материально, на пиво, например)

плейбука: --- - hosts: all gather_facts: false vars: replace_to: "" tasks: - name: set set_fact: replace_to: "- targets: ['{{ item }}:9100']\n {{ replace_to }}" with_items: "{{ play_hosts | map('extract', hostvars, 'ansible_ssh_host') | list }} " delegate_to: localhost - name: debug debug: var: replace_to delegate_to: localhost - name: replace replace: path: ./source.yml regexp: "- targets:.*" replace: "{{ replace_to }}" delegate_to: localhost run_once: true инвентори: all: hosts: a: ansible_ssh_host: "1.1.1.1" b: ansible_ssh_host: "2.2.2.2" c: ansible_ssh_host: "3.3.3.3" test-group: hosts: a: b: c:

кривовато немного, но я надеюсь никто вникать не будет и не заметит :3

мммм, регэкспы

на выходе получилось такое #some-domain-name - job_name: 'some-domain-name' static_configs: - target: ['1.1.1.1:9100'] - target: ['2.2.2.2:9100'] - target: ['3.3.3.3:9100']

хотя, этот жи yaml, можно его залоадить, сделать |from_yaml, поправить структуру targets, и заново сдампить

в общем, не удалось ничего. конечный вид таски: - name: Adding target to prometheus server blockinfile: dest: "/etc/prometheus/prometheus.yml" insertafter: EOF backup: no marker: "#{{inventory_hostname}}" block: |2 - job_name: '{{inventory_hostname}}' static_configs: {%- for m in my_hosts %} - targets: ['{{ansible_ssh_host}}:9100'] {% endfor %} tags: - playhosts получаю в файлике: #secret-hostname - job_name: 'secret-hostname' static_configs: - targets: ['1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.10:9100'] - targets: [''1.1.1.1:9100'] - targets: [''1.1.1.1:9100'] То есть оно зачем-то мне несколько подставляет, хотя в группе вообще 1 хост

но зачем static_configs? есть же file service discovery, его можно шаблонизировать без танцев с blockinfile

хотя, этот жи yaml, можно его залоадить, сделать |from_yaml, поправить структуру targets, и заново сдампить

как-то так: - name: include include_vars: file: prometheus.yaml name: prometheus delegate_to: localhost run_once: true - name: replace set_fact: msg: "{{ prometheus.test[item|int].static_configs}}" with_sequence: start=0 end={{ prometheus.test|length|int - 1}} delegate_to: localhost run_once: true

печально конечно выходит

плейбука: --- - hosts: all gather_facts: false vars: replace_to: "" tasks: - name: set set_fact: replace_to: "- targets: ['{{ item }}:9100']\n {{ replace_to }}" with_items: "{{ play_hosts | map('extract', hostvars, 'ansible_ssh_host') | list }} " delegate_to: localhost - name: debug debug: var: replace_to delegate_to: localhost - name: replace replace: path: ./source.yml regexp: "- targets:.*" replace: "{{ replace_to }}" delegate_to: localhost run_once: true инвентори: all: hosts: a: ansible_ssh_host: "1.1.1.1" b: ansible_ssh_host: "2.2.2.2" c: ansible_ssh_host: "3.3.3.3" test-group: hosts: a: b: c:

Спасибо за наводку. Оно мне поменяло все существующие targets на продакшене лол. Сейчас попытаюсь скомбинировать

то есть заменило айпишник во всех targets на айпишник хоста из тестовой группы