🐳 Как использовать Docker для упаковки приложений CLI |

🐳 Как использовать Docker для упаковки приложений CLI

Мануал

Docker – это популярная платформа для упаковки приложений в виде самодостаточных распространяемых артефактов.

Он создает образы, включающие все необходимое для запуска конкретного программного обеспечения: исходный код, зависимости от пакетов сторонних производителей и необходимые характеристики среды.

Поскольку образы Docker могут запускаться везде, где установлен Docker, они являются жизнеспособным форматом для распространения ваших приложений CLI.

Экосистема Docker включает Docker Hub в качестве общедоступного реестра по умолчанию, что дает вам полную цепочку инструментов для публикации, обновления и документирования ваших инструментов.

Вот как можно использовать Docker для упаковки CLI-приложений вместо традиционных менеджеров пакетов ОС и загрузки отдельных бинарников.

Зачем использовать Docker для приложений CLI?

Docker позволяет пользователям быстрее и проще установить вашу новую утилиту.

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

Нет необходимости вручную извлекать tar-архивы, копировать их в системные папки или редактировать PATH.

Докеризованное программное обеспечение также упрощает пользователям выбор различных версий, выполнение обновлений и инициирование откатов.

Каждый отдельный релиз, который вы создаете, должен получить свой собственный неизменяемый тег, который уникально идентифицирует его Docker-образ.

🐳 Как добавлять, заменять и удалять теги образов Docker

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

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

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

Контейнеры Docker имеют свою собственную частную файловую систему; удаление контейнера не оставляет следов его существования на хосте.

Это может побудить больше пользователей попробовать ваше приложение.

Создание образа Docker для приложения CLI

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

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

Обычно лучше всего начинать с минимального базового образа, на котором работает оптимизированная операционная система, такая как Alpine.

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

Две важные инструкции Dockerfile для инструментов CLI – ENTRYPOINT и CMD.

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

Большинство базовых образов по умолчанию запускают оболочку при старте контейнера.

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

Инструкция ENTRYPOINT Dockerfile определяет процесс переднего плана контейнера.

Установите его на исполняемый файл вашего приложения:

ENTRYPOINT ["demo-app"]

Инструкция CMD работает в паре с ENTRYPOINT.

Она предоставляет аргументы по умолчанию для команды, заданной в ENTRYPOINT.

Аргументы, которые пользователь вводит при запуске контейнера с помощью docker run, отменяют CMD, заданный в Dockerfile.

Хорошее применение CMD – когда вы хотите показать базовую справку или информацию о версии, когда пользователь опускает определенную команду:

ENTRYPOINT ["demo-app"]
CMD ["--version"]

Вот несколько примеров, показывающих, как эти две инструкции приводят к выполнению разных команд при создании контейнеров:

# Запуск нового контейнера из образа "demo-app-image:latest"

# Запускает "demo-app --version"
docker run demo-app-image:latest

# Запускает "demo-app demo --foo bar"
docker run demo-app-image:latest demo --foo bar

Собираем все вместе

Вот образ Docker, на котором запущено простое приложение Node.js:

#!/usr/local/bin/node
console.log("Hello World");
FROM node:16-alpine
WORKDIR /hello-world

COPY ./ .

RUN npm install

ENTRYPOINT ["hello-world.js"]

Вариант базового образа node:16-alpine используется для уменьшения общего размера вашего образа.

Исходный код приложения копируется в файловую систему образа с помощью команды COPY.

Устанавливаются npm-зависимости проекта, а скрипт hello-world.js устанавливается в качестве точки входа образа.

Соберите образ с помощью docker build:

docker build -t demo-app-image:latest

Теперь вы можете запустить образ, чтобы увидеть Hello World, выведенное на ваш терминал:

docker run demo-app-image:latest

На этом этапе мы готовы выложить свой образ в Docker Hub или другой реджестри, откуда его смогут скачать пользователи.

Любой человек, имеющий доступ к образу, сможет запустить вашу программу, используя только Docker CLI.

# Запуск демо-приложение с томом данных, смонтированным в /data
docker run -v demo-app-data:/data demo-app-image:lates

Другие возможные проблемы

Проблема монтирования возникает снова, когда вашей команде нужно взаимодействовать с файлами в файловой системе хоста.

Вот простой пример инструмента загрузки файлов:

docker run file-uploader cp example.txt demo-server:/example.txt

В итоге мы ищем файл example.txt внутри контейнера.

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

docker run -v $PWD:/file-uploader file-uploader cp example.txt demo-server:/example.txt

Также важно подумать о том, как пользователи будут предоставлять значения конфигурации вашему приложению.

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

Предложение альтернативных вариантов, таких как флаги командной строки и переменные окружения, может упростить работу для простых случаев использования:

# Установка переменной окружения LOGGING_DRIVER в контейнере
docker run -e LOGGING_DRIVER=json demo-app-image:latest

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

Пользователям необходимо передать флаг -it в docker run, чтобы включить интерактивный режим и выделить псевдо-TTY:

docker run -it demo-app-image:latest

Пользователи должны помнить о необходимости установки этих флагов, иначе ваша программа не сможет принимать ввод.

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

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

Когда это возможно, простой docker run image-name выполняет задачу установки и использования без ограничений.

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

Заключение

Docker используется не только для развертывания в облаке и фоновых сервисов.

Он также становится все более популярным в качестве механизма распространения обычных консольных приложений.

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

см. также:

 

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий