hito4-1.md

Hito 4: Composición de servicios - Justificación de herramientas

En este documento se justifica la elección de imágenes y explicaciones correspondientes para la realización del hito 4.

1. Elección de las imágenes base

Se tomará una decisión con respecto a la elección de imagen base a partir de los siguientes criterios:

1. Compatibilidad con herramientas actuales: debe ser compatible con las herramientas instaladas actualmente en el proyecto.
2. Tamaño y rendimiento: lo más habitual es que una imagen que ocupe un espacio reducido sea más rápida a la hora de iniciarse, al no tener que cargar tantos datos. El tamaño de las imágenes se revisará en Docker Hub y el rendimiento dependerá del tiempo que tarde en ejecutar los tests el contenedor.
3. Mantenimiento: este aspecto será evaluado se basará en cuándo fue la última vez que se actualizó, y si recibe actualizaciones de manera frecuente, lo que se verificará en Docker Hub.
4. Seguridad: no debería tener serias vulnerabilidades. Esto se comprobará según las vulnerabilidades registradas en Docker Hub.

1.1. Imagen base para la app

Entre las opciones de imágenes consideras para la creción de un entorno de pruebas aislado, se encuentran:

• Node (tag slim): imagen oficial de Node.js con herramientas esenciales para el desarrollo.
• CircleCI Node: imagen de Node.js optimizada para su uso en entornos CI/CD (Continuous Integration/Continuous Deployment).
• Bitnami Node: imagen de Node.js de Bitnami, una pila de aplicaciones preconfigurada para facilitar la implementación.
• Alpine: imagen mínima basada en Alpine Linux, ideal para contenedores pequeños y eficientes.

Finalmente se optó por Alpine para Node, en concreto, node:23.4-alpine.

1. Compatibilidad con herramientas actuales: al ser de node ya viene con Node.js preinstalado, por lo que es totalmente compatible con el proyecto.
2. Tamaño y rendimiento: inicialmente ocupa 53.54 MB, y como no es necesario instalar Node, se considera un tamaño aceptable.
3. Mantenimiento: tiene el sello de imagen oficial en Docker Hub y es actualizado regularmente, siendo la última actualización hace el 10/12/2024.
4. Seguridad: no presenta vulnerabilidades, lo que se puede observar en la propia página de Docker Hub.

También se ha creado un fichero .dockerignore para evitar la copia de determinados archivos durante la creación de contenedores.

1.2. Imagen base para la BD

Dado que la base de datos elegida para el almacenamiento de información de la aplicación es PostgreSQL, se ha seleccionado la imagen base oficial de Postgre, concretamente, postgres:14.

1. Compatibilidad con herramientas actuales: al haber utilizado PostgreSQL para la creación de las estructuras de la base de datos de la app, se garantiza su compatibilidad con el toolchain actual.
2. Tamaño y rendimiento: la imagen oficial de PostgreSQL 14 está optimizada para ser ligera. Esto resulta en tiempos de inicio rápidos y un menor consumo de recursos, lo que mejora el rendimiento general y agiliza los procesos de desarrollo y despliegue.
3. Mantenimiento: al tratarse de la imagen oficial, recibe actualizaciones frecuentes y regulares en Docker Hub, lo que garantiza que se incluyan las últimas mejoras y correcciones.
4. Seguridad: aunque presenta algunas vulnerabilidades, su estatus oficial garantiza que estas son monitoreadas y gestionadas de manera proactiva por el equipo de mantenimiento.

1.3. Imagen base para el sistema de logs

La elección de la pila ELK (Elasticsearch, Logstash, Kibana) para gestionar los logs en un entorno de contenedores se basa en su capacidad para manejar grandes volúmenes de datos de manera eficiente, su flexibilidad y sus potentes herramientas de visualización.

• Elasticsearch: permite almacenar y buscar logs de forma escalable. elasticsearch:7.17.9.
• Logstash: proporciona un pipeline configurable para procesar y transformar los datos entrantes. logstash:7.17.9.
• Kibana: ofrece una interfaz gráfica intuitiva que facilita el análisis y monitoreo de los logs en tiempo real. kibana:7.17.9.

Este ecosistema se adapta perfectamente a entornos distribuidos como clusters de contenedores, permitiendo identificar rápidamente problemas y optimizar el rendimiento del sistema.

1. Compatibilidad con herramientas actuales: al integrar la pila ELK, se garantiza una buena compatibilidad con las herramientas utilizadas actualmente. Además, estos tres elementos funcionan en conjunto como una potente herramienta para monitorización y logging.
2. Tamaño y rendimiento: las imágenes oficiales de la pila ELK están optimizadas para ser eficientes en cuanto a tamaño y rendimiento.
3. Mantenimiento: dado que son imágenes oficiales, reciben actualizaciones frecuentes en Docker Hub. Esto contribuye a que se mantenga la estabilidad de la infraestructura.
4. Seguridad: con su sello oficial, la confianza en la rápida resolución de vulnerabilidades y configuraciones de seguridad recomendadas minimizan los riesgos asociados.

2. Explicación del Dockerfile

El Dockerfile define cómo construir una imagen Docker para ejecutar la aplicación desarrollada. Comienza seleccionando una imagen base ligera y optimizada, node:23.4-alpine, que incluye Node.js en su versión 23.4 junto con un sistema operativo minimalista basado en Alpine Linux, ideal para reducir el tamaño de la imagen y mejorar el tiempo de despliegue.

A continuación, se añaden metadatos de mantenimiento, como el nombre de la responsable y la versión de la imagen, lo que ayuda a identificar y gestionar la imagen en un entorno de producción.

Se establece al usuario root temporalmente para crear el directorio /app, donde se alojará la aplicación. Este directorio se configura para que sea propiedad del usuario node, promoviendo una práctica de seguridad al evitar la ejecución de la aplicación como usuario root. Luego, se cambia al usuario node para ejecutar los siguientes pasos:

1. El directorio de trabajo se define como /app, asegurando que todas las operaciones posteriores se realicen en este contexto.
2. Los archivos package.json y package-lock.json se copian al contenedor con los permisos adecuados.
3. Se procede con la instalación de las dependencias necesarias mediante npm install.
4. Se copia el código de la aplicación al contenedor, también con los permisos asignados al usuario node.
5. Se ejecuta el comando npm run build para compilar la aplicación, asegurando que esté lista para ejecutarse.

Finalmente, el contenedor expone el puerto 3000, indicando que la app estará accesible a través de este puerto, y define el comando de inicio como npm run start-server, lo que ejecuta el script para iniciar el servidor de la aplicación.

En conjunto, este Dockerfile está diseñado para ser seguro, eficiente y compatible con entornos de despliegue modernos.

3. Estructura del clúster de contenedores

3.1. Redes

Todos los servicios están conectados a una red llamada brushnbid-network, que utiliza el controlador bridge. Esto asegura que los contenedores puedan comunicarse entre sí usando nombres de contenedor como hosts.

3.2. Contenedores, volúmenes y dependencias

Los contenedores están diseñados para colaborar entre sí, cada uno cumpliendo un rol específico en el ecosistema de la aplicación.

1. app (aplicación principal): es el punto de entrada para los usuarios y la lógica de negocio. Se comunica con db para el acceso a la base de datos y con logstash para el envío de logs, de los que depende, asegurando que estén disponibles antes de iniciar. Expone el puerto 3000 para la interacción externa.
2. db (base de datos PostgreSQL): almacena los datos estructurados utilizados por la aplicación. Usa un volumen persistente (pgdata) para garantizar la retención de datos entre reinicios. Permite que otros contenedores (como app) se conecten a través del puerto 5432.
3. elasticsearch (motor de búsqueda y almacenamiento de logs): proporciona un backend para almacenar y buscar logs y otros datos. Se comunica con logstash, que le envía logs procesados, y con kibana, que consulta los datos para visualización. Utiliza un volumen persistente (esdata) para mantener los datos indexados de forma segura.
4. logstash (procesador de logs): recibe logs desde app, los procesa y los envía a elasticsearch, del que depende para asegurarse de que puede enviar datos procesados.
5. kibana (interfaz de monitoreo y visualización): ofrece una interfaz gráfica para consultar y analizar los datos almacenados en elasticsearch, del que depende para obtener los datos necesarios.

3.3. Otros detalles de configuración

• Los contenedores se comunican usando los nombres definidos en el archivo, por ejemplo, db, logstash o elasticsearch.
• Las variables de entorno como DB_HOST y ELASTICSEARCH_HOSTS especifican las direcciones de otros servicios.
• Se definen límites de recursos para algunos contenedores: elasticsearch tiene límites de memoria (mem_limit) y opciones de Java optimizadas, al igual que logstash, ajustado mediante variables de entorno (LS_JAVA_OPTS).
• Los logs del contenedor app están configurados con un controlador de registro (json-file) que limita el tamaño y número de archivos para evitar saturar el almacenamiento.

3.4. Captura en Docker Desktop del clúster en ejecución