Onedir-пакеты и репозиторий

Onedir («one directory») — это формат поставки Salt, при котором пакет несёт в одном каталоге всё необходимое: собственный интерпретатор Python, библиотеки-зависимости и сам код Salt. Установленный onedir-пакет живёт в /opt/saltstack/salt и никак не зависит от системного Python — на хосте может стоять сколь угодно старый дистрибутив, Salt всё равно работает на своём рантайме. Сегодня это рекомендуемый и фактически единственный официальный формат пакетов. Вторая часть темы — репозиторий: в конце 2024 года пакетная инфраструктура Salt переехала с repo.saltproject.io на packages.broadcom.com (Artifactory), и все инструкции, скрипты и пайплайны, ссылающиеся на старый домен, требуют обновления. В новом репозитории доступны только версии начиная с 3006 — более старые пакеты получить нельзя.

Как это работает

Onedir-пакет ставится обычным пакетным менеджером (apt, dnf, zypper) из репозитория Broadcom и разворачивает изолированное окружение в /opt/saltstack/salt. Внутри — свой Python и свой набор site-packages, поэтому системные Python-библиотеки Salt не видит. Для установки дополнительных Python-зависимостей в это окружение существует отдельная команда salt-pip: например, salt-pip install saltext-... ставит community-расширение именно туда, где его найдут execution- и state-модули. Это особенно важно после релиза 3008: в ходе «Great Module Migration» значительная часть модулей вынесена из ядра в отдельные расширения (GitHub-организация salt-extensions), и их подключение — это как раз salt-pip. При подключении репозитория вы фиксируете мажорную ветку (3006, 3007 или 3008) в конфигурации источника пакетов, а точечные релизы (3008.1, 3008.2) приходят как обычные обновления.

Когда применять

Onedir — выбор по умолчанию для любых новых инсталляций: единый формат для всех поддерживаемых дистрибутивов, отсутствие конфликтов с системным Python и предсказуемое поведение при обновлениях ОС. Если у вас остались старые инсталляции на классических пакетах (до 3006), путь один — миграция на onedir по официальному гайду, потому что классические сборки в репозитории Broadcom отсутствуют. Отдельный сценарий — автоматизация: если репозиторий подключается через Ansible, Terraform, cloud-init или собственные формулы, укажите в шаблонах packages.broadcom.com и конкретную мажорную ветку, чтобы разворачиваемые машины не «уезжали» на другую версию при выходе нового мажора.

Типичные ошибки

Классика после переезда — пайплайны и золотые образы, в которых зашит repo.saltproject.io: они начинают падать на этапе apt update, и чинить это приходится в самый неудобный момент. Вторая ошибка — ставить Python-зависимости системным pip3 и удивляться, что Salt их не видит: onedir использует собственные site-packages, нужен salt-pip. Третья — обновление 3006 → 3008 без учёта Great Module Migration: состояние, которое годами работало, вдруг сообщает об отсутствующем модуле, потому что тот переехал в saltext-…. И, наконец, не закрепив мажорную ветку в конфигурации репозитория, легко получить внезапный скачок на новый мажор при очередном плановом обновлении пакетов.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы