Desarrollo de una API Rest para la gestión de un sistema de infraestructura como código

Vega Herrera, Gonzalo (2020). Desarrollo de una API Rest para la gestión de un sistema de infraestructura como código. Proyecto Fin de Carrera / Trabajo Fin de Grado, E.T.S.I. de Sistemas Informáticos (UPM), Madrid.

Description

Title: Desarrollo de una API Rest para la gestión de un sistema de infraestructura como código
Author/s:
  • Vega Herrera, Gonzalo
Contributor/s:
  • Gil Abad, María del Carmen
Item Type: Final Project
Degree: Grado en Ingeniería de Computadores
Date: June 2020
Subjects:
Freetext Keywords: Automatización; Pipelines de Jenkins
Faculty: E.T.S.I. de Sistemas Informáticos (UPM)
Department: Sistemas Informáticos
Creative Commons Licenses: Recognition - No derivative works - Non commercial

Full text

[img] PDF - Users in campus UPM only - Requires a PDF viewer, such as GSview, Xpdf or Adobe Acrobat Reader
Download (2MB)
[img] Archive (ZIP) - Users in campus UPM only
Download (101kB)

Abstract

El presente trabajo de fin de grado presenta la solución de un problema real y común en grandes compañías que quieren automatizar el despliegue de infraestructuras informáticas. En este proyecto se pretende desarrollar en una API REST que valide datos de entrada del usuario y ejecute el proceso necesario para el despliegue automático de la infraestructura. La fase de análisis de este proyecto comienza por el estudio de la situación previa a los despliegues de infraestructura automatizados para identificar todos los puntos de mejora, además de las características y funcionalidades necesarias. En la situación anterior, en el que el despliegue de infraestructura se hacía de forma casi totalmente manual, el simple hecho de ofrecer un entorno de trabajo podía llegar a llevar una semana, mientras que usando nuevas tecnologías y herramientas se pueden automatizar todas las tareas repetitivas de este proceso, reduciendo con ello el proceso a un par de horas. Debido a que en una gran compañía existen un gran número de departamentos y funciones, estos entornos de trabajo son altamente configurables en el momento de solicitarlos, tanto en el hardware del que disponen como en el software con el que cuentan. Para conseguir la automatización de estos despliegues de infraestructura existen una serie de pipelines de Jenkins, que son una secuencia idempotente de scripts, estructurados en pasos ordenados, que desarrollan tareas concretas necesarias para el despliegue de la infraestructura. Para realizar la solicitud de estos entornos se cuenta con formularios en los que introducir tanto datos del solicitante como la configuración deseada, que una vez rellenos serán enviados a los pipelines encargados de desplegar los entornos de trabajo. Para esta tarea se desarrolla un mecanismo que permitirá la interacción de los usuarios finales con el sistema de despliegue de infraestructura. Otra de las necesidades de este sistema, en el que se está automatizando todo el proceso, es que los propios despliegues de entornos de trabajo se puedan integrar con otros futuros desarrollos. Es por ello que la decisión final es la de crear una API REST, que recibida una petición la almacene y en el caso de que sea válida llame al pipeline adecuado para su ejecución. Uno de los principales requisitos de esta API es que sea escalable, pudiendo añadir nuevos formularios para nuevos tipos de entornos de trabajo con facilidad y sin que para ello haya que contar con grandes conocimientos de programación. A continuación, en la fase de diseño se buscaron las herramientas más apropiadas para la solución del problema. El lenguaje de programación elegido para el desarrollo de esta API es Python, versión 3, debido a que se trata de un lenguaje simple y rápido en cuanto al desarrollo, ordenado y limpio de cara a su extensibilidad y por el hecho de contar con frameworks y librerías muy adecuados para el fin perseguido. En cuanto al framework, el elegido es Flask, por su claridad y porque ofrece las características buscadas para este desarrollo. Se trata de un micro-framework orientado específicamente al desarrollo de webs, web apps y APIs, y esta principalmente compuesto por Werkzeug como toolkit para aplicaciones Web Server Gateway Interface (WSGI) y por Jinja como motor de templates, ambos desarrollados también en Python. La principal librería adicional que se usa en este proyecto es WTForms, una librería para la descripción de formularios que ya cuenta con algunos validadores de datos y tipos de campos predefinidos y que dada su sencillez en la descripción de formularios hace posible que terceras personas añadan nuevos formularios sin tener que tener conocimientos avanzados de Python ni del funcionamiento interno de la API. El entorno de desarrollo elegido para el desarrollo de este proyecto ha sido Linux ya que ese va a ser el sistema operativo sobre el que funcionara la API y tener un entorno de desarrollo lo más parecido posible al de producción facilita la detección temprana de errores. Como IDE se ha usado Pycharm Community Edition de JetBrains y para tener una mayor facilidad en el despliegue del entorno de pruebas y en las pruebas también se ha hecho uso de imágenes Docker para el despliegue de la base de datos. El desarrollo de este proyecto se ha decidido dividir en dos componentes, la API en sí que será la encargada de aceptar, almacenar, validar y procesar las peticiones, y los formularios que descriptivamente representan los campos a rellenar, así como también los requerimientos de estos. Con este planteamiento, teniendo una API lo suficientemente flexible y probada, solo será necesario desarrollar nuevos formularios a medida que aparezcan nuevos tipos de entornos de trabajo a solicitar. El siguiente paso fue el de la codificación, que se realiza de forma paralela con la elaboración de pruebas, según se desarrollan nuevas funcionalidades se añaden pruebas para estas. Como convención de estilo estándar de código se ha usado el recomendado en el lenguaje Python, PEP8, con el fin de que el código sea más fácil de leer y editar en el futuro por otros desarrolladores. Para la automatización de estas comprobaciones de que nuevas aportaciones no rompen ninguna funcionalidad y que además cumplen con el estándar PEP8 se han realizado con el módulo tox. El proyecto cuenta con más de un 95% de cobertura y todas las pruebas se han realizado con el framework para pruebas pytest. A continuación, se pasa a la instalación, uso y mantenimiento de este proyecto. Los requisitos para poner en funcionamiento este sistema son sencillos, simplemente se necesita un servidor web y un servidor de base de datos, habiendo sido elegidos en este caso Apache HTTP server y MySQL, ambos proyectos de código libre. Para mayor facilidad en el despliegue, balanceo y escalabilidad se ha decidido desplegar este proyecto en un contenedor Docker que es orquestado con Kubernetes. La escalabilidad ha sido uno de los principales puntos tenidos en cuenta durante el desarrollo de este proyecto, por lo que se enumeraran las medidas tomadas para la escalabilidad de la API, dado que se trata de un sistema que está sujeto a una gran carga de trabajo y además debe ser tolerante a fallos para conseguir tener una alta disponibilidad. Dado que una API está pensada para ser usada por terceros la usabilidad de esta también es muy importante, y es por ello que se ha diseñado con el fin de que su uso sea intuitivo. A parte, con el fin de que personas que quieran contribuir al proyecto, ya sea añadiendo nuevas funcionalidades a la API o desarrollando nuevos formularios tengan una curva de aprendizaje lo más plana posible se ha escrito documentación describiendo como instalar un nuevo entorno de desarrollo, los requisitos que se espera que sigan las contribuciones e instrucciones para desarrollar nuevos formularios. El aspecto de la reusabilidad de esta API también ha sido tenido en cuenta, y para ello se ha hecho lo más genérica posible, siendo posible su uso no solo para solicitar entornos de trabajo, sino que también se podrá utilizar en un futuro para la validación de datos de entrada y la ejecución de tareas, sean cuales sean estas. También se sacarán conclusiones de si el proyecto ha cumplido con todos los requisitos, si todas las cualidades buscadas han sido conseguidas y posibles mejoras de cara al futuro en este proyecto u otros similares. La estructura de esta memoria de proyecto seguirá el mismo orden que los párrafos anteriores, profundizando en cada capítulo en uno de ellos. Abstract: This final project consists on a description and solution of a real problem commonly found in big companies that are in the process of automating infrastructure deployments. The goal of this project is to develop a REST API that validates user entry data and launches the necessary process for deploying the requested infrastructure. In the analysis phase of this project the previous way of doing this deployments is examined in order to identify all the possible improvement points and the needed characteristics and functionality. In the previous situation, in which almost everything was done manually, the sole task of delivering a work environment could take up to a week, but this can be improved using modern technologies and tools for the automation of all the repetitive tasks in this process, reducing with this the delivery time to a couple of hours. Because in a big company there is a big number of departments and functions, these work environments are highly configurable when requesting them, both in the hardware and software aspects. To achieve the automation of these infrastructure deployments a set of Jenkins pipelines exist, which are a sequence, structured in steps, of idempotent scripts that do the necessary tasks for the infrastructure deployment. In order to make the request of this work environments there are available forms in which the requestor inputs his/her data and the desired configuration. This information will be validated and if is valid will be sent to the appropriate pipeline for the deployment of the infrastructure. For this task, we need a mechanism that will allow the interaction of end users with the infrastructure deployment system. Other of the needs of this project, in which we are automating the process of infrastructure deployment system, is to be integrate able with other future developments. It is for this reasons that the final decision is to create a REST API that will receive, store and validate requests, and in case of valid ones, launch the appropriate pipeline for the deployment. One of the most important requirements of this API is its scalability; this means that adding new forms for new types of work environments should be an easy task that does not require great programming knowledge. Later, in the design phase there is an examination of the most appropriate tools for this solution. The chosen language to develop this API is Python 3, because is a simple and fast language in terms of development, clean and tidy making extending the project easier and because it has frameworks and libraries suitable for our purpose. Flask is used as the main framework, for its simplicity and because it has the desired capabilities for this project. It is a micro-framework specifically oriented to the development of webs, webapps and APIs. Flask’s main components are Werkzeug as toolkit for applications Web Server Gateway Interface (WSGI) and by Jinja as templating engine. Both components also use Python in their code. The main library used in this project is WTForms in order to describe forms, and already has different predefined field types and validators. Thanks to its simplicity in describing forms makes possible for people without much Python experience or knowledge of the API internals to develop them. The chosen development environment for the project is Linux, which is the operating system on which the API will be running, and this will make easier to find possible errors soon. As IDE Pycharm Community Edition by JetBrains is used and to make the deployment of the database used in the development and testing environments more repeatable and easier Docker is used. This project is composed of two components, the API, that is responsible of accepting, storing, validating and processing the requests, and the forms that describe all the fields and their requirements. With this division, and having a generic enough and well-tested API, when developing forms the API will not need modifications. The next step is the coding phase, which is done simultaneously with tests development. Each new functionality has its tests. This project follows the Python standard coding convention, PEP8, in order to make the code easier to read and edit in the future and by other developers. For automating the tests in order to be sure that new functionality does not break anything and that code is always PEP8 compliant the tox module is used. The project has a testing coverage higher than 95% and all tests use the testing framework pytest. In the next chapter, there is some information about installation, use and maintenance of this project. The requirements for this project to run are just a web server and a database server, Apache HTTP Server and MySQL, both open source projects. To make easier the deployment, load balancing and scalability the project is deployed in a Docker container which will be orchestrated with Kubernetes. As scalability of the API is important, we will see some measures taken in order to increase it, as it is a system with a big load and that should be fail tolerant to achieve a high availability. As others will use this API, usability is also very important in the design, in order for the API to be easy to use. In addition, to make it easier for others to collaborate with the project adding new functionalities to the API or making new forms there is a documentation with information about the project and about setting up the development environment and the expected requirements of future contributions. In order to increase the reusability of the API, the design should be as generic as possible, and right know it would not be only be suitable for requesting new work environments, it can also work for entry data validation and execution of any similar task. Also some conclusions will be drawn to ensure the project meets all the requirements, all the desired capabilities are achieved and about future possible improvements for this or similar projects. The structure of this project will follow the same order as the one described in the previous paragraphs, going deeper into each of them.

More information

Item ID: 64038
DC Identifier: http://oa.upm.es/64038/
OAI Identifier: oai:oa.upm.es:64038
Deposited by: Biblioteca Universitaria Campus Sur
Deposited on: 27 Sep 2020 09:27
Last Modified: 27 Sep 2020 09:27
  • Logo InvestigaM (UPM)
  • Logo GEOUP4
  • Logo Open Access
  • Open Access
  • Logo Sherpa/Romeo
    Check whether the anglo-saxon journal in which you have published an article allows you to also publish it under open access.
  • Logo Dulcinea
    Check whether the spanish journal in which you have published an article allows you to also publish it under open access.
  • Logo de Recolecta
  • Logo del Observatorio I+D+i UPM
  • Logo de OpenCourseWare UPM