Ждун
-vvvv
Timur
-vvvvv
Timur
В командной строке при запуске
Ждун
ну у тебя уже слишком детализировано :D
Timur
Ну, человек сам хочет все подробности
Павел П.
Тот же модуль user не может в name принять {{new_user_name}} из - - extra-vars "new_user_name=some_user" т.к. в экстра_варс могут лишь немногие модули а не все.
Подскажите плиз, как такое поведение обычно обходится?
Павел П.
ансибл свежий, 2.7
Womchik
Павел П.
https://docs.ansible.com/ansible/latest/modules/user_module.html#parameters
name
required
Name of the user to create, remove or modify.
aliases: user
Timur
Timur
Что именно не получается сделать?
Павел П.
создать на сервере нового линуксового юзера с именем, переданным через extra-vars
Womchik
Павел П.
сам плейбук roles/ssh-user/tasks/main.yml:
- name: Add new_user_name to my group
user:
password={{encrypted_user_password.stdout}}
name={{new_user_name}}
groups=my_group
append=yes
state=present
createhome=yes
expires=ansible_date_time.epoch + 86400
register: user_created
Ошибка:
ERROR! this task 'user' has extra params, which is only allowed in the following modules: shell, win_shell, include_vars, add_host, raw, include_role, meta, set_fact, include, import_tasks, script, import_role, include_tasks, group_by, command, win_command
Womchik
name:
append:
Womchik
в такой форме не = должно быть в плейбуке
Павел П.
и правда. Посыпаю голову пеплом, вечер а голове. Спасибо!
Vadim
Подскажите, пожалуйста, не понимаю синтаксис. Вот есть такая таска:
- name: Install docker
hosts: build
roles:
- { role: "nickjj.docker", tags: ["docker"] }
- docker
- build
become: yes
Что такое { role: "nickjj.docker", tags: ["docker"] }? У меня такая роль не определена, нет директории nickjj.docker в roles. Откуда это берется? И что за теги?
Tadeusz
тэги крутая штука, без них энсибл не энсибл
Vladislav 👻
вот прям чувствую, что логику под тег закладывали не ту, которая работает
Vladislav 👻
я подозреваю, что хотели запустить ту самую сферичную роль только по тегу docker
Sergey
Да.
Vladislav 👻
не подразумевая, что этот тег все равно надо указывать при запуске
Sergey
Только это не таска, а целый плей, ибо hosts и roles.
Vladislav 👻
вот именно
Sergey
Vladislav 👻
т.е. запусти плейбук и забудь тег - пошла вся роль работать
Sergey
т.е. запусти плейбук и забудь тег - пошла вся роль работать
Ну голову же такой запускатель как-то не забыл?...
Vladislav 👻
мне кажется созатель роли скорее забыл, либо автор как-то не правильно использует
Vladislav 👻
к сожалению, логика тегов в ансибле - это лимитирование, а не логическое управление
Vladislav 👻
а следовательно делать из жирафа слона не стоит...
Timur
Их либо через мету нужно указывать как депенденси либо вручную через ansible-galaxy выкачивать
Vadim
а можно в galaxy посмотреть исходники этих ролей? Я вот вижу, что в репе galaxy 'nickjj.docker' есть несколько тегов. А где посмотреть содержимое этих ролей?
Sergey
Это не теги git.
Sergey
Если что.
Vadim
да, я понимаю. но
Vadim
эти теги, очевидно, ссылаются на разные роли. нет? хочется понимать, в чем различие между тем, что скрывается под этими тегами
Vadim
я просто не знаю, как это в ансибле работает
Timur
Timur
~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles
Timur
Все эти пути пустые?
Timur
Ну вот там и смотрите
Vadim
Ну вот там и смотрите
вот открываю директрию tasks, там лежит main.yml, в нем перечислены некие таски. raw конфиг такой, но как происходит разделение по тегам? то есть где та логика, котора говорит: "если тег X, выолняй Y"
Denis 災 nobody
смотри слова tag:
Stanislav
спасибо
Тэги включают или выключают таски в ansible. По дефолту выполняются все таски со всеми тэгами, однако можно выполнить только определенные таски, тэгированные тэгом либо исключить некоторые таски из выполнения.
Stanislav
Господа, использует кто-нибудь, ci/cd пайпланы для тестирования и применения ролей к инфраструктуре?
Timur
Господа, использует кто-нибудь, ci/cd пайпланы для тестирования и применения ролей к инфраструктуре?
Да. В чем конкретно вопрос?
Stanislav
Да. В чем конкретно вопрос?
В организации хранения и разработки кода в git. Пока что придумал следующую схему. Отдельно хранятся проекты ролей , отдельно проекты в которых описан инвентарь и групповые переменные, а также тесты. Однако, это порождает очень много изменений проектов инвентарей при изменении ролей. Возможно, существует альтернативный подход?
Timur
В организации хранения и разработки кода в git. Пока что придумал следующую схему. Отдельно хранятся проекты ролей , отдельно проекты в которых описан инвентарь и групповые переменные, а также тесты. Однако, это порождает очень много изменений проектов инвентарей при изменении ролей. Возможно, существует альтернативный подход?
Не очень понятна суть проблемы, если честно
Timur
В чем именно трудность - можете детальнее раскрыть?
Stanislav
В чем именно трудность - можете детальнее раскрыть?
Могу, дайте 10-15 минут, доберусь до компа
Timur
Время пошло 😏
Nklya
Отдельно хранится каждая роль и в этой же репе тесты.
Это стандартный воркфлоу, зачем изобретать велосипеды?
Timur
У нас роли тестируются молекулой
Timur
Для каждой роли написан ряд сценариев с различными параметрами и видами окружения
Timur
Которые прогоняются при каждом коммите
Timur
Вполне рабочим вариантом является монорепа, где в одном репозитории сразу хранятся плейбуки, набор ролей и различные инвентари с наборами переменных
Timur
Вот тут пара хороших примеров приведена даже:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#directory-layout
Stanislav
У нас роли тестируются молекулой
добрался до компа. У нас так же.
Есть инфраструктура, которая представляет собой по сути несколько типов серверов. А это в свою очередь набор ролей, применненых с определенными переменными к этим хостам.
Тестирование должно быть для каждой роли, а также, для уникального сочетания ролей, которые применяются на конечные хосты. Т.е роли + молекула это "юнит тестирование", а когда они собираются вместе (requirements.yaml), тогда происходит тестирование, что изменения одной роли не повлияли на другую и все сервисы, запущенные на сервере выполяются ожидаемым образом. Это делается с помощью vagrant + testinfra. Если эти тесты завершаются успешно, то происходит деплой на боевые тачки.
Stanislav
В этой схеме хорошо, что в любой момент можно посмотреть какой набор ролей на какой группе хостов + есть интеграционные тесты. Однако, поскольку есть проект (инвентарь), который зависит от набора ролей, то изменение ролей влечет изменение инвентаря (не всегда). Когда типов серверов (проектов инвентарей) много, то изменения приходится вносить в большое количество проектов. Это минус такого подхода.
Stanislav
@tgadiev А как в варианте с монорепой управлять версией ролей? или тестировать надо сразу все кейсы для всей инфраструктуры для каждого коммита (всегда последняя версия роли)? Тогда это может быть проблемой по времени, тесты не завершатся за удобоваримый промежуток времени. Деплоить тогда тоже надо на всю инфраструктуру, чтобы обеспечить протестированный код на инфраструктуре. Деплоить тогда становится тоже долго, а если использовать канареечные развертывания, то еще дольше.
Stanislav
Вобщем, столкнулся с такой проблемой. Любой вариант, который получается придумать или прочитать чреват одними или другими минусами, чем то приходится жертвовать. А разработчиков ролей мало, хочется жизнь упростить не жертвуя качеством ))
George
Тебе и так, и так тулинг для сборки и тестов писать
George
Stanislav
А в чем проблема с монорепой ?
Ну с ходу вижу следующее:
1. Не контроллируем, какая версия роли применилась на хосты (а фиксация на версии роли важна, чтобы новый код не поломал существующую функциональность)
2. Нет возможности проверить интеграцию ролей между собой
3. Должны тестировать и раскатывать всю инфраструктуру, которая в монорепе, при каждом коммите, иначе получается, что изменения существуют в репозитории, но их нет на хостах (что ломает концепцию cd). Однако тестирование и раскатка занимает очень много времени и влечет много изменений в инфраструктуре при каждом комите.
4. Сложно сделать трассировку, какая роль к какому хосту применена в конкретный момент времени.
5. Изменения сложно мержить, сложнее, чем в отдельных проектах.
Timur
Ну с ходу вижу следующее:
1. Не контроллируем, какая версия роли применилась на хосты (а фиксация на версии роли важна, чтобы новый код не поломал существующую функциональность)
2. Нет возможности проверить интеграцию ролей между собой
3. Должны тестировать и раскатывать всю инфраструктуру, которая в монорепе, при каждом коммите, иначе получается, что изменения существуют в репозитории, но их нет на хостах (что ломает концепцию cd). Однако тестирование и раскатка занимает очень много времени и влечет много изменений в инфраструктуре при каждом комите.
4. Сложно сделать трассировку, какая роль к какому хосту применена в конкретный момент времени.
5. Изменения сложно мержить, сложнее, чем в отдельных проектах.
Почему много времени занимает деплой? Тестов так много или ролей последовательных?
George
Например, с монорепой удобнее делать связанные роли, т.к. между ними не возникнет конфликтов
George
Почему много времени занимает деплой? Тестов так много или ролей последовательных?
Нужен тулинг, который будет только изменения тестировать
Это типикал проблема монореп.
Timur
Монорепа удобна, если все роли и плейбуки в ней принадлежат одному проекту и деплой происходит на ограниченное количество энвов