Система управления Ansible

[clickfreak]

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

Ansible был выбран изначально и про миграцию, слава богу, думать не пришлось.

[spacediver]

Сколько процентов конфигурационных задач покрываете этой системой? Какой объем, возраст кодовой базы? С чем столкнулись при росте кодовой базы? Чокак рефакторинг? :)

Спасибо за статью, пишите еще! :)

[clickfreak]

Ansible пока используется только в управлении инфраструктурой распределённых NS-серверов и покрывает все задачи конфигурирования (частичное использование было бы странно), кроме одной. Исключением является управление анонсированием префиксов (BGP), которое производится вручную для каждого узла, очень уж аккуратно нужно это делать (сами BGP-сессии поднимаются Ansible'ом). Объем кодовой базы не такой уж большой и разрастаться пока особо не собирается. Небольшой рефакторинг плэйбуков был при упрощении синтаксиса плэйбуков в одной из версий. А работать с Ansible начал примерно в апреле этого года.

[spacediver]

А, ну и вопрос вечера (почему я собственно принялся гуглить «selectel chef» и нашел эту статью): есть ли плагин для провизионировния ваших виртуалок?

Ради чего все ;)

[clickfreak]

Плагина пока нет. Но мы подумаем над этим :)

[Dyr]

Ну спрошу и у вас — как с поддержкой FreeBSD?

[akme]

fbsdmon.org/ports/python/ansible
blather.michaelwlucas.com/archives/1692
www.freshports.org/sysutils/ansible/

[clickfreak]

Если честно — не пробовали. Но, судя по исходному коду, как минимум начальная поддержка есть (определение оборудование, ZFS, pkgng, группы, пользователи, sysctl, сервисы). Кстати, там же обнаружил поддержку NetBSD, OpenBSD, HP-UX, AIX и горстку Solaris'ов (сам Solaris и производные от OpenSolaris'a), но без практического опыта утверждать что Ansible действительно хорошо работает на этих системах я не возьмусь.

[kay]

Не нашел значительных преимуществ Ansible по сравнению с Puppet кроме как «на управляемые узлы не нужно устанавливать никакого дополнительного ПО, всё работает через SSH». Остальные преимущества имхо высосаны из пальца.

[kay]

Да работал, он меня вполне устраивает. В сутки, полагаю, до 50 коммитов в свою конфигурацию провожу. К сожалению не использовал ни Chef, ни Ansible, поэтому мне сложно сравнивать.

[erthad]

Не сложный же он для простых вещей. Но очень хреново расширяемый.

[clickfreak]

Убедить Вас что Ansible лучше у меня вряд ли получиться, могу лишь добавить следующее:

Puppet, за 8 лет существования оброс солидным количеством документации, howto, модулями и примерами конфигураций на все случаи жизни, но вот почему-то когда с ним работаешь складывается впечатление что тебе приходится общаться с монстром, наверное поэтому этих howto так много. И да, лишние зависимости, в числе которых Ruby…

— за ~1.5 года существования Ansible (а стабильную версию зарелизили только около 8 месяцев назад) статей появилось не так много, но их достаточно чтобы системному администратору описать простым и лаконичным языком то что он делал до этого в консоли не задумываясь о программистских абстракциях.

Немного о прошлом основного разработчика Ansible и по-совместительству CTO AnsibleWorks Michael DeHaan:
— Автор и бывший лидер Cobbler (3 года)
— бывший продакт менеджер Puppet…

Видать что-то его не устроило в существующих инструментах и он решил сделать ещё один с учётом предыдущих ошибок. И Ansible у него пока получается просто конфектой.

[kay]

С Ruby согласен на 100% =) Но к счастью не так часто приходится на Ruby темплейты писать.

[pavelsh]

Хорошо бы, чтобы из конфеКТы что-то приличное вышло ;)

Если серьезно — думаю что не устроило его то, что не он владелец puppet и он решил придумать что-то свое с «карточными играми и неприличными девушками».

Посмотрим, во что превратиться Ansible с течением времени.

[erthad]

* Он намного проще, чем Puppet (в т.ч. благодаря гибкости)
* Модули на все или почти все случаи жизни из коробки (в паппете аналог этому — ресурсы)
* Которых нет — очень просто дописываются (сравнимо с LWRP шефа, а может и проще) и на любом языке, хоть на awk.
* Практически не вытягивает зависимостей в т.ч. для управляющей части (не помню как у puppet с этим)
* Нет гемора с сертификатами
* Нет гемора с hiera
* Инвентарь проще (впрочем, из коробки в чем-то более ограничен, т.к. не хранит состояние клиентов), но тоже очень легко расширяется

[antirek]

>>в романах американской писательницы Урсулы Ле Гуин ансиблом называется устройство для оперативной космической связи.
Еще анзибль как средство космосвязи упоминается у Орсона Карда в «Игре Эндера» (кстати, скоро фильм по этой книге выходит: )

[drakmail]

Столкнулся с вроде как и простой (но на деле не очень) проблемой — допустим, я хочу ruby на сервере. Причём, не просто ruby, а ruby, установленный через chruby + ruby-install. Ок, тут всё легко, буквально в пару строк ставится chruby, ставится ruby-install, компилируется нужная версия ruby, в /etc/profile.d/ добавляется нужный файл для bash'а (загрузка chruby, установка актуальной версии ruby).

А дальше начинается самое интересное — например, я хочу через модуль gem ansible установить хотя бы bundler — пишу

gem: name=bundler state=latest

и тут понимаю, что ansible выполняет все команды через sh и, соотвественно, мой файл в profile.d не читает.

Искал долго — гугл не подсказал, как можно по умолчанию заставить ansible использовать bash в качестве оболочки.

В общем, как-то так (получилось немного сумбурно, наверное).

Знает ли кто-нибудь, как такое можно решить? Пока обошел проблему с помощью костыля через подключение chruby и установку требуемых гемов через модуль команд.

[spacediver]

А выполнить удаленно bash -c «нужная команда»? ЕМНИП, баш можно подобным образом заставить стартануть с чтением нужных конфигов (правда, нужно проверить, которые из них для случая, когда баш — логиновый шелл, а какие нет) и выполнить потребную команду.

Как-то так :)

[drakmail]

Просто очень хочется использовать именно модуль gem в ansible для этого, так как это правильнее, на мой взгляд. Иначе в чём тогда его смысл? :)

[spacediver]

Перечитав исходное, не совсем понял, откуда тут башевые конфиги вообще. Для подгрузки рубистического окружения для логинящихся в баш пользователей?.. Но это вроде не ваш случай, вы же на сервере.

Может быть, нужно понять, как решить ту же задачу, что решается этими башевыми конфигами?

Условно говоря, перед вызовом gem подгружать ему нужное ruby-окружение? Возможно, придать команде какой-то предхук, или отнаследоваться от команды gem ;)

p.s. Я довольно абстрактно рассуждаю, не до конца понимая вашу задачу и инструменты )))

[drakmail]

Ну, башевые конфиги не нужны. Просто я хочу вместо установки переменных окружения (PATH) и запуска команды gem, грубо говоря (что выльется в что-то вида:

# YML task file
— name: Install bundler
script: install-bundler.sh

# install-bundler.sh
source /usr/local/share/chruby/chruby.sh
chruby ruby-2.0
gem install bundler

) использовать простой DSL и написать так:

gem: name=bundler state=latest

[drakmail]

Смысл ansible, если использовать его тупо как пускалку bash скриптов с немного продвинутой функциональностью :) Поэтому, я тут тоже вижу решение только в виде допиливания самому нужной функциональности ansible.

[drakmail]

Спасибо, не видел такой штуковины, выглядит очень интересно! Правда, под задачи управления конфигурациями подходит слабовато, но это и не её ниша.

[spacediver]

Ну как сказать, с Chef на нее иногда переходят.

[drakmail]

Там вроде не переходят на неё, а скорее, с помощью неё дополняют шефа.

[spacediver]

Искал долго — гугл не подсказал, как можно по умолчанию заставить ansible использовать bash в качестве оболочки.

/etc/ansible/ansible.cfg:

# use this shell for commands executed under sudo
# you may need to change this to bin/bash in rare instances
# if sudo is constrained
#executable = /bin/sh

[clickfreak]

Ни разу не использовал chruby, но если требуется установить переменные окружения, то возможно также подойдёт использование параметра «environment», пример:

vars:
  chruby:
    rubypath: /usr/local/bin/ruby
    some_other_env_var: var_value

tasks:
  - name: test env
    shell: echo $rubypath
    environment: chruby

[Sov1et]

Почитайте вот эту статью про различия profile и bashrc www.joshstaiger.org/archives/2005/07/bash_profile_vs.html. Должно помочь

[spacediver]

О, и в vagrant'е появился провижнер ansible.

Хороший знак.

[spacediver]

У ней консольный вывод цветной. Думаю, подружимся.

[luckyredhot]

*facepalm*
У вас у первого *nix регистронезависимый что ли?!

[luckyredhot]

Вот оно! Машины уже считают себя умнее людей))

[spacediver]

lol

[MARDEN]

Буквально на днях начал использовать Ansible, Всем нравится, но возникла проблема входа на сервер по ssh от имени другого юзера. Т.е. я залогинен под собой, а мне нужно подключиться под другим юзером:
ansible-playbook test.yml -u test
Выдает ошибку:

Скрытый текст

Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the remote directory. Consider changing the remote temp path in ansible.cfg to a path rooted in "/tmp". Failed command was: mkdir -p $HOME/.ansible/tmp/ansible-1381305415.14-95794596656422 && chmod a+rx $HOME/.ansible/tmp/ansible-1381305415.14-95794596656422 && echo $HOME/.ansible/tmp/ansible-1381305415.14-95794596656422, exited with result 255

Не понимаю почему. Сам юзер на сервере есть, ключ проброшен. Через консоль зайти могу, а через Ansible не получается. Работает почему-то только через sudo:
sudo -u test ansible-playbook test.yml -u test

[MARDEN]

На сервере лежат оба ключа: и мой, и test.

[clickfreak]

Выполните с параметром -vvvv, в процессе будет много отладочной информации и будет видно на каком этапе произошла ошибка.
Судя по приведённому сообщению, авторизация прошла успешно, но не было прав для создания временных файлов. Проверьте может ли пользователь создать директорию $HOME/.ansible/tmp/. Если это по каким-то причинам запрещено и нельзя исправить — добавьте в начало плэйбука remote_tmp: /tmp, тогда ansible будет создавать временные файлы в соответствующей директории.

[MARDEN]

Добавил remote_tmp в плейбук, но сразу получил ошибку: «ERROR: remote_tmp is not a legal parameter in an Ansible Playbook».

Пользователь имеет все необходимые права, я от его имени без проблем выполнил те команды, которые Ansible не смог.

[clickfreak]

Проверил, действительно не работает. Оказалось что этот параметр можно поменять только в ansible.cfg (о нём я в статье не упоминал, его местонахождение: /etc/ansible/ansible.cfg, ~/.ansible.cfg, `pwd`/ansible.cfg). Попробуйте изменить remote_tmp именно там. Хотя похоже проблема всё-таки не там.
Выполните ansible <имя_группы> -vvvv -u <имя_проблемного пользователя> -m ping (до изменения ansible.cfg). Если выполнится без ошибок — проблема где-то в плейбуке, если с ошибкой — отладочной информации будет намного больше чем в случае с ansible-playbook.