Gleb
спорноватое утверждение ;)
самый простой пример:
есть группы хостов, пускай будут all, db, front, back, bastion
есть юзеры, которые тоже делятся на условные группы: admins, developers, dba
простецкая и очевидная задача: размещать (включая AllowUsers в sshd_config) юзеров так:
- admins: all
- developers: [front, back]
- dba: db
- all users: bastion
то есть нужна некоторая роль, которая соберёт всех юзеров из релевантных для хоста групп, создаст их и добавит в sshd_config
но тут вам не шеф - массивы/хеши на конверже не мержатся
какие тут бескостыльные варианты?
не делать такую дичь как выше написано, ансибл это не система для управления юзерами
Sergey
спорноватое утверждение ;)
самый простой пример:
есть группы хостов, пускай будут all, db, front, back, bastion
есть юзеры, которые тоже делятся на условные группы: admins, developers, dba
простецкая и очевидная задача: размещать (включая AllowUsers в sshd_config) юзеров так:
- admins: all
- developers: [front, back]
- dba: db
- all users: bastion
то есть нужна некоторая роль, которая соберёт всех юзеров из релевантных для хоста групп, создаст их и добавит в sshd_config
но тут вам не шеф - массивы/хеши на конверже не мержатся
какие тут бескостыльные варианты?
Удерживать себя от странного и использовать централизованное управление пользователями (LDAP/FreeIPA/AD).
Sergey
Vladimir
Ясн
Gleb
плейбук почему нет? он же всего лишь набор ролей
Sergey
Ну и сам концепт - отстой, потому что нет идемпотентности как класса.
Sergey
Ты хочешь кодить - кодь, вот причём тут Ансибл?
Vladimir
Ну, да. Я понял, что логику надо передумать
Vladimir
Vladimir
В конце концов, переменную со списком пакетов можно переопределить
Maxim
переопределить не подходит - хост-специфик останутся, а общие затрутся
Vladimir
Дак это
Vladimir
подготовь 2 плейбука
Vladimir
Один на провиженинг голого сервера
Vladimir
Второй на настройку специфика
Gleb
Maxim
почему плохая?
Maxim
я без подвоха, если что
Maxim
уже неоднократно слышу ответы вида "ансибл не для ххх", и уже не очень понимаю, для чего же он
Sergey
Gleb
почему плохая?
на сотнях хостов все очень медленно будет ну и в целом собирать хосты в кучу я бы не стал, группами всегда проще оперировать
Vladimir
Да не плохая, просто, почему бы не разделить настройку сервера на два этапа?
Первоначальная настройка (один плейбук), и настройка под конкретную задачу (второй плейбук)
Vladimir
У тебя же гибкость тогда образуется
Vladimir
Ладно. Я нуб, советовать не буду
Sergey
Sebor▂▅▇█▓▒░
Vladimir
Sergey
Tadeusz
Maxim
Tadeusz
так в salt шел бы лучше :)
Vladimir
Maxim
ок, давайте я попробую по-другому спросить
в шефе можно завести списки с одинаковым именем для хоста, роли (группы хостов) и кукбука (нечто среднее между ролью и плейбуком в ансибле)
при запуске шеф-клиента на конкретном хосте все эти списки помержатся в один и в кукбуке ты оперируешь уже "полным" списком для этого хоста
то есть условно в роли all я делаю массив packages = [tmux], в роли db - packages = [mysql, libmysqlclient], в описании хоста db01 - входящего в роль db - packages = [emacs]
и на фазе запуска шеф-клиента на db01 мне доступна переменная packages, содержащая [emacs, libmysqlclient, mysql, tmux]
и я могу сделать в кукбуке что-то вроде:
package packages do
action :install
end
таким образом я имею один кукбук для установки всех нужных пакетов, не размазывая это на много ролей/плейбуков
как это принято решать в ансибле?
Sergey
ок, давайте я попробую по-другому спросить
в шефе можно завести списки с одинаковым именем для хоста, роли (группы хостов) и кукбука (нечто среднее между ролью и плейбуком в ансибле)
при запуске шеф-клиента на конкретном хосте все эти списки помержатся в один и в кукбуке ты оперируешь уже "полным" списком для этого хоста
то есть условно в роли all я делаю массив packages = [tmux], в роли db - packages = [mysql, libmysqlclient], в описании хоста db01 - входящего в роль db - packages = [emacs]
и на фазе запуска шеф-клиента на db01 мне доступна переменная packages, содержащая [emacs, libmysqlclient, mysql, tmux]
и я могу сделать в кукбуке что-то вроде:
package packages do
action :install
end
таким образом я имею один кукбук для установки всех нужных пакетов, не размазывая это на много ролей/плейбуков
как это принято решать в ансибле?
У каждой роли - свой список пакетов. Нужные роли назначаются на группу хостов в конкретном play.
Maxim
ну то есть у меня будет набор ролей, в каждой из них будет что-то вроде tasks/install_packages.yml, в котором будет набор инструкций вида - package: "name=NAME"
Maxim
и никак в каком-то одном месте этими списками рулить "не положено"
Sergey
Maxim
define компонент :)
Sergey
define компонент :)
Если ты покащенитствовать хочешь - сразу предупреждаю, лучше не надо.
У тебя архитектор есть? Вот у него спроси, из каких компонентов состоит технологическая архитектура проекта.
Sergey
Верхнеуровневый блок, в общем.
Maxim
я же сразу написал
Maxim
я без подвоха, если что
Sergey
Вот для трёхзвенки типовой компоненты: веб-сервер, БД, сервер приложений.
Maxim
ну то есть я просто не понимаю, можно ли обойтись без многочисленной копипасты, и что делать с зависящими от "внешних условий" компонентами (типа sshd_config)
Sergey
Sergey
Maxim
вместо sshd_config можно подставить правила файрвола, например, ну в общем много можно придумать вариантов, когда надо управлять чем-то, что состоит/зависит от окружающих сущностей
Sergey
Maxim
?
Maxim
так а в чём параметризация?
Sergey
Maxim
ну то есть "параметризованные роли" - это что?
Maxim
или как это "в оригинале" называется, чтобы по-русски не гуглить? ;)
Sergey
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-roles
Maxim
спасибо, пойду читать
977
Коллеги как это упростить?
Michael
😐 записать в одну строку?
977
Нужно уменьшить кол во строк
977
Но чтобы работало
Michael
977
Csw это нужно?
Logan
а я ведь шутил про фото с экрана...
Logan
мои глаза
977
[Cisco:vars] для чего нужно?