AguasNegras

La arquitectura de Heroku es modular, es decir, se pueden añadir funcionalidades al Stack mediante piezas de software llamadas add-ons. Un ejemplo de eso lo vi aquí cuando añadí el soporte para gestión de releases a través de un add-on.

Hay bastantes más add-ons disponibles en la página, para enviar sms, para conectar como amazon rds, etc… Los hay gratuitos, de pago, en beta… en fín, de todo tipo.

En esta práctica voy a añadir el add-on de Redis.

Instalación de Redis

Pues por fín una instalación de un solo paso:

sudo apt-get install redis-server

Una vez instalado, para verificar:

redis-cli

Y debe responder una bonita consola de la que salgo con Ctrl-C.

Cuarta Práctica

Dado que Redis es un almacén del tipo clave – valor (key-value), se da bastante bien para hacer cachés, lo que haré será configurar Redis como un almacenamiento que expire cada 30 segundos, es decir que solo se leerá de la base de datos realmente cada 30 segundos, el resto de las veces se impactará contra Redis. Esto es muy burdo, claro, pero sirve para hacer una demo.

Pasos:

1. Configurar la aplicación para usar Redis.
2. Actualizar TickDAO para que use Redis.
3. Probar la aplicación en local.
4. Desplegar en Heroku.

Paso 1

Esta parte es tan sencilla como añadir al pom.xml esto:

<dependency>
         <groupId>redis.clients</groupId> 
         <artifactId>jedis</artifactId>
         <version>2.0.0</version>
</dependency>

Paso 2
En este paso se modifica TickDAO para primero intente leer los ticks de Redis y si no vaya a la base de datos.
En primer lugar añado como variables estáticas un pool de conexiones a Redis (jedisPool) y la clave de los ticks:

private static JedisPool jedisPool;
private static final String TICKCOUNT_KEY = "tickcount";

A continuación, en el bloque de código static en el que inicializo PostgreSQL, aprovecho y cargo también el pool de Redis, solo resalto que la URL de Redis se lee de una variable de entorno llamada REDISTOGO_URL:

//Inicialización de Redis
Pattern REDIS_URL_PATTERN = Pattern.compile("^redis://([^:]*):([^@]*)@([^:]*):([^/]*)(/)?");
Matcher matcher = REDIS_URL_PATTERN.matcher(System.getenv("REDISTOGO_URL"));
matcher.matches();
Config config = new Config();
config.testOnBorrow = true;
jedisPool = new JedisPool(config, matcher.group(3),
Integer.parseInt(matcher.group(4)), Protocol.DEFAULT_TIMEOUT, matcher.group(2));

Por último, el getTickCount() queda así:

public int getTickCount() throws SQLException {
		Jedis jedis = jedisPool.getResource();
		int tickcount = 0;
		String tickcountValue = jedis.get(TICKCOUNT_KEY);
		if (tickcountValue != null) {
			System.out.println("read from redis cache");
			tickcount = Integer.parseInt(tickcountValue);
		} else {
			tickcount = getTickcountFromDb();
			jedis.setex(TICKCOUNT_KEY, 30, String.valueOf(tickcount));
		}
		jedisPool.returnResource(jedis);
		return tickcount;
	}

Es decir, cuando se va a hacer una lectura, primero se hace desde Redis, si el valor no existe (es null) se lee de base de datos y se inserta en Redis.
A probar.

Paso 3
Aquí vendría todo el mvn install, etc, pero antes, como ya estoy harto de andar exportando las variables de entorno cada vez que voy a hacer algo en local, voy a hacer dos cosas.
Primero, voy a crear un exportarVariables.sh que exportar tanto REPO, como POSTGRESQL_URL como REDISTOGO_URL.
Así que:

gedit exportarVariables.sh

Y pongo lo siguiente:

export REPO=~/.m2/repository
export DATABASE_URL=postgres://helloheroku:helloheroku@localhost/helloheroku
export REDISTOGO_URL=redis://:@localhost:6379/

Ahora hago el script ejecutable:

chmod 777 exportarVariables.sh

Y como segundo paso, ya que este archivo solo es aplicable en local, lo añado al .gitignore. Hala, listo, ahora sí que sigo de la manera habitual:

mvn install
. ./exportarVariables.sh
sh target/bin/webapp

Y ahí esta, si entro en localhost:8080/ticks.jsp, veré que siempre muestra los mismos ticks… hasta que pasan 30 segundos, que actualiza la cuenta con el número de veces que haya recargado la página. Es decir, se esta escribiendo en base de datos, pero no se esta leyendo. Hasta pasados 30 segundos, claro.

Paso 4
Vale, pues para desplegar, primero tengo que añadir el add-on de Redis al Stack de esta aplicación en Heroku:

heroku addons:add redistogo:nano
-----> Adding redistogo:nano to fierce-autumn-4530... done, v11 (free)

Correcto, ahora basta con dar los pasos habituales:

git add .
git commit -m "añadido Redis para caché de lectura"
git push github master
git push heroku  master

Listo, con esto ya hago un heroku open y abro ticks.jsp, puedo ver que el comportamiento es exactamente igual que cuando ejecuto en local.

Código en GitHub

Conclusiones
Añadir add-ons a Heroku es trivial, en general consiste en bajar la librería que proporciona la api y listo (teniendo instalado el servicio en local, claro).
También es interesante que si escalo el proceso tick a un par de dynos, siguen impactando contra Redis, es decir, no levantan su propia instancia de Redis, realmente esta funcionando como una caché en RAM.

Heroku no solo sirve para ejecutar aplicaciones web Java, sino que en realidad sirve para ejecutar cualquier tipo de aplicación Java. Observando el proyecto podemos ver que hay dos aplicaciones bien diferenciadas, la aplicación web (que se lanza a través del script webapp generado por Maven) y la aplicación SchemaGenerator, ejecutada a través del script schemaGenerator. Mientras que la primera es una aplicación web normal y corriente, SchemaGenerator es simplemente un proceso Java puro, se lanza se ejecuta y termina sin ningún tipo de interfaz gráfica involucrada.

A este tipo de proceso en Heroku le llaman “worker process”, podría traducirlo de cualquier manera, pero paso, así que se queda como proceso worker, hala.

Tercer Práctica

El objetivo de esta práctica es desarrollar una aplicación que inserte un tick en la base de datos cada segundo. Se podrá visualizar refrescando la misma página ticks.jsp y posteriormente la escalaré a dos dynos.

Pasos:

1. Crear la clase Ticker.java que insertará un tick en la base de datos cada segundo.
2. Probar la aplicación en local.
3. Desplegar la aplicación en Heroku, escalarla a dos dynos y detenerla.

Paso 1

Creo la clase Ticker.java, el código es trivial, con un while(true) y un sleep(1000), de todas formas queda en GitHub.

Se declara el programa en el pom.xml para generar el script que lo lanza:

	es.aguasnegras.helloheroku.Ticker
	ticker

Paso 2

Se instala en local y se ejecuta:

mvn install
export REPO=~/.m2/repository
export DATABASE_URL=postgres://helloheroku:helloheroku@localhost/helloheroku
sh target/bin/ticker

Y en otra consola:

export REPO=~/.m2/repository
export DATABASE_URL=postgres://helloheroku:helloheroku@localhost/helloheroku
sh target/bin/ticker

Ahora puedo comprobar en localhost:8080/ticks.jsp que efectivamente, se van actualizando los ticks independientemente de la aplicación.

Paso 3
Vale, ahora a desplegarla en Heroku. Para poder ejecutar el proceso en Heroku en su propio dyno, hay que declararla en el Procfile:

tick: sh target/bin/ticker

Listo, añado a git y subo a GitHub y Heroku:

git add .
git commit -m "añadido proceso worker"
git push github master
git push heroku master

Si abro http://fierce-autumn-4530.herokuapp.com/ticks.jsp puedo ver que todo sigue igual, cada vez que recargo la página se añade un tick a la base de datos. Voy a arrancar el worker:

heroku scale tick=2

Si hago un heroku ps me confirma que se han arrancado dos procesos, y es más, un heroku logs -t va refrescando la salida con dos ticks cada segundo, uno tick.1 y otro tick.2.
Además el jsp me confirma que se han ido insertando en la base de datos.
Bueno, pues ya esta. A poner el código en GitHub

Código en GitHub

Conclusiones
Bueno, pues ya he visto como se ejecuta un proceso demonio y he trasteado un poco el Procfile, que es otro fleco que convendría investigar un poco, a ver que más cosas se pueden hacer.
Es curioso que el proceso se lanza mediante un scale y no un heroku run, supongo que podría igualmente con el heroku run… a ver. Efectivamente, se puede ejecutar igualmente con un heroku run, la diferencia es que no se puede escalar, claro.

Una de las cosas que más me impresionó de Ruby on Rails, más que el framework en sí o el lenguaje, fue el excelente soporte que había creado la comunidad. Hablo específicamente de como se enlazaba tu proyecto local con GitHub y GitHub con Heroku, con lo cual podías tener el proyecto en producción en cuestión de minutos.

Esto es algo que lamentablemente no he visto en Java en los cinco años que llevo dedicado a estos menesteres, y menos con un alojamiento de la categoría de Heroku (otro día hablaré sobre ello y el PaaS, etc…). Pues bien, el pasado 25 de Agosto, Heroku añadió soporte para Java. Este paso me parece crucial. Desde mi punto de vista, la gran fortaleza de PHP, RoR, etc… viene de la comunidad, es un lenguaje “accesible” a cualquiera, basta con comparar los hostings existentes para PHP y los existentes para Java. Hay otras plataformas para Java, por ejemplo, Google App Engine, pero desde mi punto de vista son mucho más restrictivas que Heroku. Como de todas formas esto es solo una impresión, he decidido seguir el Heroku For Java Workbook a ver qué tal resulta

Requisitos

1. Cuenta en GitHub.
2. Cuenta en Heroku.
3. Tener instalado Git

Instalación de las herramientas de línea de comando de Heroku (heroku)

Lo primero es instalar las herramientas de linea de comando de Heroku, llamadas heroku (sin mayúscula), estas a su vez tienen otros requisitos:

1. Instalar Ruby (apt-get install ruby).
2. Instalar RubyGems (se descarga de RubyGems.org y se ejecuta sudo ruby setup.rb)
3. Se instala el cliente en sí: sudo gem install heroku.
4. Para verificar si todo ha ido bien, el comando heroku version debe devolver algo como heroku-gem/2.6.1

El siguiente paso es añadir nuestra clave SSH pública a Heroku, primero se hace login: heroku auth:login, e introducimos nuestro email y contraseña.

A continuación basta con hacer heroku keys:add y listo, añadida nuestra clave SSH.

Instalación de Maven

La instalación de Maven viene descrita en su misma página de descarga de manera bastante sucinta. En cualquier caso estos son los pasos a dar:

1. Descomprimir el archivo (en mi caso en $HOME/Herramientas).
2. Añadir la variable de entorno M2_HOME, que es el directorio de Maven (en este caso sería export M2_HOME=$HOME/Herramientas/apache-maven-3.0.3)
3. Añadir la variable de entorno M2 que son los binarios de Maven (export M2=$M2_HOME/bin)
4. Añadir la variable MAVEN_OPTS al entorno. Esta variable son comandos que se pasan a la JVM que ejecuta Maven, en nuestro caso será para aumentar la memoria disponible para la ejecución de Maven (por defecto son 64 Mb, pero la vamos a aumentar a 256): export MAVEN_OPTS=”-Xms256m -Xmx512m”.
5. Añadir la variable M2 al Path: export PATH=$M2:$PATH
6. Si ejecutamos mvn –version debería salir la versión actual de Maven (3.0.3), la version de la JVM, etc…

Primera Práctica

El objetivo de esta primera práctica es construir una aplicación web, es decir un simple html con su web-inf, etc. Los pasos son cuatro:

1. Crear la aplicación web a partir de un arquetipo de Maven.
2. Probar la aplicación web en local.
3. Desplegar la aplicación web en Heroku.
4. Escalar la aplicación web en Heroku.
5. Ver los logs de la aplicación en Heroku.
6. Deshacer una publicación en Heroku.

Paso 1

Entro en mi directorio de trabajo (Heroku) y una vez dentro genero el proyecto con la siguiente línea:

mvn archetype:generate -DarchetypeCatalog=http://maven.publicstaticvoidmain.net/archetype-catalog.xml

Ahora Maven irá preguntando por una configuración básica del proyecto, estas son las respuestas que he ido dando:

1. Pregunta el arquetipo que se desea usar, realmente solo hay uno, así que pulso 1.
2. GroupId es el identificador del equipo de desarrollo, en este caso y por nomenclatura Java (es también el prefijo de toda la paquetería): es.aguasnegras
3. ArtifactId es el nombre del proyecto: helloheroku
4. Version se deja en blanco, será la 1.0-SNAPSHOT
5. Package es la paquetería del proyecto, introduzco es.aguasnegras.helloheroku
6. Por último, muestra un resumen y pide confirmación: Y.

Con esto tengo el proyecto creado según la estructura de directorio estándar de Maven. Debo tener un index.html, un Main.java y un pom.xml que contiene la configuración del proyecto según Maven.

Lo interesante es el Main.java. En Heroku no despliego sobre un servidor de aplicaciones (caso usual en Java) sino que es la misma aplicación la que crea su servidor, Jetty (por eso el arquetipo de Maven era embedded-jetty-archetype). Esto tiene sus pros y sus contras, pero de momento esta bien. Se puede ver en el main de Main.java como se instancia el servidor.

Una ventaja de esto es que voy a poder probar la aplicación en local sin tener que caer en todo el tedio de instalar un Tomcat, un Weblogic, un JBoss o un Glassfish. Y ese es el siguiente paso.

Paso 2

Primero hay que tener en cuenta que Maven me gestiona las dependencias (librerías, vaya) en tiempo de compilación, si quiero tenerlas disponibles en tiempo de ejecución (cuando arranque en local), tengo que exportar una variable llamada repo:

export REPO=~/.m2/repository

Para arrancar la aplicación en local, entro en el directorio (helloheroku) y ejecuto:

mvn install
sh target/bin/webapp

Abro en un navegador localhost:8080 y ahí esta: “hello, world”.

Para parar la aplicación, Ctrl-c en la consola y listo. Una vez probada en local, hay que moverla (pasarla, exportarla, publicarla… publicarla, sí, me gusta) a Heroku.

Paso 3

Para publicar la aplicación en Heroku, primero hay que crear un archivo llamado “Procfile” en el raíz del proyecto y añadirle una línea describiendo como se arranca la aplicación:

touch Procfile
echo web: sh target/bin/webapp | tee Procfile

Creo un repositorio de git para el proyecto:

git init
git add .
git commit -m "commit inicial del proyecto helloheroku"

Ahora viene lo bueno, la parte de cacharreo con Heroku.

Primero creo el stack de Heroku que va a alojar la aplicación, este stack tiene que ser del tipo “cedar” que es el único que admite aplicaciones Java:

heroku create --stack cedar
Creating fierce-autumn-4530... done, stack is cedar
http://fierce-autumn-4530.herokuapp.com/ | git@heroku.com:fierce-autumn-4530.git
Git remote heroku added

El comando me ha devuelto una URL http y otra para git. Si abro la URL en un navegador, me dice que enhorabuena, tengo creada mi app.
Ahora, con git, envío el master local a Heroku:

git push heroku master

Cuando llegue a Heroku veré en la consola que se lanza un proceso de Maven (mvn install) y que se detecta el Procfile y se lanza la aplicación web. Por último, me informa de que se ha desplegado en la URL correctamente.

-----> Heroku receiving push
-----> Java app detected
-----> Installing Maven 3.0.3..... done
-----> Installing settings.xml..... done
-----> executing .maven/bin/mvn -B -Duser.home=/tmp/build_s6y8o29xnjfx -s .m2/settings.xml -DskipTests=true clean install
 
-----> Discovering process types
       Procfile declares types -> web
-----> Compiled slug size is 12.8MB
-----> Launching... done, v5
       http://fierce-autumn-4530.herokuapp.com deployed to Heroku

Si ahora abro http://fierce-autumn-4530.herokuapp.com/ en el navegador, puedo ver el “hello, world”.

Bueno, pues ya esta desplegada la aplicación en un servidor, ahora, ¿cómo se aumenta?

Paso 4

Ya esta desplegada la aplicación en un servidor, pero claro, esto no sería la nube si no pudiera ampliar fácilmente los servidores en los que ejecuta. Voy a aumentar la aplicación a dos servidores:

heroku scale web=2
Scaling web processes...  This action will cause your account to be billed at the end of the month
 For more information, see http://docs.heroku.com/billing
 Are you sure you want to do this? (y/n) y
Scaling web processes... done, now running 2

La verdad que no entiendo muy bien como pretenden cobrarme, porque no he dado ningún dato… pero oye… ellos mismos. Aunque habrá que mirar más a fondo el tema de como cobran.

Por último, voy a verificar que efectivamente estan corriendo dos instancias y voy a reducir a una de nuevo:

heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 17m          sh target/bin/webapp
web.2         up for 2m           sh target/bin/webapp
 
heroku scale web=1
Scaling web processes... done, now running 1

Hasta el momento toda esta información de salida es bastante… escueta. ¿Cómo se ven los logs?

Paso 5

Pues muy fácil, hay dos forma de ver los logs, estática o dinámica. Estática, me muestra lo que hay hasta el momento:

heroku logs

Dinámica, no deja de ser un tail, va actualizando el log según se van creando mensajes nuevos:

heroku logs -t

Paso 6

Por último, Heroku ofrece soporte para control de versiones. No me refiero solo a código, si no también, como en el ejemplo a variables de entorno, por ejemplo.

Primero me aseguro de que el servidor tiene soporte para el control de releases, mediante el addon de releases:

heroku addons:add releases:basic
-----> Adding releases:basic to fierce-autumn-4530... failed !    
releases:basic add-on already added.

Esta añadido, ahora voy a añadir una variable de entorno y a verificar que se ha hecho:

heroku config:add MYVAR=42
Adding config vars:  MYVAR => 42
Restarting app... done, v6.
 
heroku config
DATABASE_URL        => postgres://tpqbfpkzqb:OILC1r62mtQ5YkqKTeA7@ec2-107-20-227-173.compute-1.amazonaws.com/tpqbfpkzqb
JAVA_OPTS           => -Xmx384m -Xss512k -XX:+UseCompressedOops
MAVEN_OPTS          => -Xmx384m -Xss512k -XX:+UseCompressedOops
MYVAR               => 42
PATH                => .maven/bin:/usr/local/bin:/usr/bin:/bin
REPO                => /app/.m2/repository
SHARED_DATABASE_URL => postgres://tpqbfpkzqb:OILC1r62mtQ5YkqKTeA7@ec2-107-20-227-173.compute-1.amazonaws.com/tpqbfpkzqb

Muy bien, pues ahora, toca volver atrás:

heroku releases
Rel   Change                          By                    When
----    ----------------------          ----------                   ----------
v6    Config add MYVAR    agustinventura@gma..  45 seconds ago           
v5    Deploy cd3c58f          agustinventura@gma..  29 minutes ago           
 
heroku rollback
Rolled back to v5
 
heroku config
DATABASE_URL        => postgres://tpqbfpkzqb:OILC1r62mtQ5YkqKTeA7@ec2-107-20-227-173.compute-1.amazonaws.com/tpqbfpkzqb
JAVA_OPTS           => -Xmx384m -Xss512k -XX:+UseCompressedOops
MAVEN_OPTS          => -Xmx384m -Xss512k -XX:+UseCompressedOops
PATH                => .maven/bin:/usr/local/bin:/usr/bin:/bin
REPO                => /app/.m2/repository
SHARED_DATABASE_URL => postgres://tpqbfpkzqb:OILC1r62mtQ5YkqKTeA7@ec2-107-20-227-173.compute-1.amazonaws.com/tpqbfpkzqb

¡Listo! Hecha la vuelta atrás a la última publicación estable.

Código en GitHub

Conclusiones

Pues de momento parece que Heroku ofrece lo que promete, uso de Java estándar, e integración con herramientas actuales: git y Maven. Además me ha sorprendido gratamente la herramienta de consola con más utilidades de lo que parece y que hace muy sencillo aumentar el número de instancias de la aplicación.

Esto sí, echo en falta… un plugin de Eclipse, tendré que investigar si existe o esta en desarrollo.

Igualmente tengo que investigar bien las opciones de facturación y algunos conceptos como dyno, stack, etc…