Какова цель проталкивания изображения в конвейере CI / CD?

Question

Контекст: чтение этого сообщения в блоге.

Загрузка изображений в реестр кажется "правильным делом" ... но я не понимаю, почему.

Какую цель это служит?Это потому, что сервер, на котором я ssh, должен иметь локальную копию изображения?И чтобы сделать это, один из подходов - извлечь изображение из реестра?

Answer 1

Какую цель это служит?Это потому, что сервер, на котором я ssh, должен иметь локальную копию изображения?И чтобы сделать это, один из подходов заключается в извлечении образа из реестра?

С точки зрения CI / CD реестр докеров является эквивалентом репозитория артефактов для изображений.Вы хотите, чтобы центральный источник этих образов загружался с одного хоста докера на другой, поскольку ваш сервер сборки, скорее всего, отличается от ваших серверов dev и prod.

Не могу я просто загрузитьобраз с одного компьютера (скажем, CI / CD-сервер) через SSH?использование dockerhub мне кажется излишне церемонным.Как и в этом примере (я знаю, этот API устарел, но он иллюстрирует мою точку зрения).

Можно сохранять / загружать изображения непосредственно на хост докера, но естьнесколько серьезных недостатков.Во-первых, вы теряете любую выгоду от многоуровневой файловой системы докера.При создании приложения в CI / CD большую часть времени необходимо перестраивать только последние несколько слоев с изменениями вашего приложения.Там должно быть то же самое предыдущее базовое изображение и различные общие слои, чтобы создать Ваше приложение, которое остается идентичным.В реестре эти общие уровни видны, только различие выталкивается и вытягивается, что ускоряет развертывание и экономит дисковое пространство.С помощью команды сохранения / загрузки все слои отправляются каждый раз, поскольку вы не знаете состояние удаленного сервера при запуске сохранения.

Во-вторых, это не масштабируется при добавлении хостов для запуска образов.,Каждому хосту потребуется скопировать образ, если вы захотите запустить его на этом хосте, например, для обработки отработки отказа или балансировки нагрузки.Это также не будет работать, если вы перейдете в режим роя или kubernetes, так как вы можете легко добавить новые узлы в кластер, у которых не будет вашего изображения.По умолчанию режим Swarm ищет sha256 образа в реестре, чтобы гарантировать, что всегда используется один и тот же образ, даже если тег изменен в реестре после первоначального развертывания.

Имейте в виду, что вы можете запустить свой собственныйсервер реестра (есть образ докера и API-интерфейс открыт).Многие репозитории артефактов (например, artifactory и nexus) включают поддержку реестра Docker.И многие облачные провайдеры включают реестр в свои предложения контейнеров.Поэтому вам не нужно переходить на удаленный док-концентратор для локального развертывания.

И последнее замечание: сервер реестра полезен для разработчиков, которые теперь могут использовать тот же образ, который используется в dev и prod, для тестирования на другихмикросервисы, которые они пишут локально, без необходимости создавать все локально или ssh на CI / CD-сервере или даже в prod, чтобы сохранять и отправлять изображения обратно на свои ноутбуки.

Answer 2

Рассматривайте образ докера как новый способ распространения вашего программного обеспечения на свои серверы, а реестр докеров как централизованное хранилище общих образов (например, npm.org для js, maven.org для java).

Например, если вы разрабатываете Java-приложение , за годы до докера вы можете использовать .jar файлы для этого.Более удобный образ докера состоит в том, что он также включает все зависимости уровня ОС, такие как JDK / JRE и конфигурации системы.Так что это поможет вам избежать эффекта "это работает на моей машине".

Для распространения docker image вы также можете использовать просто файл Docker и постоянно создавать его на каждой машине.Docker-Repository позволяет вам централизованно хранить образы до сборки.

Загрузка в Docker-репозиторий на вашем CI / CD позволяет собрать ваш дистрибутив один раз и продолжить работу с одним и тем же дистрибутивом как в средах интеграции, так и в среде prod.,

Использование только Dockerfile не гарантирует вам одно и то же состояние в каждой сборке в каждый момент времени, потому что вы можете устанавливать внешние зависимости в вашем Dockerfile сценарии, которые могут обновляться или даже удаляться между двумяпоследовательные сборки.

Answer 3

Обычно вы используете конвейер CI, CD, когда вы хотите упростить процесс сборки / тестирования / развертывания, и обычно это происходит, если у вас есть производственная инфраструктура для поддержки, которая действительно важна для вашего бизнеса.

Нет необходимости в конвейере CI / CD, если вы просто играете / прототипируете IMO, и в этом случае вы можете напрямую создавать образы докеров на машине или создавать поверх ssh.Это совершенно разумно.

Посмотрите на «реестр» как на хранилище вашего двоичного образа (то есть на фиксированную версию вашего кода, которая в идеале версионирована, и вы знаете, что она работает)

Тогда развертывание происходит какпросто, как сказать вашим серверам, чтобы вытащить образ и запустить его из любого места

В гибкой архитектуре узлы могут быть запущены или выключены в любое время, и они должны иметь возможность извлекать последний код из какого-либо места, чтобы автоматически запускать и запускать его в любое время безвмешательство.

Answer 4

Реестр является единственным источником правды в этом случае.Это означает, что вы можете иметь несколько узлов (серверов), кластеров и иметь единственное место, откуда вы можете получить свои изображения.Также, если ваши узлы выпадающие - вы можете быстро запустить свой образ в новом.Также вы можете автоматизировать обновление вашего изображения с помощью реестра webhook, например, когда вы добавляете новую версию реестра изображений, вы собираетесь отправлять webhook любому сервису, который может обновить ваши контейнеры до последней версии.