Технический бэклог — Планы

Внедрение Repository Manager

Отказоустойчивость Производительность
Что такое менеджер репозиториев (repository manager)?
Это приложение реализующее две вещи:
  • Прокси для внешних репозиториев-регистров (docker/npm/composer/...);
  • Хранилище внутренних артефактов. Например докер образов наших сервисов которые мы потом отгружаем в кубер.

Зачем нам нужен менеджер репозиториев?
1. Надежный доступ к артефактам
Мы не зависим от доступности packagist/npm registry/greensight dockerhub/gitlab и т д. Если что из этого упало или недоступно по сети — мы по-прежнему можем собирать и отгружать.
Образы и пакеты мы получаем из кэша менеджера если они были загружены ранее или явно помещены в него, а не из самих регистров.

2. Ускорение билдов и значительное уменьшение внешнего траффика
Если используем self-hosted решение, то менеджер репозиториев у нас в локальной сети относительно ci/cd, что выливается в эти два преимущества.

3. Удобства для разработчиков, связанные с доступами и скоростью установки зависимостей на локалках.
Например, чтобы подтянуть в сервис клиент другого сервиса разработчику больше не нужно в своём сервисе в composer.json указывать путь до репозитория с этим клиентом.
Также ему не нужен непосредственный доступ к этому репозиторию.
Всё что нужно - 1 раз настроить доступ к менеджеру репозиториев.
Также из менеджера репозиториев готовый пакет будет получатся значительно быстрее чем выкачиванием исходников из гитлаба.

4. Безопасность, например контроль за тем какие внешние зависимости установлены, контроль лицензий и уязвимостей.

Для себя мы выбрали Nexus. В результате выполнения фичи:
  1. Развернут Nexus в инфре Ensi;
  2. Настроены все сервисы Ensi и ci/cd на работу с ним.