Dockerhub

Новые ограничения в использовании Docker Hub и как GitLab реагировал на их ввод

30.11.2020 22:22:08 |

Автор: admin

Ни для кого уже не новость, что начиная с 2 ноября 2020 года Docker Hub ввел ограничения на скачивание образов: для анонимных пользователей он будет равен одной сотне за шесть часов, а для авторизованных пользователей будет зависеть от уровня подписки.

В компании GitLab мы очень внимательно следили за этими изменениями, так как они затрагивали практически всех наших пользователей и клиентов. Сегодня я хотел бы рассказать о том, какие изменения мы внесли и как адаптировались к новым правилам.

Что же произошло?

Публичный регистр контейнеров Docker Hub очень широко и часто используется сообществом DevOps для достижения разнообразных целей: запуска CI/CD задач, стандартизации процессов, выката контейнерных приложений как в sandbox, так и в production. Как только мы узнали о введении новых ограничения по количеству запросов, мы начали анализ новых правил, чтобы понять, как они повлияют на работу наших пользователей, и как мы можем почем решить возможные проблемы.

Согласно новым правилам после 100 запросов за 6 часов с одного клиентского IP адреса каждый новый docker pull вернет ошибку 429 - too many requests, что несомненно приведет к сломанным CI/CD конвейерам, невозможности выкатить приложения и целому букету ошибок в ваших Kubernetes кластерах. Вполне понятно, что этот лимит может быть очень быстро достигнут, особенно если все задачи выполняются с одного и того же GitLab Runner агента, или если команда из нескольких инженеров работает с одного и того же публичного адреса.

Аутсорсинг Dependency Proxy

Как отметил мой коллега Tim Rizzi "Нам следует срочно всем рассказать о Dependency Proxy", который изначально создавался для проксирования и кэширования образов Docker Hub. Этот функционал существует в GitLab уже довольнейший давно (начиная с версии 11.11), но до сегодняшнего дня был доступен только для пользователей Enterprise подписки уровня Premium. Перед продуктовой командой встал вполне резонный вопрос: "Стоит ли нам вынести Dependency Proxy в open source версию продукта, помогая таким образом широкому сообществу пользователей минимизировать проблемы из-за новых ограничений Docker Hub?"

Не вдаваясь в подробности, ответ на этот вопрос был ДА. При принятии решения, в какой уровень подписки должен попадать тот или иной функционал продуктовая команда GitLab всегда руководствуется вопросом "Кто является целевым пользователем?". Согласно этому принципу те возможности, которые чаще всего запрашивает индивидуальный участник или разработчик, попадают в Core или Open Source версию продукта. Скачивание образов с Docker Hub вполне соответсвует этому описанию. Более того аутсорсинг Dependency Proxy поможет большому количеству разработчиков повысить надежность и производительность их CI/CD конвейеров.

Как результат, начиная с версии 13.6 вышедшей 22 ноября 2020 года, проксирование и кэширование образов в GitLab стало абсолютно бесплатным для всех наших пользователей!

Что дальше?

К сожалению, идеальные решения не появляются мгновенно. Мы как никто другой знаем, что нашему продукты есть куда расти, поэтому активно работаем над улучшением функционала Dependency Proxy и уже в ближайших релизах планируем добавить новые возможности / решить имеющиеся проблемы:

13.7 (22 декабря, 2020)
- gitlab-#11582 сделает возможным использование Dependency Proxy для приватных групп в GitLab (сегодня работает только для публичных проектов)
- gitlab-#241639 позволит использовать закэшированный образ даже если Docker Hub недоступен. На сегодня это невозможно, так как даже при наличии закэшированного образа, его манифест всегда скачивается из конечного регистра
- gitlab-#21619 добавит новый параметр pull_policy в YAML описании CI/CD задач, позволяющий разработчикам самим указывать политику скачивания контейнера (always, if-not-present, never) вместо того, чтобы полагаться на настройки GitLab Runner
- gitlab-runner-#26558 позволит конфигурировать GitLab Runner с набором политик для скачивания образов (always, if-not-present)

Мониторинг ограничений

Решения обозначенные выше, а также в блог посте моего коллеги Steve Azzopardi, помогут упростить работу с новыми ограничениями, но не избавят от них на все 100%. Поэтому мы также выработали набор советов и инструментов, цель которых - помочь широкому сообществу адаптироваться к новым лимитам за счет их мониторинга.

Как проверить текущее значение лимита?

Документация Dockerрекомендует использовать HTTP запрос для проверки текущего значения ограничений запросов в Docker Hub.

Начнем с определения образа, для которого мы хотим получить текущее ограничение и получения токена для авторизации:

$ IMAGE="ratelimitpreview/test"$ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$IMAGE:pull" | jq -r .token)$ echo $TOKEN

Следующий шаг - симуляция запросаdocker pull. Вместо использования методаGETотправляемHEADзапрос (он не учитывается при подсчете ограничений). Ответ на этот запрос содержит параметрыRateLimit-Limit и RateLimit-Remaining.

$ curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/$IMAGE/manifests/latest

В примере ниже количество запросов ограничено2500, из которых2495еще доступны.21600определяет шестичасовой период (в секундах)

RateLimit-Limit: 2500;w=21600RateLimit-Remaining: 2495;w=21600

Автоматизация проверки лимитов

Michael Friedrich, один из евангелистов GitLab, поделился готовым решением на Python для проверки ограничений. Проект включает подробную документацию по установке и использованию

$ python check_docker_hub_limit.py --helpusage: check_docker_hub_limit.py [-h] [-w WARNING] [-c CRITICAL] [-v] [-t TIMEOUT]Version: 2.0.0optional arguments:  -h, --help            show this help message and exit  -w WARNING, --warning WARNING                        warning threshold for remaining  -c CRITICAL, --critical CRITICAL                        critical threshold for remaining  -v, --verbose         increase output verbosity  -t TIMEOUT, --timeout TIMEOUT                        Timeout in seconds (default 10s)

Скрипт возвращает следующие exit коды в зависимости от указанных параметров

0- OK
1- WARNING
2- CRITICAL

$ python3 check_docker_hub_limit.pyOK - Docker Hub: Limit is 5000 remaining 4997|'limit'=5000 'remaining'=4997$ echo $?0$ python3 check_docker_hub_limit.py -w 10000 -c 3000WARNING - Docker Hub: Limit is 5000 remaining 4999|'limit'=5000 'remaining'=4999$ echo $?1$ python3 check_docker_hub_limit.py -w 10000 -c 5000CRITICAL - Docker Hub: Limit is 5000 remaining 4998|'limit'=5000 'remaining'=4998$ echo $?2

Экспортер Prometheus

Кроме этого мы подготовили и выпустили экспортер для Prometheus, который позволит экспортировать метрики ограничений и реализовать их полноценный мониторинг.

Репозиторий проекта включает демо контейнер, включающий себе экспортер, Prometheus, Grafana, и docker-compose инструкции для его выката

$ cd example/docker-compose$ docker-compose up -d

Перейдите по адресу http://localhost:3000 для доступа к дэшборду Grafana

Надеюсь, наш опыт и рекомендации окажутся для вас полезными!

Подробнее..

Категории: It-инфраструктура , Open source , Gitlab , Ci/cd , Devops , Облачные сервисы , Docker , Prometheus , Мониторинг , Gitlab ci , Observability , Блог компании gitlab , Dockerhub

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

10.11.2020 10:22:20 |

Автор: admin

В 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 курс доступен по цене предзаказа, а также можно стать консультантом-тестером и повлиять на итоговый контент курса.