Docker es una plataforma popular para empaquetar aplicaciones como artefactos distribuibles independientes. Cree imágenes que incluyan todo lo que necesita para ejecutar un software en particular, como código fuente, dependencias de paquetes de terceros y características de entorno requeridas.
Dado que las imágenes de Docker pueden ejecutarse en cualquier lugar donde esté instalado Docker, son un buen formato para implementar 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?
CONTENIDOS DE LA PAGINA
Docker puede hacer que sea 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, copiar a carpetas del sistema o PATH edición involucrada.
El software dockerizado también permite a los usuarios seleccionar fácilmente 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 del software una al lado de la otra mediante el lanzamiento de contenedores basados en diferentes etiquetas de imágenes.
Otro beneficio es la facilidad con la que los usuarios pueden probar su aplicación de manera segura sin comprometerse a largo plazo. Las personas pueden ser reacias a agregar nuevos paquetes a sus máquinas por temor a que el software no se limpie completamente una vez eliminado. Los contenedores Docker tienen su propio sistema de archivos privado; quitar un contenedor no deja rastro de su existencia en el host. Esto puede animar a más usuarios a probar su aplicación.
Una consecuencia natural de la implementación Dockerizada es el requisito de que los usuarios ya tengan Docker ejecutándose en su computadora. Hoy en día, muchos desarrolladores lo ejecutarán de forma natural, 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 los 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 ligeramente diferentes a las que se usan para cualquier otro tipo de software. El objetivo es proporcionar una imagen lo más liviana posible y, al mismo tiempo, incluir todo lo que la aplicación necesita para funcionar.
Por lo general, es mejor comenzar con una imagen base mínima que ejecute un sistema operativo optimizado como Alpine. Agregue solo los paquetes que requiere su software, como el lenguaje de programación, el marco y las dependencias.
Dos instrucciones vitales de Dockerfile para herramientas CLI son ENTRYPOINT Y CMD. Juntos definen el proceso de primer plano que se ejecutará cuando los contenedores se inicien desde la imagen. De forma predeterminada, la mayoría de las imágenes base inician un shell cuando se inicia el contenedor. Debe cambiar esto para que la aplicación 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 educación trabaja en conjunto con ENTRYPOINT. Proporciona argumentos predeterminados para el conjunto de comandos en ENTRYPOINT. Argumentos proporcionados por el usuario al iniciar el contenedor docker run sobrescribirá 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"]
Estos son algunos ejemplos que muestran cómo estas dos declaraciones hacen 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 archivo demo-app nombre ejecutable. Se usa automáticamente como un proceso de primer plano porque está configurado ENTRYPOINT. El comando recibe los argumentos que el usuario ha proporcionado 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 componentes básicos de las imágenes de Docker que contienen las herramientas de la 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 del nodo se utiliza para reducir el tamaño general de la imagen. El código fuente de la aplicación se copia en el sistema de archivos de imagen a través del archivo COPY instrucción. Las dependencias npm del proyecto están instaladas y el hello-world.js el guión se establece como el 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 en su terminal:
docker run demo-app-image:latest
Ahora está listo para enviar su imagen a Docker Hub u otro registro donde los usuarios pueden descargarla. Cualquier persona con acceso a la imagen podrá iniciar el software utilizando solo la CLI de Docker.
Gestión persistente de datos
Dockerizar una aplicación CLI presenta algunos desafíos. El más importante de ellos es cómo gestionar la persistencia de los datos. Los datos creados dentro de un contenedor se pierden cuando el contenedor deja de funcionar, a menos que se guarden en un volumen Docker externo.
Los datos deben escribirse en rutas claramente definidas en las que los usuarios pueden montar volúmenes. Es una buena idea agrupar todos los datos persistentes en un solo directorio, por ejemplo /data. Evite utilizar demasiadas ubicaciones que requieran el montaje de varios volúmenes. Su guía de inicio debe documentar los volúmenes que su aplicación necesita para que los usuarios puedan establecer 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 el 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 pareciendo example.txt dentro de El contenedor. En esta situación, los usuarios deberán asignar el montaje de 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 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 comando y variables de entorno puede simplificar 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 relaciona con las aplicaciones interactivas que requieren la intervención del usuario. Los usuarios deben pasar el -it marcar un 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 requieren un TTY para que los usuarios no se vean atrapados por errores inesperados.
Estos puntos débiles significan que las aplicaciones dockerizadas pueden volverse engorrosas 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, no requieren interacciones con el sistema de archivos y una configuración mínima. Cuando esto es posible, uno simple docker run image-name Cumple con 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 los usuarios que tienen 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 fácilmente el software utilizando el único docker CLI que muchos profesionales del software ya utilizan a diario.
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 satisfechas. 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 que pueda volver a una pizarra limpia si lo desea.
La creación de una imagen de Docker no suele ser más complicada 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 la 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 ofrecerá a los usuarios la mejor experiencia posible al usar el software Dockerized.
