После массовых ограничений доступа к Docker Hub в России в начале 2026 года многие компании остались без привычных образов на сборках и в CI. Разберём практические варианты замены Docker Hub: зеркала, Selectel, Yandex CR и собственный registry — с конкретикой, командами и оценкой затрат.
Статья была полезной?
В марте 2026 года ряд российских провайдеров и облачных площадок ввёл жёсткие ограничения на доступ к публичному Docker Hub, что привело к ошибкам pull в CI/CD и простоям сборок. Неполадки начались 10 марта 2026: внутренние мониторинги показали рост ошибок 403/429 и падение скорости до 5–10 КБ/с при загрузке слоёв больших образов.
Последствия ощутили сразу: у компаний с непрозрачной политикой кеширования образов сборки стали падать, а команды DevOps потратили первые две недели на поиск обходных путей и миграцию на альтернативные реестры.
Сообщение об ошибке при docker pull из Docker Hub
Самый быстрый способ вернуть сборки в рабочее состояние — поднять локальный pull-through cache или прокси, который кэширует образы из Docker Hub. На практике это даёт 90–99% успеха для уже скачанных слоёв и минимизирует внешний трафик.
Что нужно и сколько: выделите VM с минимум 2 vCPU, 4 ГБ RAM и SSD 200–500 ГБ при ожидаемой суммарной базе образов 500 ГБ. Оценка времени развёртывания — от 30 минут до 4 часов, включая SSL и интеграцию в CI.
mkdir -p /srv/registry
cat > /srv/registry/config.yml <<EOF
version: 0.1
proxy:
remoteurl: https://registry-1.docker.io
storage:
filesystem:
rootdirectory: /var/lib/registry
http:
addr: :5000
EOF
docker run -d --name registry-proxy -p 5000:5000 \
-v /srv/registry:/var/lib/registry \
-v /srv/registry/config.yml:/etc/docker/registry/config.yml \
registry:2После запуска настройте на каждой хост-машине /etc/docker/daemon.json для использования зеркала (пример для Linux):
{
"registry-mirrors": ["http://10.0.0.10:5000"],
"insecure-registries": ["10.0.0.10:5000"]
}Перезапустите Docker: systemctl restart docker. Проверяйте логи proxy: docker logs -f registry-proxy, и держите мониторинг диска: df -h /var/lib/registry. При росте база слоёв будет увеличиваться на 5–300 МБ за образ, средний слой — 50–100 МБ.
Если у вас много консьюмеров (50+ машин) — добавьте nginx-передел с кешем для уменьшения числа обращений к proxy/внешним хостам. Конфигурация кеша должна позволять хранить файлы до 30 дней и ограничивать общий объём кеша, например 300 ГБ.
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=docker_cache:200m
max_size=300g inactive=30d use_temp_path=off;
server {
listen 80;
server_name mirror.internal;
location /v2/ {
proxy_cache docker_cache;
proxy_cache_valid 200 301 302 7d;
proxy_pass http://127.0.0.1:5000;
}
}Реальная выгода: при тесте на 60 виртуальных машинах с параллельными сборками nginx-кеш снизил внешний трафик на 87% и ускорил pull в среднем с 40 с до 6 с для образов, уже закешированных локально.
Архитектура проксирования и зеркалирования образов Docker
Если хочется облачный управляемый вариант в России с поддержкой командной работы и SLA — Selectel предлагает контейнерный регистр, интегрированный с облачной платформой. При переходе вы получите централизованное хранение, RBAC и возможность репликации образов.
Примерный порядок действий (март—апрель 2026): создаёте проект в панели Selectel, включаете Container Registry, получаете endpoint вида registry.sel.cloud/namespace и token для CI. На практике создание реестра занимает около 10 минут.
# получить токен в панели Selectel
# пример логина
docker login registry.sel.cloud -u -p # тег и пуш
docker tag myapp:latest registry.sel.cloud/your-namespace/myapp:2026-04-15
docker push registry.sel.cloud/your-namespace/myapp:2026-04-15Примеры цен (оценка на апрель 2026): хранение образов от 0.50 ₽/ГБ/месяц, исходящий трафик 0.02–0.05 ₽/ГБ в зависимости от зоны и объёма. При активности 1 ТБ/месяц egress составит ~20–50 ₽, хранение 1 ТБ — ~512 ₽/месяц. Точные цены уточняйте в панели Selectel.
Когда выбирать Selectel: если нужна минимальная поддержка, интеграция с VPC Selectel и готовые механизмы автоматизации через их API. Срок миграции: 1–3 дня для малого проекта (до 200 образов), 7–14 дней для корпоративной миграции с интеграцией в CI и правами доступа.
Практическая рекомендация: используйте immutable теги (например, 2026-04-15), включите ограничение кварталов на хранение и автоматический бэкап manifest. Для CI добавьте два токена: один для билдера (push), второй только для pull-пулов в production.
Yandex Cloud Container Registry (Yandex CR) — стабильная альтернатива с поддержкой интеграции в Yandex Cloud: IAM, приватные сети, KMS для ключей. Для российских проектов это один из самых распространённых вариантов с 99.95% SLA при корпоративных настройках.
Процесс миграции занимает от 30 минут (если у вас уже есть Yandex Cloud) до 3 дней при настройке доступа и IAM-политик. На практике команды тратят 2–8 часов на настройку CI и 1–3 дня на аудит прав.
# авторизация через yc
yc init
# создаём registry в нужном каталоге
yc container registry create --name my-registry --folder-id # логин в registry через yc
yc container registry get-credentials --name my-registry | docker login -u oauth --password-stdin registry.cloud.yandex
# тег и пуш
docker tag app:latest registry.cloud.yandex/your-repo/app:1.0.0
docker push registry.cloud.yandex/your-repo/app:1.0.0Пример цен (апрель 2026): хранение от 0.45 ₽/ГБ/месяц, исходящий трафик внутри Yandex Cloud — бесплатно, на внешние сети — от 0.02 ₽/ГБ. Для компании с 500 ГБ образов месячные затраты на хранение ~225 ₽, при egress 200 ГБ добавьте ~4–10 ₽.
Особенности: Yandex CR поддерживает репликацию образов между регионами и интеграцию с KMS для подписи образов. Рекомендация — включить подписывание и использовать lifecycle rules: удалять тег-образ через 90 дней, если он не помечен как release.
Если нужно максимальное управление и отсутствие зависимости от внешних сервисов — разворачиваем собственный Docker registry с HA и политиками хранения. Это дороже по начальной имплементации, но даёт контроль над данными и конвертируемыми политиками.
Оценка ресурсов: для продакшен-кластера registry рекомендуются 2–4 инстанса по 4 vCPU, 8–16 ГБ RAM, общий SAN/RAID массив от 1 ТБ и балансировщик. Время внедрения: pilot — 2–3 дня, production HA — 2–3 недели, включая тесты и интеграцию CI.
version: '3.7'
services:
registry:
image: registry:2
restart: always
ports:
- 5000:5000
environment:
- REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry
volumes:
- registry_data:/var/lib/registry
networks:
- regnet
nginx:
image: nginx:1.25
ports:
- 443:443
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- /etc/letsencrypt:/etc/letsencrypt:ro
networks:
- regnet
volumes:
registry_data:
networks:
regnet:Обязательно настройте TLS через Let's Encrypt или корпоративный CA, используйте HTTP/2, включите gzip и client_max_body_size 0 для больших push-ов. Для аутентификации применяйте token-based auth (OAuth) или интеграцию с LDAP/AD — базовая auth через htpasswd допустима для небольших команд.
Регулярно запускайте garbage-collect: docker exec -it registry bin/registry garbage-collect /etc/docker/registry/config.yml. Этот процесс временно блокирует запись и требует ~10–30% времени простоя в зависимости от объёма метаданных. Рекомендуется запускать GC ночью и держать активный snapshot перед запуском.
Настройте квоты: например, лимит 10 ГБ на namespace для команд разработки и 50–200 ГБ для production-репозиториев. Без квот одна команда может заполнить диск 1 ТБ за 2–3 месяца при агрессивном использовании CI.
При миграции с Docker Hub на альтернативы встречаются повторяющиеся проблемы. Перечислю самые частые с практическими решениями и цифрами.
Автоматизация миграции и поддержания синхронизации образов критична для стабильности. Ниже — проверенные инструменты и практики с примерами конфигураций и расписаний.
skopeo позволяет синхронизировать образы между реестрами без локального docker daemon. Пример команды для зеркалирования образа nginx ежечасно:
crontab -l | { cat; echo "0 * * * * /usr/bin/skopeo copy \
--all docker://docker.io/library/nginx:stable \
docker://registry.internal/library/nginx:stable"; } | crontab -При практике skopeo sync можно настроить расписание каждые 6 часов и хранить 4 копии в регистре. На тестовой площадке синхронизация 50 образов заняла 45 минут и потребовала 120 ГБ временного пространства.
# .gitlab-ci.yml snippet
stages:
- mirror
mirror_images:
stage: mirror
image: quay.io/skopeo/stable
script:
- echo "$REGISTRY_PASS" | docker login registry.sel.cloud -u $REGISTRY_USER --password-stdin
- skopeo copy --all docker://docker.io/library/busybox:latest docker://registry.sel.cloud/your-namespace/busybox:latest
only:
- schedulesСоздайте pipeline по расписанию (пример: каждые 6 часов). Для надёжности держите логирование и уведомления при ошибках: уведомлять в Slack при non-zero exit code и повторной попытке 2 раза с интервалом 10 минут.
Инфраструктуру registry лучше описать в коде. Примерная конфигурация для production: 2 инстанса 4 vCPU/8 GB, балансировщик, общий NFS 2 ТБ, TLS через Certbot. Используйте Terraform для создания инфраструктуры и Ansible для развёртывания registry, nginx и бэкапов.
Оценка стоимости при таком развертывании (апрель 2026) на публичных облаках: ~4000–8000 ₽/мес за инфраструктуру, плюс хранение образов, зависящее от объёма. Частный облачный вариант у Selectel или Yandex часто дешевле при больших объёмах.
Если вы хотите подробные инструкции по настройке CI для GitHub Actions или GitLab — смотрите материалы по интеграции: Как настроить Docker в CI и DevOps-практики для регистров. Внутренние ссылки содержат шаблоны workflow и готовые job-скрипты.
Если у вас уже есть учётная запись Selectel, перевести сборки можно за 1–3 дня: создать registry в панели (10 минут), получить токен, в CI заменить адрес и credentials, прогнать pipeline для проверки pull/push и задеплоить. Для 200 репозиториев потребуется ~8–16 часов автоматизированной перетегировки образов (skopeo или GitLab CI). Небольшие ручные правки — документировать scripts/registry-migrate.sh и запускать по очереди, ставить throttle по 5 параллелей, чтобы не перегрузить сеть.
Нужно предусмотреть: TLS-сертификаты (Let's Encrypt или корпоративный CA), мониторинг дискового пространства и метрик (Prometheus), политику garbage-collection и квоты на namespace. Планируйте диск с запасом 30–50% от ожидаемого объёма образов и выделяйте отдельный NFS/SAN для репликации. Не забывайте про резервное копирование метаданных и план восстановления: тест восстановления раз в квартал.
Секреты доступа (токены, пароли) храните в менеджерах секретов: HashiCorp Vault, Yandex Lockbox или аналогах. Для CI используйте переменные проекта с masked-значениями и rotate-токены каждые 7–30 дней. Никогда не храните токены в репозиториях; при компрометации токенов — выполняйте revoke и выдачу новых в течение 15 минут.
Чаще всего из-за несоответствия namespace/tags и отсутствия доступа у билд-агентов к новому registry. Проверьте: 1) корректность docker login, 2) права токена (push/pull), 3) наличие образа в целевом реестре (skopeo inspect), 4) сеть (firewall/прокси). Логи CI обычно содержат ошибку: unauthorized или manifest unknown — это указывает на проблемы с авторизацией или неправильным тегом.
Если нужно — могу подготовить готовый playbook Ansible и скрипты для автоматического зеркалирования 1000+ образов с отчётом по стоимости и объёму. Также могу прислать шаблон .gitlab-ci.yml для синхронизации образов и cron-расписание для skopeo.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…