Ansible client for windows

Setting up a Windows Host¶

This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host.

Host Requirements¶

For Ansible to communicate to a Windows host and use Windows modules, the Windows host must meet these requirements:

Ansible can generally manage Windows versions under current and extended support from Microsoft. Ansible can manage desktop OSs including Windows 7, 8.1, and 10, and server OSs including Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, and 2019.

A WinRM listener should be created and activated. More details for this can be found below.

While these are the base requirements for Ansible connectivity, some Ansible modules have additional requirements, such as a newer OS or PowerShell version. Please consult the module’s documentation page to determine whether a host meets those requirements.

This is an example of how to run this script from PowerShell:

If running on Server 2008, then SP2 must be installed. If running on Server 2008 R2 or Windows 7, then SP1 must be installed.

Windows Server 2008 can only install PowerShell 3.0; specifying a newer version will result in the script failing.

The username and password parameters are stored in plain text in the registry. Make sure the cleanup commands are run after the script finishes to ensure no credentials are still stored on the host.

WinRM Memory Hotfix¶

When running on PowerShell v3.0, there is a bug with the WinRM service that limits the amount of memory available to WinRM. Without this hotfix installed, Ansible will fail to execute certain commands on the Windows host. These hotfixes should be installed as part of the system bootstrapping or imaging process. The script Install-WMF3Hotfix.ps1 can be used to install the hotfix on affected hosts.

The following PowerShell command will install the hotfix:

For more details, please refer to the Hotfix document from Microsoft.

WinRM Setup¶

Once Powershell has been upgraded to at least version 3.0, the final step is for the WinRM service to be configured so that Ansible can connect to it. There are two main components of the WinRM service that governs how Ansible can interface with the Windows host: the listener and the service configuration settings.

Details about each component can be read below, but the script ConfigureRemotingForAnsible.ps1 can be used to set up the basics. This script sets up both HTTP and HTTPS listeners with a self-signed certificate and enables the Basic authentication option on the service.

To use this script, run the following in PowerShell:

The ConfigureRemotingForAnsible.ps1 script is intended for training and development purposes only and should not be used in a production environment, since it enables settings (like Basic authentication) that can be inherently insecure.

WinRM Listener¶

The WinRM services listens for requests on one or more ports. Each of these ports must have a listener created and configured.

To view the current listeners that are running on the WinRM service, run the following command:

This will output something like:

In the example above there are two listeners activated; one is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are:

Transport : Whether the listener is run over HTTP or HTTPS, it is recommended to use a listener over HTTPS as the data is encrypted without any further changes required.

CertificateThumbprint : If running over an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell:

Setup WinRM Listener¶

There are three ways to set up a WinRM listener:

Using Group Policy Objects. This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the Group Policy Objects documentation.

Using PowerShell to create the listener with a specific configuration. This can be done by running the following PowerShell commands:

To see the other options with this PowerShell cmdlet, see New-WSManInstance.

When creating an HTTPS listener, an existing certificate needs to be created and stored in the LocalMachine\My certificate store. Without a certificate being present in this store, most commands will fail.

Delete WinRM Listener¶

To remove a WinRM listener:

The Keys object is an array of strings, so it can contain different values. By default it contains a key for Transport= and Address= which correspond to the values from winrm enumerate winrm/config/Listeners.

WinRM Service Options¶

There are a number of options that can be set to control the behavior of the WinRM service component, including authentication options and memory settings.

To get an output of the current service configuration options, run the following command:

This will output something like:

While many of these options should rarely be changed, a few can easily impact the operations over WinRM and are useful to understand. Some of the important options are:

Service\Auth\* : These flags define what authentication options are allowed with the WinRM service. By default, Negotiate (NTLM) and Kerberos are enabled.

Service\Auth\CbtHardeningLevel : Specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NTLM or Kerberos over HTTPS.

Service\CertificateThumbprint : This is the thumbprint of the certificate used to encrypt the TLS channel used with CredSSP authentication. By default this is empty; a self-signed certificate is generated when the WinRM service starts and is used in the TLS process.

Winrs\MaxShellRunTime : This is the maximum time, in milliseconds, that a remote command is allowed to execute.

Winrs\MaxMemoryPerShellMB : This is the maximum amount of memory allocated per shell, including the shell’s child processes.

To modify a setting under the Service key in PowerShell:

To modify a setting under the Winrs key in PowerShell:

If running in a domain environment, some of these options are set by GPO and cannot be changed on the host itself. When a key has been configured with GPO, it contains the text [Source=»GPO»] next to the value.

Common WinRM Issues¶

Because WinRM has a wide range of configuration options, it can be difficult to setup and configure. Because of this complexity, issues that are shown by Ansible could in fact be issues with the host setup instead.

One easy way to determine whether a problem is a host issue is to run the following command from another Windows host to connect to the target Windows host:

If this fails, the issue is probably related to the WinRM setup. If it works, the issue may not be related to the WinRM setup; please continue reading for more troubleshooting suggestions.

HTTP 401/Credentials Rejected¶

A HTTP 401 error indicates the authentication process failed during the initial connection. Some things to check for this are:

Verify that the credentials are correct and set properly in your inventory with ansible_user and ansible_password

Ensure that the user is a member of the local Administrators group or has been explicitly granted access (a connection test with the winrs command can be used to rule this out).

Make sure that the authentication option set by ansible_winrm_transport is enabled under Service\Auth\*

When using Basic or Certificate authentication, make sure that the user is a local account and not a domain account. Domain accounts do not work with Basic and Certificate authentication.

HTTP 500 Error¶

These indicate an error has occurred with the WinRM service. Some things to check for include:

Verify that the number of current open shells has not exceeded either WinRsMaxShellsPerUser or any of the other Winrs quotas haven’t been exceeded.

Timeout Errors¶

These usually indicate an error with the network connection where Ansible is unable to reach the host. Some things to check for include:

Make sure the firewall is not set to block the configured WinRM listener ports

Ensure that a WinRM listener is enabled on the port and path set by the host vars

Ensure that the winrm service is running on the Windows host and configured for automatic start

Connection Refused Errors¶

These usually indicate an error when trying to communicate with the WinRM service on the host. Some things to check for:

Check that the host firewall is allowing traffic over the WinRM port. By default this is 5985 for HTTP and 5986 for HTTPS.

Sometimes an installer may restart the WinRM or HTTP service and cause this error. The best way to deal with this is to use win_psexec from another Windows host.

Failure to Load Builtin Modules¶

If powershell fails with an error message similar to The ‘Out-String’ command was found in the module ‘Microsoft.PowerShell.Utility’, but the module could not be loaded. then there could be a problem trying to access all the paths specified by the PSModulePath environment variable. A common cause of this issue is that the PSModulePath environment variable contains a UNC path to a file share and because of the double hop/credential delegation issue the Ansible process cannot access these folders. The way around this problems is to either:

Remove the UNC path from the PSModulePath environment variable, or

Use an authentication option that supports credential delegation like credssp or kerberos with credential delegation enabled

See KB4076842 for more information on this problem.

Windows SSH Setup¶

Ansible 2.8 has added an experimental SSH connection for Windows managed nodes.

Use this feature at your own risk! Using SSH with Windows is experimental, the implementation may make backwards incompatible changes in feature releases. The server side components can be unreliable depending on the version that is installed.

Installing Win32-OpenSSH¶

The first step to using SSH with Windows is to install the Win32-OpenSSH service on the Windows host. Microsoft offers a way to install Win32-OpenSSH through a Windows capability but currently the version that is installed through this process is too old to work with Ansible. To install Win32-OpenSSH for use with Ansible, select one of these three installation options:

Manually install the service, following the install instructions from Microsoft.

Install the openssh package using Chocolatey:

Источник

How to install Ansible on Windows?

Love Ansible, but wondering how to get it running on Windows?

Ansible is one of the most popular configuration administration and infrastructure automation tools. It helps to automate infrastructure configuration/provisioning, software deployments, and general infrastructure management.

Ansible was initially available on Linux. However, with Microsoft’s new viewpoint on open source, their community improvements, and their acceptance of a more agile, DevOps-minded software development method, Windows support is gradually catching up the pace.

Although Windows support requires a slight bit more configuration, it’s not very bad once the initial setup is done. There are two possible ways to get it installed.

Using Cygwin

Have you heard of Cygwin?

It is a POSIX-compatible environment to run on Windows. Means – you can run many things on Windows, which you usually do on UNIX-based OS.

If its the first time you heard about Cygwin then I would refer to their official website to get more understanding.

The default Cygwin installation doesn’t cover Ansible. Hence, you got to select them during installation, as explained below manually.

Congratulation! You have installed Cygwin with Ansible on Windows. Let’s verify it.

And, as you can see, it has successfully installed.

Go ahead and play around with it. If you are interested in learning Ansible, then check out this Udemy course.

Using Ubuntu on Windows 10

Thanks to Microsoft. Now it is possible to install Ubuntu on Windows 10.

Let’s get it started.

After the installation, let’s test whether by creating and running a demo playbook.

And, finally, run the playbook.

Conclusion

I hope this helps you to install Ansible on Windows. Check out this blog post to learn about the playbook to automate the tasks.

Источник

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 выполнялась в ОС Linux; действительно, предыдущие две редакции данной книги целиком основывались на применении Ansible в среде сосредоточенной вокруг Linux. Тем не менее, большинство сред не являются таковыми и, по меньшей мере, вероятно могут иметь во всяком случае какое- то число серверов Microsoft Windows и настольных машин. С момента выхода второго издания этой книги в Ansible была проделана большая работа по созданию на самом деле надёжного межплатфориенного инструментария автоматизации, который одинаково чувствует себя как дома и центрах обработки данных Linux, и в центрах обработки данных Windows. Конечно, существуют фундаментальные отличия в тех способах, которыми работают хосты Windows и Linux, а потому не должно быть удивительным то, что имеются некие фундаментальные отличия между тем как Ansible автоматизирует задачи в Linux и как он автоматизирует задачи в Windows. Мы обсудим в этой главе такие основы чтобы снабдить вас солидной скалой основы для начала автоматизации ваших задач Windows при помощи Ansible, а именно, рассмотрим следующие области:

Запуск Ansible из Windows

Настройку хостов Windows для их управления из Ansible

обработку аутентификации и шифрования Windows

Автоматизацию задач Windowsпри помощи Ansible

Технические требования

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

Запуск Ansible в Windows

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

Официальную документацию по установке Ansible можно обнаружить тут.

Проверка вашей сборки

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

Windows 10— версии 1607 (сборка 14393) или последующие:

обратите внимание, что вам потребуется сборка 16215 или новее если вы желаете установить Linux через Microsoft Store

поддерживаются только 64- битные версии Windows 10

Windows Server 2016/2019— версии 1709 (сборка 16237) или последующие

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

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

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

Включение WSL

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

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

Установка Linux под WSL

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

Рисунок 3.1

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

Рисунок 3.2

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

Настройка хостов Windows для управления Ansible

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

Системные требования для автоматизации через Ansible

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

Рабочих мест : Windows 7 SP1, 8.1 и 10

Серверов : Windows Server 2008 SP2, 2008 R2 SP1, 2012, 2012 R2, 2016 и 2019

В WinRM под PowerShell 3.0 существует некая ошибка, которая ограничивает объем памяти, доступный данной службе, которая в свою очередь может приводить к отказам некоторых команд Ansible. Она разрешается путём обеспечения применения KB2842230 ко всем хостам, исполняющим PowerShell 3.0.

Включение модуля ожидания WinRM

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

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

Некое соответствующее CN название хоста

В соответствующем поле Enhanced Key Usage Server Authentication (1.3.6.1.5.5.7.3.1)

Рисунок 3.3

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

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

Рисунок 3.4

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

Подключение Ansible к Windows

Рисунок 3.5

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

В WinRM также возможна аутентификация на основе сертификатов, которая несёт в себе те же преимущества и риски, что и аутентификация на основе SSH.

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

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

Рисунок 3.6

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

Обработка аутентификации и шифрования Windows

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

Механизмы аутентификации

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

Базовый : Поддерживает только локальные учётные записи

Сертификат : Поддерживает только локальные учётные записи, концептуально аналогичен аутентификации SSH на основе ключа

Kerberos : Поддерживает учётные записи AD

NTLM : Поддерживает как локальные учётные записи, так и учётные записи AD

CredSSP : Поддерживает как локальные учётные записи, так и учётные записи AD

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

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

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

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

Требования для поддержки пакетов Kerberos в широком диапазоне ОС доступны в документации Ansible для Windows Remote Management.

Рисунок 3.7

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

Рисунок 3.8

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

Замечания относительно учётных записей

Подтверждение сертификатов

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

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

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

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

Рисунок 3.9

Автоматизация задач Windows при помощи Ansible

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

Выбор правильного модуля

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

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

Для модулей win_file и win_copy в соответствующей документации рекомендуется применять обратную косую черту ( \ ) когда мы имеем дело с удалёнными объектами (пути Windows).

В своих хостах Linux продолжайте применять левую косую черту ( / ).

Для содержащих пробелы путей применяйте одиночные кавычки (а не двойные).

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

Установка программного обеспечения

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

Вы можете изучить репозиторий chocolatey и найти дополнительные сведения о нём на chocolatey.org.

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

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

За пределами модулей

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

Выводы

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

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

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

Источник