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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!


В 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=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. Они все подробно задокументированы. Ниже несколько примеров:


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

Источник: https://habr.com/ru/company/southbridge/blog/527118/


Интересные статьи

Интересные статьи

SWAP (своп) — это механизм виртуальной памяти, при котором часть данных из оперативной памяти (ОЗУ) перемещается на хранение на HDD (жёсткий диск), SSD (твёрдотельный накоп...
Чуть больше года назад я столкнулся с тем, что на внутреннем проекте совсем не айтишной компании вырос целый отдел веб-разработки, которым мне и довелось руководить. Рабочий процесс вроде...
Эксперимент с самоделкой в европейском исследовательском подразделении IBM породил ценный инструмент Ссылка на проект: github.com/IBM/MicroscoPy Я член команды IBM Research–Eu...
Предыдущая часть нашего рассказа закончилась на стыке 80-х и 90-х годов. К этому времени преподаватели несколько охладели к компьютерам. Считалось, что по-настоящему они нужны только программиста...
Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...