Un contenedor es una de las formas estándar hoy en día para crear despliegues repetibles de cualquier tipo de aplicación, desde test a microservicios. En esta práctica se trata de diseñar, usando Docker, un contenedor o contenedores con el que se puedan ejecutar fácilmente los tests unitarios sobre la aplicación que se está diseñando.
Haber superado los tests del hito anterior.
El principal objetivo del uso de Docker u otra sistema de gestión 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 servicio o proveedor 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. En este hito, sin embargo, nos vamos a centrar en la creación de entornos de prueba, ya que la mayoría de los servicios de integración continua permiten usarlos; el tener en este paso ya listo un entorno de prueba desplegable permite, en los siguientes pasos, usarlos directamente para configurarlos.
El objetivo secundario es el que el alumno tenga instaladas las herramientas necesarias para trabajar con Docker, sea el “oficial” o alternativamente Podman/Buildah; 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.
Todavía cabe un objetivo terciario, y es que entienda como se empaquetan las aplicaciones para su distribución usando esta plataforma.
Para los fines del proyecto y objetivos de la asignatura, lo importante es que la creación de ese entorno de pruebas sea reproducible, por eso se requiere del estudiante el diseño de un Dockerfile, que además tendrá que subir a un repositorio público. 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, GitHub container registry 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 continuo 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 pedirá que se usen las herramientas de construcción para hacer un despliegue y arranque de la aplicación en el contenedor y por supuesto cualquier avance (siguiendo, por ejemplo, los consejos en las anteriores evaluaciones) se valorará también. Y por supuesto la implementación de historias de usuario adicionales se valora en la rúbrica correspondiente.
La creación de un contenedor para pruebas (y, en general cualquiera), contiene varias fases
Como en todos los hitos entregables en CC, este desarrollo tendrá que estar enmarcado en un producto mínimamente viable/hito.
Subir los fuentes a GitHub mediante un pull request al documento que describa este y que se anunciará en el repositorio de la asignatura, como es habitual.
Como siempre, toda rúbrica tiene que esta correctamente identificada y
enlazada dese el README, que, como en todos los hitos, reflejará el
estado del proyecto del estudiante en este punto. Llegados a este
punto es efectivamente imprescindible que el README.md refleje el
estado del proyecto, porque es lo que va a aparecer en Docker Hub.
Aparte, se tendrá que configurar un contenedor en Docker Hub con el mismo nombre que el proyecto. Este repositorio estará configurado para que se construya el contenedor automáticamente cada vez que se actualice el repo en GitHub.
El contenedor se va a testear de la manera siguiente
docker run -t -v `pwd`:/app/test nick-estudiante/nombre-del-repo
Que ejecutará los tests, y los tests deben pasar. En este caso pwd
se va a usar en el contexto del contenedor de pruebas de una GitHub
action. Localmente podréis usar la misma línea para testearlo, pero en
cualquier otro contexto esa línea no tiene por qué ser válida.
Si por cualquier razón no se ha podido usar en Docker Hub el mismo
nick que en GitHub, se creará un fichero DOCKER_USER en el
directorio principal con el mismo.
El Dockerfile del estudiante tendrá que tener precisamente ese
nombre y estar en el directorio principal.
Se llevará a cabo en las siguientes rúbricas
Este hito contribuirá 1 punto a la nota final.
Se recuerda al estudiante que es imposible evaluar cualquiera de estas
rúbricas si no está correctamente documentada, como tal, en el fichero
README.md (si corresponde) o en un documento enlazado desde el mismo.