Dataenginer

What’s Next

Ansible can be used to do pretty much anything and over time, more and more modules/features are being added to cover the missing ground. Some of the hurdles of using Ansible to control Windows hosts are;

• WinRM is a lot slower than SSH and things like task execution and copying files take longer to complete
• A base requirement for Ansible is PowerShell 3.0 or newer, the base image of Windows 7, Server 2008, and Server 2008 R2 do not meet this requirement. This means certain hosts require further bootstrapping steps before it can be used with Ansible
• WinRM runs in a special process with different security restrictions, things like accessing network drives or accessing certain internal APIs like Windows Updates do not normally work without workarounds

The 1st 2 hurdles are not something that can be easily fixed in Ansible as they are fundamental limitations of WinRM but the last hurdle can be overcome. Over time, more and more features like support for credential delegation over and auth as well as become support have helped to alleviate these problems. Going forward here are some of the things being looked at;

• Using SSH as a transport mechanism with the Win32-OpenSSH project
• Further improve the become process to allow things like password-less become for local accounts
• Help alleviate the bootstrapping barrier and find ways to overcome some of the restrictions we have with base OS installed

There is definitely more in the pipeline than what I have mentions above but they are some of the key areas seen as where Ansible for Windows should focus on. Even so, if you are someone that manages Windows hosts with Ansible and feel like something is lacking or are looking for a killer feature not currently available, feel free to share your ideas. The best places to share this stuff would be;

• raising a Github issue or PR at the Ansible github repo
• post a comment on the Ansible Google Group page for
• talk over #ansible or #ansible-windows on the Freenode IRC network

Демонстрация работы с Ansible через Ad-hoc-команды

Демонстрационный стенд состоит из трех машин – две на Windows и одна – управляющая нода на CentOS.

Чтобы настроить Windows-хосты для работы с Ansible, запускаем на них скрипт ConfigureRemotingForAnsible.ps1 (как его запустить было продемонстрировано ранее).

Здесь осуществляется подготовка и запуск службы Windows Remote Management. На этом настройка на Windows-хосте закончена.

Теперь идем на наш управляющий узел – я покажу, как в нем настроен файл hosts, который находится по пути /etc/ansible/hosts.

Здесь указаны две наши windows-машины – 1cdevops01 и 1cdevops02, которые объединены в группу .

Клонируем к себе репозиторий с примерами скриптов и рассмотрим его структуру.

В корне репозитория есть папка group_vars. В ней лежит файл onecservers – в котором хранятся параметры для подключения к группе серверов с таким именем.

Когда Ansible будет подключаться к хостам группы onecservers (нашим Windows-хостам), он будет использовать эти параметры.

Т.е. он будет подключаться под пользователем devops через winrm, не используя никакие сертификаты (ansible_winrm_server_cert_validation: ignore).

Посмотрим, как отработают примеры.

Первый пример у нас – это модуль win_ping.

Перейдем в корень репозитория и просто пропингуем наши два windows хоста командой:

Параметр —ask-pass означает, что Ansible сейчас запросит пароль, под которым я подключусь к удаленным хостам.

Вот мы получили ответ от каждой машины – pong и все зеленое.

Дальше мы выполним команду whoami на удаленных хостах

Ansible вывел результат выполнения этой команды.

Дальше – пример про идемпотентность. Используя модуль win_service я создам на сервере тестовую службу Ansible_example_service командой.

Перейдем на удаленный узел 1cdevops01 и проверим, что в списке появилась служба Ansible_example_service.

Еще раз выполним команду – теперь она показана зеленым. Свойства changed = false, exists = true. Это значит, что Ansible пропустил ее выполнение – идемпотентность заключается в том, что при повторном выполнении результат первоначального применения не изменяется.

Дальше – удалим эту службу. Тоже используя модуль win_service.

Все, служба удалилась. Т.е. одним модулем win_service мы управляем службами на удаленных хостах.

[defaults] section

Ansible’s configuration file is divided into several sections. The main section that we will concentrate on is the general section.

inventory

• This points to the path of the inventory file which contains hostname or IP address details of managed nodes.
• On most systems, it points to , as follows:

inventory = /etc/ansible/hosts

roles_path

This contains the path of default roles directory where the Ansible playbook should look for additional roles:

roles_path = /etc/ansible/roles

log_path

• This defines the log files where Ansible should be storing its log.
• The log file and path must have enough permission for the user running Ansible to perform read and write operation.

An example is as follows:

log_path = /var/log/ansible.log

retry_files_enabled

• This is a parameter to enable the retry feature, allowing Ansible to create a file whenever a playbook fails.
• It is better to keep this disabled unless you really need it.
• This is because it creates multiple files and clogs your playbook folder with old failed tasks that are already logged in both the Ansible log and the dashboard’s playbook execution status section.

Here is an example of the parameter disabled:

Advertisement

retry_files_enabled = False

host_keychecking

• A host key is assigned for individual managed nodes.
• Now it is possible that the client nodes gets re-installed multiple times which can cause Ansible to throw warning at the time of initiating the connection.
• Disabling this parameter will make Ansible ignore the error messages related to the known_hosts keys:

host_key_checking = False

forks

• This is a parameter to define the number of parallel tasks executed to the client hosts.
• The default number is five, to save on both resources and network bandwidth.
• If there are enough resources and a large bandwidth to serve many hosts, it can be raised to the maximum number of hosts as follows:

forks = 5

sudo_user and ask_sudo_pass

• These are both legacy parameters.
• It is still possible to use them with the current version of Ansible, but they are not reliable.
• It is recommended to set these parameters when creating groups in Ansible’s inventory

sudo_user = install
ask_sudo_pass = True

remote_port

• This is a parameter to indicate which port is to be used by SSH on the client hosts which by default is 22 in most cases.
• It is also a parameter that is better set in the inventory groups:

remote_port = 22

nocolor

• This is an optional parameter.
• It allows you to show different colors for the Ansible tasks and playbook to indicate errors and successes.
• You can set to 1 if you don’t want colors, or export

nocolor = 0

Выполнение произвольных команд на машинах из инвентаря

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

ansible -i test all -a «ls -la /home/ansible»

db1 | SUCCESS | rc=0 >>

total 16

drwx------. 4 ansible ansible 108 Nov 22 13:08 .

drwxr-xr-x. 3 root    root     21 Nov 22 12:55 ..

drwx------. 3 ansible ansible  17 Nov 22 12:58 .ansible

-rw-r--r--. 1 ansible ansible  18 Aug  2  2016 .bash_logout

-rw-r--r--. 1 ansible ansible 193 Aug  2  2016 .bash_profile

-rw-r--r--. 1 ansible ansible 231 Aug  2  2016 .bashrc

drwx------. 2 ansible ansible  29 Nov 22 12:55 .ssh

-rwx------. 1 ansible ansible  22 Nov 22 13:07 .tmux.conf

remsmed2 | SUCCESS | rc=0 >>

total 28

drwx------. 4 ansible ansible 4096 Nov 22 11:00 .

drwxr-xr-x. 4 root    root      35 Nov 22 10:34 ..

drwx------. 3 ansible ansible   17 Nov 20 13:58 .ansible

-rw-------. 1 ansible ansible   43 Nov 22 11:03 .bash_history

-rw-r--r--. 1 ansible ansible   18 May 26 21:49 .bash_logout

-rw-r--r--. 1 ansible ansible  193 May 26 21:49 .bash_profile

-rw-r--r--. 1 ansible ansible  231 May 26 21:49 .bashrc

drwx------. 2 ansible ansible   29 Nov 20 13:58 .ssh

-rwx------. 1 ansible ansible   22 Nov 20 14:01 .tmux.conf

-rw-------. 1 ansible ansible   54 Nov 22 11:00 .Xauthority

Синтаксис команды:

• -i путь к файлу инвентаря, 
• all — для всех машин в инвентаре (можно указывать по
  отдельности или группами, а также  использованием *),
• -a команда, подлежащая выполнению.

Простой сценарий

Замечание: Ниже пойдет речь о ролях (roles) и сценариях (playbooks). В принципе
можно не использовать роли, а описывать все задачи непосредственно в сценариях.
Однако, такой подход противоречит рекомендациям разработчиков и не оптимален
для повторного использования кода. Предполагается, что в примере книги
сценариев лежат в /home/ansible/playbooks а роли
в /home/ansible/playbooks/roles.

Шаг 5 — Запустите несколько основных команд

Давайте запустим некоторые основные команды на серверах с помощью Ansible. Для запуска любой команды на сервере используется следующий формат.

$ ansible all -a "command" -u <username>

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

Во-первых, давайте проверим использование диска на всех наших серверах.

$ ansible all -a "df -h" -u root
server1 | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           198M  972K  197M   1% /run
/dev/sda2        50G  3.9G   44G   9% /
tmpfs           989M     0  989M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           198M  4.0K  198M   1% /run/user/1000

server2 | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           198M  922K  197M   1% /run
/dev/sda2        50G  4.9G   43G  10% /
tmpfs           989M     0  989M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           198M  4.0K  198M   1% /run/user/1000

Таргетинг на отдельные хосты и группы

До сих пор мы запускали команды на всех удаленных серверах одновременно. Но это не всегда так. Чтобы запустить команду только на одном сервере, вы должны использовать следующий формат.

$ ansible server1 -a "uptime" -u root
server1 | CHANGED | rc=0 >>
 21:38:26 up 11 min,  2 users,  load average: 0.00, 0.20, 0.19

Приведенная выше команда проверяет время безотказной работы на server1 из группы инвентаризации.

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

$ ansible server1:server2 -m ping -u root

Вы также можете настроить таргетинг на группы или подгруппы непосредственно из файла инвентаризации.

$ ansible groupname -m ping -u <username>

Обновите все серверы

В этом руководстве мы предполагаем, что все удаленные серверы работают под управлением ОС Debian или Ubuntu.

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

$ ansible all -m apt -a "update_cache=yes upgrade=yes" -u root

Параметр определяет модуль для запуска Ansible. Параметр относится к аргументам или командам для связанного модуля. Здесь мы используем модуль Ansible для обновления серверов точно так же, как мы использовали модуль в нашем последнем примере. обновляет кэш APT на сервере, а указывает Ansible запустить . команда.

Если вы используете пользователя , как описано выше, вам необходимо изменить команду , чтобы она выполнялась с повышенными привилегиями sudo.

$ ansible server2 -m apt -a "update_cache=yes upgrade=yes" -K -b -u ansible

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

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

$ ansible all -a "reboot" -u root

Это были лишь некоторые из основных команд, которые вы можете запускать с помощью Ansible.

Обновление платформы 1С тонкого клиента с вебсервера без публикации базы данных, когда сервер 1С ПРОФ.

Обновление платформы 1С: тонкого клиента с вебсервера описывается

здесь:

https://its.1c.ru/db/v8316doc#bookmark:adm:TI000001058, (11.2.2. Обновление через диалог публикации на веб-сервере)

и здесь:

https://its.1c.ru/db/v8319doc#bookmark:adm:TI000000428, (6.2. Получение дистрибутива клиентского приложения) — доступно только для КОРП

Для ПРОФ реализация полностью описана в данной статье. Выражаю благодарность Панюшкину Михаилу Михайловичу за разбор задачи и доведение ее до практического результата.

Обновление не проходит если например предварительно установка выполнялась регламентными политиками и есть в папке conf файл adminstall.cfg
Этот файл следует удалить, чтобы данная установка тонкого клиента проходила успешно

Применяется только для системы «1С:Предприятие» под ОС Windows.
Файл adminstall.cfg указывает на то, что установка системы программ «1С:Предприятие» выполнялась с использованием средств администрирования ОС Windows. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие» и представляет собой текстовый документ в кодировке UTF-8.
В файле может располагаться единственная строка, определяющая вариант установки:

AdmInstall=

Описывает режим установки:
Logon — установка выполнена с помощью logon-скрипта во время входа пользователя в домен.
Restart — установка выполнена с помощью групповых политик.

46

What is Ansible?

What is Ansible some of you may ask? Well according to ansible.com

Now this is a very vague statement that can mean multiple things based on whoever is looking at it. To myself, Ansible is an easy way to manage multiple servers and have it conform to a state that you define without having to write any shell scripts.

Compared to other configuration management tools like Chef, Puppet, SaltStack, Ansible can achieve the same thing but in my mind the key areas where it shines are;

• No agent’s are required on the client hosts, Ansible uses in built technologies like SSH, and for Windows WinRM, to communicate
• Ansible uses yaml to organise actions to be run, unlike other tools there is no pre-requisites to know any programming languages like Ruby or Python to create an Ansible playbook
• It works with a wide variety of platforms, Ansible can run manage pretty much anything with an SSH server which can cover network devices, Unix OS’ like AIX and Solaris and the standard Linux distros like RHEL, Ubuntu. I’ve even seen it been used to manage an IBM mainframe running Z/OS
• It is open-source project with a large and passionate community behind it, this allows you to get down and dirty into the internals to see how it works as well as having multiple people worldwide contributing to Ansible and adding more and more modules daily

Now there are many blog posts, talks, videos about Ansible that will give it more justice than what I can do so I’ll stop while I’m ahead

Ansible – краткий обзор#

Ansible – современный инструмент CM, который облегчает настройку удаленных серверов благодаря своей простоте и низкому порогу вхождения.

Сценарии Ansible пишутся на YAML, что позволяет создавать сложные сценарии проще, чем другими инструментами этой же категории.

Ansible не требует установки специального ПО на управляемые хосты – доступ осуществляется по стандартному протоколу SSH. Установить Ansible нужно только на хост, с которого будет происходить управление другими хостами.

Ansible предоставляет следующие базовые функции:

• Идемпотентность. Ansible отслеживает состояние ресурсов в целевых управляемых системах для исключения повторения задач, которые уже были выполнены. Пример: если требуемый пакет уже установлен в системе, Ansible не будет пытаться установить его. Основная цель Ansible состоит в том, чтобы система достигала/сохраняла желаемое состояние, даже если процесс запускается несколько раз. При запуске плейбука выдается отчет о состоянии каждой задачи и статус внесла ли задача изменение в системе;
• Переменные, условные выражения и циклы. При составлении сценария автоматизации можно использовать переменные, условные выражения и циклы. Это позволяет сделать автоматизацию более универсальной и эффективной;
• Факты о системе. Ansible собирает подробную информацию об управляемых нодах и предоставляет ее в виде глобальных переменных. Собранные факты можно использовать в плейбуках;
• Шаблонизация. В качестве системы шаблонов Ansible использует Jinja2 Python. Шаблоны упрощают параметризацию конфигурационных файлов. Например: вы можете создать шаблон для настройки демона SSH и применить его на нескольких серверах, повесив на разные порты в зависимости от заданных переменных;
• Поддержка модулей и плагинов. В поставку Ansible включено множество встроенных модулей, а это значительно упрощает написание общих задач (установка пакетов через /), работу с распростаненным ПО (MySQL, PostgreSQL, MongoDB, etc) и управление зависимостями (composer, npm, etc). Если в стандартной поставке Ansible не нашлось нужного модуля, вы всегда можете написать свой на Python;

Настройка WinRM для Ansible

Соединение с WinRM может оказаться непростым делом, особенно, если вы не находитесь в одном домене с ним. Существует несколько удобных команд WinRM, которые могут помочь установить соединение с WinRM с сервера Ansible, или с любого другого сервера.

Просмотр текущей конфигурации WinRM. Находясь в PowerShell, выполните следующие команды:

В результате будут выведена текущая конфигурация WinRM, доверенные хосты, настройки шифрования и т.п. Для моего лабораторного сервера Ansible я устанавливаю параметр AllowUnencrypted (работать без шифрования) в значение true, а в качестве значения TrustedHosts (доверенные хосты) ставлю *, что позволяет работать с любыми хостами.

Чтобы разрешить нешифрованный трафик, выполните команду:

Чтобы добавить новый TrustedHost (доверенный хост) в конфигурацию, выполните команду:

Также вы можете указать конкретный хост, если вам это нужно.

Configuring the Ansible Inventory

Now that we have Ansible installed and a fully functioning Windows host up and running, we need to create an inventory file so Ansible knows how to connect to the Windows host. Create a new file called with the following contents:

What this inventory tell’s Ansible is that there is a group called and it contains 1 host called . It then set’s the actual hostname it connects with to and the various args to let Ansible know how to connect over WinRM. In a normal scenario, the variable does not need to be defined and Ansible will connect to a host using the host name specified but in our case we want to still connect over the localhost loopback but display a more human friendly name in the output.

Now that Ansible knows what host to connect to, it needs to know how to connect to it. By default it will use SSH but this won’t work for Windows so we need to specify . There are a lot more options available to configure WinRM but I find the ones set above are what most people need or will ultimately use. Here is a brief explanation of what each variable does:

• ansible_user: simply the username that will be used in the connection, this can be a local or domain user and it should be a member of the local Administrators group
• ansible_password: do I need to explain this one
• anisble_connection: tells Ansible to use the WinRM connection plugin, this must be set for Ansible to connect otherwise it will try and fail to use SSH
• ansible_port: will default to 5985 or 5986 depending on what is set to and if the scheme isn’t set will default to 5986. In our case we need to set a custom port as Vagrant forwards 5986 to 55986 so that is what we will connect to
• ansible_winrm_transport: a weirdly named argument that specifies what auth protocol to use, I like setting this explicitly so I know for sure what it is using.
• ansible_winrm_server_cert_validation: when using self signed certificates, this must be set to otherwise it will fail.

The variable is pretty important as it determines how your credentials are sent and validated on the server. It also affects on what type of account that can be used in the connection. Here is a basic overview on the options that are available

• basic: the credentials are base64 encoded and sent to the server, this is quite insecure, especially when not running over HTTPS, and should be avoided where possible
• certificate: similar to SSH keys but not quite the same, certificate auth uses X509 certificates that are mapped to a local user but due to the complexity of the setup required it is not very popular
• ntlm: the all-rounder of auth options, an older Microsoft protocol that works in the majority of situations but is less secure than others
• kerberos: the best option to use when dealing with domain accounts, supports credential delegation and is one of the most secure options to choose from
• credssp: useful when credential delegation is required but Kerberos is not available

Once the inventory has been set up, you can test your setup by running

If you don’t get a success message, then something has gone wrong so double check your setup and verify you followed each step. The module shows that Ansible can communicate with the new host over WinRM but say we wanted to create a new directory we can use the win_file module instead. The argument specifies the module to use while allows you to specify the arguments to the module like , and so on. To create a new folder called in the C drive, run the following command:

On the Virtualbox session, you should now see the newly created folder.

The beauty of most Ansible modules is that they are idempotent, if you were to run the command again no changed will occur.

While you can continue to run Ansible modules in this ad-hoc fashion, it is best to start using playbooks to group tasks together. The added benefit of using a playbook is that there is not escaping rules when dealing with backslashes and you can take advantage of host vars.

Запуск модулей Ansible

Модули Ansible – это фрагменты кода, которые можно вызывать из плейбука, а также из командной строки для упрощения выполнения процедур на удаленных нодах. Например, модуль apt используется для управления системными пакетами в Ubuntu, а модуль user – для управления пользователями системы. Команда ping, которую мы уже использовали в этом мануале, также является модулем, обычно он применяется для проверки соединения между главной нодой и хостами.

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

Чтобы выполнить модуль с аргументами, добавьте в команду флаг -a, а затем соответствующие параметры в двойных кавычках:

В качестве примера мы используем модуль apt для установки пакета tree на server1:

Определение целей для выполнения команд

При выполнении специальных команд Ansible вы можете настроить целевые хосты, а также любую комбинацию групп, хостов и подгрупп. Например, вот как можно проверить подключение каждого хоста в группе servers:

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

Чтобы добавить в шаблон исключение, используйте восклицательный знак, поставив перед ним escape-символ \, как показано ниже. Эта команда будет запущена на всех серверах из группы group1, кроме server2:

Если вам нужно запустить команду только на серверах, которые входят и в group1, и group2, вам следует использовать символ &. Не забудьте поставить перед ним обратный слеш:

За дополнительной информацией о том, как использовать шаблоны при определении целей для команд, обратитесь к разделу 5 мануала Создание файла инвентаря Ansible.

Terraform

The aim is to simply create a record in the Terraform state file for the dynamic inventory script using terraform.py . Preferably created a new module which will be used in main.tf.

The directory structure is kept as standard:

However, if you look closely, there is an additional ./module/terraform-aws-ansible folder. This module is referred in ./maint.tf .

Let’s have a close look at the main.tf under module : module/terraform-aws-ansible

• The provider is ansible 

• provider "ansible" {
  version = ">=0.0.3"
  }
  # Remote
  resource "ansible_group" "remote" {
  count = "${var.local_enabled ? 0 : 1}"
  
  inventory_group_name = "${var.group_name}"
  vars = "${var.group_vars}"
  }
  resource "ansible_host" "remote" {
  count = "${var.counter >= 1 ? var.counter : 0}"
  
  inventory_hostname = "${element(var.hosts, count.index)}"
  groups = 
  vars = "${var.host_vars}"
  }
  # Local
  resource "ansible_group" "local" {
  count = "${var.local_enabled ? 1 : 0}"
  
  inventory_group_name = "${var.group_name}"
  vars = "${var.group_vars}"
  }
  resource "ansible_host" "local" {
  count = "${var.local_enabled ? 1 : 0}"
  
  inventory_hostname = "${element(var.hosts, count.index)}"
  groups = 
  vars = "${var.host_vars}"
  }
  

Let’s have a close look at the main.tf under module : active-directory:

This section only covers the part of terraform which will provide records in state file that will be used by inventory script and does not include the provision of workspace and resources. 

• Import the above module here
• This will create  record in the Terraform state file for the dynamic inventory script to dig for. Example Output :

  "resources": {
  "ansible_group.remote": {
  "type": "ansible_group",
  "depends_on": [],
  ....
  

• Thinking ahead here there are few variables that will be needed during DC configuration with ansible. Like admin user account , password, subnet IP, host ips.

The above is variables are added in the imported module :

module "dc_ansible" {
source = "../module/terraform-aws-ansible"

group_name = "dc_hosts"
hosts = "${module.ad.instance_private_ips}"
counter = "${var.instance_count}"

group_vars {
  root_domain_dn = "dc=${var.stage},${var.root_domain_dn}"
  cluster_ips = ""
  sha_id = "${var.revision_id}"
  build_id = "${var.jenkins_build_id}"
  domain_name = "${var.stage}.${var.zone_name}"
  dep_stage = "${var.stage}"
  ad_safe_mode_password = "your-ad-safe-mode-password"
  dn_admin_u = ".\Administrator"
  dn_admin_pwd = "Admin-Pass01"
  ad_subnets = ""
}

host_vars {
  ansible_user = "${var.ssh_user}"
  ansible_password = "${var.secure_password}"
  ansible_connection = "winrm"
  ansible_winrm_transport = "basic"
  ansible_winrm_server_cert_validation = "ignore"
}

local_enabled = false
}

Terraform Output

We now have a workspace create. Let’s select the workspace and perform terraform state pull and see the output of above module referring ansible provider.

• Group variables: Type: ansible_group , followed by inventory_group_name and var. This group has variables specified in active-directory/main.tf
• Host variables: There are two hosts, ansible_host.remote.0 and ansible_host.remote.1 of which the first becomes primary and the other secondary DC . Similarly , the host_vars from active-directory/main.tf is part of this.

Once we have the required state, now let’s look into using the inventory script terraform.py

Setting up the WinRM listener on Windows

Before Ansible can communicate with a remote Windows node, it must be able to make a connection to it. It does this through the Microsoft protocol WinRM. WinRM is the same protocol that PowerShell Remoting uses to run remote commands from within PowerShell.

For Ansible to use WinRM to communicate with the Windows node, you must configure WinRM. To do this, Ansible provides a PowerShell script that sets various WinRm options.

Your first task will be to download the configuration script and run Ansible on the Windows node. To do that, assuming you already have PowerShell Remoting enabled on your target Windows computer and you’re at a Windows workstation:

Download the ConfigureRemotingForAnsible.ps1 PowerShell script to your local Windows computer. This tutorial will assume it’s saved in ~Downloads.

Run the configuration script on the Windows node Ansible will manage using the command. The command below will run the command on the tutorial’s two demo machines and prompt you for the password for the local adminuser account on the Windows nodes.

Краткий словарь терминов Ansible

В этом руководстве широко используются такие термины Ansible:

• Control Machine (или Node): ведущая система, в которой установлен Ansible и откуда он может подключаться к нодам и выполнять на них команды.
• Нода (Node): сервер, управляемый Ansible.
• Файл инвентаря (Inventory): файл, который содержит информацию о серверах, которыми управляет Ansible, обычно находится в /etc/ansible/hosts.
• Плейбук (Playbook): файл, содержащий серию задач, которые нужно выполнить на удаленном сервере.
• Роли (Roles): коллекция плейбуков и других файлов, которые имеют отношение к цели (например, к установке веб-сервера).
• Play: полный набор инструкций Ansible. В play может быть несколько плейбуков и ролей, включенных в один плейбук, который служит точкой входа.

Вопросы

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

Python нужен только на Linux-машинах. А он там, скорее всего, уже есть. На Windows-хостах единственный нюанс – нужно включить службу Windows Remote Management. Но это быстро решается групповыми политиками.

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

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

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

Через тот же choco можно все интересные и нужные пакеты раскатывать. С Windows он очень спасает. Очень удобный пакетный менеджер.

Через WSL на Windows 10 можно ли управляющую систему Ansible запустить?

Не пробовал. Я знаю, что быстрее всего в Docker поднять контейнер и через него работать. Пробросить плейбуки и запускать.

Еще хотелось акцентировать внимание на термине идемпотентность – он звучит академически, а суть очень крутая – Ansible запоминает состояние и перед тем, как что-то сделать с системой, проверяет, не было ли это уже сделано. На этапе отладки плейбуков это очень круто помогает

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

Там есть режим стартовать с конкретного шага. Вообще Ansible очень интересный и мощный.

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

Чем групповые политики не устроили?

Я не говорю, что групповые политики – это плохо. Но этими групповыми политиками же нужно будет что-то запускать. А скрипты настраивать не так удобно, как плейбуки.

Configure a Windows Host for Ansible

• Windows 7, 8.1, 10, 11
• Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019, 2022
• PowerShell 3.0+ and .NET 4.0+
• WinRM or OpenSSH (experimental)

The supported nodes include all the modern releases of Windows Desktop and Server.
The full list includes Windows 7, 8.1, 10, 11, and Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019, 2022.
Ansible requires PowerShell 3.0 or newer and at least .NET 4.0 to be installed on the Windows host.
You need to upgrade only old Windows 7 and Windows Server 2008 nodes.
The communication between Ansible Controller and the target node is executed via a WinRM listener that needs to be created and activated.
Ansible 2.8 has added an experimental SSH connection for Windows-managed nodes for Windows 10+ clients and Windows Server 2019+.
In this example, we’re going to cover the WinRM connection method with “basic” authentication.
Refer to manual for more WinRM wide range of configuration options.

Setting up a Test Windows Host

You probably already have a host ready to go for testing, but what’s good about a blog post that cannot show you how to do this. In this post I am going to use vagrant to download a pre-baked image online and spin that up. To start off, create a file called  with the following contents:

In the same directory, run the command and it will automatically download the image and start up a new VM in Virtualbox. Windows images are quite large so be careful running these commands on a connection with limited data. These images have been created by Matt Wrock and are designed to be as lightweight as possible but unfortunately lightweight and Windows does not fit in the same sentence. If you want to know more about this process and how these images were generated, Matt’s article on this is fantastic and can be found here. This image is stored in a local cache so this step will only need to run the download process once, subsequent runs should be a lot quicker.

In a few minutes you should be presented with this glorious site

The username and password required to log onto the new box is just. To finish the prep required by Ansible, log onto the box and open a new PowerShell window (as an Administrator) and run:

These commands will download and run the script  which sets up a HTTPS WinRM listener and enable various authentication protocols. The script itself is quite useful for quickly setting up a dev box but I would try and avoid using it in a production environment. This is because it enables certain protocols useful for development and testing but it enables all of them which just become more attack vectors to exploit. I am hoping to expand on this topic in the future but as WinRM is a complex service, it is a bit too much to delve into for this blog post at this time.

To test that everything is worked fine, run the following command to verify WinRM is up and running over a HTTPS listener:

A successful test of WinRM over HTTPS