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

  • Tutorial
Так получилось, что на нашем проекте сейчас используется 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.

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

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    0
    Решал подобную задачу проще. Использовал config.vm.provision. В итоге не пришлось городить костыли и заводится без танцев с бубном везде. Смысл в том, что запускается Ansible в самой VM.
      0
      Решал подобную задачу проще. Использовал config.vm.provision.

      В смысле, шелл-провиженинг с командой, которая запускает Ansible на целевом хосте?

      Вообще говоря, при условии, что ансибловские рецепты лежат рядом с проектом и монтируются на гостевую систему вместе с ним и в гостевой системе установлен Ansible (что для девелоперского окружения вполне допустимо) — отличный вариант.

      Разве что провиженить так что-то кроме dev-окружения на вагрантовской виртуалке не получится (ну, или получится, но будет решительно неудобно).

      Ну и да, целью тут было скорее поделиться опытом, а не рассказать, как надо делать. Потому что если бы я что-то такое прочитал в самом начале, то вряд ли бы пошел тем путем, которым пошел :-)
        0
        В смысле, шелл-провиженинг с командой, которая запускает Ansible на целевом хосте?

        Именно так. Сначала ставим ansible и после запускаем.

        Разве что провиженить так что-то кроме dev-окружения на вагрантовской виртуалке не получится (ну, или получится, но будет решительно неудобно).

        Почему же не получится? С той же VM можно запустить ansible на прод. Делается в 2 команды.

        Ну и да, целью тут было скорее поделиться опытом, а не рассказать, как надо делать. Потому что если бы я что-то такое прочитал в самом начале, то вряд ли бы пошел тем путем, которым пошел :-)

        Теперь можете попробовать такой вариант и это спасет кучу времени вам и другим разработчикам.
          0
          Ответ ниже (не на ту ссылку нажал).
      0
      Почему же не получится? С той же VM можно запустить ansible на прод. Делается в 2 команды.

      Я подумал сразу про такую же схему для продакшена/QA/whatever — запихнуть туда Ansible и провиженить локалхост. Это решение из той же категории, что и описанное в статье — так делать не стоит, поэтому и ответил сразу, что неполучится.

      А с девелоперской виртуалки — да, можно, конечно.
        0
        Вот еще хорошая статья по той же тематике
        www.azavea.com/blogs/labs/2014/10/running-vagrant-with-ansible-provisioning-on-windows/

        Там рекомендуется шелл под win: babun.github.io

          0
          Нет никаких проблем запустить Ansible из-под Windows. Virtualbox + гостевая Linux ОС легко решает «проблему».
            0
            Всё так.

            Изначальным планом было отпровиженить машину с гостевым Debian'ом, на которой не было бы самого ansible (сама идея, состоящая в том, что на конфигурируемой машине нет ничего, кроме sshd, достаточно привлекательна) и попытка запустить всё это дело под Windows имела скорее академический интерес и долго не прожила (впоследствии на виртуалку для разработчиков был-таки поставлен ansible и вместо удаленного провиженинга стали использовать локальный — на виртуалке выполняется ansible-playbook и она сама себя настраивает).
              0
              Это если у вас рабочая машина имеет все права, а если вас заказчик засадил куда нибудь в AWS…

            Only users with full accounts can post comments. Log in, please.