Pull to refresh

Ansible под Windows с костылями, подпорками и интеграцией с Vagrant

Reading time 5 min
Views 28K
Так получилось, что на нашем проекте сейчас используется Ansible. Я не буду останавливаться на том, что такое Ansible, как его готовить и с чем употреблять, а также на том, почему используется именно он (ибо выбор этот для условий эксплуатации под ОС от Microsoft оптимальным не назовешь) — в контексте этого поста предлагаю считать это данностью. Также ни для кого не секрет, что очень много веб-разработчиков по разным причинам работает под Windows. Нежелание сражаться с линуксами, нехватка денег на мак, танчики после работы, корпоративная политика — причин тоже может быть вагон. И о них в этом посте тоже не будет ни слова.

Если обстоятельства таковы, что вам нужно использовать Ansible под Windows (что, в принципе, не так уж и напряжно, хоть и нигде толком не описано) и, чего доброго, интегрировать это дело с Vagrant под Windows — прошу под кат.



Начну, пожалуй, с предупреждения. Если вы выбираете провиженер для автоматизации развертывания проектной инфраструктуры и в качестве мастера хотите использовать свою рабочую станцию на Windows и только её — лучше не используйте Ansible. Вот что написано в его документации по установке: “Currently Ansible can be run from any machine with Python 2.6 installed (Windows isn’t supported for the control machine)”. Всё описанное ниже — система костылей и подпорок на крайний случай. И если всё же крайний случай наступил или вы не ищете легких путей, поехали.

Установка


В общем, тут ничего удивительного нету. Если сабж не поддерживает Windows из коробки, а нормально работает только под *nix — можно попытаться устроить в винде небольшой *nix при помощи Cygwin. Более того, можно нагуглить уже готовые инстукции о том, как поднять Ansible под Cygwin, но мне удалось сделать это, как мне кажется, проще и чище, чем, например, автору этой инструкции.

Забегая вперед, скажу, что для меня это был первый опыт работы с Cygwin'ом (сам я давно на Linux'е, эта инстукция в целом — попытка дать возможность команде работать с опрометчиво выбранным без скидки на Windows инстументом) и установка пакетов там оказалась штукой не совсем для меня очевидной. Пришлось загуглить: оказывается, чтобы установить пакет, нужно, найдя его в списке, нажать вот на эту иконку — тогда изменится его статус; чтобы добавить или удалить пакеты, нужно запустить инсталлятор и идти тем же путем, что и при начальной установке.

Еще одна заметка. Если вы из Беларуси, используйте зеркало Белтелекома (http://ftp.mgts.by/pub/cygwin) — по опыту это единственный способ установить всё быстро. Для этого введите указанный адрес в поле под списком зеркал и нажмите Add, после чего выберите его в списке.

При установке Cygwin выберите следующие пакеты:
  • binutils (из Devel)
  • libuuid-devel (из Libs)
  • python (from Python)
  • python-crypto (from Python)
  • python-setuptools (from Python)

Опционально — gcc-core из Devel, тогда некоторые питоновские модули соберутся из исходников на C, в противном случае останется довольствоваться питоновской реализацией.

Чем объясняется этот набор? Нормально поставить Ansible можно только через питоновский пакетный менеджер pip, а он не работает без libuuid-devel, по меньшей мере на версии Cygwin для x86_64. binutils позволяет pip'у использовать Cygwin'овскую реализацию libuuid. Остальное, думаю, понятно — для самого Ansible.

Сразу после устновки Cygwin рекомендую объяснить ему, где находится ваша домашняя директория. По умолчанию он будет использовать в качестве оной какую-то свою папку; использование в этом качестве виндовой пользовательской папки кажется мне несколько более понятным и прозрачным; кроме того, это решает некоторые пролемы, которые возникают при запуске из-под Cygwin'а Vagrant'а — без дополнительных шаманских пассов он будет постоянно пересоздавать виртуалку.
Это можно сделать следующей командой, выполненной в Cygwin:
mkpasswd -l -c -p "$(cygpath -H)" > /etc/passwd

С обвязками закончили. Теперь сам Ansible. Тут всё неожиданно просто пару команд в Cygwin — и готово:
  • easy_install pip
  • pip install ansible==1.5.3


Почему именно 1.5.3, спросите? Это последняя на данный момент версия, работающая под Windows и не имещая некоторых назойливых багов.

Кроме этого, нужно объяснить Ansible, что такую фичу ssh, как ControlMaster, использовать не нужно (под Windows она не работает). Суть ее в следующем: ssh устанавливает соединение с хостом, создает сокет и не убивает его в течение некоторого конфигурируемого времени. При следующем подключении он, если возможно, использует этот сокет (уже установленное соединение), чтобы не устанавливать его заново и Ansible работает без накладных расходов по установке соедиения на каждый таск. Сделать это можно через переменную окружения: ANSIBLE_SSH_ARGS=-o ControlMaster=no или через конфиг Ansible, указавтам в секции [ssh_connection] опцию ssh_args = -o ControlMaster=no. На stackoverflow можно найти немного информации на эту тему.

В общем и целом, это всё. После этого из Cygwin можно использовать ansible-playbook как и в *nix.

Ansible с Vagrant: свяо атмосфреа


В теории, Vagrant интегрируется с Ansible красиво и прозрачно. Но только не под Windows. При первой же попытке запустить vagrant provision с Ansible в качестве провиженера под Windows вы получите какую-нибудь замысловатую ошибку. Причина достаточно проста: Ansible будет работать только под Cygwin. Найти простой способ заставить vagrant вызывать его нужным способом мне не удалось. Казалось бы, велика ли беда: соорудить батник по имени ansible-playbook.bat, который будет запускать уже реальный ansible-playbook в Cygwin, положить его в %Path% так, чтобы Vagrant попадал на него — всего-то! Но не тут-то было.

Vagrant под Windows — это такая же системы костылей и подпорок со своим bash'ем и коллекцией *nix утилит. Соответственно, просто написать bash не получится: Vagrant разбавит %Path% путем к своей директории с *nix-утилитами (кстати, тем же грешен и GitBash), а нам нужен именно Cygwin и именно его утилиты.

В итоге путем проб, ошибок и длительных страданий был рожден этот batch. Он может быть отвратителен, но никаких познаний в скриптинге под Windows у меня не было, поэтому слепил из того, что было, следуя методологии StackOverflow Driven Development.
Также в процессе оказалось, что это лучшее место, чтобы задать упомянутую выше переменную окружения ANSIBLE_SSH_ARGS. Задавать ее в конфиге неудобно, потому что Ansible не мержит конфиги, а берет первый найденный — соответственно, либо не получится использовать конфиг Ansible в контексте проекта, либо придется задать этот параметр для всех, даже для тех, кому он не нужен (а выключение ControlMaster очень сильно замедляет провиженинг). Также его можно было указать в Vagrant-файле, но тогда без дополнительных подпрыгиваний не получилось бы использовать ansible-playbook без Vagrant'а.

Этот .bat предполагает, что Cygwin'овский bin добавлен в %Path% (неважно, в какую именно часть), а путь к самому батнику добавлен в %Path% перед Cygwin'овским bin.

В итоге всё вышеописанное уложилось буквально в несколько достаточно кратких инстукций в шагах по развертыванию проекта и было более-менее успешно обкатано на вновь пришедших на проект разработчиках разного уровня.
Tags:
Hubs:
-2
Comments 9
Comments Comments 9

Articles