Первые шаги с Ansible: автоматизация типовых задач Windows и Linux

Когда количество серверов перевалило за сотню, а каждое обновление или проверка службы превращались в многочасовую рутину по SSH/RDP, становится понятно: ручные правки конфигов и bash-скрипты уже не спасают. Нужен инструмент, который возьмёт на себя повторяемые операции, не требуя при этом перелопачивания всей инфраструктуры. Ansible — именно такой порог входа в мир Infrastructure as Code. Он одинаково легко управляет и Linux, и Windows, используя нативные протоколы без агентов, а первые плейбуки вы запустите уже через час после установки. В этой статье я проведу вас по пути, который сам прошёл от ручного администрирования до автоматизации типовых задач: настройка соединения, инвентаря, написание первых плейбуков и типовые грабли, на которых чаще всего спотыкаются новички.

Почему Ansible — лучший выбор для первого шага в автоматизации

Для системного администратора, привыкшего набирать команды в терминале, Ansible — естественный переход от единичных скриптов к системной автоматизации. Он не требует разворачивать отдельный управляющий сервер с базой данных, как Puppet или Chef, не заставляет устанавливать агентов на целевые машины и использует понятный YAML, который читается почти как техническое задание. Более того, Ansible отлично ложится на гибридные среды, где локальное железо соседствует с облачными инстансами — единый инвентарь и единый подход к конфигурации.

Ключевые преимущества Ansible для сисадмина:

• Без агентов: на управляемых машинах нужны только штатные протоколы — SSH для Linux и WinRM для Windows. Никаких демонов, обновлений агента, конфликтов версий.
• Гибридная поддержка: единый язык описания задач для обеих ОС. Windows-службы, реестр, пакеты — всё это управляется теми же плейбуками, что и nginx на Ubuntu.
• Простота входа: YAML с отступами — не нужно быть программистом, чтобы понять, что делает плейбук. Даже коллеги, далёкие от кодинга, через неделю начинают предлагать правки.
• Версионирование: плейбуки и инвентарь лежат в Git, как любой код. Откатить изменения, провести code review или запустить CI/CD пайплайн при пуше — привычный workflow разработчика, применённый к инфраструктуре.
• Модульность: тысячи готовых модулей под любую задачу — от управления пакетами и файлами до настройки сетевых устройств или DNS-записей. Не нужно изобретать велосипед, достаточно найти подходящий модуль в документации.

Важно понимать разницу с Terraform: последний заточен под provisioning — создание виртуалок, сетей, дисков. Ansible же конфигурирует то, что уже создано: ставит софт, правит конфиги, управляет службами. В реальной практике они часто идут рука об руку — Terraform поднял инстансы, Ansible привёл их в целевое состояние, а потом ещё и следит за дрифтом конфигурации.

Предварительная настройка: Control Machine и требования

Управляющая машина в терминологии Ansible — Control Node — это тот самый центр, откуда вы будете запускать плейбуки. Важно: это должен быть Linux (нативный или WSL), на Windows без дополнительных танцев с бубном Ansible не заведётся.

Требования к Control Machine:

Установка Ansible на Linux (Control Machine)

Если у вас Ubuntu/Debian, проще всего поставить через pip в виртуальном окружении, чтобы не засорять систему. Но для первого знакомства можно и глобально. Я предпочитаю такой подход:

sudo apt update
sudo apt install python3-pip -y
pip3 install --user ansible
export PATH=$PATH:~/.local/bin
ansible --version

После выполнения последней команды вы увидите версию Ansible, путь к конфигу и информацию о Python. Если видите что-то вроде «ansible 2.9» — лучше обновить: современная практика требует Ansible Core 2.12+.

Установка Ansible на Windows (через WSL)

Да, Ansible на Windows без WSL — боль. Но это не приговор: WSL2 работает вполне сносно, а накладные расходы на виртуализацию для Control Node некритичны. Главное — не пытайтесь запускать Ansible из PowerShell или cmd, только из терминала установленного дистрибутива.

Шаг 1: Включение WSL

Запустите PowerShell от имени администратора и выполните:

wsl --install

Или, если нужна конкретная версия WSL 2:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

После перезагрузки установите ядро WSL 2 с официального сайта Microsoft и задайте WSL 2 версией по умолчанию: wsl --set-default-version 2.

Шаг 2: Установка Linux-дистрибутива

В Microsoft Store найдите Ubuntu 22.04 LTS (или Debian — кому что ближе), установите. При первом запуске создайте пользователя и пароль — это будут учётные данные внутри WSL.

Шаг 3: Обновление дистрибутива

Первым делом внутри WSL-терминала обновляем индексы и пакеты:

sudo apt update && sudo apt upgrade -y

Шаг 4: Установка Ansible

Теперь как на обычном Linux:

sudo apt install python3-pip -y
pip3 install --user ansible
export PATH=$PATH:~/.local/bin
ansible --version

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

Настройка подключения к Windows: WinRM и скрипт ConfigureRemotingForAnsible

Сюда стоит заглянуть сразу после первых успешных подключений по SSH к Linux-серверам, потому что Windows традиционно требует чуть больше телодвижений. WinRM (Windows Remote Management) — это штатный SOAP-протокол удалённого управления, но по умолчанию он выключен, и без предварительной подготовки плейбуки будут падать с непонятными ошибками.

Почему WinRM важен?

• Это единственный стандартный способ, через который Ansible может выполнять модули на Windows.
• Без включённого WinRM любое обращение к Windows-хосту заканчивается таймаутом или отказом в соединении.
• По умолчанию WinRM слушает HTTP (TCP 5985), но в production я рекомендую сразу настраивать HTTPS (TCP 5986) с самоподписанным сертификатом — так трафик шифруется, и можно безопасно передавать учётные данные.

Шаг 1: Включение WinRM на целевом Windows-сервере

Самый простой путь — взять готовый скрипт из репозитория Ansible. Именно его я и использую при разворачивании тестовых стендов:

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1" -OutFile "$env:TEMP\ConfigureRemotingForAnsible.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\ConfigureRemotingForAnsible.ps1"

Скрипт делает всё необходимое:

• Включает WinRM и задаёт автоматический запуск службы.
• Создаёт правило в Windows Firewall для порта 5986/TCP (HTTPS).
• Генерирует самоподписанный сертификат для прослушивания HTTPS.
• Настраивает CredSSP, если требуется двухфакторная аутентификация для некоторых модулей.

Запускать его нужно обязательно в PowerShell с правами администратора. Если серверов несколько — заверните в цикл или используйте Ansible позже для массового включения WinRM (рекурсия, да, но после первой настройки вы сможете управлять WinRM через Ansible).

Шаг 2: Установка pywinrm на Control Machine

Эта зависимость не входит в основной пакет Ansible, поэтому её часто забывают. Без неё Ansible не сможет взаимодействовать с WinRM. Установка проста:

pip install pywinrm[credssp]

Если у вас виртуальное окружение — не забудьте его активировать. В production обязательно фиксируйте версию в requirements.txt, чтобы избежать сюрпризов.

Шаг 3: Настройка инвентаря для Windows

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

Пример YAML-инвентаря:

all:
  hosts:
    win-server01:
      ansible_host: 192.168.1.10
      ansible_user: Admin
      ansible_password: SuperSecret123
      ansible_connection: winrm
      ansible_port: 5986
      ansible_winrm_server_cert_validation: ignore

Для HTTP (если всё же оставили 5985) порт меняется, но я настоятельно советую сразу переходить на 5986.

Шаг 4: Проверка подключения

Модуль win_ping — простейший тест живучести:

ansible win-server01 -i inventory.yml -m win_ping

Если всё хорошо, получите JSON с «SUCCESS». Если нет — читаем диагностику: чаще всего проблема в недоступности WinRM из-за брандмауэра или неправильных учётных данных.

Настройка подключения к Linux: SSH и базовые требования

Здесь всё намного привычнее: Ansible стучится по SSH с ключами или паролем и выполняет модули через Python. Главное — убедиться, что на целевых машинах есть Python подходящей версии.

Требования к Linux-целевым машинам:

Проверка подключения к Linux

ansible all -i inventory.yml -m ping

Модуль ping для Linux проверяет именно работоспособность SSH и наличие Python. Ответ — «pong».

Инвентарь для Linux

Минимальный вариант:

all:
  hosts:
    web01:
      ansible_host: 10.0.0.5
      ansible_user: root
    db01:
      ansible_host: 10.0.0.6
      ansible_user: admin

Для Linux не нужно указывать ansible_connection, потому что по умолчанию используется SSH. Однако если хотите управлять через WinRM с Linux-машины на Windows (что бессмысленно), тогда и надо переопределять.

Создание инвентаря: группировка и параметры хостов

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

Структура инвентаря

Формат INI удобен для быстрых черновиков, но для версионирования и сложных конфигураций YAML — более гибкий:

# inventory.ini
[webservers]
web01 ansible_host=10.0.0.5
web02 ansible_host=10.0.0.6

[dbservers]
db01 ansible_host=10.0.1.5

Тот же инвентарь в YAML выглядит аккуратнее и легче расширяется:

all:
  children:
    webservers:
      hosts:
        web01:
          ansible_host: 10.0.0.5
        web02:
          ansible_host: 10.0.0.6
    dbservers:
      hosts:
        db01:
          ansible_host: 10.0.1.5

Группировка хостов

Группы позволяют запускать задачи не на отдельных серверах, а на логическом слое. Типичный пример из жизни: обновить ядро на всех серверах роли «app», перезагрузить только те, что помечены как «staging», и деплоить новую версию только на «canary».

# Запустить плейбук только для группы webservers
ansible-playbook -i inventory.yml site.yml --limit webservers

Переопределение параметров в команде

Иногда нужно на лету изменить инвентарь или указать конкретный хост без правки файла. Тогда спасают аргументы командной строки:

# Задать конкретный хост
ansible all -i 'win-server01,' -m win_ping

# Указать другой файл инвентаря
ansible-playbook -i /path/to/inventory.yml playbook.yml

Первые плейбуки: автоматизация типовых задач

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

Структура плейбука

---
- name: Название плейбука
  hosts: целевая_группа
  tasks:
    - name: Описание задачи
      module_name:
        параметр1: значение1
        параметр2: значение2

Здесь hosts может быть группой из инвентаря, «all» или шаблоном имени. Модуль выполняет конкретную операцию, а параметры определяют её поведение.

Типовые задачи для Linux

Типовые задачи для Windows

Пример плейбука для Windows

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

---
- name: Первоначальная настройка Windows Server
  hosts: win-servers
  tasks:
    - name: Остановить службу Spooler
      win_service:
        name: Spooler
        state: stopped

    - name: Установить параметр в реестре
      win_regset:
        key: HKLM\Software\MyCompany\Agent
        value: 1
        data: enabled

Запуск:

ansible-playbook -i inventory.yml win-setup.yml

Чек-лист: первые шаги с Ansible

Пройдите по пунктам, чтобы не упустить ничего важного:

• [ ] Control Machine развёрнута (Linux или WSL).
• [ ] Python и pip установлены на Control Machine.
• [ ] Ansible установлен (проверено через ansible --version).
• [ ] Для Windows: модуль pywinrm[credssp] установлен.
• [ ] WinRM включён на целевых Windows-серверах (скрипт ConfigureRemotingForAnsible.ps1 отработал).
• [ ] Инвентарь создан, для Windows явно указан ansible_connection=winrm.
• [ ] Подключение проверено: win_ping для Windows, ping для Linux.
• [ ] Написан первый плейбук с парой простых задач.
• [ ] Плейбук успешно выполнен.

Типовые ошибки и как их избежать

Каждая из этих ошибок — кусок моего времени, вырванный ночными дебагами. Хорошо, что их можно обойти, зная подводные камни.

Ошибка 1: Ansible пытается подключиться к Windows через SSH

Причина: в инвентаре не указан ansible_connection=winrm.
Решение: добавьте для всех Windows-хостов строку ansible_connection: winrm или, если используете INI, ansible_connection=winrm. Без этого Ansible будет стучаться по 22 порту и упадёт с таймаутом.

Ошибка 2: Проверка сертификата WinRM не проходит

Причина: самоподписанный сертификат не может быть проверен стандартными средствами.
Решение: временно добавьте ansible_winrm_server_cert_validation: ignore. В перспективе настройте внутренний центр сертификации и включите валидацию — иначе злоумышленник может подменить сервер.

Ошибка 3: Python не найден на Linux-целевой машине

Причина: отсутствует Python или версия слишком старая для модулей Ansible (например, Python 2.6 на CentOS 6).
Решение: установите Python 3.x через пакетный менеджер ОС. Если на древней системе это невозможно, рассмотрите использование модуля raw для предварительной установки питона.

Ошибка 4: WinRM не включён на Windows

Причина: пропустили запуск ConfigureRemotingForAnsible.ps1.
Решение: запустите скрипт в PowerShell от администратора. Лучше сразу добавить его в ваш образ виртуалки или скрипт развёртывания, чтобы новые серверы сразу были готовы к управлению.

Ошибка 5: Неправильный порт WinRM

Причина: в инвентаре указан порт 5985 (HTTP), а сервер слушает только HTTPS на 5986.
Решение: проверьте настройки WinRM на целевом хосте: winrm enumerate winrm/config/listener. Если используется самоподписанный сертификат с портом 5986, скорректируйте инвентарь и не забудьте добавить ansible_winrm_server_cert_validation: ignore.

FAQ: частые вопросы по Ansible для Windows и Linux

Q: Можно ли запустить Ansible на Windows без WSL?
A: Нет. Нативно Ansible работает только на POSIX-системах. Все варианты с Cygwin или Docker внутри Windows — это костыли, которые создадут больше проблем, чем решат. WSL2 — официальный и единственный поддерживаемый способ.

Q: Почему WinRM не включён по умолчанию?
A: Из соображений безопасности. Открытый WinRM без дополнительной настройки — потенциальная дыра. Поэтому его включают осознанно, с минимальными привилегиями для управляющих аккаунтов.

Q: Как проверить, что Ansible правильно подключился к хосту?
A: Самый быстрый способ — ad-hoc команда с модулем проверки: ansible all -i inventory.yml -m ping (Linux) или ansible windows -i inventory.yml -m win_ping (Windows).

Q: Можно ли использовать Ansible для управления сетевыми устройствами?
A: Да, существуют специализированные модули (ios, junos, nxos и т.п.). Но это отдельная история, требующая настройки учётных данных и подключения через CLI/API. Для старта лучше сосредоточиться на серверах.

Q: Как обновить Ansible до последней версии?
A: pip install --upgrade ansible. Если использовали виртуальное окружение — сначала активируйте его.

Q: Что делать, если плейбук не выполняется на Windows?
A: Проверьте по контрольному списку: включён ли WinRM? Верно ли указан ansible_connection? Соответствует ли порт (5985 или 5986)? Установлен ли pywinrm? И простая проверка связи: Test-WSMan -ComputerName win-server01 с Control Machine не пройдёт, но можно запустить локальный тест на самом Windows-сервере, а между машинами проверить telnet на порт.

Q: Можно ли использовать Ansible для управления облачными ресурсами?
A: Да, есть модули под AWS, Azure, GCP. Но чаще IaC-задачи по созданию ресурсов отдают Terraform, а Ansible используют для конфигурации уже запущенных инстансов. Впрочем, один Ansible тоже может развернуть инфраструктуру, хотя это не всегда идемпотентно.

Q: Как хранить плейбуки и инвентарь в Git?
A: Инициализируйте репозиторий, добавьте файлы, закоммитьте. Важно: не храните секреты (пароли, ключи) в открытом виде. Используйте Ansible Vault для шифрования переменных или внешние vault-решения (HashiCorp Vault).

Заключение: от ручного администрирования к автоматизации

Первые шаги с Ansible — это не просто установка утилиты. Это смена мышления: вместо списка «зайти на сервер и сделать» вы начинаете описывать желаемое состояние системы в коде, который можно отревьюить, сохранить в истории и воспроизвести в любой момент. Вы уже разобрались с базовыми вещами:

• развернули Control Node (Linux или WSL);
• научились настраивать WinRM для Windows и проверять SSH для Linux;
• структурировали хосты в инвентаре с группами;
• написали и запустили первые плейбуки — и они выполнили реальную работу вместо вас;
• узнали типичные ловушки и теперь сэкономите часы на их обходе.

Впереди — более сложные сценарии: роли для переиспользования кода, условия, циклы, шаблоны jinja2, интеграция с CI/CD и динамические инвентари из облачных провайдеров. Но даже сейчас вы уже автоматизировали задачи, которые ещё недавно заставляли кликать мышкой или набирать однотипные команды. Добро пожаловать в мир Infrastructure as Code, где конфигурация управляется так же строго, как программный продукт.