Половина серверов на Ubuntu, половина на Astra: как жить с таким парком

MAATRIX

Классическая ситуация конца 2026 года: часть парка — привычная Ubuntu, на которой команда работает годами, часть — Astra Linux, появившаяся из-за требований заказчика или регулятора, и обе части будут жить рядом ещё долго, потому что «переписать всё за квартал» не про реальную инфраструктуру. Проблема не в том, что Astra чем-то плоха — проблема в том, что один и тот же плейбук на одной половине парка отрабатывает штатно, а на другой падает или, хуже, тихо делает не то. Ниже — не про «что ломается при переезде», а про то, как организовать работу, когда переезд не закончится ещё год или два и обе системы нужно поддерживать одновременно.

Почему смешанный парк — это нормальное переходное состояние, а не авария

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

• Новые серверы под конкретные контракты или контуры разворачиваются сразу на Astra, а старая инфраструктура продолжает работать на Ubuntu, пока не появится ресурс и повод её переносить.
• Часть сервисов критична к даунтайму настолько, что миграция откладывается до планового окна, а окно наступит не завтра.
• Часть ПО банально не сертифицирована или не протестирована под Astra, и переносить его раньше времени — создавать себе проблему поддержки на пустом месте.

Опасность не в самом факте гетерогенности, а в том, что происходит, если её не признать официально и не начать ей управлять: тогда каждый новый сервер настраивается «на глаз», по памяти администратора, который его поднимал, а через полгода никто не может внятно сказать, почему сервис X живёт на Ubuntu, а сервис Y — на Astra. Если у вас ещё не было официального решения на этот счёт, сначала стоит определиться с критериями выбора — общая логика разобрана в статье Ubuntu или Debian: что выбрать для сервера, а специфику самого перехода на Astra мы отдельно разбирали в статье Переезд с Ubuntu на Astra Linux: что реально ломается в первый день.

Ansible с условной логикой: один плейбук, а не два параллельных

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

Базовый принцип: используйте ansible_facts['os_family'] и ansible_facts['distribution'] для ветвления, но старайтесь свести само ветвление к минимуму точек — лучше один раз описать маппинг «имя пакета → дистрибутив» в переменных, чем разбрасывать when: по всему плейбуку.

# group_vars/all/packages.yml
package_map:
  Debian:
    monitoring_agent: zabbix-agent2
    web_server: nginx
  Astra:
    monitoring_agent: zabbix-agent2
    web_server: nginx

На практике для пар Ubuntu/Astra имена пакетов чаще совпадают, чем различаются, — обе системы построены на пакетной базе Debian. Разница обычно не в названии пакета, а в том, есть ли он вообще в штатных репозиториях и какой версии. Поэтому вместо огромной таблицы соответствий на каждый пакет практичнее задать явные исключения только там, где они реально есть:

# group_vars/all/main.yml
default_packages:
  - curl
  - vim
  - htop
  - zabbix-agent2

extra_packages:
  Astra: []
  Ubuntu:
    - snapd

# roles/common/tasks/main.yml
- name: Установить базовый набор пакетов
  ansible.builtin.apt:
    name: "{{ default_packages }}"
    state: present

- name: Установить пакеты, специфичные для дистрибутива
  ansible.builtin.apt:
    name: "{{ extra_packages[ansible_facts['distribution']] | default([]) }}"
    state: present
  when: extra_packages[ansible_facts['distribution']] is defined

Второй практический приём — держать инвентарь структурированным по группам ОС, а не только по функции сервиса, и использовать group_vars на пересечении этих групп:

# inventory/hosts.ini
[web]
web-01 ansible_host=10.0.1.11
web-02 ansible_host=10.0.1.12
web-03 ansible_host=10.0.1.13

[os_ubuntu]
web-01
web-02

[os_astra]
web-03

[web:children]
os_ubuntu
os_astra

Так вы получаете возможность писать group_vars/os_astra.yml с настройками, специфичными для Astra (например, отдельный путь к конфигу сетевого менеджера или особенности политики разграничения доступа — подробнее про грабли на этом фронте мы разбирали в статье Мандатное разграничение доступа Astra Linux: грабли), не трогая при этом общую роль web.

Отдельно про грабли: если у вас уже есть старые плейбуки под Ubuntu, не адаптируйте их «по ходу прогона» на боевом парке. Прогоняйте с --check --diff и всегда явно ограничивайте --limit конкретной группой хостов — плейбук, случайно улетевший не на ту группу, на смешанном парке стоит дороже, потому что последствия для Ubuntu- и Astra-хостов бывают разными и непредсказуемыми одновременно. Базовые принципы безопасного прогона разобраны в статье про то, как начать работу с Ansible на сервере.

Единый мониторинг: один дашборд, а не два разных мира

Второй практический узел — мониторинг. Худший сценарий для смешанного парка — когда Ubuntu-серверы смотрит одна система, а Astra-серверы другая (потому что «агент для Astra не встал с первого раза, поставили что было»). В результате дежурный инженер должен помнить, в какую систему смотреть в зависимости от того, какой сервер упал, а сводного представления «весь парк, один взгляд» не существует в принципе.

Практическое решение — выбрать один стек мониторинга, который работает поверх стандартных Linux-механизмов и одинаково ставится на оба дистрибутива. Обычно это один из двух вариантов:

Если вы ещё не определились, что использовать, — сравнение подходов подробно разобрано в статье Zabbix или Prometheus: что выбрать для сервера. Для смешанного парка есть отдельный аргумент в пользу Prometheus с node_exporter: это статический Go-бинарник без зависимости от версии пакетов дистрибутива, что снимает часть головной боли с «а есть ли нужная версия агента в репозитории Astra».

Практический чеклист для унификации мониторинга на смешанном парке:

• Разворачивайте агент через тот же Ansible-плейбук с условной логикой, что и остальной софт — не отдельным скриптом «руками на Astra».
• В метаданных хоста (лейблах Prometheus, макросах Zabbix) фиксируйте дистрибутив и версию отдельным полем — это даёт фильтр по ОС в дашбордах, когда нужно сравнить поведение одного сервиса на разных системах.
• Мониторьте сам факт, что агент жив и отдаёт метрики: типичная тихая проблема смешанного парка — агент на Astra не переставился при обновлении версии, и сервер выпал из мониторинга незаметно.
• Не держите мониторинг на том же сервере, что и то, за чем он следит — именно мониторинг обычно первым сигнализирует о рассинхроне между половинами парка.

Документирование: реестр «что на чём и почему»

Третий узел — документация, и именно здесь чаще всего проваливаются смешанные парки, потому что документация кажется «делом на потом». На практике без явного реестра ответ на вопрос «а почему сервис X у нас на Astra, а не на Ubuntu» через полгода знает один конкретный человек, а не команда, — и когда этот человек в отпуске или уволился, решения принимаются заново, вслепую, иногда в противоречии с изначальной причиной.

Минимально жизнеспособный реестр — это таблица (в CMDB типа NetBox, в Confluence, даже в git-репозитории рядом с инвентарём Ansible в виде YAML) со следующими полями на каждый сервер:

# inventory/registry/web-03.yml
hostname: web-03
os: astra-linux
os_edition: special-edition-1.7
reason: "Требование заказчика по 152-ФЗ, контур с ПДн"
migrated_from: ubuntu-24.04
migration_date: "2026-03-14"
owner: infra-team
review_date: "2027-03-01"
notes: >
  Мандатное разграничение доступа включено, не отключать
  без согласования с owner. См. runbook в wiki/astra-mac.

Если у вас уже есть CMDB на базе NetBox или похожего инструмента, эти поля стоит завести как кастомные атрибуты хоста, а не держать отдельным файлом — так реестр не разъедется с реальным инвентарём. Важна не форма хранения, а сам факт фиксации: какая ОС, почему именно она, кто владелец решения и когда его пересматривать.

Отдельно стоит документировать не сами серверы, а отличия в процедурах. Runbook «как обновить веб-сервер» для смешанного парка должен явно ветвиться: «на Ubuntu делаем так, на Astra — так, а здесь разница критична, а не косметическая». Не рассчитывайте, что дежурный инженер сам сообразит по ходу дела в 3 часа ночи при инциденте.

План постепенной миграции: волнами, а не хаотично

Четвёртый узел — как двигать парк от состояния «половина на половину» к целевому состоянию, не превращая процесс в постоянный источник инцидентов. Ключевая ошибка — миграция «по мере попадания под руку»: сегодня перенесли один сервер, потому что было время, завтра другой, потому что кто-то настоял, без общего плана и приоритизации. Итог — тот самый хаотичный парк, где через год непонятно, что где стоит и почему.

Работающая альтернатива — план волнами с явными критериями для каждой волны:

1. Волна 0 — пилот. Один-два некритичных сервера, максимум телеметрии, цель — обкатать автоматизацию и мониторинг именно на новом дистрибутиве, а не сам сервис.
2. Волна 1 — низкий риск. Внутренние сервисы, staging-окружения, всё, где даунтайм не бьёт по клиентам напрямую. Здесь же обкатывается runbook отката — важно заранее понимать, как быстро вернуться на Ubuntu-образ, если что-то пошло не так, и держать план отката в явном виде.
3. Волна 2 — сервисы средней критичности. Переносятся только после того, как волна 1 отработала без сюрпризов минимум один полный цикл релизов/обновлений — не по календарю, а по факту стабильности.
4. Волна 3 — критичный прод. Переносится в последнюю очередь, в плановое окно, с полным откатным планом и, желательно, с параллельным существованием старого сервера какое-то время после переключения трафика.

Каждая волна фиксируется в том же реестре, что описан выше, с датой и критерием перехода к следующей. Если формального требования мигрировать конкретный сервис нет — вопрос «а надо ли» стоит задавать до включения его в план, а не после: миграция ради миграции добавляет нагрузку без выгоды.

Общие принципы составления такого плана — чеклист по откату, критериям готовности и точкам проверки — подробно разобраны в статье Как составить план миграции на новый сервер и применимы здесь почти без изменений.

Организационные советы для команды на разнородном парке

Технические решения выше не работают сами по себе без организационной дисциплины команды. Несколько практик, которые снижают трение конкретно там, где парк разнородный:

• Один явный владелец решения по каждому дистрибутиву. Не обязательно разные люди для Ubuntu и Astra, но должен быть тот, к кому идти с вопросом «а можно ли так сделать на Astra» — без этого решения принимаются ситуативно и противоречиво.
• Code review плейбуков с прогоном на обоих типах хостов в CI, если есть тестовый стенд с обеими ОС — не полагайтесь на то, что «раз на Ubuntu заработало, значит и на Astra заработает».
• Единый onboarding для новых инженеров: у нас смешанный парк, вот почему, вот реестр серверов, вот где разница в процедурах. Инженер, не знающий про существование Astra в парке, — гарантированный источник инцидента в первую же дежурную смену.
• Регулярный пересмотр реестра, а не «write once». Раз в квартал стоит проверять, всё ли ещё актуальна причина, по которой конкретный сервер на Astra, а не на Ubuntu.
• Явное разделение «временно смешанный» и «постоянно смешанный». Если часть парка навсегда останется на Astra по требованиям регулятора — это другой режим работы, чем активная миграция с целевой датой завершения, и команда должна понимать, в каком режиме находится прямо сейчас.

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

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