В Docker объявили об ограничении скорости передачи запросов на включение к сервису в бесплатном тарифе. В статье мы делимся стратегиями, которые позволят пользователям смягчить влияние новых ограничений скорости передачи запросов на их экземпляр GitLab.
24 августа 2020 года Docker объявили об изменениях в условиях
обслуживания и переходе к ограничениям в зависимости от
потребляемого объема. Эти ограничения скорости загрузки образов
контейнера вступили в силу 1 ноября 2020 года. Для анонимных
пользователей запросы на включение теперь ограничены сотней на
шесть часов. Для авторизованных пользователей лимит составит двести
запросов на включение за шесть часов.
Члены международного сообщества DevOps привыкли полагаться на
Docker как на неотъемлемую часть процессов CI/CD. Поэтому
неудивительно, что клиенты стали обращаться в GitLab за
пояснениями, как ограничения скорости Docker повлияют на
производственные процессы CI/CD.
Используйте зеркало реестра
Можно использовать функцию Зеркало реестра, чтобы определить количество запросов на включение образов, создаваемых для DockerHub. Когда зеркало настроено и GitLab Runner дает команду Docker включать образы, Docker сначала проверит зеркало. Если конкретный образ включается впервые, то будет установлено соединение с DockerHub. В последующие обращения этот образ будет браться с зеркала вместо DockerHub. Здесь более подробно разобрано, как это работает.
Если вы пользователь или клиент GitLab SaaS
Для общих раннеров на GitLab.com мы применяем зеркало образов DockerHub от Google. Это значит, что новый порядок включения образов не повлияет на задачи CI для общих пользователей GitLab.com. Мы продолжаем следить за влиянием, которые оказывают внесенные Docker изменения.
Если вы самостоятельно размещаете раннеры GitLab
Для начала проверьте, не предоставляет ли вам провайдер сервера или облачного сервиса зеркало реестра образов. Если предоставляет, то, вероятнее всего, его использование будет простейшим и наиболее производительным вариантом. Если же по какой-то причине размещенное зеркало реестра не может использоваться, администратор может установить собственное зеркало DockerHub.
Запустите зеркало реестра
Далее следуйте инструкции из
документации GitLab:
1.Войдите в систему на выделенном компьютере, на котором будет
работать прокси-сервер реестра контейнеров.
2.Проверьте, чтобы на компьютере был установлен Docker Engine.
3.Создайте новый реестр контейнеров:
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), следуйте инструкции из официальной документации.
4.Проверьте IP-адрес сервера:
hostname --ip-address
Желательно выбрать IP-адрес частной сети. Частная сеть обычно самое быстрое решение для внутренней коммуникации между компьютерами одного провайдера (DigitalOcean, AWS, Azure и т.д.). Как правило, трафик частной сети не учитывается в общем трафике.
5.Реестр Docker теперь доступен по
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
Обновите файл конфигурации раннера
GitLabconfig.toml, чтобы установить
engine-registry-mirror в настройках MachineOptions.
Docker-in-Docker для построения образов Docker
В зависимости от конфигурации можно по-разному этого достигнуть. В нашей документации можно найти развернутый список.
Проверьте, что все работает
Убедитесь, что Docker настроен так, чтобы использовать зеркало
Если вы запустите docker info, где
dockerd настроен для использования зеркала, на выходе
вы должны увидеть следующее:
... Registry Mirrors: http://registry-mirror.example.com ...
Проверьте каталог реестра
Реестр
API Docker может показать вам, какой репозиторий он кешировал
локально.
Поскольку мы впервые запустили docker pull node с
dockerd, настроенным для использования зеркала, мы
можем увидеть его,
перечислив репозитории.
curl http://registry-mirror.example.com/v2/_catalog{"repositories":["library/node"]}
Проверьте журналы реестра
Когда вы включаете образы, вам нужно видеть появляющиеся записи
журнала о запрашиваемой информации, запустив 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=34803188172.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.1172.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. Они все подробно задокументированы. Ниже несколько примеров:
1.Предоставлена переменная DOCKER_AUTH_CONFIG;
2.Файл config.json, размещенный в директории
$HOME/.docker пользователя, запускающего процесс
GitLab Runner.
3.Запустите docker login, если вы используете
последовательность
Docker-in-Docker.
Подводим итог
Как вы видите, адаптироваться к новым ограничениям DockerHub можно несколькими способами. Мы призываем своих клиентов выбрать тот, который подходит для потребностей их организации. Наряду с опциями, представленными в этой статье, есть еще вариант остаться в экосистеме GitLab и использовать прокси-сервер GitLab Container, который скоро будет доступен пользователям Core.
От редакции: Приглашаем узнать более
подробно о работе в Gitlab CI и изучить best
practices построения пайплайнов на курсе Слёрма
CI/CD на примере Gitlab CI. До 3 декабря 2020 курс доступен по
цене предзаказа, а также можно стать консультантом-тестером и
повлиять на итоговый контент курса.
