Компания Docker объявила о введении ограничений на частоту скачивания данных сервиса DockerHub в бесплатном тарифе. В этой статье мы расскажем о стратегиях, позволяющих пользователям смягчить влияние новых ограничений частоты запросов при использовании сервиса GitLab, установленного на своих мощностях.

24 августа 2020 года компания Docker объявила об изменениях в условиях обслуживания и переходе к ограничениям в зависимости от потребляемого трафика. Эти ограничения частоты загрузки образов контейнеров вступили в силу 1 ноября 2020 года. Для анонимных пользователей запросы на скачивание образов теперь ограничены сотней за шесть часов. Для авторизованных пользователей лимит составит двести запросов за шесть часов.
Участники международного сообщества DevOps привыкли полагаться на Docker как на неотъемлемую часть процессов CI/CD. Поэтому неудивительно, что клиенты стали обращаться в GitLab за пояснениями, как ограничения частоты скачивания образов Docker повлияют на производственные процессы CI/CD.

Применяем Registry Mirror

Можно использовать функцию «Registry Mirror», чтобы определить количество запросов к DockerHub на скачивание образов. Когда она настроена и GitLab Runner дает Docker команду скачать образы, Docker сначала проверит локальное зеркало. При первой попытке скачивания образа он будет скачан из DockerHub. Все последующие обращения к этому образу будут обрабатываться зеркалом вместо DockerHub. Здесь более подробно разобрано, как это работает.

Если вы пользователь или клиент GitLab SaaS

Для Shared Runner на GitLab.com мы применяем зеркало образов DockerHub от Google. Это значит, что новая политика скачивания образов не повлияет на задачи CI от пользователей Shared Runners. Мы продолжаем следить за влиянием, которое оказывают внесенные компанией Docker изменения.

Если вы пользуетесь GitLab Runners на своих мощностях

Для начала проверьте, не предоставляет ли вам поставщик сервера или облачного сервиса функцию Registry Mirror для образов. Если предоставляет, то, вероятнее всего, его использование будет простейшим и наиболее производительным вариантом. Если же по какой-то причине она не может использоваться, администратор может установить собственное зеркало DockerHub.

Запускаем Registry Mirror

Следуем инструкциям документации GitLab:

Заходим на целевой сервер, на котором будет работать прокси-сервер реестра контейнеров.
Проверяем, что на сервере установлен Docker Engine.
Запускаем новую Registry для контейнеров:
```
docker run -d -p 6000:5000 \
-e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
 --restart always \
 --name registry registry:2
```
Можно изменить номер порта (6000), чтобы открыть ее на другом порту. Таким образом сервер запустится с http. Если хотите включить TLS (https), следуйте инструкции из официальной документации.
Смотрим IP-адрес сервера:
```
hostname --ip-address
```
Желательно выбрать IP-адрес из частной сети. Частная сеть — обычно самое быстрое решение для внутренней коммуникации между компьютерами одного провайдера (DigitalOcean, AWS, Azure и т.д.). Как правило, трафик частной сети не учитывается в общем трафике.
Registry теперь доступна по MY_REGISTRY_IP:6000

Настройка Docker для использования

В конце надо так настроить dockerd, чтобы он использовал ваше зеркало при запуске docker pull.

Docker

Запускаем сервис dockerd руками, добавляя параметр --registry-mirror, либо вносим правки в файл /etc/docker/daemon.json и добавляем ключ registry-mirrors с соответствующим значением, чтобы не делать это руками каждый раз при перезапуске сервиса.

{
  "registry-mirrors": ["http://registry-mirror.example.com"]
}

docker-machine

Обновляем файл config.toml с настройками GitLab Runner, чтобы установить engine-registry-mirror в настройках MachineOptions.

Docker-in-Docker для сборки образов Docker

В зависимости от настроек можно по-разному этого достичь. В нашей документации есть развернутый список.

Проверьте, что все работает

Убедитесь, что Docker настроен так, чтобы использовать зеркало

Если вы запустите docker info, где dockerd настроен для использования зеркала, вывод будет примерно следующим:

...
 Registry Mirrors:
  http://registry-mirror.example.com
 ...

Проверьте каталог реестра

Docker Registry API отобразит репозиторий, кэшируемый локально.
Поскольку мы впервые запустили docker pull node с dockerd, настроенным для использования зеркала, мы можем увидеть его, просматривая репозитории.

curl http://registry-mirror.example.com/v2/_catalog

{"repositories":["library/node"]}

Проверяем журналы Registry

Вы можете увидеть записи журнала с информацией о запросах при скачивании образов, запуская команду docker logs registry, где registry — это имя контейнера, в котором работает зеркало.

...
time="2020-10-30T14:02:13.488906601Z" level=info msg="response completed" go.version=go1.11.2 http.request.host="192.168.1.79:6000" http.request.id=8e2bfd60-db3f-49a3-a18f-94092aefddf9 http.request.method=GET http.request.remoteaddr="172.17.0.1:57152" http.request.uri="/v2/library/node/blobs/sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4" http.request.useragent="docker/19.03.13 go/go1.13.15 git-commit/4484c46d9d kernel/4.19.76-linuxkit os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.13 \(darwin\))" http.response.contenttype="application/octet-stream" http.response.duration=6.344575711s http.response.status=200 http.response.written=34803188
172.17.0.1 - - [30/Oct/2020:14:02:07 +0000] "GET /v2/library/node/blobs/sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4 HTTP/1.1" 200 34803188 "" "docker/19.03.13 go/go1.13.15 git-commit/4484c46d9d kernel/4.19.76-linuxkit os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.13 \\(darwin\\))"
time="2020-10-30T14:02:13.635694443Z" level=info msg="Adding new scheduler entry for library/node@sha256:8c322550c0ed629d78d29d5c56e9f980f1a35b5f5892644848cd35cd5abed9f4 with ttl=167h59m59.999996574s" go.version=go1.11.2 instance.id=f49c8505-e91b-4089-a746-100de0adaa08 service=registry version=v2.7.1
172.17.0.1 - - [30/Oct/2020:14:02:25 +0000] "GET /v2/_catalog HTTP/1.1" 200 34 "" "curl/7.64.1"
time="2020-10-30T14:02:25.954586396Z" level=info msg="response completed" go.version=go1.11.2 http.request.host="127.0.0.1:6000" http.request.id=f9698414-e22c-4d26-8ef5-c24d0923b18b http.request.method=GET http.request.remoteaddr="172.17.0.1:57186" http.request.uri="/v2/_catalog" http.request.useragent="curl/7.64.1" http.response.contenttype="application/json; charset=utf-8" http.response.duration=1.117686ms http.response.status=200 http.response.written=34

Альтернативы зеркалам DockerHub

Настройка зеркала реестра Docker может также повысить ваши расходы на инфраструктуру. С ограничениями DockerHub, возможно, вам будет полезно аутентифицировать запросы вместо повышения частоты запросов, или выбирать безлимитный тариф (в зависимости от вашей подписки).

Существуют различные способы аутентификации с помощью DockerHub на GitLab CI. Они все подробно задокументированы. Ниже несколько примеров:

Выставлена переменная окружения DOCKER_AUTH_CONFIG;
Создан файл config.json в каталоге $HOME/.docker пользователя, запускающего процесс GitLab Runner.
Выполнена команда docker login, если вы работаете с Docker-in-Docker.

Результаты

Как вы видите, адаптироваться к новым ограничениям DockerHub можно несколькими способами. Мы призываем своих клиентов выбрать наиболее подходящий для потребностей их организации. Наряду с вариантами, представленными в этой статье, есть еще вариант остаться в экосистеме GitLab и использовать прокси-сервер GitLab Container, который скоро будет доступен пользователям Core.

От редакции: Приглашаем узнать более подробно о работе в Gitlab CI и изучить best
practices построения пайплайнов на курсе Слёрма «CI/CD на примере Gitlab CI». До 3 декабря 2020 курс доступен по цене предзаказа, а также можно стать консультантом-тестером и повлиять на итоговый контент курса.

Как уменьшить количество обращений к DockerHub из инфраструктуры CI/CD при помощи кэширования образов Docker?