Cuarto hito: Creación de un entorno de pruebas para la aplicación usando contenedores

Descripción

Antes de desplegarse a producción, las aplicaciones tienen que probarse en un entorno aislado. Generalmente se denomina staging a esta etapa en el desarrollo y despliegue de la aplicación, y se usa algún tipo de entorno, similar en todo menos en los usuarios al entorno de despliegue definitivo.

En esta práctica se trata de diseñar, usando Docker y describiendo la infraestructura mediante un Dockerfile, un contenedor o contenedores con el que se puedan hacer pruebas fácilmente en esta fase la aplicación que se está diseñando.

En una arquitectura de microservicios se usa también Docker para desplegar en contenedores separados cada uno de los microservicios, y poder publicar la aplicación fácilmente con todos los contenedores, de una forma más o menos independiente de la máquina subyacente, aunque no de la arquitectura.

Prerrequisitos

Haber alcanzado el 60% de los objetivos de los dos temas de técnicas de virtualización tras haber realizado los ejercicios propuestos. En el caso de que no se haya hecho, no se calificará este hito del proyecto. Haber superado el hito anterior.

Explicación

El principal objetivo de esta práctica es familiarizarse con este tipo de infraestructura virtual que se usa generalmente para dar un acceso limitado a una aplicación o un servicio tal como un servidor web o a un usuario, que pueda acceder por ejemplo sólo para depositar ficheros. Además de usarse para entorno de prueba, se puede usar también como entorno de producción, en caso necesario, por ejemplo, poniendo la aplicación en un contenedor de forma que se pueda desplegar con seguridad en cualquier entorno IaaS o PaaS. De hecho, muchos PaaS usan docker (o algún tipo de infraestructura similar, como lxc) para crear contenedores con los que se ejecutan las aplicaciones.

El objetivo secundario es el que el alumno tenga instaladas las herramientas necesarias para trabajar con Docker; también en qué casos conviene usarlas por motivos de seguridad o de conveniencia. Estas herramientas se añadirán a la panoplia de un administrador que al terminar la asignatura tendría que tener el alumno.

Lo importante es que la creación de ese entorno de pruebas sea reproducible. No bastará mostrar que el entorno funciona, sino que habrá que crear una serie de scripts tales que, en una instalación determinada sin el contenedor o jaula, se pueda crear fácilmente ese entorno y reproducir la aplicación que se va a probar. Generalmente, si se usa un solo contenedor es suficiente con un Dockerfile. Si se usan varios, habrá que orquestarlos usando la aplicación correspondiente.

El énfasis de esta práctica es en la creación y uso de este entorno de pruebas, por lo que también se valorará cómo se han diseñado esas pruebas y lo realista que es ese entorno. Por supuesto, también se busca que el alumno empiece a usar sistemas de despliegue reales en su aplicación, usando git, claves, integración continua y el resto de los sistemas que se usan en el ciclo de vida de un aplicación moderna.

No se exigirá que se haga ningún fichero de despliegue adicional, pero se valorará que se usen las herramientas de construcción para hacer un despliegue y eventualmente arranque de la aplicación en el contenedor. También que se incluya el despliegue en una herramienta en la nube tal como Azure de forma automática.

Entrega de la práctica

Subir los fuentes a GitHub y hacer un pull request al documento de entregas como es habitual. El documento tendrá que incluir el nombre del proyecto y un enlace a un repositorio de contenedores docker o máquina virtual Azure o Amazon donde se haya desplegado (o cualquier otro sistema). En caso de que el proyecto no sea visible, una captura de pantalla, que como todas las capturas tendrá que ir en la rama de documentación, es suficiente.

Valoración

Si la aplicación no funciona o no están los fuentes publicados, la práctica estará suspensa. Si no hay constancia en issues o commits del trabajo de uno de los miembros del equipo, también.