Глава 3. Ansible и Windows - не всё ограничено Linux

Ознакомьтесь с видеоматериалами Code in Action.

Когда вы просмотрите официальную документацию Ansible по установке, вы обнаружите разнообразные инструкции для большинства находящихся в основном потоке вариантов Linux, Solaris, macOS и FreeBSD. Вы обнаружите, тем не менее, что нет упоминания относительно Windows. Хорошие новости состоят в том, что если вы запускаете последние версии Windows 10 или Windows Server 2016 {2019}, установка и запуск Ansible теперь невероятно проста благодаря WSL (Windows Subsystem for Linux).Эта технология позволяет пользователям Windows запускать дистрибутивы Linux без изменений поверх Windows без усложнений или накладных расходов виртуальных машин, а раз так, это само по себе придаёт возможность исключительного запуска Ansible, поскольку он запросто может быть установлен и запущен.

WSL доступен только в определённых сборках Windows, и они следующие:

Вы можете запросто проверить свою сборку и номер версии из PowerShell, запустив следующую команду:

systeminfo | Select-String "^OS Name","^OS Version"
		

{Прим. пер.: Для русскоязычных версий-}

systeminfo | Select-String "^Название ОС","^Версия ОС"
		

Если вы запускаете более раннюю версию Windows, исполнение Ansible всё ещё возможно либо через некую виртуальную машину, либо через Cygwin. Однако эти методы выходят за пределы нашей книги.

после того как вы проверили свою сборку, включение WSL будет простым: Просто откройте PowerShell в качестве администратора и запустите следующую команду:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
		

После успешного завершения установки у вас будет возможность выбрать и установить предпочитаемый вами дистрибутив Linux. Имеется доступным целый ряд, однако для запуска Ansible существенно выбрать одну из тех, которая перечислена в имеющихся официальных инструкциях по установке Ansible, например, Debian или Ubuntu.

Если у вас достаточно последняя сборка Windows 10, тогда установка предпочитаемого вами Linux настолько же проста как открытие Microsoft Store и его поиск. Например, выполним поиск Ubuntu, и вы его легко сможете отыскать. Это отражено на следующем снимке экрана:

Кликните по кнопке Get и дождитесь завершения установки. Если вы работаете под Windows 10 и ваша сборка более ранняя нежели 16215, или на самом деле Windows Server 2019, тогда установка Linux является слегка более сложным процессом. Прежде всего выгрузите предпочитаемый вами дистрибутив Linux с Microsoft - к примеру, Ubuntu можно выгрузить при помощи следующей команды PowerShell:

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1804 -OutFile Ubuntu.appx -UseBasicParsing
		

После успешной выгрузки разархивируйте соответствующий файл Ubuntu.appx - он может быть ракрыт в любое местоположение на вашем системном (загрузочном) диске, обычно это C:. Если вы желаете оставить ваш дистрибутив Linux частным, его можно раскрыть куда- нибудь внутри каталога вашего профиля, в противном случае вы можете раскрыть этот файл на своём системном диске. К примеру, приводимые ниже команды PowerShell раскроют этот архив в C:\WSL\:

Rename-Item Ubuntu.appx Ubuntu.zip
Expand-Archive Ubuntu.zip C:\WSL\Ubuntu
		

по завершению вы можете запустить свой вновь установленный дистрибутив Linux при помощи названия исполняемого файла в самом вашем дистрибутиве. В случае нашего примера с Ubuntu вам придётся запустить следующее:

C:\WSL\Ubuntu\ubuntu1804.exe
		

Когда вы запускаете вновь установленный дистрибутив Linux, будь то установка через Microsoft Store, либо установка вручную, он инициализирует себя самостоятельно. В качестве части этого процесса, он запросит у вас создание новой учётной записи пользователя. Обратите внимание, пожалуйста, что эта учётная запись не зависит от имени пользователя Windows и его пароля, а потому убедитесь что вы запомнили установленный тут пароль! Он будет нужен вам при всяком запуске командчерез sudo (к примеру), хотя, как и в случае со всяким прочим дистрибутивом Linux, если пожелаете, вы можете настраивать это поведение индивидуально через /etc/sudoers. Это продемонстрировано на приводимом ниже снимке экрана:

Наши поздравления! Вы теперь имеете запущенным Linux под WSL. Прямо отсюда вы должны следовать стандартному процессу установки для Ansible и вы сможете запускать его из вашей полсистемы Linux просто как если бы имелю любую иную коробку с Linux.

До сих пор мы обсуждали лишь запуск самого Ansible из Windows. Это полезно, в особенности в корпоративной среде, в которой вероятно системы конечных пользователей Windows являются нормой. Однако как быть с реальными задачами автоматизации? Отличная новость состоит в том, что автоматизация Windows при помощи Ansible не требует WSL. Одно из основных положений Ansible состоит в том чтобы выступать без агентов, причём это остаётся справедливым для Windows так же как и для Linux. Также будет справедливо предположить, что также как почти все современные хосты Linux будут иметь включённым доступ SSH, большинство современных хостов Windows имеют встроенным протокол удалённого управления, имеющий название WinRM. По причинам безопасности эта технология отключена по умолчанию, а раз так, в этой части данной книги мы прогуляемся по тому процессу, который требуется для включения и обеспечения безопасности WinRM в удалённом управлении при помощи Ansible.

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

На практике это означает, что будут поддерживаться следующие версии Windows, предоставляя соответствие предыдущим требованиям:

Отметим, что более ранние версии ОС (такие как Windows 7 или Server 2008) не снабжены .NET 4.0 или PowerShell 3.0, и их потребуется установить прежде чем вы сможете воспользоваться Ansible. Обратите внимание, что поддерживаются и более новые версии PowerShell и, в разной степени, могут иметься исправления безопасности для .NET 4.0. Учитывая это, в бизнес- среде скорее всего уже могут иметься на своём месте политики и процедуры для такого рода вещей, причём инкорпорирование более старых ОС нежели перечисленные выходит за рамки данного текста.

После того как все подробно описанные ранее системные требования приведены в соответствие, основной остающейся задачей является включение необходимого ожидания WinRM. Когда мы этого добьёмся, мы сможем на самом деле запускать задачи Ansible в самих хостах Windows! WinRM может работать как поверх протокола HTTP, так и поверх HTTPS и, хотя он быстрее и проще настраивается на включение и работу поверх обычного HTTP, это оставит вас уязвимым для перехватчиков пакетов и потенциальной возможности выявления чувствительных данных в вашей сетевой среде. Это в особенности справедливо коггда применяется базовая аутентификация. По умолчанию, и скорее всего это не будет неожиданным, Windows не допускает удалённого управления при помощи WinRM поверх HTTP или с применением базовой аутентификации.

Иногда базовой аутентификации достаточно (скажем, в средах разработки), а если применяется она, тогда мы несомненно желаем включить в качестве транспорта для WinRM HTTPS! Однако позднее в этой главе мы рассмотрим аутентификацию Kerberos, которая является более предпочтительной, а также включим использование доменных учётных записей. На данный момент, однако, для демонстрации самого процесса подключения Ansible к некому хосту Windows с очень небольшим объёмом безопасности, мы включим WinRM поверх HTTPS с применением самостоятельно подписываемых сертификатов и включим базовую аутентификацию чтобы сделать для нас возможной работу с учётной записью локального Administrator.

Для работы WinRM поверх HTTPS, должен иметься сертификат, который имеет следующее:

В идеале следует сгенерировать некий центральный CA (certificate authority) для предотвращения атак с человеком в промежутке и тому подобного - об этом позднее. Для простоты мы создадим самостоятельно подписываемый сертификат. В PowerShell выполните следующую команду для выработки подходящего сертификата:

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "$env:computername" -FriendlyName "WinRM HTTPS Certificate" -NotAfter (Get-Date).AddYears(5)
 	   

Это должно выдать нечто подобное приводимому ниже - обратите внимание на отпечаток пальца данного сертификата, так как он потребуется вам позднее:

Поместив на место необходимый сертификат, мы теперь можем настроить некое новое ожидание WinRM при помощи такой команды:

New-Item -Path WSMan:\Localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint <thumbprint of certificate>
 	   

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

New-NetFirewallRule -DisplayName 'WinRM HTTPS Management' -Profile Domain,Private -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5986

Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $true
 	   

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

Эти команды были разбиты по отдельности чтобы снабдить нас некой идеей того процесса, который вовлечён в настройку хоста Windows для соединения с Ansible. Для автоматизации развёртываний, и систем в которых не доступен New-SelfSignedCertificate, рассмотрите возможность применения сценария ConfigureRemotingForAnsible.ps1, доступного на официальном сайте Ansible здесь.

Этот сценарий осуществляет все выполненные нами ранее шаги (и многое другое) и может быть выгружен и запущен в Powershell следующим образом:

$ansibleconfigurl = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"

$ansibleconfig = "$env:temp\ConfigureRemotingForAnsible.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($ansibleconfigurl, $ansibleconfig)

powershell.exe -ExecutionPolicy ByPass -File $ansibleconfig
 	   

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

Раз WinRM настроен, заставить Ansible общаться с Windows достаточно просто, предоставив вам на заметку в памяти два предостережения - это ожидает применение протокола SSH, а если вы не определите некую учётную запись пользователя, оно попытается применять ту же самую учётную запись пользователя, с которой работал Ansible при выполнении подключения. А это скорее всего не будет работать с именем пользователя Windows.

Кроме того, обратите внимание, что для успешного подключения требуется установка модуля Python winrm. Он не всегда устанавливается по умолчанию, поэтому будет не лишним проверить его наличие в вашей системе Ansible прежде чем приступать к работе с хостами Windows. Если он отсутствует, вы увидите нечто подобное приводимой на следующем снимке экрана ошибке:

Если вы видите такую ошибку, вам потребуется установить данный модуль прежде чем продолжить всё остальное. Должна существовать предварительно упакованная версия, доступная для вашей ОС - например, для CentOS 7 вы можете установить его при помощи такой команды:

sudo yum install python2-winrm
 	   

Если упакованная версия недоступна, установите его напрямую из pip, воспользовавшись такой командой:

sudo pip install "pywinrm>=0.3.0"
 	   

По окончанию этого мы можем проверить видимость того что настроенная нами ранее конфигурация WinRM работает успешно. Для подключения на основе SSH имеется модуль Ansible с названием ping, который осуществляет полномасштабную всеобщую проверку для гарантии связи, успешной аутентификации и доступной среды Python в некой удалённой системе. Аналогично имеется модуль с названием win_ping, который выполняет аналогичную проверку под Windows.

В своей среде проверки я бы подготовил некую опись (inventory) следующим образом для подключения к моему заново настроенному хосту Windows:

[windows]
192.168.81.150

[windows:vars]
ansible_user=Administrator
ansible_password="password"
ansible_port=5986
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore
 	   

Обратите внимание на особые переменные начинающиеся с ansible_, которые были установлены в разделе windows:vars данного плейбука. На данном этапе они должны самостоятельно пояснять себя, поскольку они рассматривались ранее в этой книге, но в особенности обратите внимание на переменную ansible_winrm_server_cert_validation, которую требуется установить чтобы игнорировать работу с самостоятельно подписанными сертификатами. Очевидно, что в примере реального мира вы оставите параметр ansible_password с открытым текстом - его следует либо поместить в Ansible Vault, либо запрашивать при запуске при помощи параметра --ask-pass.

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

ansible -i windows-hosts -m win_ping all
 	   

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

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

Теперь, когда мы установили базовый уровень подключения, требующийся Ansible для выполнения задач в неком хосте Windows, давайте погрузимся глубже в сторону вещей аутентификации и шифрования. В своей начальной части данной главы мы применяли механизм базовой аутентификации с некой локальной учётной записью. Хотя это и прекрасно для целей проверки, что происходит в средах домена? Базовая аутентификация поддерживает лишь локальные учётные записи, поэтому ясно что нам тут требуется нечто ещё. Мы также выбрали свой сертификат SSL без его удостоверения (поскольку им был самостоятельно подписываемый), что опять- таки отлично для целей проверки, но не является наилучшей практикой в промышленной среде. В этом разделе мы изучим варианты улучшения безопасности нашего соединения Ansible с Windows.

Ansible фактически поддерживает пять следующих различных механизмов аутентификации Windows:

Стоит отметить, что Kerberos, NTLM и CredSSP обеспечивают шифрование сообщений по HTTP, что повышает безопасность. Однако мы уже видели, как легко настроить WinRM через HTTPS, и управление WinRM через простой HTTP все равно не включено по умолчанию, поэтому мы будем предполагать, что канал связи уже зашифрован. WinRM - это протокол SOAP, что означает, что он обязан работать поверх транспортного уровня, такого как HTTP или HTTPS. Для предотвращения перехвата команд удаленного управления в сети рекомендуется, чтобы WinRM работал по протоколу HTTPS.

Из всех этих перечисленных методов аутентификации, наибольший интерес для нас предоставляет Kerberos. Kerberos (для целей данной главы) действенно вытесняет NTLM для аутентификации Ansible по учётным записям Active Directory. CredSSP предоставляет иной механизм, но также существуют риски безопасности, связанные с перехватом входов в систему при открытых текстах в целевом хосте, которые лучше всего представлять перед его развёртыванием - фактически он отключён по умолчанию.

Прежде чем мы перейдём к настройке Kerberos, некое краткое замечание относительно аутентификации по сертификату. Хотя изначально она может показаться привлекательной, поскольку фактически она не имеет пароля, текущие зависимости в Ansible означают, что закрытый ключ для аутентификации сертификата должен быть не зашифрован в узле автоматизации Ansible. В этом отношении на самом деле более безопасно (и разумнее) поместить пароль для сеанса базовой аутентификации или аутентификации Kerberos в хранилище Ansible. Мы уже рассмотрели базовую аутентификацию, и поэтому здесь мы сосредоточим наши усилия на Kerberos.

Поскольку аутентификация Kerberos поддерживает только учётные записи Active Directory, предполагается, что рассматриваемый хост Windows, подлежащий управлению со стороны Ansible, уже подключён к необходимому домену. Также предполагается, что WinRM поверх HTTPS уже был настроен, как это обсуждалось ранее в нашей главе.

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

sudo yum -y install python-devel krb5-devel krb5-libs krb5-workstation
		

В Ubuntu 16.04 вы бы установили такие пакеты:

sudo apt-get install python-dev libkrb5-dev krb5-user
		

Дополнительно к этим пакетам нам также потребуется установить модуль Python pywinrm[kerberos]. Его доступность будет отличаться - в CentOS 7 он не доступен в качестве RPM, поэтому нам потребуется установить его через pip следующим образом:

sudo yum install python-pip gcc
sudo pip install pywinrm[kerberos]
 	   

После этого проверьте что ваш сервер Ansible способен выявлять записи DNS, относящиеся к AD (Active Directory). Сама процедура для этого будет разниться в соответствии с вашей ОС и сетевой архитектурой, а следовательно выходит за рамки данной книги - достаточно сказать, кто ваш контроллер Ansible обязан иметь возможность выявлять ваш контроллер домена и относящиеся к нему записи для работы оставшейся части данной процедуры. {Прим. пер.: например, пропишите в свойствах IP своего сетевого контроллера DNS сервер контроллера домена, либо укажите этот сервер DNS в свойствах IP своего маршрутизатора.}

Разобравшись с DNS, далее добавьте свой домен в /etc/krb5.conf. Например, мой домен проверки mastery.example.com, а мой контроллер домена WIN-2NJFMR0MNBD.mastery.example.com, поэтому самый низ моего /etc/krb5.conf выглядит следующим образом:

[realms]
MASTERY.EXAMPLE.COM = {
kdc = WIN-2NJFMR0MNBD.mastery.example.com
}

[domain_realm]
.mastery.example.com = MASTERY.EXAMPLE.COM
 	   

Обратите внимание на заглавные буквы - это важно! Проверьте свою интеграцию Kerberos при помощи команды kinit с некой известной вам учётной записью этого домена. Вот некий пример использования Domain Administrator для моего проверочного домена:

Наконец, давайте создадим опись (inventory) хоста Windows - обратите внимание, что она практически идентична применявшейся нами в примере базовой аутентификации; только на этот раз нам придётся определить домен Kerberos после указанного имени пользователя:

[windows]
192.168.81.150

[windows:vars]
ansible_user=administrator@MASTERY.EXAMPLE.COM
ansible_password="password"
ansible_port=5986
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore
 	   

Теперь мы можем проверить подключение как и ранее:

Успешно! Наш предыдущий результат отображает успешное повсеместное подключение к Windows, включая успешную аутентификацию и доступ к нашей подсистеме WinRM.

По умолчанию WinRM настроен на разрешение управления только участникам имеющейся группы локальных Administrators в конкретном хосте Windows. Это не обязательно должна быть сама учётная запись Administrator - мы применяем её здесь исключительно в целях демонстрации. Имеется возможность применения менее привилегированных учётных записей для управления WinRM, однако их применение скорее всего зарекомендует себя ограниченным, ибо большинство команд Ansible требует некой степени привилегированного доступа. Если вы желаете иметь доступной для Ansible через WinRM менее привилегированную учётную запись, выполните в этом хосте следующую команду:

winrm configSDDL default
		

Исполнение этой команды откроет блок диалога Windows. Воспользуйтесь им для добавления тех пользователей или групп, для которых вы бы желали иметь возможности удалённого управления WinRM и предоставьте (grant) для них (как минимум) полномочия Read и Execute.

До сих пор мы игнорировали применение во взаимодействиях WinRM самостоятельно подписываемых сертификатов SSL - очевидно, это далеко от идеала и достаточно очевидно как начать подтверждение сертификатов SSL со стороны Ansible когда они не являются самостоятельно подписываемыми {Прим. пер.: а подтвержаемые удостоверяющими центрами (CA)}.

Самый простой способ сделать это когда ваши машины являются участниками некого домена это воспользоваться ADCS (Active Directory Certificate Services) - однако большинство организаций будут иметь свои собственные процессы сертификации через ADCS или иную стороннюю службу. Для продолжения работы с данным разделом мы полагаем что ваш рассматриваемый хост Windows уже имеет некий выработанный для удалённого управления сертификат и что этот сертификат доступен в формате Base64. {Прим. пер.: подробнее в наших переводах Полного руководства Windows Server 2019 Джордана Краузе и Книги рецептов Windows Server 2016 того же автора.}

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

Import-Certificate -FilePath .\certnew.cer -CertStoreLocation Cert:\LocalMachine\My
 	   

Естественно, замените указанное значение пути к сертификату FilePath тем, которое соответствует местоположению вашего собственного сертификата. Если вам это требуется, вы можете удалить любое созданное ранее ожидание HTTPS WinRM при помощи такой команды:

winrm delete winrm/config/Listener?Address=*+Transport=HTTPS
 	   

Затем воспользуйтесь имеющимся дактилоскопическим отпечатком своего импортированного сертификата создайте новое ожидание:

New-Item -Path WSMan:\Localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint <thumbprint of certificate>
 	   

Теперь перейдём к нашему контроллеру Ansible. Первое что нам следует сделать, это импортировать свой сертификат CA для ожидания WinRM в пакет CA для вашей ОС. Сам метод и местоположение для него будут различными для разных ОС, но что касается CenOS 7, вы можете поместить необходимый сертификат CA в /etc/pki/ca-trust/source/anchors/.

После того как это сделано, исполните следующие команды:

update-ca-trust enable
update-ca-trust extract
 	   

Наконец, нам требуется сообщить Ansible где искать необходимый сертификат. По умолчанию Ansible применяет модуль Certifi Python и будет применять установленное для него значение пути по умолчанию пока вы не сообщите иного. Данный процесс обновляет имеющийся пакет CA, расположенный в /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem и к счастью мы можем сообщить Ansible где его искать в своём файле описи (inventory). Обратите внимание на два дальнейших изменения в этом файле описи, как это показано в приводимом ниже коде - прежде всего мы теперь должны определять полное значение имени хоста для своего хоста Windows вместо его IP адреса, поскольку это имя хоста описи должно соответствовать значению CN в нашем сертификате для того чтобы прошло полное удостоверение. Также мы должны удалить строку ansible_winrm_server_cert_validation, что означает что все сертификаты SSL теперь подтверждаются в явном виде:

[windows]
WIN-2NJFMR0MNBD.mastery.example.com

[windows:vars]
ansible_user=administrator@MASTERY.EXAMPLE.COM
ansible_password="password"
ansible_port=5986
ansible_connection=winrm
ansible_winrm_ca_trust_path=/etc/pki/ca-trust/extracted/pem/tls-cabundle.pem
 	   

Если мы снова запустим свой тест ping, мы теперь должны увидеть SUCCESS:

Очевидно, что мы могли бы улучшить выработку своего сертификата для удаления предостережения subjectAltName, но на данный момент оно демонстрирует подключение Ansible к Windows, причём с аутентификацией Kerberos для учётной записи домена и с полным удостоверением SSL. До сих пор для демонстрации этого нам приходилось применять модуль Ansible win_ping для провеки подключения. Хотя плейбуки Windows для Ansible мгли бы занять свою собственную книгу целиком, давайте завершим эту главу нескольким простыми образцами плейбуков.

Полный перечень модулей Windows для Ansible доступен по этой ссылке и следует отметить, что хотя вы можете применять все знакомые вам конструкции Ansible с хостами Windows, такие как vars, handlers и blocks, при определении tasks вы должны применять специфичные для Windows модули.

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

Когда вы запускаете Ansible для некого сервера Linux и желаете создать некий каталог, а затем скопировать в него файл, вы должны были применять в плейбуке соответствующие модули Ansible file и copy, что выглядит как- то так:

---
- name: Linux file example playbook
  hosts: all
  gather_facts: false

  tasks:
    - name: Create temporary directory
      file:
        path: /tmp/mastery
        state: directory
    - name: Copy across a test file
      copy:
        src: mastery.txt
        dest: /tmp/mastery/mastery.txt
 	   

Однако в Windows этот плейбук завершился бы неудачно при его исполнении, поскольку модули file и copy не совместимы с WinRM. Как результат, некий эквивалентный плейбук для исполнения той же самой задачи, но на этот раз вWindows, будет выглядеть таким образом:

---
- name: Windows file example playbook
  hosts: all
  gather_facts: false

  tasks:
    - name: Create temporary directory
      win_file:
        path: 'C:\Mastery Test'
        state: directory
    - name: Copy across a test file
      win_copy:
        src: ~/src/mastery/mastery.txt
        dest: 'C:\Mastery Test\mastery.txt'
 	   

Отметим следующие отличия между данными двумя плейбуками:

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

Также отметим, что когда некое название файла содержит определённые специальные символы (например, квадратные скобки), их следует экранировать при помощи специального экранирующего (escape) символа PowerShell, `. Например, приводимая ниже задача установила бы файл c:\temp\setupdownloader_[aaff].exe:

- name: Install package
    win_package:
      path: 'c:\temp\setupdownloader_`[aaff`].exe'
      product_id: {00000000-0000-0000-0000-000000000000}
      arguments: /silent /unattended
      state: present
 	   

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

Большинство систем Linux (и несомненно прочие Unix варианты) имеют естественные диспетчеры пакетов, которые упрощают установку широкого разнообразия программного обеспечения. Диспетчер пакетов chocolatey делает это возможным для Windows, а соответствующий модуль Ansible win_chocolatey осуществляет простую установку программного обеспечения без оператора с применением Ansible.

К примеру, если вы желаете раскрутить Adobe Acrobat Reader на штатных машинах Windows, вы можете воспользоваться модулями win_copy или win_get_url для распространения надлежащего установщика, а затем своим модулем win_package для его установки. Однако приводимый ниже код сделает ту же самую задачу с меньшим кодированием:

- name: Install Acrobat Reader
  win_chocolatey:
    name: adobereader
    state: present
 	   

Обсуждение системы пакетов chocolatey гораздо глубже сферы данной книги, однако заслуживает внимания благодаря упрощению установки пакетов и управлению ими для платформ Windows.

точно также как и для любой платформы, может настать время, когда у какого- то модуля модуля не достаёт точно соответствующей функциональности. Хотя для этого жизнеспособным решением является написание собственного модуля (или изменение уже имеющегося), порой требуется какое- то немедленной решение. Для этой цели на помощь приходят модули win_command и win_shell - ими можно воспользоваться для запуска буквальных команд PowerShell в Windows. В официальной документации Ansible присутствует множетво примеров, к примеру следующий код создаст при помощи PowerShell каталог C:\Mastery:

- name: Create a directory using PowerShell
      win_shell: New-Item -Path C:\Mastery -ItemType Directory
 	   

Для этой задачи мы можем даже вернуться к традиционной оболочке cmd:

- name: Create a directory using cmd.exe
      win_shell: mkdir C:\MasteryCMD
      args:
        executable: cmd
 	   

отталкиваясь от этого должно быть возможным создание желательной функциональности в точности так же как в любой среде Windows. {Прим. пер.: рекомендуем ознакомиться с нашими переводами PowerShell и Python сообща - настроены на цифровые расследования Чета Хосмера и Книга рецептов Powershell Core 6.2 Жан-Эндрика Питерса.}

Ansible обрабатывает хосты Windows также действенно как и хосты Linux (и прочие Unix). В этой главе мы рассмотрели и как запускать Ansible с хоста Windows, и как интегрировать хосты Windows с Ansible для целей автоматизации, включая механизмы аутентификации, шифрования и даже основы специфичных для Windows плейбуков.

Вы изучили что Ansible способен запускаться из последних сборок Windows, которые поддерживают WSL, а также как достичь этого. Вы также изучили как настраивать хосты Windows для контроля со стороны Ansible и как сделать это безопасно при помощи аутентификации Kerberos и шифрования. Наконец, вы изучили основы авторизации плейбуков Windows, включая поиск верных для применения с хостами Windows модулей, экранирование специальных символов, создание каталогов и копирование файлов для такого хоста, установку пакетов и даже исполнение обычных команд оболочки в своём хосте Windows при помощи Ansible. Это звучит основательным для того чтобы вы имели возможность собирать плейбуки Windows, необходимые для управления вашими собственными штатными хостами Windows.

В своей следующей главе мы обсудим действенное управление Ansible в корпорации при помощи AWX.