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. También se puede usar directamente Docker para desplegar un servicio web, empaquetando toda la funcionalidad y creando un entorno que va a ser exactamente igual que el que vamos a tener cuando se pase a producción.
En esta práctica se trata de diseñar, usando Docker, un contenedor o contenedores con el que se pueda probar y desplegar fácilmente la aplicación que se está diseñando.
Haber alcanzado el 70% de los objetivos de las sesiones hasta este hito. En el caso de que no se haya hecho, no se calificará este hito del proyecto.
Haber superado el hito anterior.
El principal objetivo del uso de Docker u otra infraestructura de contenedores es aislar la ejecución de una aplicación de forma que sea mucho más fácil desplegarla, incluyendo los datos y el estado en el que se encuentre en un momento determinado; también permite crear fácilmente infraestructuras que se pueden reproducir en cualquier instalación en la nube. Además de usarse para entorno de prueba, se puede usar también como entorno de producción, en caso necesario, por ejemplo, taperizando la aplicación de forma que se pueda desplegar con seguridad en cualquier entorno IaaS donde esté instalado un gestor de contenedores o permita directamente el despliegue de contenedores. De hecho, los PaaS usan docker (o algún tipo de infraestructura similar) 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.
Para los fines del proyecto y objetivos de la asignatura, 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.
En este sentido, si se usa cualquier otro servicio de contenedores como Azure o AWS se tendrá que hacer de forma automática o automatizarse con algún script de shell que se incluirá también en el repositorio.
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 código adicional para desplegar este fichero como contenedor, pero se valorará que se usen las herramientas de construcción para hacer un despliegue y arranque de la aplicación en el contenedor.
Subir los fuentes a GitHub hacer un pull request al documento que describa las prácticas y que se anunciará en el repositorio de la asignatura. El documento tendrá que incluir el nombre del proyecto y un enlace a un repositorio de contenedores docker o máquina virtual Azure o Bluemix donde se haya desplegado (o cualquier otro sistema). Se puede usar también Zeit, que permite desplegar contenedores con cualquier tipo de servicio. En cada caso, usar la configuración y recomendaciones para desplegar correctamente.
Como en la práctica anterior, 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.
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.