DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE...
57
1 DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE ENTORNOS PARA LA OFICINA ASESORA DE SISTEMAS DE LA UNIVERSIDAD DISTRITAL AUTOR: MANUEL FERNANDO MUÑOZ GARCÉS UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTA, D.C 2017
Transcript of DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE...
1
DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE ENTORNOS PARA LA OFICINA ASESORA DE SISTEMAS DE LA UNIVERSIDAD
DISTRITAL
AUTOR:
MANUEL FERNANDO MUÑOZ GARCÉS
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS
BOGOTA, D.C 2017
2
DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE ENTORNOS PARA LA OFICINA ASESORA DE SISTEMAS DE LA UNIVERSIDAD
DISTRITAL
AUTOR:
MANUEL FERNANDO MUÑOZ GARCÉS
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS
DIRECTOR: ING. CARLOS ENRIQUE MONTENEGRO MARÍN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS
BOGOTA, D.C 2017
3
Nota de aceptación:
___________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
________________________________
Firma del Director del Trabajo de Grado
_________________________________
Firma del jurado
Bogotá, 2017
4
TABLA DE CONTENIDOS
1. INTRODUCCIÓN ........................................................................................ 7
2. PLANTEAMIENTO DEL PROBLEMA ......................................................... 9
2.1. Descripción del problema....................................................................... 9
2.2. Formulación del problema.................................................................... 10
3. JUSTIFICACIÓN ....................................................................................... 11
4. OBJETIVOS .............................................................................................. 13
4.1. Objetivo general ................................................................................... 13
4.2. Objetivos específicos ........................................................................... 13
5. DELIMITACIÓN ........................................................................................ 14
5.1. Alcances .............................................................................................. 14
5.2. Limitaciones ......................................................................................... 14
6. MARCO TEÓRICO ................................................................................... 15
6.1. La metodología Scrumban ................................................................... 15
6.1.1. Scrum .................................................................................................. 16
6.1.2. Kanban ................................................................................................ 18
6.2. Docker ................................................................................................. 19
6.2.1. Contenedor Vs Máquina virtual tradicional ........................................... 20
6.2.2. Contenedores como Servicio (CaaS) ................................................... 22
6.2.3. Imágenes en Docker ............................................................................ 22
6.3. DockerHub ........................................................................................... 23
6.4. Docker-Compose ................................................................................. 24
6.5. Docker-Machine ................................................................................... 24
7. METODOLOGÍA ....................................................................................... 25
8. FASE DE ANÁLISIS ................................................................................. 28
8.1. Estado actual ....................................................................................... 28
8.2. Comparación con Vagrant ................................................................... 29
8.3. Arquitectura de Docker ........................................................................ 30
8.4. Funcionamiento de Docker .................................................................. 31
5
9. FASE DE DISEÑO .................................................................................... 34
10. FASE DE EJECUCIÓN ............................................................................. 36
10.1. Instalación de la plataforma ................................................................. 36
10.1.1. Docker Engine .................................................................................. 37
10.1.2. Docker Compose .............................................................................. 40
10.1.3. Docker Machine ................................................................................ 41
10.2. Dockerfile ............................................................................................. 41
10.3. Docker-Compose.yml .......................................................................... 42
11. RESULTADOS Y DISCUSIÓN .................................................................. 44
12. CONCLUSIONES ..................................................................................... 52
13. TRABAJOS FUTUROS ............................................................................. 53
13.1. Integración con un sistema de gestión de configuración ...................... 53
14. GLOSARIO DE TÉRMINOS...................................................................... 54
15. BIBLIOGRAFÍA ......................................................................................... 56
6
LISTA DE FIGURAS
Figura 1: Arquitectura de Máquina virtual tradicionales Fuente: [10] .................... 20
Figura 2: Arquitectura de contenedores de Docker. Fuente: [10] ......................... 21
Figura 3: Vista principal de DockerHub. Fuente: [18] ........................................... 23
Figura 4: Tablero de Scrumban del Proyecto. Fuente: Propia .............................. 27
Figura 6: Arquitectura de Docker. Fuente: [20] ..................................................... 30
Figura 7: Esquema del funcionamiento de Docker. Fuente: [21] .......................... 32
Figura 8: Esquema general de la arquitectura. Fuente: Propia ............................. 34
Figura 9: Esquema de funcionamiento. Fuente: Propia ........................................ 35
Figura 10: Diagrama de despliegue del prototipo. Fuente: Propia ........................ 44
Figura 11: Construcción de los contenedores de forma exitosa. Fuente: Propia .. 49
Figura 12: Despliegue exitoso del entorno de desarrollo. Fuente: Propia ............. 49
Figura 13: Beego localhost: 8081. Fuente: Propia ................................................ 50
Figura 14: MongoDB localhost: 8000. Fuente: Propia .......................................... 50
Figura 15: Swagger localhost: 8088. Fuente: Propia ............................................ 51
LISTA DE TABLAS
Tabla 1: Sprint Backlog. Fuente: Propia. .............................................................. 26
Tabla 2: Tabla comparativa entre Docker y Vagrant. Fuente: [19] ........................ 29
7
1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas es una institución autónoma de
educación superior, de carácter público, constituida esencialmente por procesos y
relaciones que generan estudiantes y profesores identificados en la búsqueda libre
del saber. Su misión es la democratización del acceso al conocimiento para
garantizar, a nombre de la sociedad y con participación de Estado, el derecho
social a una Educación Superior con criterio de excelencia, equidad y
competitividad mediante la generación y difusión de saberes y conocimientos con
autonomía y vocación hacia el desarrollo sociocultural para contribuir
fundamentalmente al progreso de la Ciudad de Bogotá y el país [1]. Su finalidad es
generar egresados con capacidad de actuar como protagonistas del cambio social
y de sí mismo, en la formación del espíritu científico aplicado a la indagación,
interpretación y modificación de la realidad y en la contribución a forjar ciudadanos
idóneos para promover el progreso de la sociedad.
La Oficina Asesora de Sistemas (OAS) se encarga del desarrollo, mantenimiento
y soporte del sistema de información de la UDFJC, actuando como una factoría de
software a la medida, la cual se encarga de desarrollar y gestionar soluciones para
los diferentes ámbitos y dependencias de la institución educativa.
Todo esto, implica que se establezcan diversos entornos para el desarrollo de las
diversas soluciones de software, los cuales varían dependiendo del tipo de
producto de software que es este construyendo. Y cada uno de estos entornos
cuenta con un pool de aplicaciones, librerías, Frameworks, etc.
Para llevar a cabo el proceso de despliegue de los entornos de desarrollo la OAS
cuenta con una infraestructura de TI la cual se compone de una colección
heterogénea de elementos tales como servidores, máquinas virtuales, particiones
8
lógicas, enrutadores, dispositivos de almacenamiento, sistemas operativos,
middleware, aplicaciones y servicios. Los cuales deben ser configurados de forma
manual en los host que pertenezcan a cada uno de los proyectos con sus
especificaciones establecidas.
Este proyecto pretende proponer una idea de mejora para la Oficina Asesora de
Sistemas en un proceso de automatización del despliegue de entornos de
desarrollo que facilite la vinculación de un nuevo desarrollador a un grupo de
trabajo o la creación de un nuevo proyecto desplegando de forma más ágil y
controlada los equipos asociados al proyecto. El despliegue de esta solución estará
apoyado por tecnologías de desarrollo libre y bajo el marco de trabajo Scrumban,
comprendiendo procesos de estudio teórico, análisis, diseño y ejecución de
pruebas conceptuales.
9
2. PLANTEAMIENTO DEL PROBLEMA
2.1. Descripción del problema
La Universidad Distrital Francisco José de Caldas cuenta actualmente con 8
plantas físicas las cuales representan las 12 sedes legalmente constituidas en
espacios públicos estatales, que hace parte de la ciudad de Bogotá [2], donde la
comunidad universitaria está en constante crecimiento para hacerle frente a la
demanda de aspirantes que buscan acceder por un cupo en la institución, por este
motivo la UDFJC dentro de su dependencias cuenta con la OAS la cual es la
encargada de gestionar internamente los servicios TI en su infraestructura
tecnológica en búsqueda de contribuir al objetivo institucional de ampliar cada vez
más las oportunidades de acceso a la educación superior [3].
Adicionalmente la función de la OAS a través de los años se ha centrado en el
desarrollo, mantenimiento y soporte del sistema de información de la Universidad
en sus componentes de apoyo a los procesos académicos y administrativos. En
cuanto al primer tipo de procesos, la OAS gestiona el sistema Cóndor y la
Aplicación Académica con sus funcionalidades para los procesos del tránsito de
los estudiantes por la Universidad, y de los procesos de gestión académica de los
proyectos curriculares y las facultades entre otros. [4]
De esta forma la OAS se comporta como una factoría de software a la medida, la
cual provee soluciones viables y pertinentes a la UDFJC en sus diferentes
procesos. Por lo tanto en cada uno de los proyectos en los que esta la OAS, cada
programador desarrolla en local y cada uno es responsable por instalar todos esos
paquetes de software en su máquina, actualizar las versiones, configurar las
librerías, etc.
10
Esto puede llegar a generar situaciones como:
Algo que le funciona a un desarrollador no le funciona a otros
Alguien agregó una nueva librería o cambio la configuración de un software
sin documentarlo, por lo tanto el resto del equipo de desarrollo no sabe del
cambio.
Otro software en la máquina de uno de los desarrolladores está provocando
problemas en la instalación del proyecto.
Algunas de las integraciones que funcionan en el local del desarrollador no
funciona en el momento de publicación o en remoto
Ingresa un nuevo desarrollador en el proyecto y hay que perder un tiempo
prudencial explicando e instalando el entorno de desarrollo.
Este problema se agrava ya que en la OAS se cuenta con más de un desarrollador
por proyecto y usan varias herramientas contando lenguaje de desarrollo, base de
datos, librerías, etc. y además sus versiones. De forma habitual se tiende a generar
un gran abanico de configuraciones, presente en los entornos de desarrollo de
cada uno de los hosts del equipo de desarrollo. A medida que el proyecto crece,
tiene más dependencias y genera mayores problemas.
2.2. Formulación del problema
¿De qué forma se puede implementar una solución que permita la configuración
automatizada y ágil despliegue de entornos para el desarrollo de software dentro
de la OAS?
11
3. JUSTIFICACIÓN
Para poder construir soluciones de software se necesita un equipo de desarrollo,
una metodología, una serie de recursos en hardware como servidores,
ordenadores, dispositivos de almacenamiento, dispositivos incorporados en red,
etc. y una serie de recursos a nivel de software como las bases de datos, IDEs,
Frameworks, librerías, Pods, NuGets, etc. los cuales gracias a los nuevos avances
tecnológicos hacen más sencilla la forma integrar herramientas en la nube,
introduciendo conceptos como PaaS y IaaS los cuales brindan métodos más
versátiles y fáciles de afrontar los nuevos retos a solucionar.
Todo esto hace que las soluciones estén cada vez más cargadas de componentes
de diversas tecnologías aumentando así la cantidad de requisitos para la
construcción de las mismas lo que lleva al departamento de infraestructura de las
compañías a tener que instalar y configurar mayor cantidad de softwares dentro de
los entornos de desarrollo.
La Oficina Asesora de Sistemas, carece de un sistema que gestione el despliegue
de los diferentes entornos de desarrollo de forma eficaz y automatizada, que sea
configurada una única vez y solo baste con que el administrador de la
infraestructura corra una “receta” y el sistema de gestión despliegue las bases de
datos, IDEs, Frameworks, librerías, Pods, NuGets, etc. necesarios para dicho
entorno de trabajo.
Esta solución tecnológica permite reducir el tiempo invertido si se efectuara de
forma individual permitiendo ejecutar una serie de comandos secuenciales en los
dispositivos pertenecientes a un entorno de trabajo en específico. Proporcionando
características relevantes como lo es la habilitación de los puertos de comunicación
de cada una de las aplicaciones o la versión de la aplicación que se va a manejar
dentro del proyecto, generando un estándar para todo el proyecto. Con lo cual a
12
su vez tendera a reducir los errores humanos teniendo en cuenta que el
administrador de la infraestructura, al interactuar solo con una configuración inicial,
tanto el esfuerzo como el tiempo de concentración se reduce radicalmente, sin
permitir que se vuelva una tarea monótona y repetitiva, causal de disminución del
índice de atención.
13
4. OBJETIVOS
4.1. Objetivo general
Implementar una solución que permita la gestión automatizada y despliegue de
entornos para el desarrollo de software dentro de la OAS, basado en una
plataforma que esté soportado en tecnologías de código abierto.
4.2. Objetivos específicos
Realizar el levantamiento de la información relevante de acuerdo a los
criterios de la Oficina Asesora de Sistemas de la Universidad Distrital
Francisco José de Caldas con el objetivo de establecer los requerimientos
del sistema de gestión de entornos de trabajo.
Definir la estructura arquitectónica del sistema de gestión de entornos de
trabajo para el desarrollo de soluciones de software a la medida.
Realizar el diseño y desarrollo del prototipo de entorno de desarrollo
cliente/servidor para el sistema de gestión requerido para satisfacer las
necesidades en cada uno de los procesos dentro del desarrollo de software.
Realizar la documentación del desarrollo del sistema de gestión basado en
los procesos de análisis, diseño y ejecución teniendo en cuenta el marco de
trabajo de la metodología Scrumban.
14
5. DELIMITACIÓN
5.1. Alcances
● El proyecto abarca la fase de planeación, análisis y ejecución del
marco de trabajo Scrumban para el diseño del sistema de gestión.
● El proyecto estará estructurado en 24 iteraciones, 2 iteraciones en la
fase de inicio, 6 iteraciones en la fase de elaboración y 16 iteraciones en la
fase de construcción.
● El equipo de trabajo asumirá en la pasantía el rol corresponde a
desarrollador del sistema de gestión.
● El proyecto estará planteado para un ambiente local, seguro y
replicable con el fin de cumplir con las especificaciones establecidas.
5.2. Limitaciones
● La solución estará basada en los lineamientos del software libre
dando respuesta a políticas distritales e institucionales
● Realizar y documentar el sistema de gestión de acuerdo al diseño
previamente establecido y de acuerdo a la metodología comunicada y
establecida en el proyecto, tomando como marco de trabajo de Scrumban.
15
6. MARCO TEÓRICO
6.1. La metodología Scrumban
Scrumban es una metodología ágil híbrida de Scrum y Kanban originalmente
diseñada como una forma de transición de Scrum a Kanban. Scrumban es un
marco de gestión que surge cuando los equipos emplean Scrum como su forma de
trabajo elegida y utilizan el Método Kanban como una lente a través de la cual ver,
entender y mejorar continuamente su funcionamiento [5].
En Scrumban, el trabajo en equipo se organiza en iteraciones pequeñas y se
supervisa con la ayuda de un tablero visual, similar a los tableros Scrum y Kanban.
Donde se ilustran cada etapa del trabajo, se celebran reuniones de planificación
para determinar qué historias de usuarios se completarán en la siguiente iteración.
Las historias de usuario se agregan al tablero y el equipo las completa, el equipo
trabaja en tan pocas historias de usuarios a la vez como prácticas.
Dentro de la metodología de Scrumban se aplican las prácticas del método Kanban
sobre Scrum utilizando las cinco propiedades intrínsecas de la metodología. Estas
son:
Visualizar el flujo de trabajo: Aquí el énfasis es el manejo del backlog, desde que
se priorizan hasta que se convierten en un incremento del producto. En Scrumban
se trata de visualizar el flujo, aunque se puede llegar a visualizar tareas de forma
opcional dentro del proceso. La visualización de las tareas fluyen durante la
ejecución del sprint no es suficiente para visualizar todo el flujo de valor.
Limitar el Trabajo en Progreso: Esto es medir la capacidad de trabajo que tiene
el equipo en cada estado del desarrollo de software y asignar las tareas de acuerdo
a esta capacidad. De esta manera no se podrán asignar tareas que sobrepasen el
16
límite establecido.
Administrar el flujo de trabajo: Se debe monitorear el flujo de los elementos de
trabajo entre cada estado. Idealmente se busca obtener un alto flujo de trabajo, lo
que indica que el sistema está creando valor rápidamente y reduciendo costos de
retrasos.
Políticas explicitas: Es el acuerdo que establecen las condiciones para el equipo
considere un ítem del backlog como terminado. De esta forma se facilita la forma
evidenciar el flujo de trabajo y el cambio de estados, facilitando que el equipo se
auto-organice alrededor del flujo y los problemas que emerjan para proveer
sugerencias de mejora [6].
Ciclo de retro-alimentación: Permite al equipo de trabajo obtener información
para aprender, validar experimentos y adaptarse rápidamente.
Mejorar la colaboración: El uso de modelos le permite al equipo realizar
predicciones respecto a cómo afectará al proyecto un cambio propuesto, Así, tras
la implementación de una propuesta el resultado puede ser observado mediante la
medición del flujo de trabajo y el análisis de los datos obtenidos.
6.1.1. Scrum
Scrum es un marco de trabajo para el desarrollo y el mantenimiento de productos
complejos desde principios de los años 90. Scrum no es un proceso o una técnica
para construir productos; en lugar de eso, es un marco de trabajo dentro del cual
se pueden emplear varias técnicas y procesos. Scrum muestra la eficacia relativa
de las prácticas de gestión de producto y las prácticas de desarrollo, de modo que
podamos mejorar [7].
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos,
artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve
17
a un propósito específico y es esencial para el éxito de Scrum y para su uso.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las
relaciones e interacciones entre ellos. Las reglas de Scrum se describen en el
presente documento.
Las estrategias específicas para usar el marco de trabajo Scrum son diversas y
están descritas en otros lugares [7].
Scrum se basa en la teoría de control de procesos empírica o empirismo. El
empirismo asegura que el conocimiento procede de la experiencia y de tomar
decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e
incremental para optimizar la predictibilidad y el control del riesgo. Tres pilares
soportan toda la implementación del control de procesos empírico [7]:
Transparencia: Los aspectos significativos del proceso deben ser visibles para
aquellos que son responsables del resultado. La transparencia requiere que dichos
aspectos sean definidos por un estándar común, de tal modo que los observadores
compartan un entendimiento común de lo que se está viendo.
Inspección: Los usuarios de Scrum deben inspeccionar frecuentemente los
artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones. Su
inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las
inspecciones son más beneficiosas cuando se realizan de forma diligente por
inspectores expertos, en el mismo lugar de trabajo.
Adaptación: Si un inspector determina que uno o más aspectos de un proceso se
desvían de límites aceptables, y que el producto resultante no será aceptable, el
proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste
debe realizarse cuanto antes para minimizar desviaciones mayores.
18
6.1.2. Kanban
Kanban es una de las llamadas metodologías ágiles de desarrollo, pues permite
controlar de manera eficaz la producción y documentación de las tareas de
software implementadas en un proyecto.
La metodología Kanban busca adaptarse a los procesos de cambio evolutivos en
las organizaciones. Usa un tablero virtual para visualizar los elementos de trabajo,
generalmente intangibles. De esta manera el flujo de trabajo es entendible para
todos los participantes del proyecto [8].
Una de las ventajas más importante es que limita la cantidad de trabajo en curso,
lo que en un momento dado ayuda a evidenciar en qué áreas del proyecto se
presentan falencias y estimula la colaboración del equipo de trabajo para mejorar
continuamente el sistema. La metodología Kanban se rige por tres principios
fundamentales [9]:
Comenzar con lo que se hace ahora: Kanban no pide que cambie los procesos.
Se basa en el concepto de evolución constante de éstos. No busca implementar
nuevas definiciones de procesos o estilos de trabajo.
Acordar con todo el equipo perseguir el cambio evolutivo e incremental: El
equipo de trabajo debe ser consciente de que es necesario el mejoramiento
continuo, de lo contrario la metodología Kanban no podrá ser implementada con
éxito.
Respetar los procesos, roles y responsabilidades: Este aspecto es importante,
pues al sentir que tienen un lugar y son respaldados por el equipo de trabajo los
miedos al cambio se reducirán, puesto que responsabilidades, roles y procesos
estarán bien definidos.
19
6.2. Docker
Es un proyecto de código abierto, que permite el despliegue de aplicaciones dentro
de contenedores los cuales empaquetan todo lo necesario para que uno o más
procesos funcionen con todas sus dependencias, es decir, con todo lo que necesita
para poder ejecutarse, como el código, herramientas del sistema y librerías del
sistema, etc. Esto garantiza que siempre se podrá ejecutar, independientemente
del entorno en el que se quiera desplegar, bastando únicamente con tener
instalado Docker dentro de la otra máquina, sin tener problemas con el entorno de
ejecución.
Debido a que Docker funciona de forma nativa en entornos Linux a partir de la
versión 3.8 del Kernel y está basado en estándares abiertos, se puede ejecutar en
la mayoría de las principales distribuciones de Linux y en algunas distribuciones de
Microsoft. Es seguro debido a que las aplicaciones de los contenedores están
aisladas entre sí con lo cual le brinda una capa adicional de protección para cada
aplicación [10].
Su uso es ligero, porque todos los contenedores se ejecutan en una sola máquina
compartiendo el mismo núcleo del sistema operativo anfitrión y así genera un uso
eficiente de la memoria RAM.
Docker es una herramienta portátil, debido a que las imágenes de los contenedores
requieren menos espacio de almacenamiento y en consecuencia el despliegue de
los contenedores es rápido [11].
Las características principales de los contenedores son las siguientes: El tiempo
de ejecución es rápido, la capacidad para desarrollar, probar e implementar las
aplicaciones es muy eficiente y pueden interconectarse entre ellos [12].
20
6.2.1. Contenedor Vs Máquina virtual tradicional
Desde antes que aparezca el Cloud Computing, ya se utilizaba la virtualización para
el aprovisionamiento de recursos de computación [13]. El enfoque arquitectónico de
Docker es diferente al de las máquinas virtuales tradicionales, siendo la portabilidad
el punto más importante de su uso, debido a que son más fáciles de transportar.
Como se puede observar en la Figura 1 está la arquitectura de una máquina virtual
tradicional donde se aloja toda la virtualización en el sistema operativo invitado
donde se alojan las diferentes librerías y aplicaciones, con lo cual se tendría que
disponer de un gran tamaño de almacenamiento en la máquina anfitriona [10].
Figura 1: Arquitectura de Máquina virtual tradicionales Fuente: [10]
A diferencia de las máquinas virtuales, los contenedores de Docker pueden ser
vistos como herramientas más flexibles para el empaquetamiento, entrega y
despliegue del software y de sus aplicaciones.
Como se puede observar en la Figura 2, la arquitectura de un contenedor de Docker
está conformado por las librerías y la aplicación con su respectiva dependencia,
21
pero a diferencia de la máquina virtual, todos los contenedores comparten el mismo
Kernel de la máquina anfitriona. Cada uno de los contenedores posee su propio
espacio de usuario en el sistema operativo anfitrión y se ejecutan en cualquier
ordenador, en cualquier infraestructura y en cualquier nube que tenga desplegado
el motor de Docker Engine [10].
Figura 2: Arquitectura de contenedores de Docker. Fuente: [10]
Debido a que los contenedores comparten el núcleo de Linux, son mucho más
ligeros que las máquinas virtuales. En un ordenador típico, podrían funcionar pocas
máquinas virtuales a la vez, pero no se tendrían problemas para ejecutar 100
contenedores Docker. Esta característica ha hecho que Docker sea atractivo para
el sector empresarial y aumente su inmensa popularidad [14].
El núcleo de los contenedores se basa en los namespaces y cgroups de Linux, con
ello se permite aislar el conjunto de los puntos de montaje del sistema de ficheros
[15]. Esto quiere decir que dentro de un contenedor, se ejecutar únicamente las
aplicación cuyos namespaces este asociada a este contenedor a pesar de que se
encuentren desplegados más contenedores dentro de la misma máquina
22
anfitriona.
6.2.2. Contenedores como Servicio (CaaS)
Los contenedores como Servicio (Container as a Service) son unos de los tipos de
servicios que ofrece Docker, el cual proporciona agilidad, control y portabilidad,
para construir un gran número de contenedores, en los cuales se puede alojar
diferentes aplicaciones que pueden ser ejecutadas en cualquier lugar [16].
CaaS se encuentra en un punto intermedio entre el IaaS y el PaaS. Puesto que el
concepto de CaaS dispone de contenedores por demanda. Donde el CaaS puede
cumplir con las necesidades cubiertas por el IaaS ya que no se necesitaría de un
hardware virtualizado en el concepto de contenedores y también se puede pensar
en cubrir al PaaS, ya que los contenedores se utilizan para implementar el producto
final simulando una plataforma de servicio.
El uso de CaaS con Docker, ofrece la libertad de definir el entorno en el que se van
a utilizar los contenedores. De esa manera, se puede crear y desplegar las
aplicaciones de manera fácil y rápida, con lo cual se podrá responder rápidamente
a los cambios que se presenten dentro del entorno de trabajo.
Los usuarios tienen el control total, debido a que cuentan con la capacidad de
administrar y operar de forma segura la escalabilidad de los contenedores.
Además, Docker ofrece portabilidad en todo el ciclo de los contenedores, porque
pueden ser desplegados en diferentes entornos que soporten esta tecnología.
6.2.3. Imágenes en Docker
Las imágenes en Docker son como una representación de un sistema operativo
base la cual dependiendo de la imagen cuenta con aplicaciones instaladas. Sobre
esta base se puede empezar a añadir aplicaciones que se vayan a necesitar en
23
otro equipo donde se tenga la intención de usar dicha imagen. Además Docker
ofrece una forma muy sencilla de actualizar las imágenes estén ya creadas, así
como un sencillo método para crear nuevas imágenes [17].
6.3. DockerHub
DockerHub, es el servidor de registros oficial de Docker, en donde se alojan en la
nube las imágenes creadas por diferentes usuarios y desde este servidor se
descargan las imágenes base para crear los contenedores, almacena imágenes
enlaces a Docker para que se puedan desplegar en cualquier host que tenga
instalado Docker. En la figura 3 se puede observar la pantalla de inicio dentro de
DockerHub iniciando con un usuario y contraseña se pueden buscar las distintas
imágenes disponibles.
Figura 3: Vista principal de DockerHub. Fuente: [18]
Además DockerHub proporciona un recurso centralizado para el descubrimiento,
distribución y gestión de cambio de las imágenes, también cuenta con la
colaboración por parte de la comunidad y equipos de expertos.
DockerHub ofrece las siguientes características principales:
24
Repositorios de imágenes: Se pueden buscar y extraer imágenes de
bibliotecas comunitarias, oficiales y bibliotecas de imágenes privadas a las
que tenga acceso.
Generaciones automatizadas: Se pueden crea automáticamente nuevas
imágenes cuando realiza cambios en un repositorio de código fuente.
Organizaciones: Se pueden crear grupos de trabajo para administrar el
acceso a los repositorios de imágenes.
Integración con GitHub: Se pueden agregar los Hubs y sus imágenes de
Docker con los diferentes softwares para control de versión y flujos de
trabajo.
6.4. Docker-Compose
Docker-Compose, es una herramienta que define y ejecuta varios contenedores de
Docker utilizando un archivo en el formato yml, en el cual se definen todas las
configuraciones de los contenedores que se van a ejecutar.
6.5. Docker-Machine
La herramienta Docker Machine, se utiliza para instalar Docker Engine en uno o
más sistemas virtuales, pueden ser locales o remotos. Esta herramienta es muy
utilizada por los usuarios que tienen el sistema operativo Windows o OS X.
25
7. METODOLOGÍA
Para el desarrollo de este proyecto se tomó como marco de trabajo la metodología
Scrumban, debido a que este proyecto no es como tal un proyecto de desarrollo
de software si no la implementación de una herramienta que permita la gestión de
entornos para el desarrollo de software.
En el desarrollo de la metodología se tuvieron en cuenta varios aspectos para la
realización del proyecto.
Inicialmente se llevó a cabo un estudio teórico (obtenido de la documentación
oficial, artículos virtuales, páginas web, foros, etc.) detallado de la solución a
implementar dicho estudio se plasmó dentro del Marco teórico de este documento.
Posteriormente teniendo en cuenta el proceso de análisis, diseño y desarrollo
establecido en la respectiva metodología, se realiza el desarrollo mediante tres
fases, las cuales indican de manera secuencial los procedimientos. Dichas fases
son:
La fase de análisis en donde se hace un acercamiento al estado actual de la OAS
y una comparación de Docker con otra solución, para así llegar a la conclusión de
que Docker es la mejor opción para el desarrollo de este proyecto.
Luego de especificar lo anterior, se realizó la fase de diseño del proyecto el cual
se puede denominar como experimental, debido a que al identificarse las variables
estudiadas, se realizó uso y control de estas, para llevar a cabo la fase final de
ejecución en donde se configuran y despliegan los contenedores que va a
representar los entornos para el desarrollo de software.
26
La metodología Scrumban permite visualizar el progreso del desarrollo mediante
un tablero el cual muestra el estado de las tareas, para esto se utilizó un tablero
virtual en una plataforma libre y abierta como fuente para la gestión ágil del mismo.
Para la realización del tablero de Scrumban es necesario definir las tareas dentro
del sprint backlog en la tabla 1 se puede evidenciar las tareas determinadas dentro
del backlog las cuales se le da un peso dependiendo del tiempo que lleva la
realización de la misma
Tabla del Sprint Backlog:
Tareas Hrs. Puntos
Instalación de la herramienta
Revisión de la documentación oficial de Docker 8 1
Instalación de Docker CE 2 0,25
Configuración inicial de la herramienta 2 0,25
Instalación de Docker-Compose 2 0,25
Pruebas de la herramienta 4 0,5
Construcción de un entorno de desarrollo
Construcción del docker-compose.yml inicial 2 0,25
Empaquetado del proyecto 2 0,25
Adición de Angular en el docker-compose.yml 4 0,5
Construcción del Dockerfile para Angular 4 0,5
Construcción de la carpeta de Angular 8 1
Pruebas de despliegue de Angular 4 0,5
Adición de Beego en el docker-compose.yml 4 0,5
Construcción del Dockerfile para Beego 8 1
Construcción de la carpeta de Beego 4 0,5
Pruebas de despliegue de Beego 4 0,5
Adición de MongoDB y Mongo-Express en el docker-compose.yml 8 1
Integración de Angular y Beego con MongoDB 8 1
Construcción del Dockerfile para Mongo 4 0,5
Construcción del Dockerfile para Mongo-Express 4 0,5
Pruebas de despliegue de MongoDB 2 0,25
Pruebas de despliegue del entorno completo 2 0,25
Tabla 1: Sprint Backlog. Fuente: Propia.
27
Ya con el backlog establecido se procede a realizar el tablero de Scrumban el cual
para su utilización es necesario la creación de un equipo dentro de la herramienta
y el tablero, el cual tendrá diferentes listas que determinan el estado en el que se
encuentran las tareas, además de poder asociar al grupo involucrado en su
desarrollo, de esta forma se podrá evidenciar el trabajo que cada uno tenga y los
esfuerzos en su progreso.
En la Figura 4 se puede evidenciar el estado de uno de los tableros en donde la
lista marcado como To Do son las tareas que faltan por realizar por el equipo de
trabajo, en Doing las tareas en proceso de desarrollo y en Done las tareas
finalizadas satisfactoriamente.
Figura 5: Tablero de Scrumban del Proyecto. Fuente: Propia
28
8. FASE DE ANÁLISIS
8.1. Estado actual
La Oficina Asesora de Sistemas (OAS) al tener como función principal planear,
proponer e implantar la sistematización de la información de actividades, procesos
y tareas institucionales en las diferentes dependencias con miras de agilizar el
funcionamiento administrativo, operativo y de planeación de La Universidad
Distrital Francisco José de Caldas [3], se encarga de velar por el funcionamiento
del centro de datos y servidores, estableciéndose como uno de los proveedores de
servicios de TI de la institución el cual debe monitorear, operar y controlar de forma
continua dichos servicios, para reducir costes y riesgos y aumentar el tiempo de
actividad.
Por otra parte, la Oficina Asesora de Sistemas se está desempeñando como una
factoría de software a medida, con lo cual cuenta con un equipo de 22
programadores los cuales se mueven en diferentes ámbitos de desarrollo, por esta
razón el grupo de infraestructura cuenta con un ecosistema digital el cual debe
proporcionar la configuración y el tuning de los diferentes servidores y el hardening
de servidores asegurando el sistema mediante la reducción de sus
vulnerabilidades.
Dentro de su infraestructura la OAS cuenta con dos servidores de virtualización y
un sistema de almacenamiento mediante OVirt y Oracle VM (OVM), también
cuenta con una nube hibrida, la cual está constituida con OVirt en su parte privada,
con Amazon (AWS) en su parte pública y se comunican por medio de una nube
virtual privada (VPC) con una sola subred privada y una puerta de enlace privada
virtual para habilitar la comunicación con su propia red a través de un túnel
VPN/VPC
29
8.2. Comparación con Vagrant
Vagrant es una herramienta para gestionar máquinas virtuales. Por ello, Vagrant
se ejecuta sobre Virtual Box, VMware, u otras máquinas virtuales. Y como
aprovisionamiento de dicha máquina se puede utilizar Puppet, Chef o incluso un
contenedor de Docker [19].
Por el contrario Docker no necesita ejecutarse sobre una máquina virtual, se
ejecuta directamente sobre una máquina Linux, ya que sirve para crear
contenedores y ejecutar tus aplicaciones en dichos contenedores. En la tabla 2 se
puede observar una comparación entre estas dos plataformas en una serie de
factores en común para coda una de ellas y su desempeño.
Tabla Comparativa:
CARACTERÍSTICA DOCKER VAGRANT
Tipo de virtualización Contenedores VM
Recursos a nivel de hardware No Si
Plataformas compatibles Linux únicamente Linux, Unix, Windows
Tiempo de creación Menos de 10 min Más de 10 min
Tiempo de arranque Segundos Minutos
Nivel de aislamiento Débil Muy alto
Impacto en el sistema anfitrión Muy Bajo Alto
Tamaño de los sistemas virtuales creados
Muy ligero Pesado, pero mejor que
una VM completa
Cantidad de recursos a la vez Más de 50 Menos de 10
Curva de aprendizaje Suave Elevada
Tabla 2: Tabla comparativa entre Docker y Vagrant. Fuente: [19]
30
Para el desarrollo de este proyecto el uso de contenedores para el despliegue de
un entorno es la opción más viable, ya que al ser un componente más del ciclo de
desarrollo, aportan múltiples ventajas como gran flexibilidad para trabajar en
diferentes proyectos o probar tecnologías nuevas de una forma ágil.
8.3. Arquitectura de Docker
Docker usa una arquitectura de cliente-servidor, en donde el cliente se comunica
con el demonio de Docker, que sería la parte del servidor y se encarga de la
construcción, funcionamiento y distribución de los contenedores. El cliente y el
demonio de Docker, se pueden ejecutar en el mismo sistema o también conectar
un cliente a un demonio Docker que se encuentre a distancia, esta comunicación
se realiza a través de sockets o de un API REST.
La Figura 6 representa un ejemplo de la arquitectura de Docker donde se puede
evidenciar que el demonio de Docker actúa como el servidor central, que trabaja
con las imágenes y los contenedores. El cliente se comunica con el demonio,
enviándole órdenes a través de comandos [20].
Figura 7: Arquitectura de Docker. Fuente: [20]
31
En la arquitectura de Docker, existen tres recursos muy importantes, que son las
imágenes, los registros y los contenedores de Docker. Las imágenes al ser
plantillas de sólo lectura equivalen al punto de partida para crear contenedores, es
decir, desde una imagen de Docker, se pueden generar miles de contenedores y
cada uno de ellos se encuentra completamente aislado. Una diferencia clave entre
las imágenes Docker y las máquinas virtuales, es que las imágenes Docker
comparten el núcleo de Linux con la máquina anfitriona. Para el usuario final, la
consecuencia principal de esto, es que cualquier imagen Docker, debe basarse en
un sistema compatible con Linux.
Docker ofrece el servicio DockerHub [18], que es el componente oficial de la
distribución de imágenes de Docker registradas y la creación de una cuenta es
gratuita.
A partir de una imagen de Docker, se pueden crear un gran número de
contenedores, los cuales se encuentran completamente aislados y seguros. En los
contenedores Docker, se instala y configura todo lo que se necesita para que las
aplicaciones se ejecuten satisfactoriamente.
8.4. Funcionamiento de Docker
El funcionamiento de Docker está estructurado en tres pasos, En la Figura 8, se
puede observar su estructura, la cual está conformada por la construcción de
entorno de desarrollo, el despliegue y él envió de los contenedores, dependiendo
la finalidad del contenedor se puede determinar su funcionalidad, cómo se elabora,
cómo se comparten los contenedores y en qué momento se ejecutan.
32
Figura 9: Esquema del funcionamiento de Docker. Fuente: [21]
En el primer paso (construcción), Docker permite construir las aplicaciones, en los
entornos de desarrollo, sin tener preocupación por la plataforma o el lenguaje en
que se encuentren desarrolladas las aplicaciones.
Como base se utilizan las imágenes que se encuentran alojadas en los repositorios
de Docker. Para la creación de una imagen de Docker, se puede utilizar Dockerfile,
que es un fichero en el cual se describe todo el procedimiento, mediante una serie
de instrucciones con las cuales se crea una imagen. La ejecución del Dockerfile,
se inicia con la descarga de la imagen base desde el servidor DockerHub, en caso
de que no se tenga descargada la imagen. Luego se procede a añadir los paquetes
de software a instalar y si se desea la ejecución de comandos adicionales.
La construcción de una imagen utilizando un Dockerfile, es comparable a la
instalación de una nueva máquina desde cero, que puede tomar desde minutos
hasta horas, dependiendo del número de capas implicadas. Sin embargo, el
tamaño de un Dockerfile es bastante pequeño (de 1 KB o menos) y se transfiere
fácilmente a través del sistema [6]. También existe la opción de crear imágenes de
33
Docker, a partir de contenedores desplegados.
El segundo paso (despliegue), en donde solo se necesita de tener instalado Docker
en el Host deseado para ejecutar y desplegar un contenedor con todos sus
servicios y aplicaciones ya configurados. Docker puede ejecutar cualquier
aplicación y en cualquier lugar, ya que es independiente del entorno en que se
desplieguen los contenedores [16].
Finalmente, en el tercer paso (envió), Docker permite mediante su herramienta de
DockerHub registrar el nuevo contenedor creado, el cual va a representar una
imagen base en el momento en se aloje en el servidor oficial de Docker. Para de
esta forma estas nuevas imágenes estén disponibles para todos los usuarios
dependiendo de la privacidad que se le dé a esta imagen, puede estar de dominio
público o con privilegios de seguridad para que solo ciertos usuarios puedan
acceder a esta imagen.
34
9. FASE DE DISEÑO
La Figura 10 representa un esquema de la arquitectura lógica que poseen los
entornos de trabajo, donde se pueden observar los diferentes contenedores de
Docker así como la implementación de bases de datos que van ligadas a ellos.
Figura 11: Esquema general de la arquitectura. Fuente: Propia
A continuación en la Figura 12 se puede observar el esquema de funcionamiento
el cual refleja los pasos que se dan en el interior de la aplicación cuando un usuario
realiza una petición a través de la interfaz.
35
Figura 13: Esquema de funcionamiento. Fuente: Propia
En este esquema se ve como recorre la información cuando se requiere de la
funcionalidad de alguno de los contenedores de Docker, teniendo en cuenta que
el tipo de petición es HTTP y el contenido del archivo es JSON
36
10. FASE DE EJECUCIÓN
10.1. Instalación de la plataforma
Este flujo de trabajo cubre la preparación de la maquina host donde se va a
establecer la plataforma de gestión de entornos con Docker, para ello ingresamos
a una terminal de modo súper-administrador del sistema, al archivo hosts para
configurar el FQDN del equipo en donde se establece el dominio que se va a alojar
en el servidor de configuración con el siguiente dato:
10.20.0.139 docker.localdomain.local docker
Igualmente se configura el archivo del hostname:
docker.localdomain.local
Luego se verifica que este bien configurado el FQDN del equipo y que no haya
ninguna incongruencia con el siguiente comando, el cual nos indica todas las
especificaciones de nuestro host:
# hostnamectl status
37
10.1.1. Docker Engine
Existen dos tipos de ediciones de Docker, las cuales son:
Docker EE (Enterprise Edition): Esta edición incluye la plataforma Docker,
soporte, certificación y características adicionales como la gestión de contenedores
(Docker Datacenter) y Docker Security Scanning.
Docker EE está soportado por compañías como Alibaba, Canonical, HPE, IBM,
Microsoft y por una red de socios regionales. Aquellos que quieran probar Docker
EE pueden descargar una versión de prueba gratis desde el sitio oficial [21].
Docker CE (Community Edition): Docker Engine ha sido renombrado a Docker
CE, la cual es una versión de Docker de la comunidad que está disponible
gratuitamente.
La edición comunitaria está disponible en dos versiones, la versión Edge la cual se
publica cada mes con las últimas características y recibe actualizaciones de
seguridad y correcciones de errores para la versión actual. Y la versión Stable la
cual se publica trimestralmente y obtiene actualizaciones similares durante cuatro
meses después de la versión inicial. Este ciclo de actualización proporciona a los
usuarios una ventana lo suficientemente grande como para planificar
actualizaciones de versiones anteriores [21].
Aunque las dos ediciones de Docker están dirigidas a diferentes audiencias, no hay
mucha diferencia, tanto Docker EE como CE se basan en el proyecto Open Source
Docker. Por lo tanto, para este proyecto se procede a utilizar la edición comunitaria
en una maquina host con sistema operativo CentOS 7 desplegada en la plataforma
de virtualización Open Source Ovirt.
Inicialmente se procede a verificar que no hallan instaladas versiones anteriores de
Docker con los siguientes comandos:
38
# yum remove docker \
docker-common \
docker-selinux \
docker-engine
Preparar el repositorio
Antes de instalar Docker CE por primera vez en la máquina host, se debe configurar
el repositorio Docker, instalando los paquetes requeridos con el siguiente comando,
el cual proporciona la utilidad yum-config-manager. Y device-mapper-persistent-
data y lvm2 son requeridos por el controlador de almacenamiento del mapeador de
dispositivos:
# yum install -y yum-utils device-mapper-persistent-data lvm2
Posteriormente se utiliza el siguiente comando para configurar el repositorio de la
versión Stable de Docker CE.
# yum-config-manager --add-repo Https://download.docker.com/linux/centos/docker-ce.repo
Instalar Docker CE
Ya configurado el repositorio de Docker se actualiza el índice de paquetes yum por
primera vez desde la adición de los repositorios de Docker [22].
# yum makecache fast
39
Después de correr el anterior comando, el sistema solicita que acepte la clave GPC
y muestra la huella digital de la clave 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B
621E 9F35. Posteriormente se instala la última versión de Docker CE [22].
# yum install docker-ce
Se verifica la versión de Docker CE, con el siguiente comando:
# docker --version
Para iniciar el demonio de Docker se usa el siguiente comando:
# systemctl start Docker.service
Como se desea que el demonio de Docker inicie cuando se encienda la maquina
host se ingresa el siguiente comando:
# systemctl enable Docker.service
Finalmente se agrega el usuario actual de la sesión de CentOS 7 al grupo de
acoplador con el siguiente comando:
# usermod -aG Docker $(whoami)
40
10.1.2. Docker Compose
Para poder instalar Docker Compose es necesario tener instalado Docker
previamente, lo primero que se hace es instalar Python-pip con el siguiente
comando [23]:
# yum install epel-release
# yum install -y python-pip
Posteriormente se instala Docker Compose mediante pip, utilizando el siguiente
comando:
# sudo pip install docker-compose
Para finalizar la instalación de Docker Compose es necesario actualizar los
paquetes de Python en CentOS 7 para que el Docker Compose funcione
correctamente [23].
# yum upgrade Python*
Por último, se verifica la versión de Docker Compose, con el siguiente comando:
# docker-compose --version
41
10.1.3. Docker Machine
Para poder instalar Docker Machine es necesario tener instalado Docker
previamente, lo que se hace es descargar el repositorio de Docker Machine y
extraerlo en el PATH con el siguiente comando [24]:
# curl -L https://github.com/docker/machine/releases/download /v0.12.2/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine # chmod +x /tmp/docker-machine
# sudo cp /tmp/docker-machine /usr/local/bin/docker-machine
Posteriormente se verifica la versión de Docker Machine, utilizando el siguiente
comando:
# docker-machine version
10.2. Dockerfile
Dockerfile es el archivo base de Docker el cual contiene toda la serie de
instrucciones de forma secuencial para construir la imagen del contenedor, los
Dockerfile tienen algunas palabras reservadas como:
FROM: indica la imagen base a partir de la cual se va a construir la imagen
del contenedor.
MAINTAINER: documenta el creador de la imagen.
ENV HOME: establece el directorio HOME que usarán los comandos RUN.
RUN: permite ejecutar una instrucción en una terminal dentro de la imagen
del contenedor en construcción.
42
ADD: permite añadir un archivo dentro de la imagen del contenedor en
construcción.
VOLUME: establece los puntos de montaje externalizando un determinado
directorio y proporcionando persistencia (las imágenes de Docker son de
solo lectura y no almacenan datos entre diferentes ejecuciones).
EXPOSE: indica los puertos TCP/IP por los que se pueden acceder a los
servicios de la imagen del contenedor en construcción.
CDM: establece el comando del proceso de inicio que se usará si no se
indica uno al iniciar un contenedor con la imagen.
10.3. Docker-Compose.yml
Este es el archivo donde se define toda la estructura de las aplicaciones y el que
va a utilizar Docker Compose para lanzar todos los contenedores que se necesiten
con los comandos adecuados según su configuración dentro del Dockerfile de cada
uno de los contenedores. Este archivo por cuestiones de buenas prácticas y a la
hora de montar volúmenes lo mejor es que esté en la raíz del proyecto.
Lo primero que se tiene que tener en cuenta es la versión de este documento
donde la versión 3 cuenta con el uso de volúmenes y las redes, a parte de la clave
de versión, este archivo puede tener otras tres claves principales:
Services: dentro de esta clave se definen los servicios que van a tener la
aplicación.
Volumes: dentro de esta clave se permite enlazar un directorio local con un
directorio dentro del contenedor.
43
Networks: dentro de esta clave se definen las redes que se van a crear y
se van a usar por la aplicación.
Build: dentro de esta clave se indica que imagen de Dockerfile tiene que
utilizar. Con la notación . leerá el fichero Dockerfile del directorio principal
donde se encuentre el fichero docker-compose.yml
Command: dentro de esta clave se indica que comando tiene que
ejecutarse al correr el contenedor.
Docker Compose crea una red por defecto para cada grupo de servicios que
forman la aplicación si no se define la clave principal “Networks”. Todos los
contenedores que forman la aplicación estarán en la misma red y serán accesibles
a través de su IP.
44
11. RESULTADOS Y DISCUSIÓN
Para la prueba del prototipo se realizó la configuración de un entorno de desarrollo
planteado de la siguiente forma
Figura 14: Diagrama de despliegue del prototipo. Fuente: Propia
En la Figura 15 se puede observar el diagrama de despliegue del entorno de
desarrollo en el cual se muestra las imágenes de Docker necesarias para
establecer el servicio del entorno.
El usuario accede desde el navegador web al alojamiento host de forma local a
través de los puertos 8081 para Beego, 8000 para MongoDB, 4200 para Angular y
8088 para Swagger-editor.
45
La base de datos utilizada fue MongoDB. Esta base de datos se configura
automáticamente durante la construcción del proyecto y hace parte del volumen de
datos.
La estructura del proyecto es la siguiente:
- Development
- docker-compose.yml
- angular
- code
- Dockerfiel
- Beego
- code
- Dockerfile
- mongo
- Dockerfile
- mongo-express
- Dockerfile
El archivo docker-compose.yml
version: '3'
services:
angular:
container_name: "angular"
build: ./angular
volumes:
- "./angular/code:/angular/code"
ports:
46
- "4200:4200"
beego:
container_name: "beego"
build: ./beego
volumes:
- "./beego/code:/go/src/code"
ports:
- "8081:8080"
mongodb:
image: mongo
expose:
- "27017"
environment:
MONGO_INITDB_ROOT_USERNAME: sistemasoas
MONGO_INITDB_ROOT_PASSWORD: sistemasoas
mongo-express:
container_name: "mongo-express"
image: mongo-express
restart: on-failure
ports:
- "8000:8081"
depends_on:
- mongodb
environment:
ME_CONFIG_MONGODB_SERVER: mongodb
ME_CONFIG_MONGODB_ADMINUSERNAME: sistemasoas
ME_CONFIG_MONGODB_ADMINPASSWORD: sistemasoas
ME_CONFIG_MONGODB_ENABLE_ADMIN: "true"
swagger-editor:
container_name: "swagger-editor"
47
image: swaggerapi/swagger-editor
ports:
- "8088:8080"
El archivo Dockerfile de angular
FROM node
RUN npm config set proxy http://10.20.4.15:3128
RUN npm config set https-proxy http://10.20.4.15:3128
RUN npm install --unsafe-perm -g @angular/cli
COPY code/ /angular/code
WORKDIR /angular/code
CMD ng serve --host 0.0.0.0
El archivo Dockerfile de mongo
FROM mongo
ENV MONGO_INITDB_ROOT_USERNAME sistemasoas
ENV MONGO_INITDB_ROOT_PASSWORD sistemasoas
El archivo Dockerfile de mongo-express
FROM node
RUN npm install -g mongo-express
CMD mongo-express -u admin -p admin -d admin -H mongodb
El archivo Dockerfile de Beego
48
FROM golang:1.7
RUN git config --global http.proxy http://10.20.4.15:3128
RUN go get -u github.com/astaxie/beego
RUN go get -u github.com/beego/bee
RUN go get -u github.com/dgrijalva/jwt-go
RUN http_proxy=10.20.4.15:3128 go get -v gopkg.in/mgo.v2
COPY code/ /go/src/code
WORKDIR /go/src/code
CMD bee run
Para construir los contenedores pertenecientes al entorno de desarrollo se corre el
siguiente comando
# docker-compose build
49
Figura 16: Construcción de los contenedores de forma exitosa. Fuente: Propia
Y después el siguiente comando para desplegarlo:
# docker-compose up
Figura 17: Despliegue exitoso del entorno de desarrollo. Fuente: Propia
50
Ya desplegado el entorno de desarrollo, se puede acceder desde el browser a cada uno de los contenedores de la siguiente forma:
Figura 18: Beego localhost: 8081. Fuente: Propia
Figura 19: MongoDB localhost: 8000. Fuente: Propia
51
Figura 20: Swagger localhost: 8088. Fuente: Propia
En las figuras 13, 14 y 15 se pueden observar los servicios de Beego, MongoDB y
Swagger corriendo respectivamente dentro de los contenedores de Docker de
forma local dentro del host lo cual permite visualizar el alcance que tiene el uso de
los contenedores de Docker como gestor de entornos de desarrollo.
Ya que se configura una sola vez el entorno de trabajo estableciendo las
herramientas, integraciones, librerías y configuraciones necesarias para el correcto
funcionamiento del entorno de trabajo. El cual puede ser replicado de forma
automática para todos los desarrolladores de un proyecto, dejando atrás la
instalación y configuración de forma manual el todos estas herramientas
necesarias para que un host pueda trabajar dentro de los proyectos de la OAS
Mejorando así el tiempo de vinculación de un host a un proyecto, además de
estandarizar la versión de todas las herramientas teniendo la certeza que va a
funcionar de forma óptima en todos los equipos dentro de un proyecto, sin importar
la cantidad de equipos vinculados al mismo.
52
12. CONCLUSIONES
La correlación de soluciones de software en una organización permite generar
agilidad de los procesos a trabajar, así como mejorar la calidad y rendimiento de
los mismos. De igual manera, permite el fácil intercambio de información, útil en el
momento de despliegue y producción del software. Por lo tanto al automatizar la
gestión de despliegue de entornos de trabajo para la construcción de software
permite agilizar una serie de procesos operativos, enfocando el tiempo en el
desarrollo de soluciones que brinde apoyo a la comunidad institucional.
El desarrollo de esta plataforma permitirá realizar pruebas a nuevas tecnologías de
forma eficientemente y a menor costo, al igual que permite tener un mayor control
sobre los entornos de trabajo, con la posibilidad de modificarlos de manera más
sencilla cumpliendo con nuevos requerimientos por parte de nuevos desarrollos.
Docker permite desplegar entornos de trabajo de una forma ágil definiendo la
estructura del entorno de trabajo en un archivo docker-compose.yml y definiendo
en cada contenedor un archivo Dockerfile, que luego se puede trasladar fácilmente
el entorno de desarrollo a producción, pruebas o cualquier otro entorno de trabajo.
Una de las características más importantes que se puede observar en el desarrollo
de este proyecto es la independencia entre contenedores lo cual permite optimizar
al máximo las ventajas que ofrece el modelo arquitectónico CaaS.
53
13. TRABAJOS FUTUROS
13.1. Integración con un sistema de gestión de configuración
Una buena línea de investigación puede ser la integración de Docker como
despliegue de entornos de trabajo con un sistema de gestión de configuración
como Puppet, Chef, Foreman, Ansible, SaltStack o CFEngine los cuales pueden
desplegar un host dentro de una máquina virtual Y de esta forma correr el archivo
.yml de Docker para el despliegue del entorno de desarrollo.
54
14. GLOSARIO DE TÉRMINOS
CaaS: Acrónimo de (Container as a Service) Contenedores como Servicio.
CentOS: (Community ENTerprise Operating System) Es un sistema operativo
producto basado en la distribución Linux Red Hat Enterprise Linux RHEL,
diferenciándose con este por la remoción de todas las referencias a las marcas y
logos propiedad de Red Hat.
Docker: Plataforma de contenedores de software.
Dockerfile: Archivo con instrucciones para construir una imagen de Docker de
forma automática.
DockerHub: Sitio con repositorios oficiales de Docker.
FQDN: Es un nombre que incluye el nombre de un host y el nombre de dominio
asociado a este.
IaaS: Acrónimo de (Infrastructure as a Service) Infraestructura como Servicio.
Máquina Virtual: Es un software que simula a un ordenador y puede ejecutar
programas como si fuese un ordenador real.
MongoDB: Base de datos de código abierto orientada a documentos.
OAS: Acrónimo de Oficina Asesora de Sistemas. Órgano de la Universidad Distrital
Francisco José de Caldas.
55
PaaS: Acrónimo de (Platform as a Service) Plataforma como servicio.
RPM: Es una herramienta de administración de paquetes pensada básicamente
para GNU/Linux. Es capaz de instalar, actualizar, desinstalar, verificar y solicitar
programas. RPM es el formato de paquete de partida del Linux Standard Base.
TI: Acrónimo de tecnología de la información.
UDFJC: Acrónimo de Universidad Distrital Francisco José de Caldas
56
15. BIBLIOGRAFÍA
[1] «Misión de la Universidad distrital Francisco José de caldas,» Universidad
distrital Francisco José de caldas, [En línea]. Available:
https://www.udistrital.edu.co/#/universidad.php.
[2] «Distribución espacial de la Universidad distrital Francisco José de caldas,»
Universidad distrital Francisco José de caldas , [En línea]. Available:
https://www.udistrital.edu.co/index.php#/universidad.php.
[3] «Objetivo de la Oficina Asesora de Sistemas,» Universidad Distrital Francisco
José de Caldas, 2008. [En línea]. Available:
https://portalws.udistrital.edu.co/oas/.
[4] Universidad Distrital Francisco José de Caldas, «Plan Maestro de Informática
y Telecomunicaciones 2012 - 2018,» Bogota, 2012.
[5] lean software engineering, «Scrum-ban,» 26 10 2010. [En línea]. Available:
http://leansoftwareengineering.com/ksse/scrum-ban/.
[6] C. Zheng and D. Thain, «Integrating Containers into Workflows,» in
Proceedings of the 8th International Workshop on Virtualization Technologies
in Distributed Computing, 2015.
[7] K. Schwaber y J. Sutherland, «La Guía Definitiva de Scrum: Las Reglas del
Juego,» Scrum.Org, 2013.
[8] K. Scotland, «Aspects of Kanban,» Methods & Tools, 2017. [En línea].
Available: http://www.methodsandtools.com/archive/archive.php?id=104.
[9] D. J. Anderson, «Kanban: Successful Evolutionary Change for Your
Technology Business,» Kanban Group, 2010.
[10] Dockercon17, «Docker Project official website,» 2017. [En línea]. Available:
https://www.docker.com/what-docker.
[11] B. Varghese, L. T. Subba, L. Thai, and A. Barker, «Container-Based Cloud
Virtual Machine Benchmarkin,» IEEE International Conference on Cloud
Engineering (IC2E), 2016.
[12] C. Pahl and B. Lee, «Containers and Clusters for Edge Cloud Architectures --
A Technology Review,» 3rd International Conference on Future Internet of
Things and Cloud, 2015.
[13] K. Seo, H. Hwang, I. Moon, O. Kwon, and B. Kim, «Performance comparison
analysis of linux container and virtual machine for building cloud,» 2014.
[14] C. Boettiger, «An introduction to Docker for reproducible research,» ACM
SIGOPS Oper. Syst. Rev.
57
[15] M. Amaral, J. Polo, D. Carrera, I. Mohomed, M. Unuvar, and M. Steinder,
«Performance Evaluation of Microservices Architectures Using Containers,»
IEEE 14th International Symposium on Network Computing and Applications,
2015.
[16] Docker, «Docker project official website,» [En línea]. Available:
https://www.docker.com/enterprise.
[17] E. A, «Docker, Qué es y sus principales características.,» 05 Mayo 2014. [En
línea]. Available: https://openwebinars.net/blog/docker-que-es-sus-
principales-caracteristicas.
[18] Docker, «DockerHub,» [En línea]. Available: https://hub.docker.com/.
[19] A. M. d. C. G. Oterino, «javiergarzas.com,» 21 Agosto 2015. [En línea].
Available: http://www.javiergarzas.com/2015/08/docker-vs-puppet-vs-vagrant-
vs-chef.html.
[20] Docker docs, «Docker Engine,» 2017. [En línea]. Available:
https://docs.docker.com/engine/understanding-docker/.
[21] Docker, «Docker Docs,» https://docs.docker.com/, 2017.
[22] Docker inc., «Docker docs,» 2017. [En línea]. Available:
https://docs.docker.com/engine/installation/linux/docker-ce/centos/.
[23] Docker Inc., «Docker docs,» 2017. [En línea]. Available:
https://docs.docker.com/compose/install/.
[24] Docker Inc, «Docker Docs,» 2017. [En línea]. Available:
https://docs.docker.com/machine/install-machine/#installing-machine-directly.
