Блог

Последние несколько месяцев я экспериментировал с docker и наслаждался преимуществами создания и запуска Java-приложений внутри контейнеров.

Несколько недель назад я наткнулся на плагин jib maven и заметил, что jib может создавать образы для реестров docker без использования демона docker.

После добавления jib в один из моих проектов и запуска mvn clean install jib:build (на виртуальной машине, на которой не установлен docker) я был удивлен, что jib фактически создал и отправил изображение, содержащее мой проект, в удаленный реестр.

Из любопытства я зашел в Интернет, чтобы узнать больше о том, как jib создает и отправляет образы docker без установленного docker, но практически не нашел информации по этому вопросу. Мне удалось найти статью, в которой объясняется несколько способов создания изображений без использования docker, а также я попытался понять, как jib:build работает цель maven, прочитав ее исходный код, но ни один из них не дал мне никакого представления о том, что происходит за сценами при запуске jib:build .

Я был бы очень признателен, если бы кто-нибудь рассказал больше о плагине jib maven и о том, как он на самом деле создает и отправляет изображение за кулисы без использования демона docker.

(Разработчик Jib здесь. Я очень слегка коснусь темы на очень высоком уровне и только концептуально. Имейте в виду, что следующее охватывает только один аспект построения изображений.)

Концептуально анатомия изображения контейнера удивительно проста; это просто набор архивных файлов плюс некоторые метаданные об изображении (около двух файлов JSON). Вы получите, что если вы распакуете некоторые архивные файлы упорядоченным образом (точнее, смонтируете объединение), у вас останутся некоторые файлы и каталоги; по сути, это содержимое файловой системы образа, которое вы получите и увидите во время выполнения. Добавьте в сцену пару небольших файлов JSON для некоторых метаданных об изображении (например, переменные среды во время выполнения, точка входа в изображение, из каких архивов состоит это изображение и т. Д.), И у вас уже есть образ контейнера в ваших руках. Затем вы взаимодействуете с реестром контейнеров через API реестра Docker (т. Е. Отправляете и получаете HTTP-запросы и ответы), чтобы загрузить эти архивные файлы (после сжатия) и файлы JSON, и вуаля! Вы создали и отправили изображение в реестр.

Итак, да, вы можете создать эти архивные файлы, используя старые добрые tar файлы командной строки (эти архивные файлы называются «слои изображений»), создать несколько файлов JSON с помощью текстового редактора и загрузить их в реестр с помощью curl . Я делал это раньше. Конечно, для того, чтобы любая среда выполнения контейнера могла фактически запускать такой образ, вашим архивам может потребоваться включить некоторые минимально необходимые скелетные файлы и каталоги для корректной работы, например, как система Linux (на самом деле не так много). Но все же, нет никаких ограничений в содержимом архивных файлов; они даже не обязательно должны быть действительным архивом tar. (Да, вы можете злоупотреблять реестром контейнеров для загрузки любых мусорных данных. Например, этот сценарий оболочки загружает 40 МБ случайных байтов в Docker Hub.) И вы все равно можете утверждать с файлами метаданных JSON, что ваш (полностью сломанный) «образ» состоит из этих больших двоичных объектов мусора. (Конечно, такой образ не сможет выполняться во время выполнения.)