Так получилось, что на нашем проекте сейчас используется 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 pippip 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.
В итоге всё вышеописанное уложилось буквально в несколько достаточно кратких инстукций в шагах по развертыванию проекта и было более-менее успешно обкатано на вновь пришедших на проект разработчиках разного уровня.
Автор: kamazee
