Spring Boot ha sido uno de los proyectos que han contribuido a agilizar el desarrollo de aplicaciones web en Java. De la forma tradicional el siquiera tener una aplicación web con un “Hola mundo” corriendo involucra el descargar el servidor de aplicaciones de nuestra preferencia, configurar el proyecto para desplegar en dicho servidor, agregar un archivo de configuración necesaria en un XML y en algunos casos el definir las conexiones a las bases de datos en el servidor de aplicaciones. Spring Boot, por otro lado nos ahorra toda esta talacha de varias formas, lo más relevante es la inclusión de un servidor de Tomcat embebido, lo cual nos permite el tener una aplicación web corriendo en cuestión de minutos y únicamente siendo indispensable el tener Java y una herramienta de construcción (Maven o Gradle) instalados

. Aquí les dejo un ejemplo: https://spring.io/guides/gs/spring-boot/

Otra de las ventajas de Spring Boot es lo sencillo que es el desplegar una aplicación web en cualquier lugar. El construir un proyecto de Spring Boot con los plugins de Maven genera un archivo ejecutable que es posible correr en cualquier computadora con la versión de Java con la que se compiló el proyecto. Al tener el servidor de Tomcat embebido el abrir el ejecutable levanta este servidor y monta la aplicación, la cual se hace disponible por defecto en el puerto 8080 (http://localhost:8080). Si a esto le añadimos el soporte de una base de datos en memoria con H2 con la siguiente entrada

Podríamos tener una aplicación que literalmente se la podemos pasar a una persona y sin necesidad de configuración alguna y hasta sin necesidad de tener acceso a Internet puede probarla.

Hay una infinidad de otras ventajas que trae consigo Spring Boot, pero me concentraré en una que me sorprendió al verla en acción y es la facilidad en la que uno puede hacer un despliegue en una instancia de Amazon EC2.

A continuación veremos en un caso práctico cómo desplegar una aplicación empaquetada de Spring Boot a una instancia de Amazon EC2, registrarla como un servicio y al final asociarla a un subdominio de un dominio existente, todo esto tomando en cuenta la siguiente configuración:

• Sistema operativo: Amazon Linux
• Base de datos: MySQL 5
• Java 8
• Maven
• Spring Data JPA y Hibernate en la capa de acceso a datos

El proceso involucra las siguientes fases:

• Fase 1: Preparaciones del proyecto - Corresponde a las configuraciones necesarias para distinguir entre los diferentes tipos de ambientes.
• Fase 2: Preparación de la instancia de Amazon EC2 - Una vez que hayamos creado nuestra instancia de Amazon EC2 necesitamos instalar el software necesario para el proyecto.
• Fase 3: Subida de la aplicación - Empaquetada nuestra aplicación la subiremos a la instancia de Amazon y la registraremos como un servicio.
• Fase 4: Registro de un subdominio - Si tenemos un dominio existente podemos crear un subdominio con el cual podamos acceder a la aplicación web.

Fase 1: Preparaciones del proyecto

Configuración de perfiles

Lo primero que es extremadamente recomendable (para mí necesario) es el separar la configuración en un perfil de desarrollo y un perfil de despliegue como mínimo. Spring y Spring Boot facilitan esto de dos formas, la primera es un archivo “application.properties” que viene en el esqueleto de Spring Boot en donde se pueden especificar propiedades de configuración como el puerto usado, nivel de logging, JDBC, etc.

Se pueden definir configuraciones específicas para un perfil creando un archivo properties con el nombre “application”, un guión (-) y el nombre de perfil, por ejemplo:

application-prod.properties : Para el perfil con el nombre “prod” (producción)

application-dev.properties : Para el perfil con el nombre “dev” (desarrollo)

Y claro, en application.properties tendremos las propiedades que serían comunes entre ambos. Ahora si ejecutamos la aplicación generada con el parámetro

Spring cargará las propiedades del archivo application-prod.properties.

De forma similar, podemos discriminar qué Beans de Spring son cargados dependiendo del perfil especificado. Esto se hace únicamente añadiendo la anotación:

Al Bean que va a ser discriminado. Esto es útil por ejemplo para quitar la configuración de H2 en el perfil de producción o la inyección de datos de ejemplo.

Definición de conexiones con la base de datos

Idealmente en el ambiente de desarrollo estaremos usando una base de datos en memoria H2. En la configuración de producción estaremos usando el JDBC de MySQL, por lo que en application-prod.properties especificaremos:

Adicionalmente es recomendable añadir:

Si no incluimos esto anterior la conexión a la base de datos se “muere” después de un determinado periodo de inactividad (no sé el dato exacto pero es menos de 24 horas). Estas propiedades indican que si fracasa el query de validación (SELECT 1) antes de una consulta entonces se destruye la conexión con la base de datos y se crea una nueva.

Ya por último podemos indicar si Hibernate debe de hacer alguna acción con el esquema al iniciar nuestra aplicación con la propiedad:

La cual puede tener los siguientes valores:

• update: Actualiza el esquema (ALTER TABLE)
• create: Elimina el esquema anterior (DROP TABLE) y lo vuelve a crear (CREATE TABLE)
• create-drop: Elimina el esquema al terminar la aplicación y lo crea al iniciar la aplicación

Es importante mencionar que esto anterior es útil para la realización de pruebas o para la creación inicial de la base de datos y es mejor eliminar esta configuración en producción por el cáracter destructivo que representan estas acciones.

Plugin de despliegue

Para poder hacer uso de la funcionalidad de registrar la aplicación como un servicio tenemos que añadir el siguiente plugin de construcción de Spring Boot 1.3:

Hasta esta fecha que Spring Boot 1.3 no ha sido liberado es necesario incluir en el archivo de dependencias el repositorio de milestones de Spring para que obtenga la versión del último milestone indicado anteriormente:

Compilación

Por último empaquetamos nuestra aplicación con

Fase 2: Preparación de la instancia de Amazon EC2

Una vez que hayamos creado la instancia de Amazon Linux en Amazon EC2 y creado nuestro grupo de seguridad para que podamos entrar vía SSH, iniciaremos la instalación del software necesario. Primero nos aseguramos que tengamos actualizados todos los repositorios de yum con

Instalamos los siguientes paquetes:

• MySQL 5.5
• Apache HTTP Server: Servidor HTTP que funciona out-of-the-box y que lo usaremos como proxy.

Desinstalamos la versión de Java 7 que viene preinstalada e instalamos la versión 8:

Inicializamos el servidor de Apache:

Lo hacemos que inicie junto con el inicio el sistema:

Verificamos que todo se encuentre correctamente ingresando a la URL de nuestra instancia de Amazon EC2, lo que nos debe de responder con una landing page del servidor.

Iniciamos el servicio de MySQL:

Configuramos el servidor de MySQL con el siguiente comando:

Esto nos hará las siguientes preguntas:

• Primero es el password de la cuenta de root. Al inicio la cuenta root de MySQL no cuenta con un password por lo que damos Enter. Luego nos pedirá si le queremos establecer un password, lo hacemos.
• Eliminar las cuentas de usuario anónimas
• Deshabilitar login de root de forma remota
• Eliminar las base de datos de prueba
• Recargar los privilegios y guardar los cambios

De preferencia es mejor contestar afirmativo a las preguntas anteriores.

Registramos ahora a MySQL para que inicie junto con el inicio del sistema:

Con esto ya tenemos la instancia lista para nuestra aplicación.

Fase 3: Subida de la aplicación

Aquí entra una caja negra en el proceso. Lo importante es que el JAR o WAR empaquetado se suba al servidor, ya sea por medio de algo tan sencillo como una transferencia SFTP o algo más sofisticado como parte de un Job de Jenkins. En fin, una vez subido es posible registrarlo como un servicio por medio de crear una liga simbólica a init.d, suponiendo que nuestra aplicación está en una carpeta /jar dentro de la carpeta home de ec2-user, el comando sería el siguiente:

Con esto podemos iniciar la aplicación con:

Sin embargo, nunca indicamos qué perfil usar, por lo que la aplicación no se comportará como deseamos. Para indicar el perfil hay que crear un archivo de configuración con terminación .conf que tenga el mismo nombre que el ejecutable, por ejemplo miapp.conf

En este archivo agregamos la siguiente línea que indica los parámetros adicionales que serán añadidos a la ejecución del programa y especificaremos el perfil correspondiente que queremos usar en Amazon

Por último es recomendable el registrar la aplicación para que se inicie con el inicio del sistema, esto se hace de la misma forma que el servidor de Apache y MySQL

Los logs de la aplicación en este modo se estarán registrando en el archivo

/var/log/miapp.log

Última fase: Registro de un subdominio

En esta última sección quiero indicarles cómo de la forma que hemos configurado todo es posible usar un dominio del que tengamos control para generar un subdominio que apunte a nuestra aplicación de Spring Boot. Para esta última parte es necesario el tener un dominio registrado y acceso a su configuración DNS.

Primero es necesario que registremos una nueva “Elastic IP” y asignarla a nuestra instancia para tener una IP fija.

Después usando esta IP creamos un nuevo registro en nuestro DNS con la siguiente configuración:

• Name: subdominio.dominio.com
• TTL: 60
• Class: IN
• Type: A
• Record: {IP fija de la instancia}

Esto hará que el DNS redirija a la instancia cuando se ingrese el subdomino indicado. Ahora es necesario configurar la instancia para redirigir las peticiones al lugar adecuado. Afortunadamente el servidor HTTP de Apache cuenta con una amplia gama de funcionalidades entre las cuales está el poder ser usado como proxy inverso. Podemos indicarle que si llega una petición de un cierto subdominio, se redirija a una determinada dirección. En el caso concreto de lo que queremos, necesitamos redirigir a la dirección local de la instancia de Tomcat lanzada de Spring Boot, que por defecto es ejecutada en el puerto 8080, esto se hace añadiendo la siguiente entrada de hosts virtuales al archivo de configuración alojado en:  /etc/httpd/conf/httpd.conf :

Al final el flujo quedaría de la siguiente forma:

Con esto ya tenemos una aplicación de Spring Boot desplegada completamente y disponible en subdominio.dominio.com. Cabe mencionar que esto es únicamente una forma de varias de alojar una aplicación de Spring Boot y es la que hallé más sencilla y suficientemente controlada, sin embargo, me gustaría conocer si ven mejoras a este proceso y de qué forma y en dónde despliegan ustedes sus aplicaciones de Spring Boot.