in Ingeniare
Extensión de la arquitectura Docker para el despliegue automático de contenedores
RESUMEN
Los contenedores se han convertido es una estrategia ideal para acelerar el proceso de desarrollo de plataformas. Su importancia radica en la capacidad que tienen de separar una aplicación e interactuar con sus partes sin que la totalidad de la aplicación tenga que ser afectada. Los contenedores pueden compartir procesos entre varias aplicaciones, de manera muy similar al esquema propuesto por la arquitectura orientada a servicios. El objetivo de esta investigación fue definir una arquitectura para el despliegue automático de contenedores en contextos académicos; la verificación y validación de la arquitectura se realizó mediante la construcción de una plataforma que adapta los conceptos de la arquitectura y permite visualizar nivel a nivel cada uno de sus componentes. Se realizó un análisis bibliográfico sobre las arquitecturas propuestas para la gestión de contenedores, con lo cual se evidenciaron fortalezas y debilidades. El resultado directo de esta investigación fue la propuesta arquitectónica para el despliegue de contenedores como una extensión de Docker. El resultado indirecto fue la plataforma web con miras a la verificación y la validación de la arquitectura.
Main Text
1. Introduction
El diseño y la programación de algoritmos definen las bases y las competencias que debe adquirir un ingeniero de desarrollo, por tanto, los cursos de programación son de vital importancia en el proceso de formación [1]. Las habilidades en programación que un estudiante adquiere en su proceso de formación están calificadas como las competencias requeridas en el siglo XXI [2], lo que realza la importancia de aplicar un proceso de enseñanza aprendizaje que asegure la adquisición de competencias en el área de programación.
Facilitar la enseñanza de la programación es una actividad que no solo requiere conocimiento técnico por parte del docente, sino habilidades para motivar a los estudiantes a superar los obstáculos que se presenten en su formación [3]. Un estudiante frustrado, probablemente, incrementará las estadísticas de deserción [1].
El proceso de formación de un desarrollador de software requiere de tiempo y dedicación, y existen múltiples problemáticas que inciden en el éxito o el fracaso [4]. Entre estas problemáticas se encuentran la formación y la experticia del docente, los conocimientos previos que debe tener el estudiante, así como los recursos tecnológicos a los que tiene acceso el desarrollador, entre otros [5].
En [6]critical thinking and collaboration or recognized as Higher Order Thinking Skills (HOTS se plantea que los procesos actuales de enseñanza son ineficientes, lo cual crea en el estudiante una resistencia que, eventualmente, se transformará en miedo a la programación [7], [8]. Existe evidencia de trabajos —como, por ejemplo, [9]— en los que utilizan otras estrategias para enseñar programación (p. ej., el caso de los videojuegos).
Este documento presenta una arquitectura soportada en Docker [10] [11] para el despliegue automático de contenedores en procesos de desarrollo software orientados a la web. El enfoque de este proyecto busca proporcionar herramientas que permitan emplear estrategias diferentes dirigidas a que el estudiante en formación del área de sistemas esté en capacidad de construir aplicaciones.
El artículo está organizado de la siguiente forma: inicia con una revisión de literatura acerca de arquitecturas para el despliegue de contenedores, posteriormente, presenta la arquitectura utilizada como línea de base en la presente investigación. Continua con la descripción de la arquitectura propuesta para el despliegue automático de contenedores en contextos académicos. Finaliza con el planteamiento de las limitaciones de la presente investigación y las conclusiones del estudio.
2. Revisión de literatura
La Tabla 1 presenta una descripción de arquitecturas para la gestión de contenedores y su comparación con la propuesta de arquitectura de este artículo.
3. Arquitectura de referencia
El desarrollo de aplicaciones robustas es un requerimiento fundamental en la industria del software [14] geographically distributed development teams, new business models and diverse cultural interactions steer these tools. Software development supported by web-based services, built on top of Web 2.0 technologies, is emerging as a new paradigm for distributed software development. New generation software forges (web-based development environments. Una buena práctica para el desarrollo de software es planear y realizar seguimiento a cada fase del ciclo de vida del aplicativo. Por tal motivo, es importante el uso de herramientas que apoyen la producción y la puesta en marcha del software. La arquitectura de referencia utilizada en esta investigación fue Docker [10] Docker agiliza la configuración de los equipos de desarrollo, de modo que permite la virtualización de un servidor en muchos espacios aislados de trabajo y compartir recursos en una máquina anfitriona. Adicionalmente, Docker permite encapsular entornos y aplicaciones que, posteriormente, pueden ser utilizadas en otros espacios de trabajo, lo que facilita el uso y la configuración de las herramientas.
La arquitectura cliente servidor de Docker se presenta en la Figura 1. La capa cliente puede ejecutar instrucciones directamente sobre el anfitrión de Docker para descargar y desplegar imágenes y contenedores. En el Docker Host existe un Docker Daemon; este se encarga de controlar las imágenes y los contenedores que un cliente puede generar [15]. Toda la comunicación entre cliente y servidor se realiza a través de sockets utilizando un API de tipo Restfull [11].
El Docker Daemon controla las imágenes a través del Docker registry, el cual es el encargado de organizar y publicar las imágenes que un usuario puede llegar a utilizar. Cada contenedor se crea a partir de una imagen y es un entorno aislado y seguro en el que se ejecuta la aplicación [17].
El despliegue de la arquitectura de Docker se puede realizar sobre un servidor Linux o sobre hipervisores tipo I y II. Los hipervisores tipo I son aquellos que se utilizan a través de hardware, y se caracterizan por ser rápidos y costosos. Los hipervisores tipo II no son tan rápidos como los hipervisores tipo I, sin embargo, son económicos e, incluso, algunos se pueden utilizar de forma gratuita [20].
4. Arquitectura propuesta
Utilizar Docker para construir una nueva arquitectura requiere tres aspectos fundamentales: 1) la definición de los elementos diferenciadores de las dos arquitecturas; 2) la construcción de los componentes que permiten que la arquitectura se despliegue en un entorno de desarrollo; y 3) la ejecución de pruebas con el fin de validar la implementación de la nueva arquitectura.
4.1 Diseño de la arquitectura
La solución tecnológica propuesta en esta investigación se compone de una arquitectura base y una plataforma para la gestión automática de imágenes y contenedores. La arquitectura base reutiliza la totalidad de la arquitectura Docker y añade dos artefactos que permiten la automatización en contextos académicos. La Figura 2 describe la arquitectura base propuesta; en color verde se presentan los elementos diferenciadores con relación a la arquitectura Docker: middleware y primary storage of containers.
El cliente Docker permite la ejecución de tres instrucciones que se encargan de realizar la descarga de las imágenes. En la arquitectura base propuesta es posible apreciar una capa que cubre al cliente, la cual automatiza este proceso. Esta capa es un middleware [21] que gestiona una plataforma Web, la cual permite el uso y la administración de contenedores a usuarios que están en proceso de aprendizaje en contextos de desarrollo académico.
La siguiente capa de la arquitectura está ubicada en el cliente y se denomina “almacenamiento primario de contenedores”. La arquitectura define este almacenamiento como un espacio de nombres y un conjunto de repositorios que permiten la identificación, selección y búsqueda de los contenedores que puedan ser definidos por los usuarios. La implementación de la arquitectura en la plataforma utiliza el concepto de identificadores únicos para el almacenamiento primario, con lo cual un usuario puede llegar a crear muchos contenedores con el mismo nombre.
La arquitectura propuesta encapsula los conceptos de Docker, de modo que se logra una abstracción total para el usuario. Como resultado de esta abstracción un usuario no necesita tener conocimientos técnicos sobre Docker para implementar la arquitectura desarrollada. A continuación, se presentan los artefactos que hacen parte de la arquitectura y de la plataforma desarrollada utilizada para su verificación y validación.
4.1.1 Artefactos de la solución
• Primer artefacto. Servidor Linux con distribución Ubuntu en su versión 19.04 [22]. El hardware para la implementación estaba soportado con un procesador Intel(R) Core (TM) i5-8250U, con 8 gigas de RAM y conexiones ethernet.
• Segundo artefacto: Docker Community Edition CE. Lo utilizan desarrolladores nuevos en el uso de la tecnología o grupos pequeños de desarrollo. El canal de actualización para la descarga fue “Stable”, ideal para para personas que necesitan trabajar con contenedores sin errores [16].
• Tercer artefacto. La plataforma web desarrollada con base en los lineamientos definidos en la arquitectura propuesta. La implementación se realizó con base en patrones arquitectónicos y de diseño, buscando simplificar la funcionalidad, mantenibilidad y escalabilidad del sistema [23]. En el desarrollo de la aplicación web se utilizaron los patrones creacionales: Factory Method, Prototype y Singleton. Los patrones estructurales: Decorator y Facade, y los patrones de comportamiento Iterator y Template [24].
• Cuarto artefacto: Docker registry. Fue utilizado con el fin de acceder a los índices de las imágenes y presentar a los usuarios un listado de componentes reutilizables susceptibles de ser seleccionados sin conocimientos técnicos. La arquitectura puede implementar cualquier tipo de contenedor almacenado en Docker, sin embargo, en la plataforma se personalizaron dos contenedores para facilitar la comprensión de la arquitectura: 1) contenedores para bases de datos MySql [25] y 2) contenedor para servidores Web apache.
4.2 Implementación de la arquitectura
La arquitectura requiere de una plataforma web para su despliegue y validación. A continuación, se presenta la configuración base requerida por la plataforma, la descarga de imágenes de prueba, la inclusión de las imágenes en el repositorio de la arquitectura y el ejemplo de funcionamiento de la plataforma Web.
4.2.1 Instalación y configuración de componentes básicos
1. Instalación de la máquina virtual Oracle VM Virtual Box.
2. Definir distribución de Linux. Es importante definir qué distribución de Linux utilizar. Según [26], las versiones más estables de Linux son: Redhat, Debian, Ubuntu, Linux Mint, Fedora y MX Linux.
La versión que se utilizó para este caso de estudio fue Ubuntu (Server 19.04 Disco Dingo), por las
siguientes razones:
• Distribución sencilla y con un repositorio de paquetes amplio.
• Docker tiene paquetes preconfigurados para Ubuntu.
• Sistema operativo actualizado cada dos meses y con una frecuencia de soporte a largo plazo (dos años).
• Es una distribución utilizada en contextos académicos.
3. Instalación de Docker.
4. Descarga y sincronización del repositorio base de la arquitectura. En este punto se realizó la descarga de imágenes de prueba tales como: MySql, PHP, Java y Python, entre otras.
5. Creación del contenedor MySql a partir de la imagen almacenada en el repositorio de la arquitectura. Este contenedor es el que permite el almacenamiento de usuarios desde la plataforma que gestiona la arquitectura. La plataforma provee una interfaz de usuario final.
La instrucción “FROM” especifica la imagen que se desea descargar, en este caso se solicita la última versión de MySql. La instrucción “ENV” permite inicializar una variable que puede estar definida dentro de la imagen, en este caso se inicializó la variable “MYSQL_ROOT_PASSWORD” con una contraseña de ejemplo. La instrucción “EXPOSE” permite definir el puerto sobre el cual los contenedores de esta imagen prestarán sus servicios.
7. Creación del contenedor Apache-PHP a partir de la imagen almacenada en el repositorio de la arquitectura. La plataforma desarrollada que soporta la arquitectura fue construida en el lenguaje de programación PHP.
8. En la Figura 4 se presenta la configuración del Dockerfile para el contenedor Apache-PHP.
La instrucción “FROM” especifica la imagen que se desea descargar, en este caso se solicita la versión 7.2 de PHP con Apache. Adicionalmente, se incluyen las instrucciones de descargar las librerías necesarias para descomprimir [28]. Posteriormente, se definen las variables básicas para la instalación del apache y se presenta el puerto que será expuesto a fin de consumir los servicios del contenedor.
4.3 Modelo vista controlador de la plataforma
La Figura 5 presenta la estructura de ficheros utilizada en el componente de administración de contenedores de la plataforma desarrollada.
Como se describió, la arquitectura permite el uso de cualquier contenedor. En la plataforma desarrollada este proceso se automatiza mediante la ejecución de instrucciones parametrizadas que aíslan al usuario final de la problemática de instalación y configuración. La Figura 7 presenta las instrucciones que hacen parte de uno de los controladores para la creación de contenedores.
A fin de visualizar los contenedores se sigue el mismo principio: aislar la complejidad al usuario final y ejecutar instrucciones para presentar los resultados finales. La Figura 8 presenta las instrucciones utilizadas en el propósito de visualizar los contenedores en las vistas de usuario final.
La arquitectura propuesta fue verificada y validada por la plataforma desarrollada. A continuación, se presentan las funcionalidades de la plataforma, las cuales brindan una comprensión mayor de la arquitectura.
4.3.1 Funcionalidades plataforma
La plataforma desarrollada para la gestión de los contenedores cuenta con un sistema de autenticación y autorización [30]. Por defecto, un usuario requiere un navegador para hacer uso de la plataforma, un usuario y una contraseña que le permiten acceder al componente que administra y gestiona los contendedores. Si el usuario desea crear un contenedor nuevo lo puede realizar a partir de una imagen descargada o, en su defecto, tener acceso a la lista de imágenes que le permitirán acceder a más contenedores sin tener conocimiento técnico de Docker.
La Figura 9 presenta el modelo de clases implementado en la autenticación, autorización, gestión de contenedores y descarga de imágenes.
La clase usuarios representa los posibles desarrolladores que tendrán permisos para gestionar imágenes y contenedores en la plataforma desarrollada. La clase imágenes representa las imágenes almacenadas en la plataforma Docker, las cuales han sido descargadas con anterioridad del sitio oficial. La clase contenedores es una abstracción de los posibles contenedores que puede llegar a crear un usuario a través de la plataforma.
La plataforma desarrollada cuenta con las funcionalidades descritas en la Tabla 2.
A fin de acceder a la plataforma un usuario debe tener credenciales de acceso (f01). La plataforma verifica las credenciales de un usuario, posteriormente, le permite visualizar las imágenes que tiene disponible para su uso, tal como se presenta en la Figura 10 (f02, f03, f05, f06, f07). En cada imagen brinda opciones para crear contenedores (f04) y ver detalles de las imágenes de acuerdo con la información suministrada por el Docker registry. Dependiendo de la imagen a utilizar, se presentan interfaces personalizadas, lo que permite la creación de contenedores con información mínima y sin conocimientos sobre los aspectos técnicos de la filosofía de contenedores.
La creación de un contenedor a través de la plataforma solicita tres valores: nombre del contenedor, puerto sobre el cual desea exponer los servicios y, por último, el nombre del espacio de nombres que el usuario desea manejar para el almacenamiento de sus archivos. Los contenedores creados son de propiedad del usuario en sesión, es decir, que al ingresar con otro usuario no aparecerán esos contenedores.
Como se describió, los contenedores tienen propietarios y estos usuarios pueden realizar múltiples funciones con sus contenedores. La plataforma provee opciones para iniciar o detener los servicios de los contenedores (f06).
La Figura 11 presenta la interfaz que permite manipular un contenedor de mysql. En cada contenedor se pueden crear bases de datos (f08). Para cada base de datos existe un intérprete (f09) que permite utilizar el lenguaje de definición de datos DDL.
En la Figura 11 se presenta la forma como se pueden visualizar las tablas de cada base de datos (f10).
La Figura 12 describe la interfaz para subir sitios web a un contenedor (f11, f12). Los archivos deben estar en formato zip.
De acuerdo con [12], la plataforma web desarrollada (f13) cumple con el 65 % de los requerimientos funcionales que debería tener un sistema de administración de contenedores. El 35 % de los requerimientos no desarrollados están orientados hacia el balanceo de carga y la transferencia de contenedores entre diferentes hosts, sin embargo, ese 35 % no hace parte del alcance de la presente investigación.
5. Limitaciones
• La plataforma desarrollada requiere la implementación de funcionalidades adicionales, como, por ejemplo, la personalización de otros tipos de contenedores.
• Está orientado solo a contextos académicos en los que las personas están en proceso de aprendizaje para entornos web.
• La degradación de un contenedor afecta los demás contenedores, por tanto, se debe utilizar un sistema de balanceo a fin de que la plataforma detecte la falla y la corrija de manera automática, tal como lo realiza Kubernates.
• La cantidad de contenedores y procesos que puede llegar a crear un usuario son ilimitados, por tanto, se debe gestionar una cuota para cada sesión de usuario.
6. Conclusiones
• Docker no es una herramienta dirigida a orquestar contenedores, se utiliza para gestionarlos en un entorno particular. Es importante contar con una suite de administración de contenedores. Existen herramientas como Kubernates, un orquestador de contenedores construido por Google que tiene por objeto crear aplicaciones distribuidas soportadas en contenedores. El uso y la administración de Kubernates requiere de conocimiento técnico o personal con capacitación en el tema.
• Docker Swarm es otra herramienta para organizar clústeres de contendedores. La diferencia con Kubernates radica en su enfoque: Swarm busca extender el uso de la API de Docker a fin de que todos los contenedores se vean como una sola unidad. Existen otras herramientas con fines similares, sin embargo, ninguna de ellas está enfocada en procesos de formación de profesionales.
• Docker permite extender su arquitectura mediante la adición de componentes, los cuales componentes pueden estar encapsulados en un middleware. A través del middleware se puede realizar la ejecución de código desde una interfaz web hasta el sistema operativo base que contiene el host Docker.
• El proceso de verificación y validación de la arquitectura se llevó a cabo con la implementación de la plataforma, teniendo un marco controlado de usuarios que permita garantizar la aplicación de todos los conceptos de la arquitectura.
• La arquitectura propuesta puede utilizarse en entornos de capacitación para formación de desarrolladores junior, puesto que permite encapsular la complejidad de Docker y, al mismo tiempo, utilizar la potencia de Docker.
RESUMEN
Main Text
1. Introduction
2. Revisión de literatura
3. Arquitectura de referencia
4. Arquitectura propuesta
4.1 Diseño de la arquitectura
4.1.1 Artefactos de la solución
4.2 Implementación de la arquitectura
4.2.1 Instalación y configuración de componentes básicos
4.3 Modelo vista controlador de la plataforma
4.3.1 Funcionalidades plataforma
5. Limitaciones
6. Conclusiones