Docker Inc. ограничила доступ к своим сервисам, в том числе к Docker Hub, для пользователей из России и Беларуси. Для команд, которые тянут образы с Hub, обновляют engine/desktop и опираются на официальные registry, это ломает привычный CI/CD и деплой.
Ниже – зачем так сделали, что ломается на практике, какие есть альтернативы контейнеризации и какие рабочие подходы снижают зависимость от одного коммерческого registry.
Почему доступ ограничили
Официальная линия – соблюдение международных санкций и экспортных ограничений. Западные вендоры в IT массово режут продажи, аккаунты и облачные сервисы для ряда юрисдикций, чтобы не попасть под штрафы у себя. Docker в этом ряду не уникален: похожие ограничения касались и других SaaS и registry.
Актуальные заявления и changelog по политике доступа смотрите на блоге Docker и в документации Docker Hub (условия могут меняться).
Что ломается у разработчиков
- Docker Hub – pull/push образов, rate limits, login, official images. Без зеркала pipeline падает на
docker pull. - Обновления и поддержка – сложнее получать пакеты Desktop, документацию и платные планы; на self-hosted engine критичнее именно Hub, чем сам runtime.
- Зависимость от base-образов – многие Dockerfile начинаются с
FROM nginx:.../node:...с Hub; без кэша или mirror сборка останавливается. - Время и риск – срочный поиск зеркал, перепись registry URL, аудит лицензий и происхождения образов.
Альтернативы и смежные инструменты
«Docker» часто путают с тремя разными слоями: runtime, registry и оркестратор. Резать нужно то, что реально недоступно.
Podman
Podman – OCI-совместимый runtime без обязательного root-демона. CLI близкий к Docker (podman build/run/pull), хорошо стыкуется с systemd и rootless. Образы те же OCI: registry может быть любой (Quay, GHCR, self-hosted).
Kubernetes (containerd / CRI-O)
Kubernetes – не «замена Docker Desktop», а оркестрация. В современных кластерах runtime – containerd или CRI-O, Docker engine не обязателен. Имеет смысл, если уже есть или нужен кластер; для локальной разработки одного сервиса это избыточно.
LXC / LXD (Incus)
LXC/LXD (и форк Incus) – системные контейнеры ближе к «лёгкой ВМ», чем к app-container Docker. Удобны для изоляции окружений и сервисов на хосте, но это другой operational model, не drop-in для Docker Compose.
Свой registry
Harbor, GitLab Container Registry, Nexus, distribution (registry:2) – хранение своих сборок и прокси/кэш внешних base-образов. Снимает зависимость от одного публичного Hub.
Рабочие подходы
- Зеркала и pull-through cache – корпоративный proxy-registry кэширует base-образы; CI ходит только во внутренний endpoint.
- Локальный кэш образов – на build-агентах держать часто используемые base-слои; не собирать «с нуля из интернета» на каждый пайплайн.
- Мульти-registry – дублировать критичные образы (GHCR, Quay, внутренний Harbor), в Dockerfile/compose – переменные registry prefix.
- Меньше vendor lock-in – OCI-стандарты, Podman/buildah/buildkit, не привязываться к Docker Hub как к единственному источнику.
- Сеть и доступ – часть команд использует VPN или прокси для доступа к зарубежным registry; это отдельная организационная и юридическая зона ответственности компании, не «магия в Dockerfile».
Пример смены префикса registry (идея, не привязка к конкретному зеркалу):
# вместо # docker pull nginx:1.25 # использовать свой mirror/proxy (URL задаёте вы): docker pull registry.example.internal/library/nginx:1.25 # Podman аналогично podman pull registry.example.internal/library/nginx:1.25
Кратко
Ограничения Docker-сервисов для RU/BY – следствие санкционной политики вендора, а не «поломки Linux-контейнеров». Runtime (engine, Podman, containerd) можно держать, а вот registry и SaaS нужно планировать: зеркала, свой Harbor, OCI-альтернативы, меньше зависимости от одного Hub. Следите за официальными заявлениями Docker и политикой доступа вашего registry.
