Лимиты pull-операций Docker Hub: как они работают и где создают проблемы
Эта инструкция объясняет, как Docker Hub ограничивает скачивание образов: какие лимиты действуют для разных типов пользователей, что именно считается pull-операцией и почему эти ограничения особенно заметны в автоматических сборках и CI/CD. Материал поможет учитывать возможности Docker Hub при настройке инфраструктуры и избежать неожиданных сбоев.
Docker Hub — это главное место, где хранятся публичные Docker-образы. Им пользуются и когда вручную работают с контейнерами, и в автоматизированных системах для сборки и развёртывания. Но есть нюанс: на скачивание образов из Docker Hub есть лимиты, которые зависят от того, как вы к нему обращаетесь и как используете сервис.
Обычно на эти лимиты мало кто обращает внимание — до тех пор, пока сборки внезапно не начинают падать с ошибками, а деплой не прерывается без очевидных причин.
1. Что Docker Hub считает pull-операцией
Pull-операция — это фактическое скачивание Docker-образа с Docker Hub. Проще говоря, лимит расходуется не при любых обращениях к Docker Hub, а только в момент загрузки данных.
Расход pull-лимита происходит в следующих случаях:
- когда вы явно выполняете команду
docker pull; - когда при сборке через
docker buildтребуется загрузить базовый образ с Docker Hub; - когда вы запускаете
docker compose up, и нужного образа нет в локальном кэше.
Если сборка или запуск выполняются в новом или изолированном окружении (например, на сервере или в CI/CD), локальный кэш образов отсутствует. В этом случае Docker каждый раз заново скачивает образы с Docker Hub, и pull-лимит расходуется при каждом запуске.
Из-за этого лимиты могут заканчиваться неожиданно, даже если используются одни и те же образы.
2. Какие лимиты действуют и как Docker Hub их применяет
Docker Hub ограничивает количество pull-операций в зависимости от того, авторизованы вы или нет. Эти ограничения обнуляются через определённое время.
Если вы не авторизованы
Docker обращается к Docker Hub без входа в аккаунт:
- можно скачать 100 образов за 6 часов;
- лимит считается для вашего IP-адреса.
Если вы авторизованы бесплатным аккаунтом
- можно скачать 200 образов за 6 часов;
- лимит привязывается к вашему аккаунту, а не к IP-адресу.
В этом случае каждое скачивание будет учитываться для конкретного аккаунта, даже если вы работаете с разных машин.
Платные тарифы
- количество скачиваний без ограничений;
- эти тарифы подходят для проектов с высокой частотой сборок.
3. Почему проблемы с лимитами чаще всего проявляются в CI/CD
При обычной работе с Docker на локальной машине лимиты Docker Hub почти не ощущаются: образы скачиваются один раз и затем используются из кэша.
В CI/CD всё устроено иначе. Сборки в CI/CD чаще всего запускаются в чистом окружении, где:
- нет сохранённых образов;
- каждый запуск начинается «с нуля»;
- базовые образы приходится скачивать заново.
Дополнительно нагрузку увеличивает то, что:
- один pipeline может загружать несколько образов за одну сборку;
- несколько pipeline-ов могут выполняться одновременно;
- при сбоях или ошибках job-ы автоматически перезапускаются и снова выполняют pull.
В результате даже небольшой проект может за короткое время израсходовать значительное количество pull-операций, особенно если в сборках используются публичные образы из Docker Hub.
Именно поэтому при использовании CI/CD почти всегда требуется авторизация в Docker Hub. Подробно этот момент разобран в инструкции «Регистрация в Docker Hub: как снять ограничения на загрузку образов» .
Заключение
Понимание того, когда и при каких действиях расходуются pull-лимиты, помогает избежать неожиданных ошибок при сборке и деплое. Учитывая эти ограничения заранее, можно более осознанно настраивать CI/CD и инфраструктуру в целом, не сталкиваясь с внезапными сбоями при работе с Docker Hub.
Удачи в дальнейшей работе!