Cómo usar Docker para empaquetar aplicaciones CLI – CloudSavvy IT

Docker es una plataforma popular para empaquetar aplicaciones como artefactos distribuibles autónomos. Crea imágenes que incluyen todo lo que necesita para ejecutar un software en particular, como su código fuente, las dependencias de paquetes de terceros y las características requeridas del entorno.

Como las imágenes de Docker pueden ejecutarse en cualquier lugar donde esté instalado Docker, son un formato viable para distribuir sus aplicaciones CLI. El ecosistema de Docker incluye Docker Hub como un registro público disponible de forma predeterminada, lo que le brinda una cadena de herramientas completa para publicar, actualizar y documentar sus herramientas.

Así es como puede usar Docker para empaquetar aplicaciones CLI en lugar de los administradores de paquetes del sistema operativo tradicionales y las descargas binarias independientes.

¿Por qué usar Docker para aplicaciones CLI?

Docker puede hacer que sea más rápido y fácil para los usuarios instalar su nueva utilidad. llegan a docker run your-app en lugar de tener que buscar instrucciones de instalación específicas de la plataforma. No hay extracción manual de tar archivos comprimidos, copiar en carpetas del sistema o PATH edición involucrada.

El software dockerizado también facilita a los usuarios seleccionar diferentes versiones, realizar actualizaciones e iniciar reversiones. Cada versión distinta que cree debe tener su propia etiqueta inmutable que identifique de forma única su imagen de Docker. A diferencia de los administradores de paquetes normales, los usuarios pueden ejecutar fácilmente dos versiones de su software una al lado de la otra iniciando contenedores basados ​​en diferentes etiquetas de imagen.

Otro beneficio es la facilidad con la que los usuarios pueden probar su aplicación de manera segura sin comprometerse a largo plazo con ella. Las personas pueden dudar en agregar nuevos paquetes a sus máquinas por temor a que el software no se limpie por completo cuando se elimine. Los contenedores Docker tienen su propio sistema de archivos privado; quitar un contenedor no deja rastro de su existencia en el host. Esto podría alentar a más usuarios a probar su aplicación.

Una consecuencia natural de la distribución dockerizada es el requisito de que los usuarios ya tengan Docker ejecutándose en su máquina. Hoy en día, muchos desarrolladores lo ejecutarán de forma rutinaria, por lo que es una elección bastante segura. Si le preocupa bloquear a los usuarios que no quieren usar Docker, aún puede proporcionar opciones alternativas a través de sus canales de distribución existentes.

Creación de una imagen de Docker para una aplicación CLI

Las imágenes de Docker para aplicaciones CLI son un poco diferentes a las que se usan para cualquier otro tipo de software. El objetivo es proporcionar una imagen que sea lo más liviana posible y, al mismo tiempo, agrupar todo lo que su aplicación necesita para funcionar.

Por lo general, es mejor comenzar con una imagen base mínima que ejecute un sistema operativo simplificado como Alpine. Agregue solo los paquetes que requiere su software, como su lenguaje de programación, marco y dependencias.

Dos instrucciones vitales de Dockerfile para herramientas CLI son ENTRYPOINT y CMD. Juntos, estos definen el proceso de primer plano que se ejecutará cuando los contenedores se inicien desde su imagen. La mayoría de las imágenes base iniciarán de forma predeterminada un shell cuando se inicie el contenedor. Debe cambiar esto para que sea su aplicación la que se ejecute automáticamente, eliminando la necesidad de que los usuarios la ejecuten manualmente dentro del contenedor.

los ENTRYPOINT La instrucción Dockerfile define el proceso de primer plano del contenedor. Establezca esto en el ejecutable de su aplicación:

ENTRYPOINT ["demo-app"]

los CMD la instrucción funciona en conjunto con ENTRYPOINT. Proporciona argumentos predeterminados para el comando que se establece en el ENTRYPOINT. Argumentos que proporciona el usuario al iniciar el contenedor con docker run anulará el CMD establecido en el Dockerfile.

un buen uso para CMD es cuando desea mostrar ayuda básica o información de la versión cuando los usuarios omiten un comando específico:

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

Aquí hay algunos ejemplos que muestran cómo estas dos instrucciones dan como resultado que se ejecuten diferentes comandos cuando se crean contenedores:

# 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

Ninguno de los ejemplos requiere que el usuario escriba el demo-app nombre ejecutable. Se usa automáticamente como el proceso de primer plano porque es el configurado ENTRYPOINT. El comando recibe los argumentos que el usuario le dio a docker run después del nombre de la imagen. Cuando no se proporcionan argumentos, el valor predeterminado --version se usa

Estas dos instrucciones son los bloques de construcción fundamentales de las imágenes de Docker que albergan las herramientas CLI. Desea que el ejecutable principal de su aplicación sea el proceso de primer plano predeterminado para que los usuarios no tengan que invocarlo ellos mismos.

Poniendo todo junto

Aquí hay una imagen de Docker que ejecuta una aplicación simple de 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"]

La variante basada en Alpine de la imagen base de Node se utiliza para reducir el tamaño total de su imagen. El código fuente de la aplicación se copia en el sistema de archivos de la imagen a través del COPY instrucción. Las dependencias npm del proyecto están instaladas y el hello-world.js script se establece como punto de entrada de la imagen.

Construye la imagen usando docker build:

docker build -t demo-app-image:latest

Ahora puedes ejecutar la imagen para ver Hello World emitido a su terminal:

docker run demo-app-image:latest

En este punto, está listo para enviar su imagen a Docker Hub u otro registro donde los usuarios pueden descargarla. Cualquiera que tenga acceso a la imagen podrá iniciar su software utilizando solo la CLI de Docker.

Gestión de datos persistentes

Dockerizar una aplicación CLI presenta algunos desafíos. El más destacado de estos es cómo manejar la persistencia de datos. Los datos creados dentro de un contenedor se pierden cuando ese contenedor se detiene, a menos que se guarden en un volumen externo de Docker.

Debe escribir datos en rutas claramente definidas en las que los usuarios puedan montar volúmenes. Es una buena práctica agrupar todos sus datos persistentes en un solo directorio, como /data. Evite utilizar demasiadas ubicaciones que requieran el montaje de varios volúmenes. Su guía de inicio debe documentar los volúmenes que necesita su aplicación para que los usuarios puedan configurar la persistencia cuando crean su contenedor.

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

Otros posibles desafíos

El problema de montaje reaparece cuando su comando necesita interactuar con archivos en el sistema de archivos del host. Aquí hay un ejemplo simple de una herramienta de carga de archivos:

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

Esto termina buscando example.txt dentro de El contenedor. En esta situación, los usuarios deberán enlace de montaje su directorio de trabajo para que su contenido esté disponible para el contenedor:

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

También es importante pensar en cómo los usuarios proporcionarán valores de configuración a su aplicación. Si normalmente lee desde un archivo de configuración, tenga en cuenta que los usuarios deberán montar uno en cada contenedor que creen. Ofrecer opciones alternativas, como banderas de línea de comandos y variables de entorno, puede optimizar la experiencia para casos de uso simples:

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

Otro desafío se refiere a las aplicaciones interactivas que requieren la intervención del usuario. Los usuarios deben pasar el -it bandera a docker run para habilitar el modo interactivo y asignar un pseudo-TTY:

docker run -it demo-app-image:latest

Los usuarios deben recordar establecer estos indicadores cuando sea necesario o su programa no podrá recopilar ninguna entrada. Debe documentar los comandos que necesitan un TTY para que los usuarios no se vean sorprendidos por errores inesperados.

Estos puntos conflictivos significan que las aplicaciones dockerizadas pueden volverse difíciles de manejar si no están diseñadas específicamente teniendo en cuenta la contenedorización. Los usuarios obtienen la mejor experiencia cuando sus comandos son puros, sin necesidad de interacciones con el sistema de archivos y con una configuración mínima. Cuando esto es posible, un simple docker run image-name cumple el objetivo de instalación y uso sin fricción. Todavía puede contener software más complejo, pero depende cada vez más de que los usuarios tengan un buen conocimiento práctico de la CLI de Docker y sus conceptos.

Resumen

Docker no es solo para implementaciones en la nube y servicios en segundo plano. También es cada vez más popular como mecanismo de distribución para aplicaciones de consola regulares. Puede publicar, consumir, ejecutar y mantener software fácilmente utilizando el único docker CLI que muchos profesionales de software ya usan día a día.

Ofrecer una imagen de Docker lista para usar para su aplicación brinda a los usuarios más opciones. Los recién llegados pueden comenzar con un solo comando que configura un entorno preconfigurado con todas las dependencias atendidas. No hay riesgo de contaminar el sistema de archivos o el entorno de su host Docker, lo que evita conflictos con otros paquetes y garantiza la capacidad de volver a una pizarra limpia si lo desea.

La creación de una imagen de Docker no suele implicar más que las rutinas que ya está utilizando para enviar compilaciones a diferentes administradores de paquetes del sistema operativo. Las consideraciones más importantes son mantener su imagen lo más pequeña posible y asegurarse de que el punto de entrada y el comando sean apropiados para su aplicación. Esto brindará a los usuarios la mejor experiencia posible al usar su software dockerizado.

Deja un comentario

En esta web usamos cookies para personalizar tu experiencia de usuario.    Política de cookies
Privacidad