Ciclo 7 de la maestría en ingeniería de software asignatura DevOps
Las siguientes variables de entorno se configuran en el Dockerfile que se encuentra en la raíz de la aplicación con el fin de recibir métricas de desempeño, logs, cantidad de solicitudes y el resto de capacidades que se proveen desde New Relic.
- NEW_RELIC_APP_NAME el valor que se le pone a esta variable es devops-entrega-4
- NEW_RELIC_LOG se configura la salida stdout
- NEW_RELIC_DISTRIBUTED_TRACING_ENABLED es para habilitar las trazas distribuidas, lo tenemos con el valor true
- NEW_RELIC_LOG_LEVEL se establece el valor info para generar registros de log
Para instalar la dependencia de Newrelic, se especifica la siguiente instrucción:
RUN pip install newrelic
Es necesario especificar el siguiente ENTRYPOINT para ejecutar la aplicación con los argumentos de newrelic
- ENTRYPOINT [ "newrelic-admin", "run-program" ]
En esta entrega se hace uso de varios servicios de AWS, como Fargate, ECS, ECR, CodeDeploy, CodeBuild, Load Balancer y definición de tareas, con el fin de realizar entrega continua con despliegue Blue/Green.
La nueva url para acceder a los servicios de blacklist es:
LB-app-python-1206019677.us-east-1.elb.amazonaws.com
- buildspec.yml: contiene las estapas de
pre_buildpara la instalación de dependencias y ejecución de tests unitarios, la etapa de build permite la creación de la imagen de docker y la etapa depost_buildcrea los artefactos para poder leer la imagen desde S3. - appspec.json: como su nombre lo indica, contiene la configuración que especifica la aplicación, el puerto del contenedor, el nombre del contendor y la definición de tarea asociada.
- taskdef.json: contiene la configuración para la definición de tarea, como el mapeo de puertos, el role de ECS para la ejecución de la tarea y capacidad de recursos, como memoria y CPU.
Se configuraron variables de entorno para que la aplicación pudierá realizar la conexión con la base de datos en la definición de la tarea del contenedor con los siguientes nombres:
DB_USERDB_PASSWORDDB_HOSTDB_PORTDB_NAME
Para los chequeos de salud de la aplicación en el Load Balancer, se adiciona el enpoint ping. A continuación, se adjunta captura de pantalla del endpoint el cual solo retorna el mensaje 200 y el código HTTP 200
Las consideraciones que se tuvieron en cuenta para la entrega 1 siguen estando vigente, sin embargo, es importante mencionar el proceso que se ha llevado a cabo para la realización de la pruebas unitarias
Nota: es recomendable la instalación de un ambiente virtual con python, desde la raíz del proyecto se puede utilizar el comando python -m venv .venv el cual creará la carpeta .venv en la raíz del proyecto.
Las pruebas unitarias se pueden ejecutar localmente desde la raíz del proyecto, con el comando pytest --cov=. -v -s --cov-fail-under=75, con este comando se ejecutan todas las pruebas unitarias que validan que los flujos de la aplicación brinden la respuesta esperada, además, se especifica que el coverage debe ser superior al 75%, en caso contrario fallará.
Desde la raíz del proyecto se puede apreciar la carpeta tests, en esta carpeta se incluye el archivo conftest.py que permite la configuración inicial de las pruebas, como la definición de un cliente http y lo que debe ocurrir al finalizar todas las ejecuciones de las pruebas. Por otra parte, como existen dos endpoints, se crean dos archivos de pruebas, uno para agregar un email a la lista negra y otro para obtener el email. Todas las pruebas se ejecutan correctamente y tienen un coverage superior al 90%. En la raíz del proyecto también se incluye el archivo .coveragerc que permite omitir los archivos de tests que no deben ser tenidos en cuenta para el coverage. Por último, en el archivo de compilación buildspec.yml se incluye el comando antes mencionado para la ejecución de los tests unitarios cuando se realice la compilación en CodeBuild de AWS.
Coverage
La aplicación ha sido desarrollado en python y Flask, para su ejecución, recomendamos configurar y activar un ambiente virtual de python, luego instalar las dependencias con el comando pip install --no-cache-dir -r requirements.txt. Vale la pena mencionar que existe un archivo Dockerfile en la raíz del proyecto, este carga la configuración y hace uso de variables de entorno para la conexión a la base de datos postgresql que está localmente, si no se desea ejecutar la aplicación con Docker, desde la raíz del proyecto bastaría ejecutar python application.py, de esta menera se tomaría por defecto SQLite y la aplicación funcionaría sin problemas. Cabe aclarar que en AWS Beanstalk no se ejecutó la aplicación contenerizada, en su lugar, se cargó un archivo comprimido para ejecutar la aplicación, el archivo comprimido se encuentra en la raíz del proyecto con el nombre Archivador.zip
A continuación se especifica cada endpoint con lo necesario para realizar las peticiones http que permitan agregar un correo a la lista negra y consultar si un correo está en la lista negra y la razón por la cual el correo se agregó a la lista negra:
Permite agregar un email a la lista negra global de la organización.
| Método | POST |
| Ruta | /blacklists |
| Parámetros | Sin parámetros en la URL |
| Encabezados | `Authorization: Bearer token` |
| Cuerpo |
{
"email": Correo electrónico a agregar en la blacklist,
"app_uuid": Identificador de la aplicación en formato UUID,
"blocked_reason": Razón por la cual se desea bloquear el correo
} |
Respuestas
| Código | Descripción | Cuerpo |
|---|---|---|
| 401 | El token no es válido. | {"message": "The token is invalid"} |
| 403 | El token no está en el encabezado de la solicitud | {"message": "The token is required"} |
| 400 | Cuando no se envía un campo requerido | Mensaje campos faltantes: {"message": 'All fields are needed'} |
| 500 | Error interno que no está contemplado que suceda | {"message": 'Internal server error, the account could not be created'} |
| 412 | Cuando está duplicado el email o el identificador de la app | {"message": mensaje de acuerdo al campo duplicado} |
| 201 | Se agrega exitosamente el email a la lista negra |
{
"message": "The account could be created successfully"
} |
Permite saber si un email está en la lista negra global de la organización o no, y el motivo por el que fue agregado a la lista negra.
| Método | GET |
| Ruta | /blacklists/ |
| Parámetros | email: correo electrónico que se desea consultar |
| Encabezados | `Authorization: Bearer token` |
| Cuerpo | N/A |
Respuestas
| Código | Descripción | Cuerpo |
|---|---|---|
| 401 | El token no es válido. | {"message": "The token is invalid"} |
| 403 | El token no está en el encabezado de la solicitud | {"message": "The token is required"} |
| 404 | El email no ha sido encontrado | {"is_email_present": valor booleano que indica que el email no está en la lista negra de la organización} |
| 200 | El email está presente en la lista negra global de la organización |
{
"is_email_present": true,
"reason": Descripción que expresa la justificación por la cual se ha tomado la decisión de bloquear el email
} |
En la raíz del proyecto existe el archivo Ciclo_7_DevOps.postman_collection.json el cual es una colección de postman, en ella se encuentra la carpeta Entrega 1, esta carpeta contiene una carpeta de Tests la cual se puede ejecutar para probar todas las respuestas que la aplicación puede brindar, además, posee dos peticiones, una de tipo Post para agregar un email a la lista negra de la organización y otra de tipo Get para consultar si un email está presente en la lista negra. A continuación, se muestra como se ve la estructura mencionada anteriormente desde el postman:
Para la correcta ejecución de los escenarios de prueba en postman, se han definido las variables EMAIL, APP_UUID, BLOCKED_REASON, TOKEN, GET_EMAIL, la variable HOST es la URL base para realizar las peticiones, en local se puede reemplazar por http://localhost:5000, en este momento se encuentra configurado con el dominio de AWS Beanstalk en donde se ejecutó la aplicación: proyecto-entrega-1-env-1.eba-pzar3z2n.us-east-1.elasticbeanstalk.com/
Para la ejecución de los tests en postman, se deben realizar los siguientes pasos:
- En la carpeta Tests, oprimir en los tres puntos y seleccionar la opción "Run folder"
- Una vez seleccionada esta opción, se listarán todas las peticiones encargadas de ejecutar los tests, debemos fijarnos que todos los checkbox estén seleccionados
- Oprimir la opción "Run Ciclo 7 DevOps", Ciclo 7 DevOps es el nombre de la colección, si la colección ha cambiado de nombre, posiblemente la opción aparezca "Run nombre_colección"
4. Al ejecutar todos los tests, se debe validar que se ejecutaron 26 tests, fallaron cero y se omitieron cero como se puede ver a continuación.
