WSL на Windows Server 2019: Ansible и мониторинг без Linux jump-server

Когда мы смотрели на WSL в рамках GA Windows Server 2019, основным ожиданием было «запускать Linux-утилиты без отдельной VM». Звучит скромно. Но после того как развернули первые WS2019 у клиентов и начали реально пользоваться WSL в работе - оказалось, что конкретный выигрыш выше, чем ожидали.

Откуда вообще взялась проблема

В managed-инфраструктуре с гибридными средами - Windows-ноды рядом с Linux-кластерами - у нас исторически жил отдельный Linux jump-server. Небольшая виртуалка, на которой крутились:

• Python-скрипты мониторинга - опрашивали Windows-хосты через WMI и SNMP, агрегировали метрики.
• Ansible-плейбуки для Windows-таргетов - win_service, win_copy, патчинг, конфигурация ролей.
• Разные вспомогательные скрипты - парсеры логов, сборщики отчётов, которые написаны на bash или Python и переписывать на PowerShell никто не собирался.

VM маленькая, но это всё равно отдельная сущность: её надо патчить, мониторить, backup-ить, объяснять клиенту зачем она вообще нужна. В нескольких проектах эта VM жила только ради того чтобы запускать Ansible - и это всегда ощущалось как некоторый перебор.

Альтернативой был Windows-хост с cygwin или git bash. Работало криво: половина Python-библиотек вела себя непредсказуемо, PATH-конфликты, проблемы с переносами строк в скриптах. Не то.

Что меняет WSL в GA

Установка на Server Core - через Install-WindowsFeature Microsoft-Windows-Subsystem-Linux, затем загрузка и распаковка дистрибутива вручную (Store на Server Core недоступен). Ubuntu 18.04 ставится нормально, apt работает, Python 3.6 из репозитория тоже.

Дальше - просто запускаем то, что раньше жило на jump-сервере:

# Внутри WSL на Windows Server 2019
pip3 install ansible pywinrm
ansible-playbook -i inventory/windows.yml playbooks/patch-iis.yml

WinRM-соединения от Ansible к другим Windows-хостам через WSL работают корректно. Ansible не знает что запущен в WSL - ему всё равно, он видит Python, модули, сетевой доступ к таргетам.

Python-скрипты мониторинга запустились без изменений. Единственный момент - библиотеки, которые зависят от нативных расширений, иногда требуют apt install дополнительных пакетов. Ничего экзотического, стандартный Linux-кейс.

Что реально работает, а что нет

Важно понять ограничения сразу, без иллюзий.

Работает нормально:

• Python-скрипты без нативных расширений, зависящих от Linux-ядра.
• Ansible для Windows-таргетов через WinRM - основной сценарий.
• bash-скрипты для автоматизации задач, которые работают с сетью и файлами.
• SSH-клиент - подключаться к Linux-хостам из WSL на Windows Server.

Работает с оговорками:

• Файловые операции через /mnt/c/ заметно медленнее, чем с файловой системой внутри WSL. Скрипты, которые интенсивно читают Windows-пути, это почувствуют.
• inotify и другие механизмы уведомлений о файлах работают ненадёжно - если скрипт на них завязан, могут быть сюрпризы.

Не работает:

• Docker внутри WSL - ядро не поддерживает нужные cgroup/namespace на этом уровне абстракции.
• Systemd - WSL не запускает полноценный init.
• Всё что требует прямого доступа к Linux-ядру через /proc, /sys в серверном смысле.

Нас это не сильно беспокоит: задачи мониторинга и Ansible в эти ограничения не упираются.

Как это выглядит в практике

На одном из клиентских объектов - Windows Server 2019 в роли orchestration-хоста для Windows-инфраструктуры - перенесли Ansible и скрипты мониторинга с отдельного jump-сервера прямо в WSL на этом же хосте. Запуск через Task Scheduler: плейбуки по расписанию, скрипты мониторинга каждые несколько минут.

Результат: jump-VM выключили. Не удалили - ещё понаблюдаем - но выключили.

Один момент, который стоит отметить: запуск через Task Scheduler немного нетривиален. wsl.exe -e python3 /opt/monitor/check.py работает, но переменные окружения WSL не наследуются из Windows-сессии автоматически. Виртуальное окружение Python нужно активировать явно или прописать полный путь. Не проблема, но нужно знать заранее.

Что это меняет в инфраструктурном дизайне

Для гибридных сред, где Windows-хосты нужно автоматизировать через Ansible, WSL на WS2019 убирает необходимость держать отдельный Linux-хост только ради этого. Это не «Linux на Windows» в широком смысле - это конкретный инструмент для конкретной задачи.

Пока это решение для новых WS2019-развёртываний. На WS2016 WSL не было, там архитектура другая. Но в рамках миграций с WS2012R2/WS2016 на WS2019, которые мы ведём с октября, WSL стал одним из аргументов в пользу обновления - не главным, но реальным.

Насколько стабильно поведёт себя это в долгой работе - посмотрим. GA вышел две недели назад, production-опыт только накапливается.