LINUX.ORG.RU

Ansible 2.8 «How Many More Times»

 ,


0

3

16 мая 2019 года вышла новая версия системы управления конфигурациями Ansible.

Главные изменения:

  • Экспериментальная поддержка коллекций Ansible и пространства имен контента. Теперь контент Ansible можно упаковать в коллекцию и адресовать через пространства имен. Это позволяет упростить совместное использование, распространение и установку связанных модулей/ролей/плагинов, т.е. согласованы правила доступа к конкретному контенту через пространства имен.
  • Обнаружение интерпретатора Python — при первом запуске модуля Python на цели Ansible попытается найти правильный интерпретатор Python по умолчанию, который будет использоваться для целевой платформы (по умолчанию /usr/bin/python). Можно изменить это поведение, установив ansible_python_interpreter или через config.
  • Устаревшие аргументы CLI --sudo, --sudo-user, --ask-sudo-pass, -su, --su-user и --ask-su-pass были удалены, вместо них нужно использовать --become, --become-user, --become-method и --ask-become-pass.
  • функция become была перенесена в архитектуру плагинов и стала настраиваемее.

Также большое кол-во небольших изменений, к примеру экспериментальная поддержка транспорта ssh для windows (теперь не нужно на windows настраивать winrm, а достаточно использовать встроенный в Windows 10 openssh).

>>> CHANGELOG

★★★★★

Проверено: jollheef ()

Готовьтесь переименовывать свои группы, если в них есть символы отличные [a-zA-Z0-9_]. Например, "-". Видимо это из-за пространства имён. Но в чейнджлогах ничего такого не нашёл, когда вчера читал.

pod ★★ ()
Ответ на: комментарий от slamd64

Вроде бы оно и нужно. А вроде бы и паппета хватает.

Тут все просто, например как с git, зачем что то еще если есть git .

Так с и ансаблем (про сервера и прочие кибернаты я просто молчу), виндовс из коробки пожалуйста, какие нибудь нет-раутеры (ssh+python) пожалуйста ну и т.д., зачем плодить сущности ?

mx__ ★★★★★ ()

Так-то вещь нормальная, вот только плейбуки эти ужасно смотрятся имхо, т.к. подход дурацкий: переизобретение всех команд в виде yaml. А уж если какие-то условные операции становится надо выполнить... Накрутили бы идемпотентные макросы на шелл какие-нить, было бы как-то попроще, по-моему.

vitalif ★★★★ ()
Ответ на: комментарий от anonymous

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

Хммм...

А это такое авторитетное мнение - оно к чему? К юзабилити? Или к языку напейсания? Или ещё к чему?

Поработав (и немало) и с тем, и с другим, я бы сказал пофиг на чем писать.

Разница, я бы сказал, в назначении:

ансибл хорош там, где надо выполнить какую-то _разовую_ задачу (напимер, создать новую пустую БД).

паппет хорош там, где надо выполнить какую-то _регулярную_ задачу (например, отслеживать состояние какого-то конфига).

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

В остальном они очень похожи. Лично мне уже давно до лампочки на чем писать.

slamd64 ★★★★★ ()
Последнее исправление: slamd64 (всего исправлений: 1)
Ответ на: комментарий от slamd64

Это совсем разные вещи одно для поддержания в актуальном состояние другое для развертывания. Никто не запрещает использовать и наоборот. Почему вы cfengine не уважаете и не используете?

anonymous ()
Ответ на: комментарий от anonymous

А инфраструктуру на каком-нибудь AWS тоже через NixOS провизионить?

Так и делаем :)

А за циски пока не скажу, но наверняка тоже можно.

А так – да пусть кто что хочет, то и использует!

balsoft ()
Ответ на: комментарий от slamd64

паппет хорош там, где надо выполнить какую-то _регулярную_ задачу (например, отслеживать состояние какого-то конфига).

Не очень понял. Регулярность это что про запуск что ли ?

mx__ ★★★★★ ()
Ответ на: комментарий от ncrmnt

Про chef я мало чего знаю, не доводилось с ним работать.

А в остальном, зависит от задачи.

Если это надо сделать 1 раз (типа «привезти и забыть»), то можно и ансиблом.

А вот если это какой-то долгоиграющий проект, подразумевающий саппорт и развитие, то я бы паппетом сделал. Очевидно же, что понадобится какие-то изменения вносить. И это гораздо проще сделать, скажем, в хиере (и оно автоматом приедет со следующим запуском паппет агента). Чем делать в ансибловом vault и потом плейбук запускать.

Но, в общем, на вкус и цвет все фломастеры разные.

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

slamd64 ★★★★★ ()
Последнее исправление: slamd64 (всего исправлений: 1)
Ответ на: комментарий от slamd64

Собственно, задачи сравнительно простые:

- Создать контейнер с установкой/настройкой пачки веб-служб и прикладного ПО, и в случае изменений кукбука донастройки

- Обновлять его регулярно (Кстати как лучше? Пересоздавать и мигрировать данные, или писать рецепты для обновления? Часть ПО обновляется не пакетным менеджером системы, а через pip/npm. Так как один из компонентов - iredmail, ручные обновления дико бесят и есть мысль тупо пересоздавать контейнер с ним, запуская процедуру установки с тем же конфиг-файлом, а потом донастраивать и подсоввывать данные из предыдущего инстанса)

Ну и соответственно отдельной задачей стоит кастомизация минимальной корневой фс для эмбеддед нужн под конкретную задачу перед упаковкой в образ SD карточки. К chef-solo я для этого как раз и присматривался.

ncrmnt ★★★★★ ()
Последнее исправление: ncrmnt (всего исправлений: 2)
Ответ на: комментарий от mx__

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

anonymous ()