Артефактори и репозитории: обзор Nexus, Artifactory и GitLab Package Registry в 2026

Что такое артефактори и зачем он нужен в CI/CD

Артефактори - выделенный менеджер репозиториев для бинарных артефактов и пакетов: Docker-образов, Maven-библиотек, npm-пакетов, PyPI-дистрибутивов, Helm-чартов, deb- и rpm-пакетов. Он понимает структуру формата, хранит метаданные, управляет версиями, разграничивает права и отдаёт пакеты сборщикам по стандартным протоколам: Docker Registry HTTP API V2, Maven-репозиторий по HTTP, npm registry, PyPI simple index.

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

Пример из практики. Java-проект из 40 модулей при сборке вытягивает более 300 зависимостей из Maven Central. Без проксирующего репозитория каждая сборка обращается во внешнюю сеть, ловит лимиты и падает при недоступности апстрима. Maven-прокси на Nexus или Artifactory кэширует зависимости локально: первая сборка идёт минуты, последующие секунды, а при обрыве внешнего канала пайплайн продолжает работу на кэше.

Ещё один сценарий, где разница видна сразу. Пайплайн собирает Docker-образ, тегирует его как app:1.4.2 и пушит в реестр. Через неделю этот же тег нужен для отката в production. В артефактории образ лежит как неизменяемый объект с манифестом, слоями и digest, а политика запрещает перезапись тега. В файловом хранилище останется .tar-архив или набор слоёв без метаданных, и восстановить из него рабочий образ через docker pull не получится.

Ключевые функции артефактория

• Хранение и версионирование: неизменяемые релизные версии, snapshot-сборки для Maven, теги и digest для Docker-образов.
• Управление зависимостями: разбор транзитивных зависимостей по метаданным POM, package.json, wheel-файлов и .nuspec.
• Проксирование и кэширование внешних источников: Maven Central, npmjs, PyPI, Docker Hub, репозитории вендоров.
• Контроль доступа на основе ролей: отдельные права на чтение, публикацию и удаление для команд, CI-джобов и сервисных аккаунтов.
• Интеграция с пайплайнами через REST API, CLI и плагины: Jenkins, GitLab CI, GitHub Actions, Bamboo, TeamCity.
• Работа с метаданными: для Docker это манифесты и слои, поэтому система считает реальный объём хранилища и удаляет дубли слоёв.
• Политики хранения и очистки: удаление снапшотов старше N дней, лимит числа тегов на образ, автоочистка по маске.
• Аудит: журнал публикаций и скачиваний с привязкой к пользователю или токену, что закрывает требования комплаенса.

Почему файловое хранилище не подходит для артефактов

Каталог с файлами не хранит граф зависимостей. Клиент сборки не знает, что библиотека A требует B версии 2.3 и выше, поэтому разрешение конфликтов перекладывается на инженера и превращается в ручной разбор. Артефактори отвечает на этот запрос метаданными и стандартными протоколами: mvn, npm install, pip install и docker pull работают без правок в коде и без ручного указания путей к файлам.

Пять проблем файлового хранилища, которые ломают CI/CD:

1. Нет проксирования внешних репозиториев, значит каждая сборка зависит от доступности интернета и лимитов публичных реестров.
2. Нет разграничения прав на операции: файловая шара даёт доступ к каталогу целиком, а не к отдельному пакету.
3. Нет метаданных формата: теги, слои и digest Docker-образа теряются, автоматический откат усложняется.
4. Нет дедупликации: один и тот же слой образа или jar-файл хранится десятки раз.
5. Нет политик очистки: хранилище растёт до отказа, и пайплайн падает на записи артефакта.

Граница между системой хранения инструментов и обычной СХД разобрана в материале про систему хранения инструмента: там же приведены примеры на Nexus, Harbor, GitLab и TrueNAS и план запуска хранилища с нуля.

Обзор решений: Nexus, Artifactory и GitLab Package Registry

Три решения закрывают разные сценарии, и выбор между ними определяется масштабом, бюджетом и уже сложившимся стеком.

Nexus Repository (Sonatype) выпускается в версиях OSS и Pro. Внутри одного инстанса создаются репозитории трёх типов: hosted для собственных пакетов, proxy для внешних источников, group для объединения нескольких репозиториев под одним URL. Схема group удобна тем, что в settings.xml или .npmrc прописывается один адрес, а клиент сам получает пакет из локального или проксированного репозитория. Кластеризация и расширенный RBAC доступны только в Pro, OSS рассчитан на один узел.

Artifactory (JFrog) заявляет поддержку более 30 форматов пакетов, включая Cargo, Conan, Terraform, Hugging Face модели и generic-репозитории. Ключевые возможности: виртуальные репозитории с прозрачной маршрутизацией, хранение в объектном хранилище (S3-совместимые бэкенды), горизонтальное масштабирование кластера, язык запросов по метаданным и встроенное сканирование уязвимостей через Xray. Продукт коммерческий, есть урезанное OSS-издание без кластеризации и части форматов.

GitLab Package Registry встроен в GitLab и не требует отдельного сервера. Форматы: Maven, npm, PyPI, NuGet, Composer, Conan, Helm, generic-пакеты, плюс Container Registry для Docker-образов. Интеграция с GitLab CI нативная: аутентификация идёт по CI_JOB_TOKEN без выдачи долгоживущих паролей в переменные. Ограничение принципиальное: реестр не проксирует внешние источники, он только хранит собственные пакеты.

Поддержка форматов: Docker, Maven, npm, PyPI

Проверка форматов начинается с вопроса, нужен ли проксирующий репозиторий. Если команда собирает Java- или Python-проекты, сборка почти всегда обращается к публичным реестрам, и без проксирования пайплайны становятся заложниками внешней сети.

Docker-реестры: особенности и сравнение

Все три решения предоставляют реестр, совместимый с Docker CLI и containerd, поэтому команды docker login, docker push и docker pull работают одинаково. Разница в деталях.

Nexus даёт три роли репозитория для Docker: hosted для собственных образов, proxy для Docker Hub и group для единой точки входа. Проксирование Docker Hub особенно полезно в компаниях, где исходящий трафик на внешние реестры ограничен политиками безопасности или лимитами на скачивание.

Artifactory добавляет работу с мультиархитектурными манифестами (linux/amd64 и linux/arm64 в одном теге), подсчёт и переиспользование слоёв по контрольным суммам, а также сканирование образов на уязвимости до публикации. Для парка из тысяч образов это даёт заметную экономию дискового пространства.

GitLab Container Registry включён в подписку и не требует отдельного сервера, а политики очистки настраиваются через интерфейс проекта и API: можно удалять теги старше 30 дней или оставлять только последние N версий на образ. Скачивание образов из Kubernetes-кластера настраивается через imagePullSecret, а сам кластер удобнее разворачивать рядом с реестром, чтобы не гонять сотни мегабайт между дата-центрами. Сравнение платформ оркестрации под эту задачу приведено в обзоре Kubernetes, Docker Swarm, Nomad и Amazon ECS.

Maven, npm и PyPI: нюансы настройки

Maven. Nexus и Artifactory проксируют Maven Central и корпоративные репозитории, поэтому в settings.xml достаточно указать один mirror. GitLab Package Registry хостит только опубликованные вами артефакты, поэтому внешние зависимости всё равно тянутся из публичного репозитория, если не поднимать отдельный прокси.

npm. Все три решения принимают npm publish и отдают пакеты по протоколу registry. В GitLab в .npmrc прописывается строка вида @scope:registry=https://gitlab.example.com/api/v4/packages/npm/, а токен подставляется переменной окружения. В Nexus и Artifactory проксирование npmjs позволяет пережить недоступность публичного реестра и ускоряет установку за счёт локального кэша.

PyPI. Nexus и Artifactory поддерживают прокси PyPI, что критично для воспроизводимых сборок Python-проектов: pip смотрит в корпоративный index-url, а не в публичный. В GitLab Package Registry аутентификация выполняется по токену доступа или CI_JOB_TOKEN, проксирование внешних пакетов недоступно.

Интеграция с CI/CD: практические сценарии

Типовой сценарий выглядит так: сборка создаёт артефакт, пайплайн публикует его в репозиторий, следующий этап забирает артефакт по неизменяемой версии и разворачивает в целевом окружении. Полный конвейер с этапами сборки, тестов, публикации артефактов и ручным подтверждением перед production описан в руководстве по автоматизированному развёртыванию приложений через CI/CD.

Пример интеграции GitLab Package Registry с GitLab CI

В .gitlab-ci.yml публикация Docker-образа выполняется без ручного хранения пароля: джоба логинится в реестр по предопределённым переменным CI_REGISTRY, CI_REGISTRY_USER и CI_JOB_TOKEN, после чего выполняет docker build с тегом CI_REGISTRY_IMAGE:CI_COMMIT_SHORT_SHA и docker push. Токен живёт только на время джобы, поэтому утечка секрета из логов не даёт долгосрочного доступа.

Для npm-пакетов шаг выглядит так: джоба подставляет токен в .npmrc, затем выполняет npm publish. Для Maven публикация идёт через mvn deploy с параметрами репозитория в settings.xml, который генерируется на этапе before_script. Для PyPI используется twine upload с адресом реестра GitLab и токеном в переменной.

Настройка Nexus и Artifactory для Jenkins

Для Nexus в Jenkins ставится плагин Nexus Artifact Uploader, в настройках создаётся Credentials с логином и паролем сервисного аккаунта, а в задании указываются URL репозитория, groupId, artifactId и версия. Для Artifactory используется плагин JFrog, в декларативном Jenkinsfile применяется шаг rtUpload с указанием целевого репозитория и маски файлов, а rtDownload забирает артефакт на этапе деплоя.

Что даёт такой подход на практике:

• Артефакт публикуется один раз и переиспользуется всеми окружениями, повторная сборка на stage и production исключается.
• Версии фиксируются в неизменяемом виде, откат сводится к подстановке предыдущего тега.
• Скачивание зависимостей идёт из локального кэша, среднее время пайплайна падает, а внешний трафик сокращается.
• Права на публикацию выдаются отдельным токенам, поэтому скомпрометированная джоба не может перезаписать релизный артефакт.

Сравнение по производительности, лицензированию и сложности поддержки

Производительность и масштабируемость

Artifactory масштабируется горизонтально: несколько узлов кластера обслуживают запросы, метаданные и артефакты хранятся в объектном хранилище, что позволяет отдавать тысячи образов в час. Nexus в OSS-версии ограничен одним узлом и масштабируется вертикально: больше CPU, RAM и быстрых дисков. Кластеризация появляется только в Pro. Пропускная способность GitLab Package Registry определяется инфраструктурой самого GitLab: при интенсивной работе с Docker-образами узлы, занятые другими сервисами (Gitaly, Sidekiq, веб), начинают конкурировать за дисковый ввод-вывод, и реестру требуется отдельное хранилище или тюнинг.

Лицензирование и стоимость

В облачном GitLab объём хранилища считается по всем проектам пространства имён, поэтому разросшийся Container Registry способен съесть квоту и заблокировать новые публикации. В self-managed варианте квота не действует, но растут затраты на диски и обслуживание.

Сложность развёртывания и администрирования

Nexus разворачивается за один вечер: Java-приложение, локальный диск или сетевое хранилище, обратный прокси с сертификатом. Дальше требуется настроить репозитории, роли и политики очистки, но базовый контур работает стабильно без ежедневного вмешательства.

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

GitLab Package Registry не требует отдельного администрирования, если GitLab уже обслуживается командой. Ресурсы уходят на другое: мониторинг объёма, политики очистки и контроль того, чтобы реестр не превратился в свалку. Для небольших команд, у которых нет отдельного инженера под хранилища, облачная инфраструктура запускается быстрее всего: VDS под Nexus или управляемый Kubernetes под сам GitLab и его реестр удобно арендовать, например, через Timeweb Cloud, где доступны серверы, объектное хранилище и кластер Kubernetes.

Критерии выбора: под масштаб и бюджет команды

Решать стоит по пяти параметрам: число разработчиков, объём и тип артефактов, нужные форматы, бюджет и наличие уже работающей инфраструктуры.

• До 10 человек, стартап или внутренний проект. GitLab Package Registry покрывает Docker, npm, Maven и PyPI без отдельного сервера и без новых статей расходов. Если GitLab не используется, подойдёт Nexus OSS на одном узле.
• 10-50 человек, несколько стеков. Nexus Pro или Artifactory: нужны проксирование внешних репозиториев, разграничение прав по командам и политики хранения. Проксирование снижает время сборки и снимает зависимость от доступности публичных реестров.
• 50-200 человек, несколько площадок. Artifactory с кластером и репликацией, объектным хранилищем и сканированием образов. Nexus Pro закрывает похожие задачи при меньшем бюджете, если нет требований к горизонтальному масштабированию.
• Enterprise с нормативными требованиями. Artifactory или Nexus Pro плюс аудит, интеграция с SSO, разделение сред и обязательное резервное копирование репозиториев.

Отдельная проверка перед выбором: посчитайте объём Docker-образов за год. Пять сборок в день по 600 МБ дают около 1 ТБ в год, а с учётом тегов на каждую ветку и окружение цифра растёт втрое. Если политика очистки не продумана, бесплатность GitLab Package Registry обернётся платным расширением квоты, а self-hosted Nexus потребует нового массива дисков.

Практические рекомендации и типичные ошибки

Порядок запуска, который экономит время:

1. Определите форматы и источник зависимостей. Если нужны внешние прокси, GitLab Package Registry отпадает как единственное решение.
2. Поднимите репозитории по типам: hosted для своих пакетов, proxy для внешних, group или virtual для единой точки входа.
3. Заведите сервисные аккаунты под каждый пайплайн с минимальными правами и короткоживущими токенами.
4. Настройте политики хранения сразу: срок жизни снапшотов, лимит тегов на образ, удаление неиспользуемых слоёв.
5. Включите резервное копирование конфигурации и хранилища, а также регулярную проверку восстановления.
6. Добавьте мониторинг объёма и числа запросов, чтобы предупреждение приходило до заполнения диска.

Типичные ошибки, которые встречаются в большинстве проектов:

• Отсутствие политики очистки. Хранилище заполняется за несколько месяцев, публикация артефактов падает, пайплайны встают в самый неподходящий момент.
• Слабый контроль доступа. Один общий токен на все джобы даёт любому пайплайну право перезаписать релизную версию или удалить чужой образ.
• Публикация по плавающим тегам latest вместо версии или commit SHA. Откат превращается в лотерею, потому что непонятно, какой код внутри образа.
• Игнорирование метаданных. Образы складывают в generic-репозиторий как tarball, после чего docker pull невозможен, а подсчёт занятого места и поиск версии приходится делать вручную.
• Сборка заново на каждом окружении вместо продвижения одного и того же артефакта. Результат: сборка на stage и production отличается, баг воспроизводится только в проде.
• Отсутствие резервных копий. Репозиторий артефактов быстро становится критичным сервисом, без которого не проходит ни один релиз.

Если пайплайны пишутся вручную и хочется быстрее ловить ошибки в конфигурациях публикации и тегирования, часть рутины снимает ИИ-ассистент: генерация и ревью YAML, разбор логов упавших джоб и подсказки по синтаксису шагов. Единый доступ к моделям без VPN и с оплатой в рублях даёт AiTunnel, который агрегирует более 200 моделей через интерфейс, совместимый с библиотеками OpenAI.

Начните с одного репозитория и одного пайплайна: опубликуйте Docker-образ по версии, заберите его на следующем этапе и проверьте, что повторная сборка не требуется. Такой контур из двух шагов быстрее всего показывает, хватает ли выбранного решения по форматам, правам и объёму хранилища.