Finalizar el proyecto individual con despliegue automático a las plataformas de producción.
Haber alcanzado el 50% de los objetivos del tema de gestión de infraestructuras y uso de sistemas. Sin este requisito este hito del proyecto estará suspenso. Evidentamente, tendrán que estar aprobados todos los hitos anteriores.
En la asignatura se ha visto como crear usar máquinas virtuales completas y como provisionar las aplicaciones y servicios necesarios y hacerlo de forma ágil y reproducible.
El ciclo de desarrollo de un DevOps es el siguiente
- Provisionamiento para desarrollo.
- Creación de tests unitarios, de cobertura y de integración y configuración de la integración continua.
- Provisionamiento de las máquinas de prueba (staging) y de producción. Estas máquinas pueden ser tanto PaaS como IaaS. Esto se ha hecho en los dos hitos anteriores.
- Configuración del despliegue de las desarrollo a las máquinas de staging y eventualmente a las de producción. Este despliegue tiene que ser automático.
Lo que se pretende con este ciclo es que el tiempo que pasa desde la incorporación de un nuevo desarrollador a un equipo hasta que es capaz de pasar a producción el desarrollo sea lo menor posible, de forma que el uso de recursos y el despliegue de los mismos sea un proceso ágil. Previo a tal proceso estará la elección de tales entornos de desarrollo y producción y el test de los mismos, pero en el momento que se comience el desarrollo, o paralelamente al mismo, las decisiones deben estar tomadas y las máquinas virtuales testeadas y provisionadas, con todas las configuraciones preparadas y almacenadas en un repositorio.
Este hito es el que concluye la asignatura. La documentación debe estar en
un solo documento y este documento o bien ser el README.md
del
proyecto o estar en donde se publique habitualmente, un directorio u
otra rama. La licencia debe
estar en el directorio principal. Los tests y los despliegue deben
hacerse automáticamente con una sola orden tal como make install
,
python setup.py
o
grunt
y deben usarse herramientas estándar para el mismo. Si se ha
configurado un despliegue automático desde GitHub, debe indicarse
claramente en la documentación.
Si el proyecto está coordinado con otros, también debe indicarse claramente y la documentación deberá aclarar dónde se configuran los endpoints o puntos de entrada al API de esos otros proyectos, así como si hay un script que despliegue todos los proyectos en una sola aplicación y donde está desplegada. Esto se valorará adicionalmente.
El despliegue de la aplicación deberá hacerse en una máquina virtual que se haya configurado automáticamente y a la que se haya hecho también el despliegue automáticamente. Esta máquina virtual debe ser una infraestructura como servicio, tal como Azure o cualquier otra que se proporcione de forma gratuita.
Aunque los proyectos se realizan y entregan de forma individual, en este hito se permitirá que haya commits de otros miembros del equipo con el que se esté coordinando el proyecto, siempre que se hayan hecho mediante pull requests y además quede claro, en una tarea, qué es lo que han hecho.
Lo esencial de esta práctica es
- Que se encuentre efectivamente desplegada en una máquina virtual del tipo IaaS remota, de las proporcionadas por el profesor o alguna otra.
- Que esa máquina virtual sea un IaaS y se haya configurado desde 0 usando un script de provisionamiento. Es decir, que no se haya usado una imagen ya configurada de la disponible en los repositorios de las mismas.
Esta se podrá usar, sin embargo, para pruebas de los scripts de despliegue siempre que quede claro en la documentación que es así. Ese script se podrá hacer en cualquier lenguaje de los vistos en la asignatura o alguno que no se haya visto (Puppet, Rex o Salt).
- El despliegue tiene que hacerse automáticamente a dos niveles: usando una herramienta de despliegue automático como Vagrant o Puppet para crear las máquinas virtuales y desplegar una configuración en ella, configuración hecha con Ansible, Chef o algún otro sistema, y el despliegue y ejecución de la aplicación tendrá que hacerse automáticamente con alguna herramienta de despliegue tipo Capistrano, Fabric o Flightplan.
El objetivo, en todo caso, es que el provisionamiento sea escalable y reproducible, de forma que partiendo desde 0 (una cuenta en algún proveedor de IaaS) se pueda echar una aplicación a funcionar ejecutando solamente scripts y sin ningún input por parte del usuario.
Si hay que configurar claves SSH o de bases de datos tendrá que hacerse en un fichero de configuración o en un directorio previamente. Tanto Vagrant como las otras herramientas trabajan con variables de entorno o ficheros de configuración.
Aunque sea evidente, conviene recordar dos cosas
- Se trata de una práctica de una asignatura, Infraestructura Virtual. Se evaluarán, de forma casi exclusiva, el trabajo del alumno que muestre que efectivamente se han asimilado los contenidos de la asignatura.
- Lo que no está en GitHub no se puede evaluar.
Por otro lado, la entrega se hará de la forma habitual, modificando el documento y haciendo un pull request. Instrucciones:
- En este pull request deberá indicarse claramente el proyecto que es y que se trata de la práctica final. Si el proyecto está coordinado con otros, se debe agrupar claramente en el fichero y también indicar el punto de acceso común a todos ellos.
- Un enlace al repositorio.
Los elementos de la práctica se tendrán que hacer constar en el README.md de la forma siguiente.
- El IP o dirección (no el URL) donde se haya desplegado tendrá que estar activado y se pondrá, en una línea sin nada más, de esta forma
Despliegue final: IP_o_nombre
- En esa misma IP se desplegará también el servicio web, que tendrá
que devolver
{ status: OK}
como en la práctica anterior, es decir, en la ruta/status
. - El
Vagrantfile
tendrá que estar en el directorio principal. - El fichero de despliegue usado (Capfile, Fabfile o fichero de
Flightplan) tendrán que estar también en un directorio llamado
"
despliegue
". - El script usado para aprovisionamiento estará en un subdirectorio
llamado "
provision
"
Una vez hecha la entrega, en la fecha que se haya discutido en clase y puesto en la sesión correspondiente se podrá hacer una presentación oral del proyecto. Esa presentación será optativa, pero se valorará para la nota de la práctica.
La puntuación de esta práctica tiene un peso superior al resto, contando como se indicó al principio más que los otros hitos.
- 2 puntos: provisionamiento correcta y claramente explicada.
- 2 puntos: herramienta de orquestación (que cree y despliegue las máquinas virtuales con Vagrant) correcta y bien explicada.
- 2 puntos: Despliegue hecho correctamente en un IaaS como Azure.
- 2 puntos: Presentación oral y coordinación del proyecto con otros.
- 2 puntos: Herramienta de despliegue clara y bien configurada. Se valorará que se use una herramienta adicional a la herramienta de provisionamiento.
Se recuerda que todo lo anterior se califica de forma individual. Si hay alguna copia a estas alturas del curso, la práctica estará suspensa y sin posibilidad de reenvío.