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

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

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

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

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

Docker может ускорить и упростить пользователям установку вашей новой утилиты. Они получают docker run your-app вместо того, чтобы искать инструкции по установке для конкретной платформы. Не требуется ручное извлечение архивов tar, копирование в системные папки или редактирование PATH.

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

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

Одним из естественных следствий Dockerized-распределения является требование, чтобы у пользователей уже был запущен 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"]

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

# Starting a new container from the "demo-app-image:latest" image

# Runs "demo-app --version"
docker run demo-app-image:latest

# Runs "demo-app demo --foo bar"
docker run demo-app-image:latest demo --foo bar

Ни в одном из примеров пользователю не требуется вводить имя исполняемого файла demo-app. Он автоматически используется как процесс переднего плана, потому что это сконфигурированный ENTRYPOINT. Команда получает аргументы, которые пользователь передал docker run после имени образа. Если аргументы не указаны, используется --version по умолчанию.

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

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

Вот образ 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"]

docker build -t demo-app-image:latest

docker run demo-app-image:latest

# Run demo-app with a data volume mounted to /data
docker run -v demo-app-data:/data demo-app-image:latest

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

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

# Setting the LOGGING_DRIVER environment variable in the container
docker run -e LOGGING_DRIVER=json demo-app-image:latest

docker run -it demo-app-image:latest