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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фоне Windows Linux — сплошное удовольствие. 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 отключает автообновление Windows в рабочие часы и выставляет нужную политику паролей. 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 на пилотной группе из пяти машин. Полноценный набор плейбуков под все типовые роли — бухгалтерия, кассы, юристы — обычно складывается за пару недель в фоновом режиме, без остановки текущей работы.

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