Computación en la nube y GIS: un ejemplo práctico con PostGIS

La computación en la nube ha supuesto sin duda un cambio de paradigma a la hora de desarrollar nuevos modelos de negocios dentro de las tecnologías de la información. Una de sus mayores virtudes es su eficiencia y flexibilidad frente a servicios que cada vez demandan un mayor incremento de recursos en centros de datos muchas veces limitados. Y es que debemos comprender que muchas veces el fuerte desarrollo del cloud computing no es más que un reflejo del creciente despliegue de nuevas tecnologías en el ámbito del big data, las plataformas móviles, los modelos pay-as-you-go, etc.

Tres son los modelos de servicios más comunes de computación en la nube:

• Infraestructura como Servicio (IaaS). Ofrece infraestructura de procesamiento. El usuario es el que monitoriza y gestiona su propio centro de datos remoto en un modelo de «autoservicio». En lugar de tener que comprar hardware de una manera pura y dura, puede adquirir una IaaS basado en un consumo estimado (como haría al contratar otros servicios como la electricidad, telefonía, etc.). Ejemplos típicos de IaaS serían Amazon Web Services, Windows Azure o Google Compute Engine.

• Plataforma como Servicio (PaaS). Aquí el sistema operativo viene ya preinstalado y es mantenido por el proveedor, por lo que es más barato que las IaaS. El usuario, que a diferencia de las IaaS no tiene privilegios de root, es el responsable de configurar (a veces también de instalar) los programas como lo haría a un nivel de usuario. Ejemplos de PaaS hay muchos: OpenShift, Heroku, SAP Cloud Platform, Google App Engine, etc.

• Software como Servicio (SaaS). Sería el servicio de computación más difuso. Utiliza la web para ofrecer aplicaciones que son administrados por un proveedor y a cuya interfaz accede el usuario. La mayoría de las aplicaciones SaaS se pueden ejecutar directamente desde un navegador web sin ningún tipo de descarga o instalaciones necesarias (aunque algunas pueden requerir plugins). El usuario se despreocupa de instalar y ejecutar aplicaciones en equipos individuales. ESRI ArcGIS Online, Microsoft Office 365 o incluso Gmail o Facebook serían ejemplos de SaaS.

En su conjunto a veces nos referimos a todos ellos como XaaS (X as a Service) para aludir a cualquier cosa que es susceptible de ofrecerse como servicio utilizando para ello la nube.

PaaS con un toque geoespacial

En esta entrada veremos un sencillo ejemplo de como desplegar un servidor de bases de datos PostgreSQL con sus extensiones de análisis espacial y de redes (PostGIS y pgRouting) en uno de estos servicios de computación en la nube de manera gratuita. Actualmente existen una gran cantidad de servicios de computación en la nube que ofrecen capas gratuitas para desarrolladores. Aquí utilizaremos OpenShift.

OpenShift es un producto de computación en la nube de la empresa Red Hat Enterprise, muy conocida por estar detrás de las distribuciones Linux Red Hat, Fedora y CentOS. Como PaaS que es permite al usuario centrarse en lo realmente importante: el desarrollo del servicio, mientras que la mayor parte de las tareas de administración son delegadas a la plataforma. Es quizá uno de los más conocidos dentro de los PaaS, ofreciendo 3 contenedores de aplicaciones básicos gratuitos. Las limitaciones para este tipo de cuentas son, por unidad (o gear) y a fecha de este artículo, de:

• 1 GB de datos
• 512 MB de RAM
• 15 páginas/segundo
• ~50k visitante por mes

Los límites de transferencia de datos son dinámicos, por lo que no debería haber problemas para el uso de aplicaciones web o móviles sencillas de ensayo, no así si se hace uso de streaming. Como ejemplo puedo comentar que nosotros tenemos desplegado a modo de prueba piloto en una cuenta de este tipo de OpenShift el servidor OTP que funciona bajo SantanderGo!, un servicio de planificación multimodal de itinerarios viajes. Este motor de enrutamiento, que se ejecuta en Apache Tomcat, planifica rutas para la ciudad de Santander y su área metropolitana sin ningún problema desde hace unos años, tanto para clientes web como dispositivos móviles.

A por nuestro PostGIS en la nube

Lo primero que haremos es crear una cuenta gratuita en OpenShift y dar de alta un namespace único que se aplicará a todos los Gear. Por ejemplo si elegimos como namespace «nostromo» la url a través de la cual accederemos a nuestra aplicación será:

http://miapp-nostromo.rhcloud.com

Antes de continuar debemos entender dos conceptos clave en OpenShift:

• Gear: En OpenShift es la unidad de capacidad dentro de un servidor virtual, con unos recursos limitados para que un usuario pueda ejecutar sus aplicaciones.

• Cartridge: Serían los contenedores de software preparados para ejecutarse en un «gear». En principio sobre cada gear pueden desplegarse varios cartridges, por ejemplo existen contenedores de Python, Ruby, Node.js, PHP, Django, etc. Así, para una aplicación como Geoserver necesitaríamos los cartridges de Tomcat y PostgreSQL. Si queremos ejecutar una aplicación independiente siempre podemos construirnos nuestro propio cartridge “Do-It-Yourself”.

Aunque muchas de estas aplicaciones se pueden instalar a través del panel de control web que te facilita OpenShift, aquí vamos a ver como se puede realizar todo esto por consola con la versatilidad que ofrece las OpenShift Client Tools, conocida como rhc. Para ello necesitaremos instalar previamente Ruby:

emilio@gerty:~$ sudo apt-get install ruby rubygems
emilio@gerty:~$ sudo gem install rhc

Los usuarios de Windows y MacOS pueden seguir los pasos de instalación de esta página.

A continuación ejecutamos rhc para realizar la configuración inicial:

emilio@gerty:~$ rhc setup

Y nos pedirá los siguientes datos:

Enter the server hostname: |openshift.redhat.com| (lo dejamos vacío)
Login to openshift.redhat.com: (la dirección de correo electrónico con que nos registramos)
Password: (la contraseña que utilizamos)

Si previamente no hemos indicado ningún namespace nos solicitará también uno.

A continuación nos indicará si queremos generar un token para acceder a nuestra instancia sin utilizar nuestra contraseña. Esto creará una clave privada que se almacenará en nuestro directorio de usuario ~/.ssh/id_rsa.pub de nuestro ordenador y otra pública que se enviará al servidor.

El siguiente paso es crear una aplicación nueva en OpenShift en la que instalaremos PostgreSQL y opcionalmente un lenguaje de programación como Python. Ten en cuenta que la base de datos recibirá el nombre que demos a la aplicación (en mi caso «luna»):

emilio@gerty:~$ rhc app create luna python-2.7 postgresql-9

Using postgresql-9.2 (PostgreSQL 9.2) for 'postgresql-9'
Application Options
-------------------
Domain: nostromo
Cartridges: python-2.7, postgresql-9.2
Gear Size: default
Scaling: no
Creating application 'luna' ...

Adicionalmente podemos comprobar la información del estado de nuestra aplicación recién creada mediante:

emilio@gerty:~$ rhc app show luna

Y volver a eliminarla con:

emilio@gerty:~$ rhc app delete luna

Es importante señalar que la máquina virtual se apaga tras 24 horas sin recibir ningún tipo de petición, por lo que si vemos que no conectamos con ella simplemente deberemos reiniciarla:

emilio@gerty:~$ rhc app restart -a luna

Un vez concluida la instalación accedemos a la aplicación mediante una conexión SSH, ejecutamos la terminal interactiva de PostgreSQL psql y añadimos las extensiones espaciales típicas a la base de datos:

emilio@gerty:~$ rhc ssh -a luna

[luna-nostromo.rhcloud.com ]\> psql
psql (9.2.14)
Digite «help» para obtener ayuda.

luna=# CREATE EXTENSION postgis;
CREATE EXTENSION
luna=# CREATE EXTENSION postgis_topology;
CREATE EXTENSION
luna=# CREATE EXTENSION pgrouting;
CREATE EXTENSION

Y finalmente salimos de psql:

luna=# \q

Antes de abandonar nuestra sesión SSH anotaremos los datos de configuración de nuestro servidor PostgreSQL (usuario, contraseña, base de datos, puerto) que necesitaremos posteriormente:

[luna-nostromo.rhcloud.com ]\> env|grep POSTGRESQL
[luna-nostromo.rhcloud.com ]\> exit

Una vez tenemos ya configurada toda nuestra aplicación en Openshift realizaremos un redireccionamiento de puertos (port forwarding) de nuestra máquina local a los de la base de datos remota. La idea básica es redirigir la conexiones desde un puerto de red de nuestro equipo a otro del gear de OpenShift que se encuentra a la escucha. Para ello abrimos otra consola diferente en nuestro ordenador y realizamos un port-forward de la aplicación que se desea monitorizar:

emilio@gerty:~$ rhc port-forward -a luna

Checking available ports ... done
Forwarding ports ...
Address already in use - bind(2) while forwarding port 5432. Trying local port 5434

To connect to a service running on OpenShift, use the Local address

Service    Local               OpenShift
---------- -------------- ---- -----------------
httpd      127.0.0.1:8080  =>  127.6.47.110:8080
postgresql 127.0.0.1:5434  =>  127.6.47.120:5432

Press CTRL-C to terminate port forwarding

Volvemos a la consola anterior y ya podemos importar nuestra cartografía en la base de datos PostgreSQL:

emilio@gerty:~$ shp2pgsql -I -s 930100 -d -S MoonNomenclature.shp nomenclatura | psql -U usuario -h 127.0.0.1 -p 5434 -d luna

emilio@gerty:~$ shp2pgsql -I -s 930100 -d -S MoonCraters.shp crateres | psql -U usuario -h 127.0.0.1 -p 5434 -d luna

emilio@gerty:~$ raster2pgsql -I -s 930100 -C -F -M -Y -l 2 -t 50x50 MoonDEM.tif > LunaMDE.sql
emilio@gerty:~$ psql -U usuario -h 127.0.0.1 -p 5434 -d luna -f LunaMDE.sql

Finalmente ya solo nos queda conectarnos con nuestro cliente de escritorio GIS preferido a nuestra base de datos remota y visualizar las tablas:

Imágen de cabecera adaptada del original de FutUndBeidl, bajo licencia CC BY 2.0.