Когда компания маленькая, все просто: пара разработчиков тянет образы напрямую с Docker Hub, и никто особо не задумывается, как это работает. Работает — и ладно.

Потом компания начинает расти. У нас, например, это происходило быстро: новые команды, новые продукты, новые процессы. Пришли безопасники с длинным списком требований, CI/CD-пайплайны стали падать в самый неподходящий момент. И тогда стало понятно: то, что работало на старте, больше не работает.

Меня зовут Тимофей Якунин, я менеджер облачного сервиса Evolution Artifact Registry в Cloud.ru. Прошел путь от фулстек-разработчика до руководителя отдела. Я больше пяти лет в облаке, строил разработку с нуля в двух облачных компаниях. Ниже — история о том, как мы прошли путь от простого хранилища до сервиса, на который завязаны и клиенты, и наша собственная инфраструктура.

Сначала про артефакты

Сухое определение: артефакт — это docker-образ, RPM-пакет, Debian-пакет, Helm-чарт и все в этом духе. Но мне нравится другая формулировка:

все, на что падает свет, становится артефактом.

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

Артефакты пронизывают абсолютно все процессы разработки: нет релиза без артефактов, нет деплоя без образов. Ошибки здесь — это не технические инциденты, это бизнес-риски.

Ситуация: у нас есть свой registry, но его не достаточно

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

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

Проблема первая: мы зависели от интернета

Изначально типовой сценарий выглядел так: разработчик или пайплайн обращается к внешнему реестру, а нужный образ скачивается напрямую с Docker Hub или другого публичного источника.
Пока внешний сервис доступен, все работает нормально. Но как только возникают ограничения, недоступность провайдера или сетевой сбой, сборки начинают останавливаться, а команды — ждать.

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

Решением стал кеширующий реестр. Теперь запрос идет не напрямую во внешний мир, а через прокси-слой: первый запрос уходит наружу и сохраняется в кеше, а последующие отдаются уже из него. За счет этого повторные запросы обрабатываются в 3–5 раз быстрее, а при временной недоступности внешнего реестра работа не останавливается.

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

Сейчас кеширующий реестр находится в стадии внутренней разработки и скоро появится в Public Preview. Как говорится, следите за обновлениями.

Проблема вторая: безопасность и контроль

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

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

Но на этом контроль не заканчивается.

Кеширующий реестр важен не только как ускоритель, но и как точка принятия решений: что можно пропускать в инфраструктуру, а что нельзя. Именно здесь у нас появляется следующая важная возможность — SBOM-фильтр.

SBOM, или Software Bill of Materials, — это состав образа, то есть перечень зависимостей, которые в него вошли. SBOM-фильтр срабатывает во время pull-запроса: извлекает состав, сравнивает его с белыми и черными списками, проверяет CVE и лицензии. Если политика нарушена, клиент получает HTTP 403 Forbidden, и образ не выдается.

Такой механизм помогает не только в борьбе с известными уязвимостями. Он также снижает риски supply chain атак, когда вредоносный или нежелательный компонент попадает в сборку под видом обычной зависимости.

SBOM-фильтр тоже находится на стадии внутренней разработки и должен скоро выйти в Public Preview.

Отдельно важен лицензионный контроль.

Open source нельзя использовать без оглядки: некоторые лицензии, например GPL и AGPL, накладывают обязательства по раскрытию кода при распространении ПО. Если не отслеживать такие зависимости заранее, лицензия может стать проблемой уже на этапе сертификации, поставки продукта или подписания контракта.

Проверка через SBOM позволяет увидеть такой риск заранее, а не тогда, когда исправлять уже дорого и сложно.

Проблема третья: надежность

На каком-то этапе мы осознали масштаб ответственности, которая лежит на нас. На Evolution Artifact Registry завязана собственная инфраструктура Cloud.ru, завязаны клиенты, CI/CD-пайплайны десятков команд. Это больше не «один из сервисов» — это узел, который нельзя ронять.

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

Чтобы снизить риски, мы последовательно усиливали платформу: внедрили HPA, репликацию баз данных, Multi A-Z, мониторинг, трейсинг, балансировщики нагрузки и S3 stream. Именно S3 stream хорошо показывает, как точечное архитектурное изменение может дать большой эффект.

До его внедрения Gateway проксировал скачивание через себя: когда клиент тянул образ, данные проходили через сервис, создавая лишнюю нагрузку, утечки памяти и деградацию под пиком.
После внедрения S3 stream данные начали уходить напрямую из хранилища к клиенту, а Gateway стал только выдавать подписанную ссылку и код 302.

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

В результате при пиковой нагрузке загрузка сервиса сократилась в 3 раза, а скорость ответа выросла более чем в 2 раза.

Это был не полный пересмотр архитектуры, а одно прицельное решение с заметным результатом.

Проблема четвертая: типов артефактов больше чем кажется

Изначально реестр артефактов поддерживал Docker-образы. Логично: Docker — самый очевидный артефакт.

Но команды работают не только с контейнерами. Есть виртуальные машины, которым нужны deb- и rpm-пакеты, есть CI/CD-пайплайны, которые читают базовые образы, пакеты и зависимости — и все это хочется хранить в одном месте с единым контролем безопасности.

Дорожная карта выглядит так:

На конференции GoCloud 2026 во время моего выступления меня спросили: какие форматы появятся в следующем году? Честно — не хочу планировать на пять лет вперед и раздавать обещания. Дорожная карта есть, но я предпочитаю двигаться итеративно: смотреть, что реально нужно, слушать тех, кто пользуется продуктом. Если вам чего-то не хватает — напишите нам в поддержку, это лучший способ повлиять на приоритеты.

Pypi-реестры уже вышли в Public Preview и доступны всем.

Что получилось

Сейчас Artifact Registry уже интегрирован с несколькими сервисами платформы Cloud.ru Evolution.
Например, с Evolution Container Apps реализован сценарий автодеплоя из реестра при публикации образов. С IaaS хранилище артефактов используется для дистрибуции deb- и rpm-пакетов для виртуальных машин. Также есть интеграции с Managed Kubernetes, Jupyter-ноутбуками и Workflow Studio.

Отдельный важный сценарий — Cloud.ru Evolution Stack, то есть гибридное облако, которое может работать без доступа в интернет. В такой конфигурации CI/CD получает базовые образы, Debian-пакеты, а также PyPI- и npm-зависимости напрямую из Artifact Registry. Это позволяет убрать критическую зависимость от внешних источников и сделать поставку артефактов более предсказуемой

Что мы поняли

Из финального слайда доклада — формулировки, с которыми трудно поспорить:

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

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

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

И, наконец, быстрый, функциональный и надежный Artifact Registry напрямую влияет на эффективность команд. Чем меньше простоев, ожидания и разборов инцидентов, тем быстрее идут релизы и тем устойчивее работает вся платформа.

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

Если работаете с артефактами, скажите, если вам чего-то не хватает. Лучший способ понять, что делать дальше — спросить у тех, кто этим пользуется.