Ansible для небольшого IT-отдела: разворачиваем рабочие места без ручного обхода

В прошлом месяце я в очередной раз сидел и считал, сколько времени наши инженеры убили на настройку новых рабочих мест руками. Тридцать пять компьютеров за квартал только у одной бухгалтерской конторы. На каждый — час-полтора: 1С, КриптоПро, DNS, отключить лишние службы, прописать принтер. Умножьте это на десяток клиентов, и вы поймёте, почему я в итоге сел разбираться с Ansible вместо того, чтобы в очередной раз нанимать ещё одного эникейщика.

Ручной обход — это не работа, а наказание

У нас есть клиент — торговая компания на тридцать восемь рабочих мест. Раз в квартал текучка выкидывает трёх-четырёх сотрудников и приводит новых. Инженер приезжает, садится за компьютер, ставит office, 1С, КриптоПро CSP, антивирус, настраивает принтер по IP, прописывает DNS на внутренний контроллер. Потом едет к следующему. По одному компьютеру. Ногами.

Один раз забыли отключить автообновление винды на кассовом ПК в рознице — и посреди рабочего дня комп улетел в перезагрузку с очередью покупателей у кассы. Директор звонил лично мне. Не инженеру, а мне. Вот тогда я и посчитал реальную стоимость такого подхода: час работы инженера у нас стоит клиенту от 1800 рублей, а забытый шаг в чек-листе стоит репутации.

Проблема не в людях. Люди у меня толковые. Проблема в том, что человек физически не может тридцать восьмой раз подряд одинаково внимательно выполнить одну и ту же последовательность из двадцати шагов. Где-то что-то забудется. Это не лень, это природа ручного труда.

Ansible на пальцах: что это и почему не Puppet

Ansible — это инструмент, который берёт список компьютеров и список задач и раскатывает второе на первое. Никакого агента на рабочих станциях ставить не нужно — управляющий сервер, обычно у нас это обычный Linux-ноут инженера, стучится по SSH к линуксам и по WinRM к виндовым машинам. Задачи описываются в YAML-файлах, которые называются плейбуками. Прочитал один раз — и он читается почти как русский текст: установить пакет, скопировать файл, прописать сервис DNS.

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

Ключевая штука — идемпотентность. Звучит страшно, а на деле означает простое: запустил плейбук один раз, запустил десять раз — результат одинаковый. Если пакет уже стоит, Ansible его не переустановит. Если служба уже настроена как надо, он её не тронет. Это не bat-файл, который слепо выполняет команды подряд.

Первый шаг — подружить Ansible с Windows

Тут будет честный момент: Windows изначально не заточен под удалённое управление в стиле Linux, поэтому придётся включить WinRM — встроенный протокол удалённого управления от Microsoft. Ставится коллекция ansible.windows, на стороне управляющей машины — библиотека pywinrm. Дальше нужен один скрипт настройки WinRM-слушателя на каждом компьютере, но выполнить его руками придётся всего один раз в жизни каждой машины.

У нас есть клиент с доменом на пятьдесят компьютеров, и там мы этот скрипт вообще руками не трогали — раскатали через групповую политику как startup script, привязали к OU с рабочими станциями, и на следующее утро WinRM был включён у всех разом. После этого Ansible видит машину точно так же, как видит Linux-сервер, разве что модули называются win_package, win_dns_client, win_regedit вместо привычных apt или copy.

Отдельно скажу про безопасность: WinRM лучше поднимать по HTTPS с сертификатом, а не по голому HTTP, особенно если часть машин ходит через VPN, а не сидит в одной локалке. Один раз наступили на грабли, когда пароль администратора улетел открытым текстом внутри локальной сети клиента — не критично, но неприятно.

Linux-машины настраиваются сами собой

На фоне Windows линукс — сплошное удовольствие. SSH-ключ раскинул один раз через ssh-copy-id, и всё, машина в инвентаре. Модули apt и dnf ставят пакеты, systemd управляет службами, template раскладывает конфиги с подстановкой переменных под конкретный сервер. Никакой отдельной настройки протоколов не требуется — SSH и так есть везде.

У нас на линуксах в основном крутятся Zabbix-агенты для мониторинга клиентских серверов, Nextcloud на паре площадок и внутренний DNS на некоторых стендах. Раньше каждый новый сервер настраивался вручную по бумажной инструкции, которую периодически забывали обновлять. Сейчас те же сорок строк YAML разворачивают агент мониторинга на новом сервере за две минуты, и инструкция физически не может устареть — она и есть код.

Пишем плейбук: софт, политики, DNS одним файлом

Инвентарь у нас строится по группам, а не просто списком IP-адресов. Группа бухгалтерия, группа юристы, группа продажи, группа кассы. У каждой группы свои переменные: список софта, DNS-сервер, путь до сетевого принтера. Меняешь состав софта для бухгалтерии в одном файле переменных — применяется на все восемнадцать компьютеров сразу при следующем запуске.

Сам плейбук для типового рабочего места делает примерно следующее: через модуль win_package ставит 1С, КриптоПро, 7-Zip, Adobe Reader, браузер; модулем win_dns_client прописывает внутренний DNS-сервер контроллера домена; win_regedit отключает автообновление винды в рабочие часы и включает нужную политику паролей; win_service отключает пару служб, которые в конкретной конторе не нужны и только жрут ресурсы. Всё это укладывается в один файл страниц на пять.

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

Проверка вхолостую и откат — страховка от собственной ошибки

У Ansible есть режим --check, который показывает, что изменится, но ничего не трогает по-настоящему. Плюс --diff, который показывает конкретные строки в конфигах до и после. Мы взяли за правило: любое изменение сначала гоняется в режиме проверки на одной тестовой машине, потом на реальной машине одного добровольца из офиса, и только потом на всей группе.

Однажды я чуть не отправил обновлённую политику паролей сразу на все шестьдесят компьютеров одного клиента. В плейбуке была опечатка — вместо минимальной длины пароля в восемь символов ушла бы политика в восемьдесят символов. Заметил это именно на прогоне с --check, потому что вывод показал абсурдное значение раньше, чем оно реально применилось бы. Это тот случай, когда пять минут проверки сэкономили день разгребания звонков от пользователей, которые не могут сменить пароль.

Исключения не ломают систему

Реальная жизнь состоит из исключений. У директора компании на компьютере нужен ещё и специфичный софт для видеонаблюдения, у бухгалтера-надомника — VPN-клиент с другими настройками, чем у офисных. Для этого в Ansible есть host_vars — файл переменных, привязанный к конкретной машине, а не к группе. Общий плейбук остаётся один, а особый случай описывается парой дополнительных строк рядом, без веток if-else внутри самого сценария.

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

Частые вопросы

Нужно ли ставить какой-то агент на каждый компьютер?
Нет, и это главное отличие от Puppet и Chef. Ansible работает через уже существующие протоколы — SSH для Linux и WinRM для Windows, которые входят в систему по умолчанию. Ничего лишнего устанавливать на рабочие станции не требуется, что сильно упрощает согласование с клиентом и службой безопасности.

А как быть с сотрудниками на удалёнке, чьи компьютеры не в офисной сети?
Здесь помогает VPN до внутренней сети или доступный извне WinRM по HTTPS с ограничением по IP. Мы у части клиентов используем связку с Tailscale — она поднимает частную сеть между управляющим сервером и удалёнными машинами за пятнадцать минут, и дальше Ansible работает с ними так же, как с офисными компьютерами.

Сколько времени займёт внедрение Ansible в небольшой компании?
На первый рабочий плейбук с реальной пользой у нас ушло два дня, включая настройку WinRM на пилотной группе из пяти машин. Полноценный набор плейбуков под все типовые роли — бухгалтерия, кассы, юристы — обычно складывается за пару недель в фоновом режиме, без остановки текущей работы.

Что делать, если у клиента вообще нет своего системного администратора?
Тогда весь этот слой автоматизации логично забирать на аутсорс — мы именно так и работаем с большинством клиентов. Один раз описываем инфраструктуру и типовые роли рабочих мест, дальше поддержка сводится к правке переменных в файле, а не к выездам инженера на каждый чих.