Основы автоматизации настройки Windows Server с помощью Ansible
В этой статье я хочу описать работу с Ansible при помощи командной строки, продемонстрировав, насколько легко автоматизировать настройку Windows без особых усилий. Ansible представляет собой прекрасную платформу для обучения автоматизации, и он довольно широко используется в среде центров обработки данных и на уровне предприятий. Давайте взглянем на основы автоматизации настройки Windows Server, и на то, как легко сделать это с помощью управляющего сервера Ansible.
Основы автоматизации конфигурации Windows Server с помощью Ansible
В качестве моего управляющего сервера Ansible я использую сервер Ubuntu 16.04. Управляющий сервер – это место, с которого с помощью Ansible мы будем запускать наши модули, сценарии, задачи и т.п. В моем стенде этот сервер с Ansible Tower. Для использования Ansible и работе с этой системой из командной строки нам просто потребуется установить несколько небольших утилит. Поскольку я использую сервер с Tower, то мне не требуется устанавливать Ansible, так как он входит в состав установки Tower. Однако я все же пройду по всем простым шагам, нужным для установки Ansible.
Прежде всего, обновите сервер Ubuntu последними патчами.
Установите pip
Установите pywinrm
Установите ansible
Установка PIP в Ubuntu
Что такое PIP? Это альтернативный установщик пакетов python, которые многие используют для управления действиями с пакетами, связанными с python.
Для установки PIP в Ubuntu нужно выполнить команды:
Модуль Pywinrm позволяет Ansible взаимодействовать с сервисом WinRM на Windows. Для установки модуля Pywinrm после того, как был установлен pip, выполните команду:
sudo pip install pywinrm
Установка Ansible в Ubuntu
После того, как вы установили два указанных выше пакета, нужно установить сам Ansible:
sudo pip install ansible
Для проверки версии установленного ansible введите команду:
После того, как Ansible установлен на управляющем сервере, мы готовы начать взаимодействовать с сервером Windows.
Настройка WinRM для Ansible
Соединение с WinRM может оказаться непростым делом, особенно, если вы не находитесь в одном домене с ним. Существует несколько удобных команд WinRM, которые могут помочь установить соединение с WinRM с сервера Ansible, или с любого другого сервера.
Просмотр текущей конфигурации WinRM. Находясь в PowerShell, выполните следующие команды:
В результате будут выведена текущая конфигурация WinRM, доверенные хосты, настройки шифрования и т.п. Для моего лабораторного сервера Ansible я устанавливаю параметр AllowUnencrypted (работать без шифрования) в значение true, а в качестве значения TrustedHosts (доверенные хосты) ставлю *, что позволяет работать с любыми хостами.
Чтобы разрешить нешифрованный трафик, выполните команду:
set-item .\allowunencrypted $true
Чтобы добавить новый TrustedHost (доверенный хост) в конфигурацию, выполните команду:
Также вы можете указать конкретный хост, если вам это нужно.
Скрипт PowerShell для подключения Ansible при настройке соединения WinRM
Существует удобный конфигурационный PowerShell скрипт, доступный на Github. Он позволяет автоматически настроить конфигурации WinRM, файрвола, PowerShell Remoting и т.п. для подключения Ansible. Вы можете скачать готовый скрипт его по следующей ссылке: https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
Проверка соединения Ansible при помощи Win_Ping
Для проверки соединения из Ansible, вы можете использовать команду win_ping, которая использует соединение с WinRM для подключения к серверу. Она проверяет, все ли в соединении с WinRM работает так, как ожидается.
Создайте файл inventory.yml, в котором перечислены хосты, соединения с которыми вы хотите проверить. Файл inventory.yml, который создал я, имеет только один хост для проверки и выглядит следующим образом:
Для проверки соединения с хостами, указанными в инвентаризационном файле, используйте приведенную ниже команду. Команда выполняет проверку проверки WinRM соединения.
ansible test -i inventory.yml -m win_ping
Если все верно настроили, вы должны увидеть сообщение SUCCESS.
Теперь мы можем использовать автоматизацию Ansible для управления Windows Server.
Запуск команд из Ansible на Windows Server
Для начала работы мы можем использовать несколько основных команд. Мы можем взаимодействовать с нашим сервером, как, как если мы работали бы с ним с консоли. Ниже приводится команда для получения IP конфигурации на нашем Windows Server.
ansible test -i inventory.yml -m raw -a «ipconfig»
Мы также можем остановить, запустить и перезапустить любые службы:
ansible test -m win_service -a «name=Spooler state=stopped»
Заключение
Начать использовать Ansible для автоматизациии настройки Windows Server совсем не сложно. Мы можем быстро управлять настройками сервера, устанавливать соединение с WinRM, и затем выполнять команды на сервере. Далее мы познакомимся со сценариями для дальнейшей автоматизации и глубже погрузимся в автоматизацию конфигурации Windows Server при помощи Ansible.
Управляем через Ansible Windows системами
Однажды задался целью вот моя основная система — это Ubuntu LTS релизы, начинал с 12.04 и уже на 18.04 . Администрируя инфраструктуру часто приходится сталкиваться с различными системами, что-то под Wine запускаю, что-то под Virtualbox , подключаюсь как через SSH и т. д. И вот задался целью все-таки добить шаги посредством которых я смогу посредством инструмента ansible взаимодействовать с Windows системами.
Для себя выделил интересные этапы взаимодействия
если Windows система не в домене
если Windows система в домене
$ apt — cache show ansible | grep Version
$ sudo apt — get install ansible — y
А если добавить репозитарий Ansible то версия из него более новая:
$ sudo apt — get install — y software — properties — common
Предварительные действия которые нужно выполнить на Windows 7 Pro x64 SP1
Шаг №1: Изменить тип активной сети
Пуск — Панель управления — Центр управления сетями и общим доступом , чтобы активная расположение сети было не « Общественная сеть », а либо « Домашняя », либо « Сеть предприятия ». Делается это если в данной оснастке щелкнуть чуть ниже « Просмотр активных сетей » на « Общественная сеть » и изменить на « Домашняя сеть »:
или через консоль командной строки:
Служба «Служба удаленного управления Windows (WS-Management)» запускается.
Служба «Служба удаленного управления Windows (WS-Management)» успешно запущена.
Служба WinRM не настроена на прием запросов на компьютере.
Необходимо внести следующие изменения:
Задайте для типа службы WinRM значение отложенного автозапуска.
Настройте параметр LocalAccountTokenFilterPolicy, чтобы предоставлять административные права локальным пользователям удаленным образом.
Выполнить изменения [y/n]? y
Служба WinRM была обновлена для приема запросов.
Тип службы WinRM успешно изменен.
Параметр LocalAccountTokenFilterPolicy настроен так, чтобы предоставлять административные права локальным пользователям удаленным образом.
Служба WinRM не настроена на разрешение удаленного управления компьютером.
Необходимо внести следующие изменения:
Создайте прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.
Разрешите исключение брандмауэра WinRM.
Выполнить изменения [y/n]? y
Служба WinRM обновлена для удаленного управления.
Создан прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.
Исключение брандмауэра WinRM включено.
Отобразить текущую политику Аутентификации через winrm:
Глава 3. Ansible и Windows — не всё ограничено Linux
Содержание
Основная часть ра работы с Ansible выполнялась в ОС Linux; действительно, предыдущие две редакции данной книги целиком основывались на применении Ansible в среде сосредоточенной вокруг Linux. Тем не менее, большинство сред не являются таковыми и, по меньшей мере, вероятно могут иметь во всяком случае какое- то число серверов Microsoft Windows и настольных машин. С момента выхода второго издания этой книги в Ansible была проделана большая работа по созданию на самом деле надёжного межплатфориенного инструментария автоматизации, который одинаково чувствует себя как дома и центрах обработки данных Linux, и в центрах обработки данных Windows. Конечно, существуют фундаментальные отличия в тех способах, которыми работают хосты Windows и Linux, а потому не должно быть удивительным то, что имеются некие фундаментальные отличия между тем как Ansible автоматизирует задачи в Linux и как он автоматизирует задачи в Windows. Мы обсудим в этой главе такие основы чтобы снабдить вас солидной скалой основы для начала автоматизации ваших задач Windows при помощи Ansible, а именно, рассмотрим следующие области:
Настройку хостов 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
Кликните по кнопке Get и дождитесь завершения установки. Если вы работаете под Windows 10 и ваша сборка более ранняя нежели 16215, или на самом деле Windows Server 2019, тогда установка Linux является слегка более сложным процессом. Прежде всего выгрузите предпочитаемый вами дистрибутив Linux с Microsoft — к примеру, Ubuntu можно выгрузить при помощи следующей команды PowerShell:
После успешной выгрузки разархивируйте соответствующий файл Ubuntu.appx — он может быть ракрыт в любое местоположение на вашем системном (загрузочном) диске, обычно это C: . Если вы желаете оставить ваш дистрибутив Linux частным, его можно раскрыть куда- нибудь внутри каталога вашего профиля, в противном случае вы можете раскрыть этот файл на своём системном диске. К примеру, приводимые ниже команды PowerShell раскроют этот архив в C:\WSL\ :
по завершению вы можете запустить свой вновь установленный дистрибутив Linux при помощи названия исполняемого файла в самом вашем дистрибутиве. В случае нашего примера с Ubuntu вам придётся запустить следующее:
Когда вы запускаете вновь установленный дистрибутив Linux, будь то установка через Microsoft Store, либо установка вручную, он инициализирует себя самостоятельно. В качестве части этого процесса, он запросит у вас создание новой учётной записи пользователя. Обратите внимание, пожалуйста, что эта учётная запись не зависит от имени пользователя Windows и его пароля, а потому убедитесь что вы запомнили установленный тут пароль! Он будет нужен вам при всяком запуске командчерез sudo (к примеру), хотя, как и в случае со всяким прочим дистрибутивом Linux, если пожелаете, вы можете настраивать это поведение индивидуально через /etc/sudoers . Это продемонстрировано на приводимом ниже снимке экрана:
Рисунок 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
Само применение WinRM означает широкий массив поддержки новых и старых версий Windows — под капотом будет работать почти любая версия Windows, которая поддерживают следующее:
На практике это означает, что будут поддерживаться следующие версии Windows, предоставляя соответствие предыдущим требованиям:
Рабочих мест : Windows 7 SP1, 8.1 и 10
Серверов : Windows Server 2008 SP2, 2008 R2 SP1, 2012, 2012 R2, 2016 и 2019
Отметим, что более ранние версии ОС (такие как Windows 7 или Server 2008) не снабжены .NET 4.0 или PowerShell 3.0, и их потребуется установить прежде чем вы сможете воспользоваться Ansible. Обратите внимание, что поддерживаются и более новые версии PowerShell и, в разной степени, могут иметься исправления безопасности для .NET 4.0. Учитывая это, в бизнес- среде скорее всего уже могут иметься на своём месте политики и процедуры для такого рода вещей, причём инкорпорирование более старых ОС нежели перечисленные выходит за рамки данного текста.
Совет
В WinRM под PowerShell 3.0 существует некая ошибка, которая ограничивает объем памяти, доступный данной службе, которая в свою очередь может приводить к отказам некоторых команд Ansible. Она разрешается путём обеспечения применения KB2842230 ко всем хостам, исполняющим PowerShell 3.0.
Включение модуля ожидания WinRM
После того как все подробно описанные ранее системные требования приведены в соответствие, основной остающейся задачей является включение необходимого ожидания WinRM. Когда мы этого добьёмся, мы сможем на самом деле запускать задачи Ansible в самих хостах Windows! WinRM может работать как поверх протокола HTTP, так и поверх HTTPS и, хотя он быстрее и проще настраивается на включение и работу поверх обычного HTTP, это оставит вас уязвимым для перехватчиков пакетов и потенциальной возможности выявления чувствительных данных в вашей сетевой среде. Это в особенности справедливо коггда применяется базовая аутентификация. По умолчанию, и скорее всего это не будет неожиданным, Windows не допускает удалённого управления при помощи WinRM поверх HTTP или с применением базовой аутентификации.
Иногда базовой аутентификации достаточно (скажем, в средах разработки), а если применяется она, тогда мы несомненно желаем включить в качестве транспорта для WinRM HTTPS! Однако позднее в этой главе мы рассмотрим аутентификацию Kerberos, которая является более предпочтительной, а также включим использование доменных учётных записей. На данный момент, однако, для демонстрации самого процесса подключения Ansible к некому хосту Windows с очень небольшим объёмом безопасности, мы включим WinRM поверх HTTPS с применением самостоятельно подписываемых сертификатов и включим базовую аутентификацию чтобы сделать для нас возможной работу с учётной записью локального Administrator .
Для работы WinRM поверх HTTPS, должен иметься сертификат, который имеет следующее:
Некое соответствующее CN название хоста
В соответствующем поле Enhanced Key Usage Server Authentication (1.3.6.1.5.5.7.3.1)
В идеале следует сгенерировать некий центральный CA ( certificate authority ) для предотвращения атак с человеком в промежутке и тому подобного — об этом позднее. Для простоты мы создадим самостоятельно подписываемый сертификат. В PowerShell выполните следующую команду для выработки подходящего сертификата:
Замечание
Данная команда New-SelfSignedCertificate доступна только в более новых версиях Windows — если она не доступна в ваше системе, рассмотрите возможность применение сценария PowerShell автоматизации, предоставляемого Ansible.
Это должно выдать нечто подобное приводимому ниже — обратите внимание на отпечаток пальца данного сертификата, так как он потребуется вам позднее:
Рисунок 3.3
Поместив на место необходимый сертификат, мы теперь можем настроить некое новое ожидание WinRM при помощи такой команды:
В случае успеха данная команда настроит ожидание HTTPS WinRM по порту 5986 с самостоятельно подписанным сертификатом, который мы выработали ранее. Чтобы проверить эту настройку, нам необходимо выполнить ещё два шага — открыть данный порт в имеющемся межсетевом экране и включить базовую аутентификацию с тем, чтобы мы могли проверять использование имеющейся локальной учётной записи Administrator . Этого мы достигаем при помощи двух следующих команд:
Для наших предыдущих команд вы должны получить подобный вывод:
Рисунок 3.4
Эти команды были разбиты по отдельности чтобы снабдить нас некой идеей того процесса, который вовлечён в настройку хоста Windows для соединения с Ansible. Для автоматизации развёртываний, и систем в которых не доступен New-SelfSignedCertificate , рассмотрите возможность применения сценария ConfigureRemotingForAnsible.ps1 , доступного на официальном сайте Ansible здесь.
Этот сценарий осуществляет все выполненные нами ранее шаги (и многое другое) и может быть выгружен и запущен в Powershell следующим образом:
Имеется множество иных путей раскрутки необходимых настроек WinRM для Ansible, включая групповые политики — однако этот раздел в достаточной степени описал все шаги, вовлечённые для успешного развёртывания в дальнейшем.
Подключение Ansible к Windows
Раз WinRM настроен, заставить Ansible общаться с Windows достаточно просто, предоставив вам на заметку в памяти два предостережения — это ожидает применение протокола SSH, а если вы не определите некую учётную запись пользователя, оно попытается применять ту же самую учётную запись пользователя, с которой работал Ansible при выполнении подключения. А это скорее всего не будет работать с именем пользователя Windows.
Кроме того, обратите внимание, что для успешного подключения требуется установка модуля Python winrm . Он не всегда устанавливается по умолчанию, поэтому будет не лишним проверить его наличие в вашей системе Ansible прежде чем приступать к работе с хостами Windows. Если он отсутствует, вы увидите нечто подобное приводимой на следующем снимке экрана ошибке:
Рисунок 3.5
Если вы видите такую ошибку, вам потребуется установить данный модуль прежде чем продолжить всё остальное. Должна существовать предварительно упакованная версия, доступная для вашей ОС — например, для CentOS 7 вы можете установить его при помощи такой команды:
Если упакованная версия недоступна, установите его напрямую из pip , воспользовавшись такой командой:
По окончанию этого мы можем проверить видимость того что настроенная нами ранее конфигурация WinRM работает успешно. Для подключения на основе SSH имеется модуль Ansible с названием ping , который осуществляет полномасштабную всеобщую проверку для гарантии связи, успешной аутентификации и доступной среды Python в некой удалённой системе. Аналогично имеется модуль с названием win_ping , который выполняет аналогичную проверку под Windows.
В своей среде проверки я бы подготовил некую опись (inventory) следующим образом для подключения к моему заново настроенному хосту Windows:
Обратите внимание на особые переменные начинающиеся с ansible_ , которые были установлены в разделе windows:vars данного плейбука. На данном этапе они должны самостоятельно пояснять себя, поскольку они рассматривались ранее в этой книге, но в особенности обратите внимание на переменную ansible_winrm_server_cert_validation , которую требуется установить чтобы игнорировать работу с самостоятельно подписанными сертификатами. Очевидно, что в примере реального мира вы оставите параметр ansible_password с открытым текстом — его следует либо поместить в Ansible Vault, либо запрашивать при запуске при помощи параметра —ask-pass .
Замечание
В 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, 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 это выглядело бы так:
В Ubuntu 16.04 вы бы установили такие пакеты:
Замечание
Требования для поддержки пакетов Kerberos в широком диапазоне ОС доступны в документации Ansible для Windows Remote Management.
Дополнительно к этим пакетам нам также потребуется установить модуль Python pywinrm[kerberos] . Его доступность будет отличаться — в CentOS 7 он не доступен в качестве RPM, поэтому нам потребуется установить его через pip следующим образом:
Замечание
Обратите внимание, что для сборки через pip данного модуля необходим gcc — его можно удалить по окончанию если он более не требуется.
После этого проверьте что ваш сервер 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 выглядит следующим образом:
Обратите внимание на заглавные буквы — это важно! Проверьте свою интеграцию Kerberos при помощи команды kinit с некой известной вам учётной записью этого домена. Вот некий пример использования Domain Administrator для моего проверочного домена:
Рисунок 3.7
Наконец, давайте создадим опись (inventory) хоста Windows — обратите внимание, что она практически идентична применявшейся нами в примере базовой аутентификации; только на этот раз нам придётся определить домен Kerberos после указанного имени пользователя:
Теперь мы можем проверить подключение как и ранее:
Рисунок 3.8
Успешно! Наш предыдущий результат отображает успешное повсеместное подключение к Windows, включая успешную аутентификацию и доступ к нашей подсистеме WinRM.
Замечания относительно учётных записей
По умолчанию WinRM настроен на разрешение управления только участникам имеющейся группы локальных Administrators в конкретном хосте Windows. Это не обязательно должна быть сама учётная запись Administrator — мы применяем её здесь исключительно в целях демонстрации. Имеется возможность применения менее привилегированных учётных записей для управления WinRM, однако их применение скорее всего зарекомендует себя ограниченным, ибо большинство команд Ansible требует некой степени привилегированного доступа. Если вы желаете иметь доступной для Ansible через WinRM менее привилегированную учётную запись, выполните в этом хосте следующую команду:
Исполнение этой команды откроет блок диалога 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. Вы можете сделать это (если пока не сделали этого) при помощи команды, подобной следующей:
Естественно, замените указанное значение пути к сертификату FilePath тем, которое соответствует местоположению вашего собственного сертификата. Если вам это требуется, вы можете удалить любое созданное ранее ожидание HTTPS WinRM при помощи такой команды:
Затем воспользуйтесь имеющимся дактилоскопическим отпечатком своего импортированного сертификата создайте новое ожидание:
Теперь перейдём к нашему контроллеру Ansible. Первое что нам следует сделать, это импортировать свой сертификат CA для ожидания WinRM в пакет CA для вашей ОС. Сам метод и местоположение для него будут различными для разных ОС, но что касается CenOS 7, вы можете поместить необходимый сертификат CA в /etc/pki/ca-trust/source/anchors/ .
После того как это сделано, исполните следующие команды:
Наконец, нам требуется сообщить 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 теперь подтверждаются в явном виде:
Если мы снова запустим свой тест ping , мы теперь должны увидеть SUCCESS :
Рисунок 3.9
Очевидно, что мы могли бы улучшить выработку своего сертификата для удаления предостережения subjectAltName , но на данный момент оно демонстрирует подключение Ansible к Windows, причём с аутентификацией Kerberos для учётной записи домена и с полным удостоверением SSL. До сих пор для демонстрации этого нам приходилось применять модуль Ansible win_ping для провеки подключения. Хотя плейбуки Windows для Ansible мгли бы занять свою собственную книгу целиком, давайте завершим эту главу нескольким простыми образцами плейбуков.
Автоматизация задач Windows при помощи Ansible
Полный перечень модулей Windows для Ansible доступен по этой ссылке и следует отметить, что хотя вы можете применять все знакомые вам конструкции Ansible с хостами Windows, такие как vars , handlers и blocks , при определении tasks вы должны применять специфичные для Windows модули.
В этой части данной главы мы исполним несколько примеров плейбуков Windows чтобы выделить несколько моментов, о которых вам следует знать при написании плейбуков для Windows.
Выбор правильного модуля
Когда вы запускаете Ansible для некого сервера Linux и желаете создать некий каталог, а затем скопировать в него файл, вы должны были применять в плейбуке соответствующие модули Ansible file и copy , что выглядит как- то так:
Однако в Windows этот плейбук завершился бы неудачно при его исполнении, поскольку модули file и copy не совместимы с WinRM. Как результат, некий эквивалентный плейбук для исполнения той же самой задачи, но на этот раз вWindows, будет выглядеть таким образом:
Отметим следующие отличия между данными двумя плейбуками:
Вместо привычных модулей file и copy для Windows применяются в тех же местах win_file и win_copy .
Для модулей win_file и win_copy в соответствующей документации рекомендуется применять обратную косую черту ( \ ) когда мы имеем дело с удалёнными объектами (пути Windows).
В своих хостах Linux продолжайте применять левую косую черту ( / ).
Для содержащих пробелы путей применяйте одиночные кавычки (а не двойные).
Важно всегда обращаться за консультацией к имеющейся документации для каждого индивидуального модуля, применяемого в ваших плейбуках. Например, при просмотре документации для модуля win_copy вы обнаружите рекомендацию для обменов большими файлами применять модуль win_get_url , так как имеющийся механизм обмена WinRM не очень эффективен.
Также отметим, что когда некое название файла содержит определённые специальные символы (например, квадратные скобки), их следует экранировать при помощи специального экранирующего (escape) символа PowerShell, ` . Например, приводимая ниже задача установила бы файл c:\temp\setupdownloader_[aaff].exe :
Имеется множество прочих модулей 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.
За пределами модулей
точно также как и для любой платформы, может настать время, когда у какого- то модуля модуля не достаёт точно соответствующей функциональности. Хотя для этого жизнеспособным решением является написание собственного модуля (или изменение уже имеющегося), порой требуется какое- то немедленной решение. Для этой цели на помощь приходят модули win_command и win_shell — ими можно воспользоваться для запуска буквальных команд PowerShell в Windows. В официальной документации Ansible присутствует множетво примеров, к примеру следующий код создаст при помощи PowerShell каталог C:\Mastery :
Для этой задачи мы можем даже вернуться к традиционной оболочке 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.
