Ansible и отечественные ОС: что работает из коробки, что пришлось писать самим

Когда всё началось - в феврале-марте - клиенты думали, что самая болезненная часть перехода это выбор дистрибутива. Оказалось, выбрать - не самое сложное. Самое сложное - развернуть это на сотне машин и не сойти с ума от ручной работы. Мы с самого начала делали ставку на Ansible: привычный инструмент, огромная база модулей, декларативный подход. Но когда вместо RHEL на другом конце провода оказывается Astra Linux SE или РЕД ОС 7.3 - часть привычной магии перестаёт работать.

Делимся тем, что нашли за последние месяцы реальной эксплуатации.

Контекст: что за стенд

У нас два активных проекта по инфраструктурной автоматизации с отечественными ОС. Один - региональный госзаказчик на РЕД ОС 7.3, серверный сегмент. Второй - смешанный парк: Astra Linux SE 1.7 на рабочих местах и часть серверов на Astra Linux Common Edition. Ansible Automation Platform 2.1 - наша управляющая плоскость. Ansible Core при этом 2.12.

Playbook-база у нас большая - накопилась за несколько лет работы с CentOS/RHEL. Переиспользовать хотелось максимально, переписывать - минимально.

Что работает без правок

Приятная новость: базовые вещи работают нормально.

• ansible.builtin.package - универсальный менеджер пакетов понимает и rpm (РЕД ОС, Astra Linux CE) и deb (Astra Linux SE). Главное - не упираться в yum или apt напрямую, а использовать именно package. Там, где у нас были прямые вызовы yum, пришлось поправить, но это разовая работа.
• ansible.builtin.service - управление systemd-сервисами. Оба дистрибутива используют systemd, модуль работает предсказуемо.
• ansible.builtin.user, group, file, copy, template - стандартная работа с файловой системой и пользователями. Ни одного сюрприза.
• community.general.ini_file, lineinfile, blockinfile - конфигурационные файлы. Всё стабильно.
• SSH-подключение и become - само собой. Повышение прав через sudo работает на обоих дистрибутивах без танцев.

Примерно 70% наших playbook-ов заработали без изменений или с минимальной правкой имён пакетов.

Где провалились

SELinux и мандатный контроль доступа в Astra Linux SE. Astra Linux SE использует собственный механизм мандатного контроля - Parsec. Модуль ansible.posix.selinux написан под SELinux и ничего не знает про Parsec. Попытки управлять метками через него либо ничего не делают, либо валятся с ошибкой. Пришлось писать кастомный модуль на Python, который дёргает утилиты pdpl-file и pdp-ls напрямую. Не ракетная наука, но несколько часов потратили.

FreeIPA-интеграция. Коллекция freeipa.ansible_freeipa - отличная вещь для управления пользователями, группами и политиками в FreeIPA. Но у неё есть предположение, что вы работаете с RHEL/CentOS-ориентированным дистрибутивом. На Astra Linux ряд модулей требует поправок в become-цепочке и путях к утилитам. Конкретно модуль ipahost не находил ipa-бинарник в стандартном пути - пришлось добавлять vars с явными путями или перебрасывать через симлинк. Мелочь, но неочевидная.

Firewall. На РЕД ОС 7.3 живёт firewalld, и ansible.posix.firewalld работает. На Astra Linux SE стандартная установка использует nftables напрямую или UFW - зависит от конфигурации. Модуля под это в upstream нет, community.general.ufw есть, но Astra Linux SE со своими политиками иногда не даёт UFW то, что он ожидает. Решили через ansible.builtin.command с явными nftables-командами и шаблонами правил - некрасиво, зато предсказуемо.

Сбор facts. ansible.builtin.setup работает, но ansible_distribution на обоих дистрибутивах возвращает не то, что ожидаешь, если у тебя в playbook-ах были условия вида when: ansible_distribution == "CentOS". РЕД ОС возвращает "RED", Astra Linux возвращает "Astra Linux". Простая правка, но надо пройтись по всей базе.

Что написали сами

Помимо модуля для Parsec, написали два небольших кастомных модуля:

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

adg_redos_repo - управление репозиториями в РЕД ОС. ansible.builtin.yum_repository теоретически должен работать, на практике специфика RPM-структуры РЕД ОС иногда давала непредсказуемые результаты при обновлении конфигов. Проще написали свой через template + command.

Оба лежат в нашей внутренней коллекции adg.infra - постепенно превращаем её в нечто пригодное для переиспользования.

Про Automation Platform 2.1

AAP 2.1 сам по себе тут особой роли не играет - с точки зрения совместимости с конечными хостами всё решает версия Ansible Core и коллекции. Что реально приятно в 2.1: улучшенный execution environment с изоляцией зависимостей. Мы собрали кастомный EE с нашими зависимостями и adg.infra - теперь можно запускать задачи на инфре клиента не объясняя каждый раз, откуда взялся тот или иной Python-пакет.

Общее ощущение

Ansible на отечественных ОС - рабочий инструмент, но с оговорками. Там, где дистрибутив честно наследует RHEL или Debian-семантику, всё более-менее работает. Там, где есть собственные механизмы безопасности (Parsec в Astra Linux SE) или отклонения в поведении пакетного менеджера - придётся или искать обходные пути, или писать своё.

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