Ubuntu Enterprise Store: как обновлять snaps в сети без интернета

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

Ubuntu Enterprise Store закрывает этот сценарий: принимает экспортированные snaps внутри изолированной сети и раздаёт их локальным клиентам. Тебе не придётся открывать интернет каждому узлу или обновлять серверы по одному.

Один сервер вместо выхода в интернет с каждого узла

Enterprise Store входит в Ubuntu Pro и работает между клиентскими устройствами и хранилищами Canonical. Через одну точку можно распространять snaps и charms, фиксировать разрешённые revisions и контролировать обновления внутри контура.

В сети с интернетом Enterprise Store действует как smart proxy к SaaS Snap Store. Первый запрос забирает пакет снаружи, следующие получает из локального кэша. Это сокращает повторные загрузки и оставляет один контролируемый канал выхода из сети (ubuntu.com, snapcraft.io).

В air-gap схема другая. Enterprise Store становится локальным Snap Store и не обращается ни к SaaS Snap Store, ни к интернету. Клиенты видят только внутреннее хранилище.

Но изоляция не устраняет зависимость от данных Canonical. Snaps, metadata, assertions и сведения об аккаунтах нужно подготовить на подключённой машине, перенести на носителе и импортировать внутрь.

Режим air-gap выбирают до подключения клиентов

По умолчанию Enterprise Store запускается в online mode. Air-gap включается отдельно:

sudo enterprise-store enable-airgap-mode

Не проверяй эту команду на уже работающем контуре. Документация предупреждает: отключение и повторное включение air-gap после подключения клиентов приводит к нежелательным последствиям с неопределённым результатом.

Значит, режим выбирают до регистрации устройств. Если хранилище уже обслуживает клиентов через online proxy, для air-gap безопаснее готовить отдельный экземпляр, а не переключать действующий.

Экспорт начинается на машине с доступом к SaaS Snap Store

Сначала зарегистрируй offline store. В <URL> укажи внутренний адрес, по которому клиенты будут обращаться к Enterprise Store:

store-admin register --offline <URL>

Команда создаст архив offline-snap-store.tar.gz. Перенеси его на сервер в закрытой сети и импортируй:

sudo enterprise-store push-store offline-snap-store.tar.gz

Архив содержит данные для регистрации локального хранилища. Одного его недостаточно: пакеты экспортируют отдельно.

Для каждого набора snaps зафиксируй канал и архитектуру. Так в контур не попадёт сборка, которую команда не проверяла:

store-admin export snaps <snap-names> \
 --channel=<channel> \
 --arch=<arch>

Полученный tarball перенеси внутрь и загрузи:

sudo enterprise-store push-snap <path-to-snap-tarball>

Enterprise Store раздаёт импортированные пакеты локальным клиентам. Новый revision не появится внутри сам: оператор должен снова экспортировать его с подключённой машины и провести через принятую в организации процедуру переноса.

Не забудь базовые snaps

Экспорт прикладного пакета может пройти успешно, а установка на устройстве — упасть из-за отсутствующей базы. Canonical рекомендует перенести snaps, которые уже стоят на клиентах: core, core18, core20, core22, core24 и snapd.

Собери их в тот же экспорт:

store-admin export snaps \
 core core18 core20 core22 core24 snapd \
 --channel=stable \
 --arch=amd64

Не копируй пример вслепую. Канал и архитектура должны совпадать с твоим парком устройств. Для нескольких архитектур подготовь отдельные экспорты.

PostgreSQL и ключи нужны до первого импорта

Серверу Enterprise Store требуется сетевой доступ к настроенной PostgreSQL. База может находиться на другом узле закрытого контура, но маршрут и правила firewall должны разрешать соединение до запуска хранилища.

Отдельно проверь ключи бренда. Устройства проходят аутентификацию по serial assertions для моделей конкретного brand account. Ключ, которым подписывают модели и serial assertions, сначала регистрируют в SaaS Snap Store:

snapcraft register-key

Сделай это до экспорта. Незарегистрированный ключ нельзя исправить только внутри air-gap: процедуру придётся повторить на стороне с интернетом, затем снова перенести данные.

Закреплённый revision отделяет проверку от публикации

Enterprise Store умеет переопределять revisions snaps. В закрытом контуре это полезнее автоматической доставки последней сборки: команда проверяет конкретный revision, разрешает его во внутреннем хранилище и только после этого отдаёт клиентам (ubuntu.com, snapcraft.io).

Такой контроль не заменяет тестирование. Он гарантирует другое: клиент получит выбранную сборку, а не более свежий revision, который появился в SaaS Snap Store после проверки.

Подключай клиентов после двух проверок

Наличие tarball на диске ничего не говорит о состоянии хранилища. После импорта проверь stores и account keys:

enterprise-store status

Затем запроси список загруженных snaps:

enterprise-store list-pushed-snaps

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

Рабочее правило простое: сначала выбери air-gap и больше не переключай режим; затем зарегистрируй store, перенеси его данные и пакеты; только после проверки обеих команд подключай клиентов. Иначе отлаживать придётся уже внутри сети, где нельзя скачать недостающий snap или заново зарегистрировать ключ.