ingeniareIngeniareIngeniare1909-24582390-0504Universidad Libre10.18041/1909-2458/ingeniare.29.7432ArtículosExtensión de la arquitectura Docker para el despliegue automático de contenedoresExtension of the Docker architecture for automatic container deploymentGutiérrez LópezLuz Elenaegluz@uninorte.edu.co1Guerrero AlarcónCarlos Andréscarlos.guerrero@usantoto.edu.co2Magíster en Ingeniería Área Informática y Ciencias de la Computación, Ingeniera de Sistemas. Universidad del Norte, ColombiaMagíster en Ingeniería Área Informática y Ciencias de la Computación, Ingeniera de Sistemas. Universidad del Norte, ColombiaMagíster en Ingeniería Área Informática y Ciencias de la Computación, Ingeniera de Sistemas. Universidad del Norte, ColombiaBogotáColombiaPh. D. en Ingeniería, Magíster en Informática, Ingeniero de Sistemas. Universidad Santo Tomás, ColombiaPh. D. en Ingeniería, Magíster en Informática, Ingeniero de Sistemas. Universidad Santo Tomás, ColombiaPh. D. en Ingeniería, Magíster en Informática, Ingeniero de Sistemas. Universidad Santo Tomás, ColombiaBogotáColombiaJul-Dec20202911260501202025032020Esta obra está bajo una licencia internacional Creative Commons Atribución-NoComercial-CompartirIgual 4.0.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.
ABSTRACT
Containers have become an ideal strategy to speed up the platform development process. The importance of containers is the ability they must separate an application and interact with its parts, without the entire application having to be affected. Containers can share processes between multiple applications, using the same strategy used by service-oriented architecture. The aim this paper is to present a novel architecture for the automatic deployment of containers in academic contexts. The verification and validation of the architecture was carried out through the construction of a platform that adapts the concepts of the architecture and allows to visualize each of its components level by level. In this study, a bibliographic analysis was carried out on the architectures that manage containers, showing strengths and weaknesses. The principal result of this research was the proposal of novel architecture for the deployment of containers as extension of Docker. The secondary result was the development of a web platform, this platform allows to present all characteristics of the novel approach. It was used for the verification and validation of the architecture.
Palabras claveA dministración webContenedorDesarrollo de softwareDockerKeywordsWeb managementContainerSoftware developmentDocker1. 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.
Comparación de estudios
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].
Arquitectura Docker
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].
Docker administra espacios de nombres, dispositivos de red, cortafuegos y, en general, los recursos del sistema operativo a través de libcontainer. La administración de los contenedores se realiza al dar cumplimiento al estándar Open Container Initiative-OCI [18], [19].
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.
Arquitectura Docker
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.
6. Configuración del archivo Dockerfile para el contenedor que almacena los usuarios de la plataforma, tal como se presenta en la Figura 3. Los Dockerfile son útiles para usuarios que no tienen conocimiento en la configuración de archivos de Docker [27].
Contenido Dockerfile mysql
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.
Contenido Dockerfile mysql
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.
Modelo vista controlador del componente administrador
A continuación, se describen tres ficheros de código que hacen parte de la plataforma desarrollada. La Figura 6 presenta el sistema de conexión de la base de datos a través de PDO [29].
Contenido conexion.php
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.
Contenido contecreacontroller.php
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.
Contenido imágenes base.php
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.
Modelo de clases plataforma
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.
Descripción de funcionalidades
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.
Creación 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.
Administración contenedor mysql
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.
Formulario subir sitio
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.
ReferenciasV. F. Martins, I. de Almeida Souza Concilio, y M. de Paiva Guimarães, “Problem based learning associated to the development of games for programming teaching”, Comput. Appl. Eng. Educ., vol. 26, n. o 5, pp. 1577-1589, sep. 2018.MartinsV. F.de Almeida Souza ConcilioI.de Paiva GuimarãesM.2018Problem based learning associated to the development of games for programming teachingComput. Appl. Eng. Educ.26515771589S. Popat and L. Starkey, “Learning to code or coding to learn? A systematic review”, Comput. Educ., vol. 128, pp. 365-376, en. 2019.PopatS.StarkeyL.2019Learning to code or coding to learn? A systematic reviewComput. Educ.128365376S. Azmi, N. A. Iahad y N. Ahmad, “Attracting students’ engagement in programming courses with gamification”, in 2016 IEEE Conference on e-Learning, e-Management and e-Services (IC3e), 2016, pp. 112-115.AzmiS.IahadN. A.AhmadN.2016“Attracting students’ engagement in programming courses with gamification”, in 2016 IEEE Conference on e-Learning, e-Management and e-Services (IC3e)112115I. Hadar, “When intuition and logic clash: the case of the object-oriented paradigm”, Sci. Comput. Program., vol. 78, n. o 9, pp. 1407-1426, sep. 2013.HadarI.2013sepWhen intuition and logic clash: the case of the object-oriented paradigmSci. Comput. Program.7914071426F. Špaček, R. Sohlich y T. Dulík, “Docker as platform for assignments evaluation,” Procedia Eng., vol. 100, pp. 1665–1671, en. 2015.ŠpačekF.SohlichR.DulíkT.2015en.Docker as platform for assignments evaluationProcedia Eng.10016651671M. E. Ismail, N. Sa’adan, M. A. Samsudin, N. Hamzah, N. Razali y I. I. Mahazir, “Implementation of the gamification concept using Kahoot! among TVET students: an observation”, J. Phys. Conf. Ser., vol. 1140, n. o 1, p. 012013, dic. 2018.IsmailM. E.Sa’adanN.SamsudinM. A.HamzahN.RazaliN.MahazirI. I.2018dicImplementation of the gamification concept using Kahoot! among TVET students: an observationJ. Phys. Conf. Ser.11401012013012013A. Draz, S. Abdennadher y Y. Abdelrahman, “Kodr: a customizable learning platform for computer science education,” En DM Review, vol. 2, pp. 579-582, sep. 201.DrazA.AbdennadherS.AbdelrahmanY.2001sep.Kodr: a customizable learning platform for computer science educationEn DM Review2579582S. P. Sarkar, B. Sarker y S. K. A. Hossain, “Cross platform interactive programming learning environment for kids with edutainment and gamification”, En 2016 19th International Conference on Computer and Information Technology (ICCIT), 2016, pp. 218-222.SarkarS. P.SarkerB.HossainS. K. A.2016“Cross platform interactive programming learning environment for kids with edutainment and gamification”, En 2016 19th International Conference on Computer and Information Technology (ICCIT)218222C. A. Guerrero Alarcon, L. E. Gutiérrez López y K. D. Cuervo Cely, “Los videojuegos como estrategia para incrementar la motivación y alcance de logros en procesos de aprendizaje,” En Memorias la formación de ingenieros: un compromiso para el desarrollo y la sostenibilidad, 2020.Guerrero AlarconC. A.Gutiérrez LópezL. E.Cuervo CelyK. D.2020“Los videojuegos como estrategia para incrementar la motivación y alcance de logros en procesos de aprendizaje,” En Memorias la formación de ingenieros: un compromiso para el desarrollo y la sostenibilidadH. Zhu y I. Bayley, “If Docker is the answer, what is the question?,” En 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE), 2018, pp. 152-163.ZhuH.BayleyI.2018“If Docker is the answer, what is the question?,” En 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE)152163J. Cito, G. Schermann, J. E. Wittern, P. Leitner, S. Zumberi y H. C. Gall, “An empirical analysis of the Docker container ecosystem on gitHub,” in 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR), 2017, pp. 323-333.CitoJ.SchermannG.WitternJ. E.LeitnerP.ZumberiS.GallH. C.2017“An empirical analysis of the Docker container ecosystem on gitHub,” in 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)323333R. Peinl, F. Holzschuher y F. Pfitzer, “Docker cluster management for the cloud-survey results and own solution”, J. Grid Comput., vol. 14, n. o 2, pp. 265-282, jun. 2016.PeinlR.HolzschuherF.PfitzerF.2016Docker cluster management for the cloud-survey results and own solutionJ. Grid Comput.142265282R. Muddinagiri, S. Ambavane y S. Bayas, “Self-hosted Kubernetes: deploying Docker containers locally with Minikube,” En 2019 International Conference on Innovative Trends and Advances in Engineering and Technology (ICITAET), 2019, pp. 239-243.MuddinagiriR.AmbavaneS.BayasS.2019“Self-hosted Kubernetes: deploying Docker containers locally with Minikube,” En 2019 International Conference on Innovative Trends and Advances in Engineering and Technology (ICITAET)239243R. Fernández, J. Soriano, X. Larrucea, A. L. Martínez y J. M. González-Barahona, “Towards the improvement of the software quality: an Enterprise 2.0 architecture for distributed software developments,” En 2008 First International Conference on Distributed Framework and Applications, 2008, pp. 52-59.FernándezR.SorianoJ.LarruceaX.MartínezA. L.González-BarahonaJ. M.2008“Towards the improvement of the software quality: an Enterprise 2.0 architecture for distributed software developments,” En 2008 First International Conference on Distributed Framework and Applications5259Preeth E N, F. J. P. Mulerickal, B. Paul y Y. Sastri, “Evaluation of Docker containers based on hardware utilization,” En 2015 International Conference on Control Communication & Computing India (ICCC), nov. 2015, pp. 697-700.PreethE. N.MulerickalF. J. P.PaulB.SastriY.2015nov“Evaluation of Docker containers based on hardware utilization,” En 2015 International Conference on Control Communication & Computing India (ICCC)697700I. Docker, “Overview of Docker editions,” 2019. [En línea]. Disponible en: https://docs.docker.com/engine/docker-overview/DockerI.2019Overview of Docker editionshttps://docs.docker.com/engine/docker-overview/B. Kavitha y P. Varalakshmi, “Performance analysis of virtual machines and Docker containers,” En Communications in Computer and Information Science, vol. 804, 2018, pp. 99-113.KavithaB.VaralakshmiP.2018Performance analysis of virtual machines and Docker containersCommunications in Computer and Information Science80499113S. Fu, J. Liu, X. Chu y Y. Hu, “Toward a Standard interface for cloud providers: the container as the narrow waist,” IEEE Internet Comput., vol. 20, n. o 2, pp. 66–71, mar. 2016.FuS.LiuJ.ChuX.HuY.2016marToward a Standard interface for cloud providers: the container as the narrow waistIEEE Internet Comput.2026671T. L. F. Projects, “Open container initiative,” 2016. [En línea]. Disponible en: https://www.opencontainers.org/ProjectsT. L. F.2016Open container initiativehttps://www.opencontainers.org/R. Morabito, J. Kjallman y M. Komu, “Hypervisors vs. Lightweight virtualization: a performance comparison,” En 2015 IEEE International Conference on Cloud Engineering, 2015, pp. 386-393.MorabitoR.KjallmanJ.KomuM.2015“Hypervisors vs. Lightweight virtualization: a performance comparison,” En 2015 IEEE International Conference on Cloud Engineering386393U. Batra y S. Mukharjee, “Enterprise application integration (middleware): Integrating stovepipe applications of varied enterprises in distributed middleware with service oriented architecture,” En 2011 3rd International Conference on Electronics Computer Technology, 2011, vol. 5, pp. 226-230.BatraU.MukharjeeS.2011“Enterprise application integration (middleware): Integrating stovepipe applications of varied enterprises in distributed middleware with service oriented architecture,” En 2011 3rd International Conference on Electronics Computer Technology5226230Osboxes, “Ubuntu server,” 2019. [En línea]. Disponible en: https://www.osboxes.org/ubuntu-server/Osboxes2019Ubuntu serverhttps://www.osboxes.org/ubuntu-server/A. Singh, P. Chawla, K. Singh y A. K. Singh, “Formulating an MVC framework for web development in JAVA,” En 2018 2nd International Conference on Trends in Electronics and Informatics (ICOEI), 2018, Icoei, pp. 926-929.SinghA.ChawlaP.SinghK.SinghA. K.2018“Formulating an MVC framework for web development in JAVA,” En 2018 2nd International Conference on Trends in Electronics and Informatics (ICOEI)Icoei926929C. A. Guerrero Alarcón, J. M. Suárez Pedrazay L. E. Gutiérrez López, “Patrones de diseño GOF (The Gang of Four) en el contexto de procesos de desarrollo de aplicaciones orientadas a la web”, Inf. tecnológica, vol. 24, n. o 3, pp. 103-114, 2013.Guerrero AlarcónC. A.Suárez PedrazayJ. M.Gutiérrez LópezL. E.2013Patrones de diseño GOF (The Gang of Four) en el contexto de procesos de desarrollo de aplicaciones orientadas a la webInf. tecnológica243103114R. Senington, B. Pataki y X. V. Wang, “Using docker for factory system software management: Experience report”, Procedia CIRP, vol. 72, pp. 659-664, 2018.SeningtonR.PatakiB.WangX. V.2018Using docker for factory system software management: Experience reportProcedia CIRP72659664Masgnulinux, “Distribuciones más estables: 5 versiones de GNU/Linux que recomendamos”, 2018. [En línea]. Disponible en: https://masgnulinux.es/distribuciones-mas-estables-5-versiones-de-gnu-linux-que-recomendamos/Masgnulinux2018Distribuciones más estables: 5 versiones de GNU/Linux que recomendamoshttps://masgnulinux.es/distribuciones-mas-estables-5-versiones-de-gnu-linux-que-recomendamos/J. Cito y H. C. Gall, “Using docker containers to improve reproducibility in software engineering research”, En Proceedings of the 38th International Conference on Software Engineering CompanionICSE ’16, 2016, pp. 906-907.CitoJ.GallH. C.2016“Using docker containers to improve reproducibility in software engineering research”, En Proceedings of the 38th International Conference on Software Engineering CompanionICSE ’16906907R. Avellaneda, S. Cabrera, P. A. Martínez, y C. G. Donoso Albarracín, “Apoyo tecnológico para la fidelización y captación de nuevos clientes por medio de una aplicación móvil”, Inv. Inn. Ing., vol. 5, n.º 1, pp. 92-101, jul. 2017.AvellanedaR.CabreraS.MartínezP. A.Donoso AlbarracínC. G.2017Apoyo tecnológico para la fidelización y captación de nuevos clientes por medio de una aplicación móvilInv. Inn. Ing.5192101T. P. Group, “PHP.NET,” 2019. [En línea]. Disponible en: https://php.net/manual/es/intro.pdo.phpGroupT. P.2017PHP.NET.https://php.net/manual/es/intro.pdo.phpJ. M. Suárez Pedraza y L. E. Gutiérrez López, “Tipificación de dominios de requerimientos para la aplicación de patrones arquitectónicos,” Inf. Tec., vol. 27, n. o 4, pp. 193-202, 2016.Suárez PedrazaJ. M.Gutiérrez LópezL. E.2016Tipificación de dominios de requerimientos para la aplicación de patrones arquitectónicosInf. Tec.274193202