Поскольку провал quay.io прошлая неделя все в компании понимали, насколько важна услуга. И это вызвало у меня вопрос:
Если это произойдет снова, как можно подготовить мою инфраструктуру к использованию вторичного реестра контейнеров докеров в случае, если первый будет недоступен?
На данный момент движок докеров имеет --registry-mirror вариант, но это работает только для настройки зеркала Docker Hub. Возникли некоторые нерешенные вопросы, касающиеся того, можно ли и как это изменить, чтобы разрешить зеркалирование других реестров, но не было достаточной поддержки для внесения этого изменения. Если ваш исходный реестр является концентратором докеров, использование этого флага для указания на локальный кеш или зеркало очень полезно, поскольку запросы к концентратору сначала автоматически проверяют это зеркало, а в случае сбоя затем проверяют исходный реестр. Это означает, что вам не нужно настраивать имена изображений или беспокоиться о локальном сбое.
У Containerd есть аналогичный вариант, и он поддерживает любой реестр верхнего уровня, поэтому я считаю, что это то, к чему мы в конечном итоге перейдем. Однако, если вы используете докер, даже с контейнером под крышкой, я считаю, что движок докера по-прежнему выталкивает и вытягивает изображения.
Без возможности настроить это в containerd я видел несколько вариантов кеширования изображений из других реестров:
Настройте прокси-сервер для кеширования HTTP, например squid. Вы действительно хотите убедиться, что это периодически обновляет изменяемые ответы, такие как манифесты изображений. Сами слои должны оставаться неизменными, чтобы их можно было кэшировать на долгое время.
Получите напрямую из другого зеркала или кеширующего реестра.
Используйте перехват DNS / TLS для отправки запросов в кеш или зеркало.
Настроить реестр сквозного кеширования довольно просто:
docker run -p 5000:5000 -e REGISTRY_PROXY_REMOTEURL=<upstream-url> registry:2
Однако я предпочитаю запускать зеркало, потому что сквозной кеш настроен с 7-дневный срок действия заявок. Поэтому, если произойдет сбой, и ваши записи недавно истекли из-за вашего сквозного кеша, этот сбой повлияет на вас.
Запуск зеркала включает запуск реестра, как и при сквозном кешировании, а затем репликацию тех изображений, которые вы хотите зеркалировать. На ум приходит Харбор, некоторые реестры предлагают зеркалирование как функцию. Вы указываете, какие удаленные реестры зеркалировать на или из. Я лично выполняю зеркальное отображение с помощью сценария оболочки, поскольку это позволяет мне создавать резервные копии старых образов (большинство зеркал заменят тег, если он был заменен в восходящем потоке, не оставляя вам возможности возврата). Затем я включаю этот сценарий в свои рабочие процессы CI / CD для запуска в подходящее время, например в начале спринта или каждый понедельник утром. An пример этого сценария зеркалирования находится в моем репозитории презентации.
Когда у вас есть образ, доступный в локальном реестре, вам необходимо настроить докер для извлечения из этого реестра. Без --registry-mirror вариант, вам необходимо либо настроить имена образов, либо настроить DNS / TLS на узлах сети / докеров, чтобы направлять запросы в локальный реестр вместо вышестоящего. Последний вариант выглядит привлекательно, поскольку он позволяет запускать команды докеров без каких-либо изменений, сборки образов, составления стеков, диаграмм управления и т. Д. - все работает так, как если бы они обращались к удаленному реестру. Однако управление вашими собственными сертификатами TLS и самозаверяющим ЦС, которому все хосты в вашей сети должны доверять, немного больше подвержено ошибкам. Поэтому для меня проще было изменить имя в реестре. В моем Dockerfile у меня будет что-то вроде:
ARG REGISTRY=docker.io
FROM ${REGISTRY}/library/alpine:3.9
Это позволяет создавать этот образ другим пользователям вне сети. И затем в моих командах сборки в моей сети я переопределю аргумент с помощью моего локального зеркала:
docker build --build-arg REGISTRY=local-mirror:5000 .
Я делаю то же самое в docker-compose.yml файлы с переменной:
image: ${REGISTRY:-docker.io}/my/repo:and-tag
А затем разверните это локально, например:
REGISTRY=local-mirror:5000 docker-compose up -d
Я расскажу об этом в своей презентации DockerCon. Слайды размещены на моем github по адресу: https://github.com/sudo-bmitch/presentations/tree/master/registry
Презентация находится онлайн по адресу: https://www.youtube.com/watch?v=Bm7g0saAC9k