Замена Nexus на open source: миграция пакетов и правила хранения

Зачем менять Nexus или Artifactory и что обычно болит

Когда репозиторий небольшой, коммерческий Nexus или Artifactory легко воспринимается как решение из серии «поставил и забыл». Но по мере роста команд и числа пакетов всплывают проблемы, которые бьют по бюджету и надежности.

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

Вторая причина - эксплуатация. Обычно болит сразу в нескольких местах: заканчивается диск и чистки делаются вручную; сборки замедляются из-за индексации и тяжелых метаданных; права доступа со временем расползаются; копятся снапшоты, мусорные версии и дубликаты.

На этом фоне переход на open source обычно не про «сэкономить любой ценой», а про контроль. Хочется самому задавать правила хранения, понимать, где лежат данные, и не быть привязанным к одному поставщику.

До старта важно понять, что нельзя потерять при переходе. Чаще всего критичны привычные URL и структура репозиториев (чтобы не править сотни конфигов), безопасность (аутентификация, токены, аудит) и скорость скачивания для CI.

Еще до выбора аналога Artifactory полезно договориться об ограничениях миграции: допустимое окно простоя (или требование без простоя), порядок переключения и цели по RPO/RTO. Например, RPO «не теряем ни одного опубликованного пакета» означает четкий план синхронизации и заморозки публикаций, а RTO «сборки должны заработать за час» влияет на подготовку DNS, зеркал и сценарий отката.

Open source аналоги: что сравнить перед выбором

Если планируется замена Nexus на open source, начните не с названия продукта, а с карты реальных потребностей. Одно решение может отлично закрывать Maven, но быть неудобным для Docker/OCI. Другое даст приятный интерфейс, но потребует больше ручной настройки прав.

Сначала зафиксируйте, какие типы пакетов живут у вас сейчас и какие появятся в ближайшие 6-12 месяцев. Обычно это Maven, npm, PyPI, NuGet и контейнеры Docker/OCI, но иногда всплывают редкие форматы. Чем точнее список, тем меньше сюрпризов во время миграции.

Режимы работы и совместимость

Проверьте, какие режимы нужны и как они называются в выбранном решении. В Nexus это proxy, hosted и group. В open source аналогах названия могут отличаться, но смысл тот же: кэшировать внешние источники, хранить свои пакеты и давать единый адрес для клиентов.

Перед установкой в прод сравните базовые вещи: поддерживаемые форматы и особенности (особенно npm и NuGet), наличие режимов proxy/hosted/group, удобство настройки для команд, модель прав (роли, группы, гранулярность, защита от случайной публикации), надежность (кластер или хотя бы понятный план восстановления и бэкапы), а также UI и интеграции с CI.

Отдельно про контейнеры Docker/OCI

Контейнерный registry часто становится главным потребителем диска, поэтому требования к тегам и очистке лучше проверить заранее.

Минимум, который стоит уточнить: можно ли защищать релизные теги и запрещать перезапись (включая latest), как устроена уборка (старые теги, неиспользуемые слои), и насколько решение совместимо с вашими пайплайнами сборки и деплоя.

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

Инвентаризация: что у вас есть сейчас

Перед тем как начинать замену Nexus на open source, полезно описать текущую картину так, как если бы вы передавали репозиторий другой команде. Это экономит дни: меньше сюрпризов, меньше откатов.

Начните со списка репозиториев и их роли. Обычно есть хранилища для релизов (неизменяемые версии), снапшотов (частые сборки), прокси к внешним источникам (ускорение загрузки и защита от сбоев) и локальные репозитории для внутренних пакетов. Отметьте, что реально используется, а что осталось «на всякий случай».

Дальше оцените объемы и рост. Одного общего размера на диске недостаточно: нужно понять, где именно копится. Часто 20% репозиториев занимают 80% места, и это определяет стратегию переноса и правила хранения.

Зафиксируйте, кто и как публикует артефакты. Разделите потоки на CI (например, сборки по коммиту), ручные загрузки, публикации из IDE, отдельные команды или подрядчиков. Ручные загрузки - частый сигнал, что на новом месте придется навести порядок в правах и правилах именования.

Минимальный набор данных, который удобно собрать в одну таблицу:

• репозиторий, тип (release, snapshot, proxy, local) и владельцы
• объем сейчас, прирост за месяц, топ самых «тяжелых» проектов
• способы публикации (пайплайны, токены, учетные записи)
• критичные интеграции (Jenkins или GitLab CI, IDE, Kubernetes, сканеры уязвимостей)
• внешние источники, которые проксируются, и причина

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

Целевая схема: как будет выглядеть новый репозиторий

Целевая схема нужна до миграции. Иначе вы перенесете пакеты, а потом начнете переделывать адреса, права и правила хранения. Удобнее заранее описать, как разработчики будут публиковать и скачивать артефакты в каждой среде.

Репозитории по средам: dev, stage, prod

Понятный вариант - разделить публикацию по средам, чтобы случайная сборка из dev не попала в prod. Обычно хватает:

• dev: частые публикации, snapshots, экспериментальные пакеты
• stage: кандидаты в релиз, проверка воспроизводимости
• prod: только релизы, минимальные права на публикацию

Заранее решите, разделение будет физическим (разные репозитории/бакеты/каталоги) или логическим (правила и права в одном хранилище). Небольшим командам часто достаточно логики. Для строгих контуров безопасности чаще выбирают физическое разделение.

Домены и URL: оставить старые или ввести новые

Если CI, Docker, Maven и npm уже настроены на старые адреса, сохранение URL заметно снижает риск. Обычно это делают через DNS-алиас или обратный прокси, который принимает старые запросы и отправляет их на новый сервис.

Новые URL разумны, когда вы хотите сразу навести порядок: единый нейминг, отдельный домен для внутренних сервисов, понятные имена репозиториев. Тогда закладывайте время на обновление CI и конфигов разработчиков.

Хранилище и доступность

По хранению многие начинают с локального диска, но быстро упираются в рост. Сетевое хранилище упрощает расширение и бэкапы. Объектное подходит, когда нужен дешевый объем и есть практика работы с S3-совместимыми системами.

По доступности выберите понятный минимум: один узел с хорошими бэкапами или несколько узлов с балансировкой. Если ожидается рост, сразу планируйте, где будет жить репозиторий (например, в вашем дата-центре на сервере уровня GSE S200 или на существующей платформе), и какой запас по CPU, памяти и диску нужен на 12-18 месяцев.

Пошаговый план миграции пакетов без сюрпризов

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

Шаги, которые стоит пройти по порядку

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

Дальше двигайтесь по этапам:

• Определите стратегию переключения и дату «заморозки» (когда прекращаете публиковать в старый репозиторий).
• Настройте прокси к внешним источникам и заранее прогрейте кэш для критичных зависимостей, чтобы первая сборка не стала сюрпризом.
• Перенесите hosted-репозитории: сначала общие библиотеки, затем сервисы, затем редкие пакеты.
• Синхронизируйте метаданные и теги версий (где применимо), затем включите тестовую публикацию из CI в новый репозиторий.
• Переключите клиентов: CI, рабочие машины разработчиков, кластеры. Удобнее делать это через централизованные переменные и шаблоны конфигураций.

Рабочий сценарий для снижения риска: сначала переводите чтение зависимостей на новый репозиторий, а публикацию оставляете в старом на 1-2 недели. Когда сборки стабильно проходят, включаете публикацию в новый и закрываете запись в старый.

План отката, который реально сработает

Откат должен быть заранее проверен и укладываться в минуты:

• вернуть старые адреса репозиториев в CI и шаблонах конфигурации
• временно открыть запись в старый репозиторий
• зафиксировать, какие версии успели уйти только в новый, и как их догнать обратно

Так замена Nexus на open source становится предсказуемой: меняется система, но не ломается привычный путь сборки и релиза.

Права доступа: перенос ролей и защита публикации

При миграции репозитория чаще всего ломается не выгрузка пакетов, а доступы. Люди внезапно не могут скачать зависимости, а CI публикует артефакты не туда или вообще в общий репозиторий. Права лучше перенести до основной миграции и проверить на тестовом проекте.

Сначала выпишите модель доступа: локальные пользователи, группы LDAP/AD, роли, а также токены (user tokens, access tokens, API keys). Отдельно отметьте, чем пользуются роботы в CI и какие репозитории доступны внешним командам.

Сопоставление прав в новом решении

Почти в любом репозитории права сводятся к одному набору действий. Удобно договориться о понятных ролях (reader, publisher, maintainer, admin) и сопоставить их с разрешениями:

• Read (download) и Browse - для большинства разработчиков
• Write (publish) - только для релизных пайплайнов и ответственных команд
• Delete - узкому кругу по процессу
• Admin - минимальному числу людей, лучше отдельной группе

Сервисные аккаунты CI создавайте отдельно от личных. Давайте им минимальные права: публикация только в конкретные hosted-репозитории и чтение только нужных proxy/group.

Токены делайте с ограниченным сроком жизни, храните в секретах CI, включите ротацию (например, раз в 30-90 дней) и отключайте при увольнении или смене подрядчика.

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

Логи и аудит

Чтобы разбирать инциденты и проходить проверки, заранее решите, что логировать. Минимум:

• кто скачал или опубликовал пакет (пользователь или сервисный аккаунт)
• откуда и когда
• какие действия были запрещены политиками
• изменения прав и ролей
• операции удаления и перепубликации версий

Так проще найти причину, если появилась неподписанная версия или кто-то случайно затер релиз.

Политика ретеншена: как не утонуть в версиях

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

Сначала разделите артефакты по смыслу. Релизы, которые уходят в прод, обычно хранятся долго и редко удаляются. Временные артефакты (feature-ветки, nightly, экспериментальные пакеты) должны жить ограниченное время.

Хороший старт - простые правила, которые легко объяснить и проверить:

• для релизов хранить последние N версий (например, 20) и не трогать помеченные как LTS
• для временных сборок удалять по возрасту (например, старше 14-30 дней)
• делать исключения по тегам или префиксам (keep-, release-, hotfix-)
• закреплять критичные артефакты перед чисткой
• требовать понятные теги и версии вместо случайных

Для Docker/OCI часто нужны отдельные правила. Тег latest сам по себе ничего не говорит, он просто указатель. Обычно удобнее хранить по шаблонам: main и release-теги держать дольше, feature/* и nightly чистить быстрее, а для откатов сохранять последние 5-10 образов по каждому сервису. Отдельно проверьте, что не удаляете образы, которые еще используются в кластере или в манифестах деплоя.

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

Согласование с командами лучше вести через конкретные сценарии. Разработчик хочет откатиться на версию двухнедельной давности. Если правила удаляют ее через 7 дней, откат сорвется. Тогда меняйте пороги или вводите промежуточное правило: все, что попало в staging, живет минимум 30 дней.

Контроль места на диске и обслуживание

После замены Nexus на open source проблемы часто прилетают не во время миграции, а позже: диск внезапно заканчивается, сборки падают, а времени разбираться нет. Контроль объема и регулярное обслуживание лучше заложить как обязательную часть эксплуатации.

Лимиты и наблюдение

Начните с порогов и понятных уведомлений. Важно, чтобы алерт видел не один админ, а те, кто реально реагирует.

• 70% занято: предупреждение, оценить рост и ближайшие релизы
• 85%: срочная уборка по правилам ретеншена, остановить лишние публикации
• 95%: аварийный режим, временно запретить push, назначить окно обслуживания

Чтобы понимать, что именно раздувается, раз в неделю снимайте отчет по потреблению: топ репозиториев, топ проектов, самые крупные артефакты. Это быстро выявляет перекосы, например nightly-сборки, публикуемые как «релизы», или гигабайтные debug-символы без срока жизни.

Уборка и бэкапы

Уборка должна быть регулярной и предсказуемой. Лучше фиксированное расписание и короткое окно обслуживания, чем редкие «генеральные уборки» в разгар релиза. Перед включением автоочистки протестируйте правила на копии или на одном репозитории, чтобы случайно не снести нужные версии.

Кэш прокси и временные файлы обычно можно чистить без риска, если помнить разницу: кэш восстановится скачиванием, а локально опубликованные артефакты - нет. Отдельно проверьте, где лежат временные директории загрузок и незавершенные сессии.

Бэкап должен покрывать и «мозги», и «тело» репозитория:

• метаданные (БД, конфиги, пользователи/роли, настройки)
• бинарники (blob-хранилище, артефакты)
• частота: метаданные ежедневно, бинарники по вашему RPO (часто хватает ежедневного инкремента и еженедельного полного)

Если прокси-репозиторий за месяц вырос на сотни гигабайт, а локальные релизы почти не менялись, чаще всего виноват кэш. Тогда помогают TTL, регулярная очистка неиспользуемых пакетов и отчет «что скачивают, но не используют».

Пример сценария миграции для среднего проекта

Представим средний продукт: 3-4 команды, сборки в CI, используются Maven (Java), npm (фронтенд) и Docker-образы для тестовых и прод окружений. Цель - замена Nexus на open source без остановки релизов и без потери артефактов.

Сначала поднимают новый репозиторий в отдельной среде и настраивают прокси для внешних источников (Maven Central, npm registry, базовые Docker-образы). Это снижает зависимость от интернета и позволяет проверить кеширование, не трогая текущие пайплайны.

Дальше миграция идет волнами. Удобно начать с релизов: они реже меняются, по ним проще проверить целостность, подписи и метаданные. После релизов переносят снапшоты, затем веточные сборки (feature, hotfix), которые обычно создают основной «мусор».

Примерный порядок:

• День 1-2: поднять новый репозиторий, настроить прокси и базовые репозитории (maven-releases, maven-snapshots, npm, docker).
• День 3-4: перенести релизные артефакты и образы, сверить хэши и наличие тегов.
• День 5: перенести снапшоты и веточные сборки, включить первичную политику ретеншена.
• День 6: переключить один проект в CI на публикацию в новый репозиторий и понаблюдать.
• День 7: переключить остальные проекты и команды.

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

Финиш: обновляют настройки у разработчиков (settings.xml, .npmrc, docker login), замеряют скорость скачивания и нагрузку на диск, и держат старый репозиторий в режиме read-only еще 2-4 недели. После выдержки, когда релизы повторяются из нового хранилища, старый сервер отключают.

Частые ошибки и как их избежать

Самая дорогая ошибка при замене Nexus на open source - начать перенос «с того, что проще», не понимая полную картину. Часто всплывают редкие репозитории (например, старый npm или приватный Docker registry), которые используются раз в месяц, но ломают релиз в самый неподходящий день. Лечение одно: перед любыми копированиями зафиксируйте список форматов, репозиториев, прокси, расписаний очистки и реальных клиентов (CI, разработчики, сборочные агенты).

Вторая частая проблема - слишком широкие права у CI. Если токен сборки может удалять, перезаписывать или публиковать в релизный репозиторий, одного неверного тега достаточно, чтобы потерять доверие к хранилищу. Разделяйте права: CI публикует в snapshots (или staging), а продвижение в releases делайте отдельной ролью и отдельным шагом пайплайна.

Как не сорвать сборки в день переключения

Срывы обычно происходят не из-за копирования артефактов, а из-за настроек клиентов: зеркала, пути, сертификаты, имена репозиториев. Выделите время на тест: один реальный сервис, один реальный пайплайн, полная сборка с нуля. И держите план отката: как быстро вернуть старый URL или прокси, если в новом репозитории обнаружится «дырка».

Ретеншен и бэкапы: осторожно с автоматикой

Опасно включать ретеншен сразу после переноса. Типовой сценарий: правило «оставить последние 10 версий» удаляет не версии, а единственный рабочий тег, который оказался старым. Сначала запустите ретеншен в режиме отчета (dry-run), согласуйте исключения (релизы, теги, важные ветки), и только потом удаляйте.

Перед стартом проверьте базовые вещи:

• есть ли бэкап не только blobs, но и метаданных (индексы, база)
• делали ли вы тестовое восстановление на отдельной машине
• измерен ли рост диска и есть ли пороги оповещений
• описан ли порядок смены DNS/URL и обратного переключения
• зафиксированы ли неочевидные клиенты (старые агенты, скрипты, cron)

Если Maven-проект собирался годами через один settings.xml, то смена имени репозитория без алиаса почти гарантированно сломает сборку, даже если все артефакты уже перенесены.

Короткий чеклист и следующие шаги

Чтобы замена Nexus на open source не превратилась в бесконечную ручную поддержку, закройте базовые вопросы до финального переключения. Один раз договориться и записать правила обычно дешевле, чем потом разбирать, почему пропали теги, перепутались права или внезапно закончился диск.

Проверьте минимум:

• Зафиксированы форматы и источники: какие пакеты хранятся (Maven, npm, Docker), какие репозитории нужны и кто владелец каждого.
• Описаны права: кто читает, кто публикует, кто администрирует, и что считается «продом» (например, запрет перезаписи релизов).
• Согласована политика хранения: сколько версий держим, что удаляем, какие исключения нужны (критичные релизы, регуляторные требования, «золотые» образы).
• Настроен контроль диска: пороги, алерты, регулярная уборка по расписанию и понятная процедура на случай переполнения.
• Проведен тестовый прогон: перенос части пакетов на стенд, проверка сборок и документированный план отката.

Дальше действуйте по шагам, чтобы не сломать разработку в середине спринта. Назначьте окно переключения и заранее предупредите команды, какие операции временно заморозятся (публикация, удаление, создание новых репозиториев). Отдельно прогоните критичные пайплайны: выпуск релиза, сборку из кэша, подтягивание зависимостей в изолированной среде.

Следующие практичные шаги:

• Утвердить дату cutover и короткий регламент на день миграции.
• Подготовить инструкции для команд: адреса, токены, правила публикации.
• Провести финальную сверку: размер хранилища, скорости, права, ретеншен, алерты.
• Запланировать пост-миграционный аудит через 1-2 недели: что выросло по объему, что чистить, где не хватает ограничений.

Если нужна помощь с проектированием и внедрением, можно привлечь системного интегратора. Например, GSE.kz (gse.kz) может закрыть инфраструктурную часть: подбор и поставку серверов, развертывание решения и сопровождение 24/7.