Antes de desplegarse a producción, las aplicaciones tienen que probarse en un entorno aislado . Generalmente se denomina staging a esta etapa de desarrollo, y se usa algún tipo de entorno aislado, similar en todo menos en los usuarios al entorno de despliegue definitivo.
En esta práctica se trata de diseñar, usando alguna de los sistemas de aislamiento de recursos vistos anteriormente, junto con los sistemas de creación de entornos virtuales de desarrollo, un contenedor o jaula con el que se pueda probar fácilmente en esta fase la aplicación que se está diseñando.
Si se trata de una aplicación SaaS (que no tenga una versión libre que se pueda instalar de forma independiente), en esta etapa se diseñará una aplicación cliente que pruebe diferentes funcionalidades una vez desplegado en su entorno; algo similar en el caso de un diseño IaaS. En el caso de un PaaS, habrá que crear en el contenedor el mismo entorno que tendría en el PaaS definitivo.
Haber alcanzado el 70% 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.
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, taperizando la aplicación de forma que se pueda desplegar con seguridad en cualquier entorno IaaS o PaaS.
El objetivo secundario es el que el alumno tenga instaladas las
herramientas necesarias para crear jaulas chroot y contenedores tenga claro en qué
casos son la mejor y más eficiente opción; también en qué casos
conviene usarlas por motivos de seguridad. Estas herramientas se
añadirán a la panoplia de herramientas 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.
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. Sin embargo, es posible que sea más fácil crear la aplicación para esta jaula usando cualquier lenguaje de scripting (tal como Python, PHP, Perl o Ruby) que enjaular una aplicación ya creada, con todas sus dependencias; posiblemente, en todo caso, merezca la pena hacerlo. Si se desea, se puede usar la misma aplicación que en la primera práctica. 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.
Subir los fuentes a GitHub hacer un pull request al documento que describa las prácticas y que se anunciará en la web de la asignatura. El documento tendrá que incluir el nombre del proyecto y un enlace al despliegue.
La explicación del proyecto deberá incluir las herramientas y líneas de órdenes usadas junto con por qué se ha tomado la decisión de usarlas y una pequeña explicación; también si se ha avanzado en el proyecto en sí, qué se ha añadido y qué funcionalidades tiene. Esta documentación se incluirá en ficheros de texto junto con la aplicación dentro de las que proporciona GitHub. No se permitirán ficheros binarios de un procesador de texto o PDF, sólo ficheros en Markdown (preferiblemente), Textile o algún otro lenguaje de marcas.
El funcionamiento de la aplicación se mostrará por parte del alumno con pantallazos en los que se muestre el proceso de creación e instalación. Se valorará que también esté publicado en algún sitio público.
- 5 puntos: entornos de pruebas creado y funcionando.
- 3 puntos: scripts de prueba creados y funcionando..
- 2 puntos: concedidos por originalidad de la aplicación, grado de terminación, utilidad para la asignatura, originalidad de las herramientas usadas o sistema operativo, cantidad de trabajo invertido.
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.