Quinto hito: Contenedores para despliegue en la nube.

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.

Los contenedores también se pueden usar, desde la puesta en producción de Docker, para desplegar aplicaciones de forma idempotente, es decir, de forma que la configuración sea exactamente la misma local y en la nube; todas las plataformas tienen sistemas que permiten desplegar en la nube directamente contenedores en forma de Dockerfile o de contenedores en Docker Hub ya creados y probados.

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. Esto también significa que, en este punto, tendrá que haber una aplicación que efectivamente devuelva, al menos, un estado, forma de JSON. Esto será lo que se compruebe para ver que la aplicación de ha desplegado de forma correcta.

Prerrequisitos

Haber alcanzado el 60% de los objetivos del material correspondiente de la asignatura. 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.

El URL del servicio web desplegado en un contenedor se pondrá en una sola línea de esta forma

Contenedor: https://dirección.url

El URL de DockerHub podrá estar en cualquier lugar del fichero README.md. Si hay algún despliegue adicional, simplemente también mencionadlo en cualquier lugar del fichero.

Como en la práctica anterior, esta dirección tendrá que tener instalado un servicio web que devuelva status: OK, pero en este caso, en la ruta status, no en el directorio principal; es decir, se tendrá que desplegar, como mínimo, el servicio web del hito anterior del proyecto.

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.