Ansible windows установка программ

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

Если обстоятельства таковы, что вам нужно использовать 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, после чего выберите его в списке.

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

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

В общем и целом, это всё. После этого из 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 и именно его утилиты.

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

Источник

Ansible для управления конфигурацией Windows. История успеха

Кто заинтересовался итогом такого эксперимента, милости просим под кат за расшифровкой.

Привет) Тут уже немного заспойлерили и сказали, что я фронтендер, так что можете уже расходиться =) Меня зовут Алексей, я занимаюсь всяким-разным про веб разработку довольно давно. Начинал с Perl, потом был PHP, немного RoR, немного того, чуть-чуть этого. А потом в мою жизнь ворвался JavaScript, и с тех пор я занимаюсь практически только этим.

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

Предыстория

Два года назад я оказался в Veeam, где разрабатывают продукты под Windows. В тот момент я очень удивился, но оказалось, что и так бывает =). Но больше всего меня удивил непривычно низкий уровень автоматизации всего, что связано с деплоем, с разворачиванием приложений, с тестированием и т.д.

Мы — те, кто разрабатывает под Linux — уже давно привыкли, что всё должно быть в Docker, есть Kubernetes, и всё разворачивается по одному клику. И когда я оказался в среде, где всего этого нет, это шокировало. А когда я начал заниматься автотестами, я понял, что это всего лишь 20% успеха, а всё остальное это подготовка инфраструктуры для них.


Мои ощущения в начале

Текущие условия

Немного расскажу про то, как у нас всё устроено, что нам приходится автоматизировать и чем мы занимаемся.

У нас есть куча разных продуктов, большинство из них под Windows, есть несколько под Linux и даже что-то под Solaris имеется. Ежедневно собирается довольно много билдов для всех продуктов. Соответственно, надо это всё раскатывать в тестовых лабах, как для QA, так и для самих разработчиков, чтобы они могли проверять интеграцию приложений. Всё это требует огромной инфраструктуры из множества железных серверов и виртуальных машин. А ещё иногда мы проводим тестирование производительности, когда надо поднимать сразу по тысяче виртуалок и смотреть, насколько быстро наши приложения будут работать.

Проблемы

Конечно же, на первых этапах (читай, давно) при попытке автоматизировать всё в лоб был использован PowerShell. Инструмент мощный, но скрипты деплоя получаются крайне переусложнёнными. Другая проблема заключалась в отсутствии централизованного управления этим процессом. Какие-то скрипты запускались локально у разработчиков, какие-то на виртуалках, созданных ещё в эпоху мамонтов, и т.д. Как итог: трудно был получить единый результат и понять, что работает, а что нет. Ты приходишь на работу, открываешь браузер — сервер недоступен. Почему недоступен, что случилось, где сломалось — было совершенно не понятно. Не было единой точки входа, и приходилось искать правду по рабочим чатикам, и хорошо, если кто-то отвечал.

Другая проблема, не такая очевидная — это новички. Им было сложно. Первую неделю работы они просто вникали в происходящее. Мы по привычке жили с этим, успокаивая себя тем, что жизнь — штука сложная и надо смириться. Понять и простить, так сказать.

Читайте также:  Windows 7 ключ кмс

Но в какой-то момент нашли внутренние силы перебороть это и посмотреть по сторонам. Вероятно, как-то с этим можно справиться.


Первый шаг на пути решения проблемы — её принятие

Подбор решения

Когда не знаешь, что делать, посмотри, что делают другие.

И для начала мы составили свой список требований к тому, что мы хотим получить в конце.

Убедившись, что данный список покрывает минимум необходимых и достаточных требований для нашего счастья, мы начали пробовать. Традиционно, первым делом попытались решать проблемы методом лобовой атаки. У нас много PowerShell скриптов? Так давайте объединим их в один репозиторий. Но проблема не в том, что скриптов было слишком много, а в том, что разные команды делали одно и тоже разными скриптами. Я походил по разным командам, послушал их требования, собрал одинаковые скрипты, попытался их как-то более-менее причесать и параметризировать, а потом сложил в единый репозиторий.

Fail: Попытка провалилась. Во-первых, мы стали очень много спорить, почему мы делаем так, а не этак. Почему был использован это метод, а не какой-то другой и т.д. И как следствие, появилось много желающих переделать всё «как надо», по принципу «Я сейчас форкнусь и всё за вас перепишу». А объединить ветки с таким подходом, конечно, не удастся.

Попытка номер два: предполагалось взять наш CI-сервер (TeamCity), сделать на нём некие шаблоны и с помощью наследования закрыть основную проблему из первой попытки. Но, как вы могли сразу догадаться, тут нас тоже ждал Fail: Можно использовать шаблон только последней версии, а значит, мы не добьёмся необходимой версионности. И следствие большого количества команд — шаблонов становилось очень много, управлять ими становилось всё сложнее, а на горизонте отчётливо виднелось новое болото.

Устав падать лицом о землю при всякой попытке взлететь, было решено ещё раз сесть и крепко подумать. Итак, у нас есть большая куча ps-скриптов с одной стороны и огромное количество виртуалок с другой. Но мы ошибались, т.к. корень проблемы был совершенно не в этом. Проблема была в том, что между этими вещами всегда был человек. Неважно, будь то разработчик, тестировщик или ещё кто-то, в голове всегда происходила примерно такая логическая цепочка:

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

Infrastructure as a Code

Это именно о том, что вся наша инфраструктура должна быть описана в коде и лежать в репозитории. Все виртуалки, все их параметры, всё, что туда устанавливается — всё надо описать в коде.

Возникает законный вопрос — зачем?

Отвечаем: такой подход даст нам возможность применять лучшие практики из мира разработки, к которым мы все так привыкли:

Выбор инструмента

Как все мы знаем, инструментов для управления конфигурациями довольно много. Мы свой выбор остановили на Ansible, поскольку он содержит набор фич, необходимых именно нам.
Прежде всего, от системы автоматизации мы хотим, не чтобы запускались какие-то инсталляторы, что-то куда-то мигрировало и т.д. Прежде всего от такой системы мы хотим, чтобы после нажатия одной кнопки мы видели UI необходимого нам приложения.

Поэтому ключевая для нас фишка — идемпотентность. Ansible не важно, что было с системой «до». После запуска нужного плейбука мы всегда получаем один и тот же результат. Это очень важно, когда ты говоришь не «Установи IIS», а «Тут должен быть IIS», и тебе не надо думать, был он там до этого, или нет. Скриптами такого достичь очень сложно, а плейбуки Ansible дают такую возможность.

Также надо упомянуть безагентность Ansible. Большинство систем автоматизации работает через агентов. В этом есть много своих плюсов — например, лучший перфоманс — но нам было важно отсутствие агента, чтобы систему не приходилось дополнительно как-то подготавливать.

Тут мы видим, что в базовом примере ps-скрипт будет даже лаконичнее, чем Ansible плейбук. 3 строчки скрипта против 7 строчек плейбука ради того, чтобы скачать файл.

Но, Петька, есть нюанс (с). Как только мы захотим соблюсти принцип идемпотентности и, например, быть уверенным, что файл на сервере не изменился и его не надо качать, в скрипте придётся реализовать HEAD-запрос, что добавляет примерно 200 строчек. А в плейбук — одну. Модуль Ansible win_get_url, который делает за вас все проверки, содержит 257 строк кода, которые не придётся вставлять в каждый скрипт.

А это только один пример очень простой задачи.

И если задуматься, идемпотентность нужна нам везде:

И другие примеры, где выход из ситуации — это раздувать скрипты бесконечными ветвлениями if’ов, которые невозможно будет адекватно отлаживать и невозможно управлять.

Среди прочих важных для нас вещей можно отметить, что Ansible не использует агентов для управления вашими хостами и машинами. На Linux, понятное дело, он ходит по ssh, а для Windows используется WinRM. Отсюда очевидное следствие: Ansible кроссплатформенный. Он поддерживает какое-то фантастическое количество платформ, вплоть до сетевого оборудования.

И последний, но не менее важный — это YAML формат записи конфигов. Все к нему привыкли, он легко читается, и не составляет труда разобраться, что там происходит.

Но не всё так сладко, есть и проблемы:

Как это работает?
Для начала нам нужна машина c Linux. В терминологии Ansible это называется Control Machine.
С неё будут запускаться плейбуки, и на ней происходит вся магия.

На этой машине нам понадобятся:

Самая важная часть, которую нам надо было получить, чтобы перестать страдать с ps-скриптами — это Inventory. YAML файл (в нашем случае), в котором описана наша инфраструктура и куда можно всегда заглянуть, чтобы понять, где что деплоится. И, конечно же, сами плейбуки. В дальнейшем работа выглядит как запуск плейбука с необходимым инвентори-файлом и дополнительными параметрами.

Здесь всё просто: корневая группа all и две подгруппы, webserves и dbservers. Всё остальное интуитивно понятно, только заострю ваше внимание, что Ansible по умолчанию считает, что везде Linux, поэтому для Windows надо обязательно указать winrm и тип авторизации.

Пароль в открытом виде, конечно, в плейбуке хранить не надо, здесь просто пример. Хранить пароли можно, например, в Ansible-Vault. Мы для этого используем TeamCity, который передаёт секреты через переменные окружения и ничего не палит.

Модули

Всё что делает Ansible, он делает с помощью модулей. Модули для Linux написаны на python, для Windows на PowerShell. И реверанс в сторону идемпотентности: результат работы модуля всегда приходит в виде json-файла, где указывается, были изменения на хосте или нет.

В общем случае мы будем запускать конструкцию вида ansible группа хостов инвентори файл список модулей:

Плейбуки

Плейбук это описание того, как и где мы будем выполнять модули Ansible.

В этом примере у нас три таски. Каждая таска — это вызов модуля. В этом плейбуке мы сначала создаём директорию (убеждаемся, что она есть), затем скачиваем туда AWS CLI и с помощью модуля win_packge устанавливаем его.

Читайте также:  Okko приложение для windows

Запустив этот плейбук, мы получим такой результат.

В отчёте видно, что было успешно выполнено четыре таски и три из четырёх произвели какие-то изменения на хосте.

Но что будет, если запустить этот плейбук ещё раз? У нас нигде не написано, что мы должны именно создавать директорию, скачать файл-установщик и запустить его. Мы просто проверяем наличие каждого из пунктов и пропускаем при наличии.

Это и есть та самая идемпотентность, которую мы никак не могли добиться с PowerShell.

Практика

Это немного упрощённый пример, но, в принципе, это именно то, что мы делаем каждый день.
Деплоить будем приложение, состоящее из Windows сервиса и веб приложения под IIS.

Для начала нам надо посмотреть, есть ли вообще IIS на хосте, и установить его, если нет. И хорошо бы туда сразу добавить тулзы управления и все зависимые фичи. И совсем хорошо, если хост будет перезагружен при необходимости.

Первую задачу мы решаем модулем win_feature, который занимается управлением фичами Windows. И тут у нас впервые появляются переменные окружения Ansible, в пункте register. Помните, я говорил, что таски всегда возвращают json объект? Теперь, после выполнения таски Install IIS в переменной win_feature лежит вывод модуля win_feature (уж простите за тавтологию).

В следующей таске мы вызываем модуль win_reboot. Но нам не надо каждый раз перезагружать наш сервер. Мы перезагрузим его, только если модуль win_feature вернет нам это требование в виде переменной.

Следующим этапом устанавливаем SQL. Чтобы сделать это, придуман уже миллион способов. Я здесь использую модуль win_chocolatey. Это пакетный менеджер для Windows. Да, именно то самое, к чему мы так привыкли на Linux. Модули поддерживаются комьюнити, и сейчас их уже больше шести тысяч. Очень советую попробовать.

Так, хост мы подготовили к запуску приложения, давайте его деплоить!

На всякий случай, первым делом мы удаляем существующий сервис.

Следующим шагом мы загружаем на хост новые артефакты. В этом плейбуке подразумевается, что запускается он на билд-сервере, все архивы лежат в известной папочке, а путь к ним мы указываем переменными. После копирования (win_copy) архивы распаковываются(win_unzip). Дальше мы просто регистрируем сервис, говорим путь к exe и что он должен быть запущен.

Готово!?

Вроде наш сервис готов к труду и обороне, правда, есть одно «но» — мы не соблюли принцип идемпотентности. Мы всегда удаляем существующий код и потом деплоим новый.

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

Что можно сделать? Как вариант, можно проверять контрольную сумму наших артефактов и сравнивать их с лежащими на сервере.

Мы используем модуль stat, который предоставляет всякую информацию о файлах и в том числе контрольную сумму. Далее с помощью уже знакомой директивы register пишем результат в переменную. Из интересного: delegate_to указывает, что это надо выполнить на локальной машине, где запускается плейбук.

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

Теперь посмотрим на наше веб-приложение. Опускаем часть про копирование файлов, переходим сразу к сути. Наш билд-сервер сделал паблиш, загружаем всю рассыпуху файлов на хост и используем встроенный модуль для работы с IIS-приложениями. Он создаст приложение и запустит его.

Переиспользование кода

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

Для этого в Ansible есть Роли. По сути, это конвенция. Мы создаём на сервере папочку /roles/ и кладём в неё наши роли. Каждая роль — это набор конфигурационных файлов: описание наших тасок, переменных, служебных файлов и т.д. Обычно ролью делают какую-то изолированную сущность. Установка IIS — отличный пример, если нам надо не просто его установить, но и как-то дополнительно сконфигурировать или проверить дополнительными тасками. Мы делаем отдельную роль и, таким образом, изолируем все относящиеся к IIS плейбуки в папке с ролями. В дальнейшем мы просто вызываем эту роль директивной include_role %role_name%.

Естественно, мы сделали роли для всех приложений, оставив возможность для инженеров, с помощью конфигурационных параметров как-то кастомизировать процесс.

В этом примере для роли Run My App заложена возможность передавать какой-то свой путь к артефактам.

Тут надо замолвить слово про Ansible Galaxy — репозиторий общедоступных типовых решений. Как заведено в приличном обществе, множество вопросов уже было решено до нас. И если возникает ощущение, что вот сейчас мы начнём изобретать велосипед, то сначала надо посмотреть список встроенных модулей, а потом покопаться в Ansible Galaxy. Вполне вероятно, что нужный вам плейбук уже был сделан кем-то другим. Модулей там лежит огромное количество, на все случаи жизни.

Больше гибкости

А что делать, если не нашлось ни встроенного модуля, ни подходящей роли в Galaxy? Тут два варианта: или мы что-то делаем не так, или у нас действительно уникальная задача.

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

CI
В нашем отделе мы очень любим TeamCity, но тут может быть любой другой CI-сервер на ваш выбор. Для чего нам совместное их использование?

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

Также на CI-сервере мы запускаем ansible-lint. Это статический анализатор ansible конфигов, который выдаёт список рекомендаций.

Например, здесь он говорит, что у нас лишний пробел в конце строки, и для одной таски не задано имя. Это важно, т.к. имя модуля может встречаться в одном плейбуке несколько раз, и все таски должны быть именованы.

Само собой, можно ещё писать тесты для плейбуков. Мы можем себе позволить не делать этого, т.к. мы деплоим в тестовую среду, и ничего критичного не случится. А вот если вам деплоить на прод, то лучше бы всё проверить. Благо ansible позволяет тестировать не только плейбуки, но и отдельные модули. Так что обязательно уделите ему внимание.

Бонусная удобность: можно выстраивать зависимости от билдов. Как только что-то сбилдилось, TeamCity запускает процесс редеплоя, после которого нам остаётся только глянуть логи, если вдруг что-то сломалось.

Итого

Источник

Используем Ansible для развертывания системы и программ. Колонка Ильи Русанена

Содержание статьи

Для кого?

Цель этого материала — показать основные приемы работы с Ansible для решения простой и понятной задачи. Рассказать о промышленном использовании Ansible для развертывания инфраструктуры в рамках этой заметки, разумеется, невозможно. Но уверен, после прочтения ты придумаешь, как подстроить этот замечательный инструмент под свой workflow. Или как минимум обратишь на него внимание, если раньше обходил стороной.

Зачем нужна оркестрация локальной машины?

Давай для начала определимся, зачем мы хотим управлять своим компьютером с помощью оркестратора. Под оркестрацией твоего компьютера мы будем понимать:

Читайте также:  Gimp не запускается windows 10

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

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

Воспроизводимость

Мне важно иметь возможность быстро поднять привычную рабочую среду на новой машине. Ситуации бывают разные:

В подобных случаях часто приходится раскатывать ОС с нуля, ставить весь необходимый софт и, что самое неприятное, мучительно вспоминать все пляски с бубном, которые устраивал при предыдущей настройке ОС. Поясню: в моем случае это установка Arch Linux (сама по себе довольно муторная), допиливание оконного менеджера i3, донастройка железа (вплоть до чувствительности BT-мыши), стандартная ерунда вроде локалей, шрифтов, systemd-юнитов и shell-скриптов. И все это без учета установки и настройки непосредственно рабочего софта.

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

Предсказуемость

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

Если не представляешь четко, что, как и когда ты сконфигурировал в системе (а в Linux невозможно запомнить все даже с опорой на ArchWiki), ты вскоре обнаружишь, что также не понимаешь, почему эта программа сейчас работает так, хотя раньше работала иначе. Возможно, ты ставил какой-то плагин или что-то исправлял в конфиге, но забыл?

Имея под рукой полное описание всех настроек в одном месте, ты с меньшей вероятностью столкнешься с этими проблемами.

Декларативность и поддерживаемость

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

Пример наивного «инсталлятора» пакетов в одном из моих скриптов. И это только одна функция

Кстати, если ты тоже без ума от декларативного подхода к описанию ОС, обрати внимание на дистрибутив NixOS.

Другие решения?

Разумеется, для быстрого развертывания можно приспособить и другие инструменты, например системы образов вроде эппловской Time Machine или Norton Ghost. Можно подойти и более радикально: запускать софт в контейнерах Docker или даже виртуалках в AppVM. Проблема в том, что сложно их поддерживать, управлять ими и обновлять софт на регулярной основе. Другими словами, они созданы для решения несколько других задач и не так бесшовно встраиваются в повседневную жизнь, если это не твоя работа 24/7.

Как нам поможет Ansible

Ansible — это система оркестрации. Она написана на Python, присутствует в популярных дистрибутивах и не требует клиента на целевых машинах. Инструмент активно развивается, под него существует много плагинов. Он достаточно новый, но уже популярен наряду с Puppet и Chef.

Для работы с Ansible достаточно передать скрипт (сценарий, конфиг) с перечислением действий, который он должен выполнить на целевой машине. Давай посмотрим, как писать эти конфиги.

Конфиг Ansible называется playbook. Он описывается на языке YAML. Ключевой объект конфига — задача. Это массив (список) вложенных блоков-задач, каждая из которых описывает одно действие. Задачи могут быть атомарны, а могут, в свою очередь, содержать блок подзадач. И так далее, выстраивая дерево подзадач. Примеры задач:

Задач может быть сколько угодно, и Ansible пройдется по всем и выполнит каждую по очереди. Посмотри на пример простого конфига — он описан в одном файле (часть блоков свернута для наглядности). Конечно, большие боевые конфиги удобно разделять на несколько файлов и тегировать, но для наших задач хватит и одной простыни. 🙂

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

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

Пробуем Ansible

Что нужно для работы Ansible?

Linux, Python и в некоторых случаях SSH. Сразу оговорим термины:

Строго говоря, в отличие от других систем оркестрации, устанавливать Ansible на целевом хосте не обязательно. Если у тебя есть еще один компьютер (я проделывал это, например, с Raspberry Pi 3), Ansible нужно иметь именно на нем.

Только что установленный Arch Linux с Python и Ansible через pip. Больше ничего не нужно

Перечисляем хосты и запускаем playbook

С этого момента договоримся, что мы не разделяем master- и target-машины, все действия выполняем на одной машине. Для удаленных хостов процедура будет почти такая же.

Здесь необходимо пояснение. Обычно при работе с удаленными хостами Ansible соединяется с ними по SSH и выполняет определенные в скрипте операции. Однако, поскольку мы выполняем действия над «самим собой», было бы излишне поднимать sshd-демон, чтобы законнектиться к самому себе. Для таких случаев Ansible позволяет указать дополнительный параметр ansible_connection, который определит тип соединения. В нашем случае это local.

Попробуем пропинговать хосты на отклик (в нашем случае единственный хост):

Ответ по localhost — работает.

Собираем свой playbook

Мы уже знаем, что по большей части playbook — это набор задач разной степени вложенности. Теперь научимся писать эти задачи.

Главное, что нужно усвоить, — для выполнения каждой задачи требуется использовать модуль. Модуль — это actor, который может совершать действия определенного типа. К примеру:

Для каждой задачи передаем модуль и набор параметров его запуска, например список пакетов для установки. Модулей очень много, с их полным списком ты можешь ознакомиться здесь. А пока пройдемся по тем, которые нам понадобятся.

1. Обновление системы и установка пакетов

Для обновления системы и установки базовых пакетов программ напишем пару тасков с использованием модуля pacman. Вот пример подобной задачи:

Здесь мы определили две задачи: в первой обновляем систему, во второй передаем модулю pacman список пакетов, которые нужно установить, и инструкцией become сообщаем, что надо поднять привилегии до суперпользователя.

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

Для установки из AUR можно использовать и yaourt (правда, сейчас его уже подвинул новый yay). Поскольку устанавливать из AUR под рутом нельзя, а мы определили повышение привилегий в корневой задаче, создадим отдельного юзера aur_builder и будем переходить под него в задачах установки из AUR:

Теперь при установке пакетов мы можем включить блок установки из AUR:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Илья Русанен

Главный редактор ][, занимаюсь разработкой и безопасностью

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector