Sistema de segmentación de superficies terrestres.
A continuación definiremos las instrucciones para poder tener el proyecto corriendo de manera local. Ve a la sección Instalación.
Para la instalación del proyecto es necesario descargar Docker y Docker Compose
También es necesario descargar los TILES, que son las imagenes que conforman el mapa. Se puede omitir esta descarga utilizando los tiles ubicados en test-data/tiles-mini
Tip: El path donde extraigamos los resultados es conveniente asignarlo a una variable de entorno ya que luego lo utilizaremos
export TILES="/home/tiles"
A continuación definiremos los pasos para correr el proyecto.
git clone https://github.com/mrgrassho/geo-diffUna vez instalado docker es necesario activar el swarm:mode:
docker swarm initCrear volumen, este será el medio donde se almacenarán los tiles, para ello utilizar en device el path de los TILES que descargamos en la etapa de Prerequisitos. Si asignaste el path a la variable $TILES directamente corre el siguiente comando, caso contrario reemplaza $TILES por la ubicación de los archivos es necesario que el PATH sea absoluto
docker volume create --driver local \
--opt type=none \
--opt device=$TILES \
--opt o=bind tiles-dataNota: Asegurar que el directorio de las imagenes no sea propiedad del usuario
root. Para ello correrchwon TU_NOMBRE_USUARIO:TU_NOMBRE_USUARIO $TILES
Buildear stack web y deployar a swarm, el script se encuentra en la folder services
./set_up_stack.sh docker-compose-web.yml geo-diff-web Buildear stack work y deployar a swarm
./set_up_stack.sh docker-compose-work.yml geo-diff-work Utilizando los servicios de AWS logramos deployar exitosamente las dos stacks, a partir de ello armamos una guía de como realizamos la configuración de las instancias y grupos de fw. Además discutimos las disponibilidad de la configuración actual y como mejorarla. VER GUIA AWS
| Aplicación | Función |
|---|---|
| MongoDB | Base de Datos no relacional |
| Mongo-Express | Administrador de MongoDB |
| Backend | Tile Server (Flask) |
| Frontend | UI Web (VueJS) |
| Aplicación | Función |
|---|---|
| RabbitMQ | Servidor de Mensajeria |
| Crawler | Encargado de descargar los tiles |
| Updater | Actualiza resultados procesados por los workers |
| Dealer | Repartidor de tareas a los workers |
| Worker | Procesador de tareas |
| Admin-Worker | Administrador de workers, garantiza que estén activos y realiza autoscaling de workers. Este container tiene acceso a la Docker API por la cual puede crear y eliminar workers a demanda |
El servidor de mensajeria tiene 3 queues, las cuales tiene las siguientes funciones:
| Queue | Función |
|---|---|
| Task Queue | Utilizado para alimentar a los workers. Cada worker tomará imagenes a procesar de esta cola |
| Result Queue | Utilizado para almacenar temporalmente los resultados devueltos por los workers, hasta que el updater consuma el recurso y lo desencole |
| Keep Alive | Esta cola es utilizada por el worker para notificar al admin worker que sigue corriendo |
La principal materia prima del sistema son los tiles crudos (RAW), que serán las imágenes satelitales en formato XYZ - Tiled Web Map que procesará la work stack.
Los recursos son provistos por NASA utilizando la GIBS API. Esta API brinda la posibilidad de descargar los recursos en diferentes formatos, en este caso, utilizamos el acceso generico XYZ - Tiled Web Map ya que es lo mas fácil para crawlear en formato JPEG/PNG.
Para comunicar los resultados entre ambas stacks se utiliza un volumen de Docker que sería una abstracción de un File System, esto permite que ambas stacks corran independientemente una de otra.
- RabbitMQ - Message Broker
- Flask - Micro Web Server in Python
- MongoDB - NoSQL Database
- VueJS - Frontend progressive framework
- OpenLayers - Used for Map render
En el siguiente informe se detalla diferentes pruebas utilizando configuraciones de los parametros que afectan el scaling de la work stack. El principal objetivo del mismo es encontrar el número óptimo de Workers para el hardware disponible. En este caso las pruebas fueron realizadas en una Dell XPS (1.6 GHz Dual-Core Intel Core i5, 8 GB 1600 MHz DDR3) con Ubuntu 20.04 LTS, y con los recursos provistos (~1.2GB en tiles). VER ANÁLISIS
En el siguiente análsis se evaluan diferentes configuraciones del cluster y se analiza la performance bajo diferentes configuraciones. El objetivo principal es definir los parametros adecuados maximizando los recursos disponibles. Además analizamos los tipos de hardware definidos, los parámetros que modifican el comportamiento del cluster y las ventajas de utilizar los servicios de cloud para este tipo de proyectos. En este caso las pruebas fueron realizadas en AWS utilizando 5 instancias t2.micro (3.3 GHz Intel Xeon 1 Core, 1GB de RAM, 8GB* de almacenamiento). VER ANÁLISIS
*Todas las instancias salvo el
manager/adminque tiene 30GB de almacenamiento.
Este projecto esta bajo MIT License - vea el archivo LICENSE.md para mas detalles.