Estudio de las condiciones meteorológicas en Granada a través de la información facilitada por la Agencia Estatal Española de Meteorología (AEMET)

Contenido

• Descripción del proyecto
  • Arquitectura
  • Testeo y pruebas
  • Framework y lenguaje a utilizar
• Desplegar el proyecto
• Provisionamiento de máquinas virtuales
  • Comprobación del provisionamiento en otra máquina
  • Comprobación del provisionamiento de otro compañero en mi máquina
  • Avance en el proyecto
• Automatización de la creación de máquinas virtuales
  • Avance en el proyecto
• Orquestación de máquinas virtuales
  • Comprobación de mi provisionamiento en otra máquina
  • Comprobación del provisionamiento de otro compañero en mi máquina
  • Últimos avances en el proyecto
• Dockers
• Licencia

En este proyecto, se pretende hacer un pequeño análisis de la información actualizada que nos proporciona la API de la Agencia Estatal Española de Meteorología. De esta forma, se pretende procesar la información de la misma, mostrando aquella más trascendental para los usuarios de Granada en distintas plataformas.

A través de la API de dicha plataforma, se va a acceder a la información más actualizada, y se irá almacenando, de entre dicha información, aquella que en términos generales interesa más a los usuarios.

Se pretende abordar dicho análisis de información en distintos ámbitos. Por una parte, la posibilidad de acceder a la temperatura actual, los centímetros cúbicos registrados, o la temperatura más alta/baja detectada durante ese día. En segundo lugar, proporcionar distintos análisis semanales y mensuales a partir de la información obtenida a partir de los datos actualizados que se van proporcionando a lo largo del tiempo. Este último análisis tiene su interés, ya que las estructuras de datos facilitadas a nivel semanal/mensual son menos específicas en cuanto a la información mostrada diariamente, y puede que haya aspectos de la información diaria de interés para el usuario a nivel semanal o mensual, y que actualmente vea restringido su acceso a dichos datos.

Los usuarios podrán acceder a toda la información que se analice mediante dos formas:

• A través de Twitter: se publicarán diversos tweets con la información más importante que se ha ido recabando.
• A través de un bot de Telegram también se podrá acceder a la información más relevante.

De esta forma, se pretende facilitar al usuario la consulta de la información más trascendental de una forma sencilla y rápida a través de plataformas utilizadas diariamente por millones de usuarios, como es el caso de las redes sociales mencionadas anteriormente.

Se va a utilizar una arquitectura basada en microservicios en sustitución a una arquitectura monolítica. De este modo podremos realizar y modificar cambios en el software de forma sencilla e independiente, aprovechando las ventajas que nos aporta este tipo de arquitecturas, como pueden ser:

• Versatilidad
• Autonomía: podemos actualizar un microservicio sin que dependa de los demás
• Facilidades de integración
• Aislamiento de errores: un fallo en un microservicio afectará al funcionamiento del mismo, y no tiene por qué afectar a las demás funcionalidades.

Tendremos así, una colección de distintos microservicios, donde cada uno se encargará de implementar una funcionalidad dentro de la totalidad del proyecto.

Los microservicios que se van a utilizar son los siguientes:.

• Un microservicio que se encargue de acceder a la API de la AEMET y se encargue de procesar la información obtenida.

• Un microservicio para almacenar toda la información a manejar en una base de datos.

• Un microservicio para realizar el análisis de datos. de los valores medidos a lo largo del día o la semana que puedan ser de interés.

• Tendremos un microservicio que se encargue de publicar tweets, con información relevante obtenida (a través de tweepy, y otro microservicio diferente que consistirá en un bot de telegram en el cuál podamos también poner a disposición del usuario aquellos datos que puedan ser de mayor importancia (en principio a través de telebot).

• Por último, existirá un microservicio LOG, con el que se comuniquen todos los microservicios anteriores.

Para la comunicación entre los distintos microservicios, se realizará mediante brokers. En este caso, el broker a utilizar será RabbitMQ.

A continuación, en la siguiente imagen, se puede ver un pequeño esquema de los microservicios a utilizar:

Puede consultar más información acerca de la arquitectura aquí.

Cada microservicio se testeará de forma individual, antes de desplegarlo en la nube. La realización de los tests se llevará a cabo mediante TRAVIS, y dichos tests se implementarán en Python (ya que es el lenguaje utilizado en el microservicio) con ayuda de la librería unittest.

Se va a utilizar como lenguaje de programación Python y Flask como microservicio. Además, el proyecto será desplegado en Azure.

Despliegue: https://agile-mountain-82339.herokuapp.com/

Se ha realizado un despliegue del servicio web, realizada en el PaaS Heroku. Para ello se han seguido una serie de pasos, que se pueden encontrar aquí, donde se hace un breve repaso de todo el procedimiento que se ha seguido desde el funcionamiento del servicio en localhost hasta su despliegue en Heroku con las comprobaciones correspondientes. También se puede apreciar en ese fichero todas las decisiones tomadas para llevar a cabo el procedimiento.

En este documento se detallan los distintos pasos seguidos hasta conseguir provisionar una máquina virtual (primero a nivel local y posteriormente en Azure), con todo lo necesario para poder ejecutar en ella nuestro proyecto. Para ello, se seguirán los siguientes pasos:

1. Uso de Vagrant y Ansible para provisionar una máquina virtual desde local.

2. Uso de Ansible para provisionar una máquina virtual en la plataforma Azure.

Más información aquí.

MV: 137.117.174.154

Hecho por @adrianmorente, puede consultarse en este fichero.

Se ha comprobado que el provisionamiento realizado por @adrianmorente funciona de manera correcta. Puede consultarse aquí.

Para el hito 3, se ha avanzado el proyecto añadiendo persistencia a los datos que utiliza el servicio. Para ello, se ha añadido una base de datos con mLab. A la documentación de esta avance en el proyecto se puede acceder aquí.

Por supuesto, se han añadido todos los tests necesarios para asegurar el funcionamiento correcto de esta nueva funcionalidad.

MV2: 40.89.191.234

Se ha desarrollado un script de aprovisionamiento y creación de máquinas virtuales, con el objetivo de automatizar esta tarea. Para ello, se ha utilizado el cliente de Azure (para poder crear la máquina virtual desde línea de órdenes) y ansible (para el posterior provisionamiento).

Por otra parte, se han contemplado y justificado distintas posibilidades a la hora de elegir algunos parámetros clave en la creación de máquinas virtuales en Azure, como puede ser la región, la imagen o el tamaño de la propia máquina virtual.

Se puede acceder a la información detallada en este fichero.

Para este hito, vamos a realizar un avance en el proyecto, que consiste en añadir la utilidad de logs a nuestra aplicación.

Para ello, vamos a utilizar la librería logging de Python, que nos permitirá poder gestionar los distintos mensajes que se deban enviar en nuestra aplicación. Se puede consultar más información acerca del avance aquí.

Despliegue Vagrant: 20.188.33.145

En este hito, se ha realizado la orquestación de dos máquinas virtuales en Azure, donde una de las máquinas alojará la base de datos, y la otra, el servicio REST que estamos desarrollando (el cuál hace uso de dicha base de datos, ya que es de donde adquiere la información). Para ello, haremos uso de Vagrant, una herramienta para la creación y configuración de entornos de desarrollo.

Se puede acceder a la documentación de todo lo llevado a cabo aquí.

Realizado por @AlejandroCN7, puede consultarse en este enlace.

Se ha comprobado que el provisionamiento realizado por @AlejandroCN7 funciona de manera correcta. Puede consultarse en este enlace.

Se ha llevado a cabo el provisionamiento de una máquina para poder disponer de MongoBD en local:

• Hasta ahora se utilizaba MongoDB desde mLab, por lo que se ha adaptado para poder ejecutarlo desde cualquier IP, ya sea localhost, o una que nosotros establezcamos.

• También se ha realizado el provisionamiento con ansible correspondiente, junto con la configuración del servicio asociado, para que, una vez finalizado el provisionamiento, tengamos el servicio correctamente configurado y lanzado.

A la documentación correspondiente a este avance se puede acceder desde aquí.

Contenedor: http://51.145.6.41/ Docker Hub: https://hub.docker.com/r/andreamorgar/proyecto

En este hito, se ha desplegado el proyecto en un contenedor, utilizando para ello Dockers y Azure. En este enlace, podemos acceder a la documentación asociada y a los pasos seguidos para ello.

Este software se desarrollará bajo la licencia GNU General Public License v3.0