За последние пару лет доступность внешних реестров и CDN для российских команд стала менее предсказуемой. Для пользователя это обычно выглядит как «сайт не открывается», а для разработчиков — как внезапно упавший CI, зависшая сборка или сорванный деплой.

Привет, Хабр! Меня зовут Рахимов Искандер, я фронтенд‑разработчик в компании Sofoil.

Для понимания контекста: речь идёт о подразделении Sofoil, которое занимается разработкой интерактивных обучающих систем. В команде работает 16 разработчиков, а основной стек — Angular на фронтенде и Python на бэкенде.

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

В какой‑то момент стало понятно, что проблему нужно решать системно. В качестве решения мы выбрали Sonatype Nexus 3. Расскажу, как внедряли его в инфраструктуру, какие задачи он закрыл и с какими нюансами пришлось столкнуться.

Зачем нам это понадобилось

Проблем накопилось достаточно.

Сборка в CI/CD могла значительную часть времени тратить только на скачивание зависимостей с registry.npmjs.org или pypi.org. Иногда всё заканчивалось таймаутом ещё до запуска тестов.

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

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

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

Главным триггером стали массовые развёртывания. Когда необходимо одновременно поднять 20–30 серверов, каждый из них начинает скачивать зависимости. Если все обращения идут во внешний npm или PyPI, очень быстро появляются таймауты, ошибки и непредсказуемое поведение. В таких сценариях стабильность инфраструктуры начинает зависеть от множества внешних факторов, которые мы не контролируем.

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

Почему именно Nexus

Вариантов было несколько. Например, можно использовать Verdaccio для npm и devpi для Python.

Но нам хотелось получить единый инструмент вместо нескольких специализированных сервисов.

Nexus 3 поддерживает большое количество форматов: npm, PyPI, Maven, Docker, NuGet и другие. Это оказалось удобно с точки зрения дальнейшего развития инфраструктуры. Если позже потребуется репозиторий для Docker‑образов или других артефактов, можно просто добавить новый репозиторий в существующий инстанс.

Ещё одной полезной возможностью стали групповые репозитории (group). Они позволяют объединить несколько репозиториев в одну точку входа. Разработчику не нужно помнить, где лежит пакет — во внутреннем репозитории или во внешнем кеше. Он работает с одним адресом, а Nexus сам определяет источник.

Как мы это ставили и настраивали

Процесс установки подробно описан в документации Sonatype, поэтому остановлюсь только на нашей конфигурации.

Мы пошли по пути контейнеризации и развернули Nexus через Docker Compose.

Docker Compose конфигурация

services:
  nexus:
    image: sonatype/nexus3:3.68.0
    container_name: nexus3
    restart: unless-stopped
    ports:
      - "8081:8081"
    volumes:
      - ./nexus-data:/nexus-data
    environment:
      - INSTALL4J_ADD_VM_PARAMS=-Xms2g -Xmx2g -XX:MaxDirectMemorySize=2g

Директиву version не используем, поскольку в Docker Compose V2 она считается устаревшей.

Сразу выделили контейнеру 2 ГБ памяти. На дефолтных настройках интерфейс и операции с репозиториями работали заметно медленнее.

Также важно заранее выдать корректные права на каталог nexus-data (UID 200), иначе контейнер не сможет записывать данные и завершится с ошибкой при запуске.

После старта открываем веб‑интерфейс по адресу:

http://<сервер>:8081

Начальный пароль администратора можно получить командой:

cat /nexus-data/admin.password

После смены пароля можно переходить к настройке репозиториев.

Репозитории для npm

Для npm мы создали три репозитория.

npm‑proxy — прокси‑репозиторий с Remote Storage:

https://registry.npmjs.org

При первом обращении Nexus скачивает пакет, сохраняет его локально и в дальнейшем отдаёт из собственного кеша.

Для параметров Maximum metadata age и Maximum content age установили значение 1440 минут (сутки).

npm‑hosted — репозиторий для внутренних пакетов.

npm‑group — групповой репозиторий, объединяющий proxy и hosted.

Именно адрес группового репозитория используется разработчиками и CI.

Настройка для PyPI

Для Python настроили аналогичную схему:

pypi‑proxy;
pypi‑hosted;
pypi‑group.

В качестве Remote Storage для прокси использовали:

https://pypi.org

Во время настройки столкнулись с неприятной особенностью. Некоторые пакеты с крупными manylinux‑колёсами периодически скачивались некорректно через прокси, из‑за чего сборки завершались ошибками.

Проблему решили включением параметра Strict Content Type Validation в настройках прокси‑репозитория. После этого ошибки перестали воспроизводиться.

Как подружить разработчиков и CI с Nexus

Для npm достаточно указать новый registry:

npm config set registry http://<сервер>:8081/repository/npm-group/

Если репозиторий защищён авторизацией:

npm login --registry=http://<сервер>:8081/repository/npm-group/

Для CI обычно формируется следующий .npmrc:

registry=http://<сервер>:8081/repository/npm-group/
//<сервер>:8081/repository/npm-group/:_auth="BASE64_LOGIN_PASSWORD"
always-auth=true

Для pip используем следующую конфигурацию:

[global]
index-url = http://<сервер>:8081/repository/pypi-group/simple/
trusted-host = <сервер>

Если HTTPS ещё не настроен, параметр trusted-host обязателен, иначе pip может заблокировать установку пакетов.

Что получили после внедрения

Главный результат — зависимости перестали быть внешним фактором риска.

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

Снизилось количество ситуаций, когда пайплайн падает из‑за проблем с сетью или сторонним сервисом.

При массовых развёртываниях серверы больше не конкурируют за доступ к внешним репозиториям. Все необходимые пакеты уже находятся внутри инфраструктуры и доступны через локальный Nexus.

Кроме того, появилась единая точка хранения внутренних библиотек и артефактов.

Про ограничения бесплатного Nexus 3.77+

С этим пунктом у нас связана отдельная история.

Когда Sonatype объявила о новых лимитах для бесплатной версии, мы решили проверить их на практике.

Подняли отдельный инстанс Nexus 3.77+ и написали небольшой скрипт, который в цикле очищал локальный npm‑кеш и заново устанавливал набор зависимостей из package.json одного из наших проектов — эмулировали нагрузку, похожую на то, что создают несколько параллельных CI‑агентов. Запустили скрипт вечером и оставили на ночь.

К утру счётчик показывал уже больше 300 тысяч запросов, и в интерфейсе висела красная плашка с предупреждением о превышении лимитов — Nexus сообщал, что у нас есть 30 дней до начала блокировки записи новых компонентов.

Сам Nexus продолжал работать, но эксперимент показал, что расход запросов происходит заметно быстрее, чем может показаться после чтения документации. Особенно если одновременно работают CI/CD‑пайплайны, прогреваются кеши и выполняются массовые развёртывания.

Стоит уточнить масштаб: речь идёт о команде из 16 разработчиков. Мы не относимся к числу крупных организаций с сотнями сборочных агентов, поэтому результаты теста стали для нас дополнительным аргументом внимательно следить за новыми ограничениями.

После этого теста мы решили пока использовать ветку 3.76.x, где подобных ограничений нет. Для нашей инфраструктуры это оказалось более предсказуемым вариантом.

Если вы планируете использовать версии 3.77+, рекомендую заранее оценить предполагаемую нагрузку и периодически проверять Usage Metrics. Лучше сделать это до того, как лимиты неожиданно напомнят о себе в рабочей среде.

Несколько практических советов

Используйте групповые репозитории как единственную точку входа для команды. Это позволит добавлять новые proxy‑ или hosted‑репозитории без изменения настроек у разработчиков и в CI.

Следите за размером хранилища. Кеш npm и PyPI растёт довольно быстро, поэтому Cleanup Policies стоит настроить сразу. Мы автоматически удаляем артефакты, к которым не было обращений более 180 дней.

Отключите анонимный доступ и настройте роли пользователей. В большинстве случаев открытый доступ внутри корпоративной инфраструктуры не нужен.

При первой возможности поставьте перед Nexus Nginx или Caddy с HTTPS. Это упростит настройку клиентов и избавит от необходимости использовать trusted‑host для pip.

Заключение

Для нас Nexus стал способом снизить зависимость от внешних реестров и сделать процесс сборки более предсказуемым.

Мы получили локальный кеш для npm и PyPI, единое место хранения внутренних пакетов и меньшее количество проблем, связанных с доступностью внешних сервисов.

При масштабе команды в 16 разработчиков затраты на внедрение оказались сравнительно небольшими, а эффект был заметен практически сразу.

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

Nexus 3 как прокси для npm и PyPI: опыт команды из 16 разработчиков