Vladimir
ребят, как в инвентори класть ipv6 адреса?
Vladimir
не хочет съедать чот
Vladimir
быстрый гуглёж ничего не выдал внятного
Fire
Vladimir
хочу ip
Vladimir
а всё
Vladimir
в ' ' нужно брать
Anonymous
а есть у кого нибудь плейбук для того чтоб развернуть дженсинс? как там сделать чтоб он не просил этот пароль скопировать с файла и ввести в браузер)
tutunak
Дмитрий
Доброго вечера. Делаю создание ВМ в КВМ через ансибл. Подскажите как можно проверять через ансибл что ВМ готова принимать запросы? через модуль virt.command.status не вариант, потому что статус "running" не означает ВМ готова к принятию конфигурации. Попробовал через ping:
- name: ping
ping:
register: vm23_status
until: vm23_status.ping == 'pong'
retries: 10
delay: 5
но не работает, падает с ошибкой "Error reading SSH protocol banner" - препологаю что ВМ тупо не поднялась, но не понимаю почему не срабатывает retries
Подскажите какие еще есть варианты?
Отделение Bereke Bank
Доброго вечера. Делаю создание ВМ в КВМ через ансибл. Подскажите как можно проверять через ансибл что ВМ готова принимать запросы? через модуль virt.command.status не вариант, потому что статус "running" не означает ВМ готова к принятию конфигурации. Попробовал через ping:
- name: ping
ping:
register: vm23_status
until: vm23_status.ping == 'pong'
retries: 10
delay: 5
но не работает, падает с ошибкой "Error reading SSH protocol banner" - препологаю что ВМ тупо не поднялась, но не понимаю почему не срабатывает retries
Подскажите какие еще есть варианты?
В случае с клаудами я делал wait_for на адрес и SSH порт с тайм-аут 5 мин
Lamobot
Доброго вечера. Делаю создание ВМ в КВМ через ансибл. Подскажите как можно проверять через ансибл что ВМ готова принимать запросы? через модуль virt.command.status не вариант, потому что статус "running" не означает ВМ готова к принятию конфигурации. Попробовал через ping:
- name: ping
ping:
register: vm23_status
until: vm23_status.ping == 'pong'
retries: 10
delay: 5
но не работает, падает с ошибкой "Error reading SSH protocol banner" - препологаю что ВМ тупо не поднялась, но не понимаю почему не срабатывает retries
Подскажите какие еще есть варианты?
- name: "Check for restart"
wait_for:
host: '{{ (ansible_ssh_host|default(ansible_host))|default(inventory_hostname) }}'
state: started
search_regex: 'OpenSSH'
port: '{{ ansible_port|default(22) }}'
delay: 30
sleep: 15
timeout: 600
msg: "Couldn't connect to host with ssh after restart!!!"
vars:
ansible_connection: local
Отделение Bereke Bank
Попробуй так же
Дмитрий
спасибо, попробую
Дмитрий
@zh_erzh а в параметр "host:" как то можно хост из файла хостов передать? а то к нужному хосту доступ через бастион только(
Отделение Bereke Bank
Ты создаёшь вм. Твой модуль не возвращает ip созданной машины?
Отделение Bereke Bank
@zh_erzh а в параметр "host:" как то можно хост из файла хостов передать? а то к нужному хосту доступ через бастион только(
https://privatebin.net/?dab33fcd4f4f8181#8XSnf2HkjQ7SSR52Bu7TFVt4sBBgT3hwEumgtR8CynKy
Maksim
Андрей
Накачай себе готовых ролей из гэлакси и ломай инфру)
Mai
а можно как-то отпилить одно из значений в списке в зависимости отт другой переменной?
вот поднимаю редис, и есть два порт мапа для контейнера
- xxx:xxx
- yyy:yyy
хочется как-то если zzz установлена, то “- yyy:yyy” пропустить.
можно так?
Отделение Bereke Bank
Lamobot
а можно как-то отпилить одно из значений в списке в зависимости отт другой переменной?
вот поднимаю редис, и есть два порт мапа для контейнера
- xxx:xxx
- yyy:yyy
хочется как-то если zzz установлена, то “- yyy:yyy” пропустить.
можно так?
Если zzz никак не связана, то тяжело будет.
Использовать if и лимит по количеству записей в портах, к примеру.
Или сделать два списка, один с якорем
Mai
if в jinja темлейте понятно, а в плейбуках его тоже можно чтоли?
Mai
то еcть {% if…. %} мне подходит, но только вот можно ли его всунуть в середину плейбука/таски..
Lamobot
Можно, смотря где, правда
Lamobot
то еcть {% if…. %} мне подходит, но только вот можно ли его всунуть в середину плейбука/таски..
Там есть ещё {{ x if (condition) else y }}
Mai
ммм, ну-ка ну-ка…
Lamobot
то еcть {% if…. %} мне подходит, но только вот можно ли его всунуть в середину плейбука/таски..
Можно как-то так сделать:
published_ports: '{{ zzz | bool | ternary(ports_list, (ports_list|sort)[:-1] ) }}'
https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#defining-different-values-for-true-false-null-ternary
Mai
if пока больше подходит, но похоже нужно просто в начале большой set_fact запилить и от него плясать уже
Aleksey
ничо так
Vadim "Oxyd"
Timur
а есть у кого нибудь плейбук для того чтоб развернуть дженсинс? как там сделать чтоб он не просил этот пароль скопировать с файла и ввести в браузер)
https://galaxy.ansible.com/lean_delivery/jenkins
Артём
Добрый вечер. Может кто-нибудь подсказать, почему отсутствует возможность динамического include для плейбуков? Хочется сделать единый плей, который будет вызываться с тегами и подключать только нужные плеи в себе, но с import_playbook, очевидно, выполняются все.
Артём
Даже не так. С тегами лишнее не выполняется, но происходит проверка переменных, которые не определены.
С другой стороны, пара часов размышлений - и осозналось, что можно дать им дефолты, решив проблему.
Но в целом вопрос остался - почему целенаправленно не сделали возможности динамически линковать плейбуки?
Elenhil
А зачем вам единый плейбук?
Отделение Bereke Bank
Даже не так. С тегами лишнее не выполняется, но происходит проверка переменных, которые не определены.
С другой стороны, пара часов размышлений - и осозналось, что можно дать им дефолты, решив проблему.
Но в целом вопрос остался - почему целенаправленно не сделали возможности динамически линковать плейбуки?
Пожалели людей которым потом такое дебажить
Артём
А зачем вам единый плейбук?
Для деплоя пяти десятков микросервисов, например. Проще использовать теги, чем вызывать разные плейбуки.
Elenhil
Для деплоя пяти десятков микросервисов, например. Проще использовать теги, чем вызывать разные плейбуки.
Кому проще? Почему у вас разные поейбуки, а не разные роли это решают, опять же?
Elenhil
Если у вас 50 микросервисов, у вас все равно там автоматика, ей без разницы какой плейбук пускать
Артём
Если у вас 50 микросервисов, у вас все равно там автоматика, ей без разницы какой плейбук пускать
Теги позволяют как минимум использовать полное именование и сокращения, плейбуки - нужно будет всегда использовать одно имя. Не роли - потому что на полноценную роль этот yum install && curl healthcheck не тянет, казалось, что смысла выыносить нет.
А автоматики нет.
Ок, если оторваться от деплоя микросервисов, есть и другие варианты использования корневого моно-плейбука. Вот, например, кажется, участник чата описывает обходные пути: https://medium.com/opsops/import-playbook-with-play-level-condition-775122fe78ff
Я правильно понимаю, что ваш ответ сейчас - «этого нет, потому что случаи, когда это может понадобиться, являются ошибкой планирования архитектуры»?
checkdiff
Теги позволяют как минимум использовать полное именование и сокращения, плейбуки - нужно будет всегда использовать одно имя. Не роли - потому что на полноценную роль этот yum install && curl healthcheck не тянет, казалось, что смысла выыносить нет.
А автоматики нет.
Ок, если оторваться от деплоя микросервисов, есть и другие варианты использования корневого моно-плейбука. Вот, например, кажется, участник чата описывает обходные пути: https://medium.com/opsops/import-playbook-with-play-level-condition-775122fe78ff
Я правильно понимаю, что ваш ответ сейчас - «этого нет, потому что случаи, когда это может понадобиться, являются ошибкой планирования архитектуры»?
Да, этот пост от @amarao. Интересно, а сейчас, спустя два года, этот подход еще используется или уже отошли от него?
Мне на первый ночной выходной взгляд подход показался сложным.
Timur
Теги позволяют как минимум использовать полное именование и сокращения, плейбуки - нужно будет всегда использовать одно имя. Не роли - потому что на полноценную роль этот yum install && curl healthcheck не тянет, казалось, что смысла выыносить нет.
А автоматики нет.
Ок, если оторваться от деплоя микросервисов, есть и другие варианты использования корневого моно-плейбука. Вот, например, кажется, участник чата описывает обходные пути: https://medium.com/opsops/import-playbook-with-play-level-condition-775122fe78ff
Я правильно понимаю, что ваш ответ сейчас - «этого нет, потому что случаи, когда это может понадобиться, являются ошибкой планирования архитектуры»?
По описанию у вас просто одна роль с разными параметрами запуска. Зачем разные плейбуки линковать - ума не приложу
Артём
По описанию у вас просто одна роль с разными параметрами запуска. Зачем разные плейбуки линковать - ума не приложу
Потому что не осилил параметризовать вот такое
- name: Set installed this-service version
set_fact:
this_service_installed_version: "{{ ansible_facts.packages['this-service'][0].version }}-{{ ansible_facts.packages['this-service'][0].release }}"
Артём
Если бы this-service в данном случае получилось заменить на переменную, то всё бы схлопнулось в один параметризованный плейбук.
Timur
Потому что не осилил параметризовать вот такое
- name: Set installed this-service version
set_fact:
this_service_installed_version: "{{ ansible_facts.packages['this-service'][0].version }}-{{ ansible_facts.packages['this-service'][0].release }}"
А в чем, собственно, проблема? Не очень понял
Артём
Кажется, в невозможности вложенных переменных.
service'][0].version }}-{{ ansible_facts.packages[{{ this-service-variable}}][0].release }}"
Так же не взлетит?
Timur
Кажется, в невозможности вложенных переменных.
service'][0].version }}-{{ ansible_facts.packages[{{ this-service-variable}}][0].release }}"
Так же не взлетит?
Что-то подобное можно реализовать. Только все равно юзкейс непонятен. Зачем этот говнокод с ansible_facts?
Артём
Чтобы не выводить зазря из нагрузки сервис, если плейбук дёрнули, когда пакет уже установлен.
Timur
Артём
Вывод из нагрузки. Обновление. Хелсчек. Ввод в нагрузку.
Перед этим хочется вставить проверку, что версия пакета действительно изменится, и выйти, если нет.
Timur
А в чем проблема вывода из нагрузки после обновления пакета?
Артём
В трафике на сервис, который остановлен и обновляется.
Timur
Зачем останавливать трафик при обновлении пакета?
Timur
Пока не перезапустите сервис - все равно ничего не изменится по идее
Артём
Если бы все собирали свои rpm, как nginx - да, так и есть.
В случае, если сервис - статика, и в rpm’ке идёт удаление старых файлов и подкладка новых - оно сыплет 404.
Если в rpm вшит флаш опкэша - то и того хуже, пока кэш не прогреется хелсчеками.
Timur
Если бы все собирали свои rpm, как nginx - да, так и есть.
В случае, если сервис - статика, и в rpm’ке идёт удаление старых файлов и подкладка новых - оно сыплет 404.
Если в rpm вшит флаш опкэша - то и того хуже, пока кэш не прогреется хелсчеками.
Ну, ок. В чем проблема собрать факты пре-тасками и задать параметры, исходя из них?
Timur
Можно собрать версии пакетов, прочекать наличие обновлений и запускать нужную роль обновления лишь для совпадающих условий.
Артём
Пройтись по сотне машин и собрать с них все установленные пакеты, просто чтобы разложить их по переменным? Долго.
Timur
Пройтись по сотне машин и собрать с них все установленные пакеты, просто чтобы разложить их по переменным? Долго.
Кэширование фактов вам в помощь. Пакеты же сами собой не обновляются?
Timur
И при чем тут сотня машин? Вам все равно так или иначе придется это делать
Артём
Если плейбуки запускаются не с одного компьютера - то ставить redis под кэш фактов?
Идея была в том, чтобы сделать ansible-playbook deploy.yml -t service_a -t first_side, заинклудить только плейбук update_service_a.yml, получить с него текущие версии пакетов/конфигов и обновить при необходимости. Не трогая остальные 98 машин в их плейбуках, у которых не совпадает тег.
Timur
Если плейбуки запускаются не с одного компьютера - то ставить redis под кэш фактов?
Идея была в том, чтобы сделать ansible-playbook deploy.yml -t service_a -t first_side, заинклудить только плейбук update_service_a.yml, получить с него текущие версии пакетов/конфигов и обновить при необходимости. Не трогая остальные 98 машин в их плейбуках, у которых не совпадает тег.
Это все можно сделать одной плейбукой. Зачем там инклую плейбук - все равно не понимаю
Timur
Берете закэшированные факты. Проверяете версии нужных пакетов по списку. Сравниваете с фактами. Для тех инстансов, где есть изменение (т.е. требуется обновление), задаете нужную переменную и добавляете данный инстанс в соответствующую динамическую группу (с помощью add_host или group_by), в следующем плее на нужные группы делаете нужные изменения только на тех серверах, где это требуется, используя динамические группы и полученные факты. Все.
Артём
Про кэш ещё раз уточню - если деплоят разные операторы, нужно выделять редис под общий кэш?
Есть ещё несколько моментов, которые различаются - у некоторых сервисов нестандартные хелсчеки, некоторые - инстанциированные systemd, часть на go, часть на php, так что разный механизм рестарта.
Заход на единый плейбук я делал уже не раз, всё время получается монструозная конструкция на словарях.
citius
Кажется, в невозможности вложенных переменных.
service'][0].version }}-{{ ansible_facts.packages[{{ this-service-variable}}][0].release }}"
Так же не взлетит?
~ позволяет делать вложенные переменные. вполне реализуемо.
Артём
~ позволяет делать вложенные переменные. вполне реализуемо.
А можно линк на доку/пример? По тильде гуглить непросто
Timur
Про кэш ещё раз уточню - если деплоят разные операторы, нужно выделять редис под общий кэш?
Есть ещё несколько моментов, которые различаются - у некоторых сервисов нестандартные хелсчеки, некоторые - инстанциированные systemd, часть на go, часть на php, так что разный механизм рестарта.
Заход на единый плейбук я делал уже не раз, всё время получается монструозная конструкция на словарях.
Если у вас такая сложная структура проекта - вам ее в любом случае где-то придётся отразить. Или в говнокоде плейбука или в инвентаре. Логичнее и правильнее - в инвентаре, к чему я и пытаюсь вас склонить.
Артём
А по nested_variables что-то гуглится.
citius
А можно линк на доку/пример? По тильде гуглить непросто
s3cmd_access_key: "{{ lookup('vault', 'secret/'~project~'/s3/'~s3_user~'/pass', 'key_id') }}"
project и s3_user это переменные
Timur
s3cmd_access_key: "{{ lookup('vault', 'secret/'~project~'/s3/'~s3_user~'/pass', 'key_id') }}"
project и s3_user это переменные
Такое допустимо во вспомогательных переменных
Артём
s3cmd_access_key: "{{ lookup('vault', 'secret/'~project~'/s3/'~s3_user~'/pass', 'key_id') }}"
project и s3_user это переменные
Вот за это спасибо, потому что параметризовать путь к волту тоже нужно было.
citius
но я согласен принципиально с Тимуром
лучше вам пересмотреть подход
citius
мелкие роли это не проблема, почему бы и нет
или вы за кол-во репозиториев платите?
citius
зато логика будет сильно прозрачнее - и вам проще и коллегам
Артём
И Тимуру за направление в сторону идеального варианта тоже. В результате, как обычно, будет найден баланс между «переделать всё начисто через никогда» и «оставить полный срач и хаос».
Мы за количество репозиториев не платим, но и автоматизация деплоя для нас - не та задача, на которую выделяется время. Поэтому решается она вот в три часа ночи на сдачу.
Anonymous
❔у меня серваки из одной и той же группы, к примеру database, могут быть как на debian так и на centos. Как правильно юзать ansible в таком случае?
Александр