La bitacora en aplicación java

Todos los servidores aplicativos, cuentan con un sistema de bitácoras (logs). Este sistema de bitácoras, es posible aprovecharlo para desarrollar una aplicación web, sin necesidad de definir, ni depender de una implementación de bitácora en particular.

Requisitos

• ubuntu 14.04
• docker
• cliente svn

Instalación

Código fuente

Crear el directorio de trabajo

$ mkdir -p $HOME/razzek/lab/java-logging

Descargar el codigo fuente

$ cd $HOME/razzek/lab/java-logging
$ svn co https://svn.riouxsvn.com/razzeklabs/trunk/java_logging/ .

Ejecución

Ejecutar los scripts

$ cd $HOME/razzek/lab/java-logging
$ ./00-storage.sh && ./01-tomcat.sh && ./01-wildfly.sh

En este punto, se tiene en ejecución 2 servidores aplicativos, un tomcat (8.0.x) y un JBoss (9.0.2.Final). El servidor JBoss no esta modificado, el servidor tomcat se modificó, para agregar el grupo manager-script y el usuario deploy, para poder deployar utilizando la aplicación manager, también se agregan los jars slf4j-api-1.7.13.jar y slf4j-jdk14-1.7.13.jar

Compilación y construcción

Para compilar y generar el artefacto a deployar (war) en ambas aplicaciones, se ejecuta el script:

$ ./02-build.sh

Para validar el artefacto generado, se ejecuta el script:

$ ./testwar.sh

El resultado muestra algo similar a:

Archive: /mnt/deployment/app.war
   testing: META-INF/ OK
   testing: META-INF/MANIFEST.MF OK
   testing: WEB-INF/ OK
   testing: WEB-INF/classes/ OK
   testing: WEB-INF/classes/razzek/ OK
   testing: WEB-INF/classes/razzek/java/ OK
   testing: WEB-INF/classes/razzek/java/logging/ OK
   testing: WEB-INF/content.jsp OK
   testing: WEB-INF/web.xml OK
   testing: WEB-INF/classes/razzek/java/logging/LogServlet.class OK
   testing: META-INF/maven/ OK
   testing: META-INF/maven/razzek.java.logging/ OK
   testing: META-INF/maven/razzek.java.logging/javaLogging/ OK
   testing: META-INF/maven/razzek.java.logging/javaLogging/pom.xml OK
   testing: META-INF/maven/razzek.java.logging/javaLogging/pom.properties OK
No errors detected in compressed data of /mnt/deployment/app.war.

El artefacto generado, no contiene jars, pero se emplea slf4j (existentes en JBoss 9 y agregadas a tomcat 8), para generar entradas en la bitácora (trace, debug, info, warn y error).

Bitácoras

Tomcat utiliza la bitacora nativa de java (java.util.logging) y JBoss utiliza log4j. Al ejecutar el script

$ ./03-log.sh

Se modifica la configuración indicando al sistema de bitácoras que los mensajes generador por razzek.java.logging, se alamacenen en el archivo app.log.

Para mostrar el contenido del archivo app.log, dentro del contenedor docker. se ejecuta el script para tomcat

$ ./tail-tomcat.sh

 o para wildfly:

$ ./tail-wildfly.sh

Instalación

Para instalar la aplicación creada en el paso de compilación y construcción. Se ejecuta el script:

$ ./04-deploy.sh

El script deploya tanto en tomcat, como en wildfly.

Validación

Para validar la instalación, se invoca la url para tomcat:

http://127.0.0.1:32000

Y para wildfly

http://127.0.0.1:32001

Verificando que los logs se muestran en cada invocación en los respectivos archivos de logs (scripts tail)

Conclusión

Como se puede comprobar, la bitacora, se configuró de manera externa a la aplicación. Y las bibliotecas asociadas a slf4j no se incluyeron en la construcción. Permitiendo minimizar el tamaño de artefacto (WAR) e incluso manterner una configuración independiente por servidor aplicativo (algo que se puede aplicar cuando se cuenta con multiples ambientes) sin necesidad de modificar archivos de configuración en cada nueva instalación (algo común en los sistemas actuales).

httpd para archivos estáticos

Creando un servidor de archivos estáticos javascript y hojas de estilo.

Requisitos

• ubuntu 14.04
• docker
• cliente svn

Instalación

Código fuente

Crear el directorio de trabajo

$ mkdir -p $HOME/razzek/lab/httpd-gzip

Descargar el codigo fuente

$ cd $HOME/razzek/lab/httpd-gzip
$ svn co https://svn.riouxsvn.com/razzeklabs/trunk/httpd_compress/ .

Configuración

Ejecutar los scripts

$ cd $HOME/razzek/lab/httpd-gzip
$ ./00-config.sh && ./01-content.sh && ./02-run.sh

Validación

Para validar la correcta instalación, ejecutamos el script

$ ./check-compressed-jquery.sh

Cuya salida, genera un renglon como este:

Content-Length: 95957

Al listar el contenido del directorio js:

$ ls -l $HOME/razzek/lab/httpd-gzip/js

Se observa que existen el archivo (y no el archivo jquery-1.11.3.js, que es el que se requirió)

jquery-1.11.3.js.min

Dicho archivo, coincide en tamaño (y contenido) con el archivo recibido por el script. A continuación, se generan los equivalentes comprimidos.

$ ./03-compress.sh

Posteriormente se ejecuta el script, para recuperar el archivo nuevamente

$ ./check-compressed-jquery.sh

Esta consulta genera un renglon como el siguiente

Content-Length: 33139

Que es menor que en la primer consulta. Al consultar nuevamente el directorio js, se puede observar que existe un archivo jquery-1.11.3.js.min.gz, el cual coincide en tamaño con esta consulta

Como funciona

Suponiendo que se solicita el archivo script.js, el servidor, al recibir la petición, valida que el cliente, acepte compresión (Accept-encoding: gzip) y en base a la existencia de alguno archivo determina qué contenido envia.

Estas reglas se encuentran definidas en el archivo

https://svn.riouxsvn.com/razzeklabs/trunk/httpd_compress/compress.conf

Para agregar un nuevo archivo, se requiere agregar a la carpeta js, se siguen los siguientes pasos:

1. Obtener el archivo original (file.js en este ejemplo)
2. Opcionalmente, minimizar el archivo (YUI Compressor o Refresh-JS por ejemplo) y renombrarlo como file.js.min
3. Comprimir con gzip (zopfli puede ser una alternativa), si se tiene el archivo minimizado se comprime solo el minimizado en caso contrario, el original.
4. Agregar a la carpeta js el archivo original o minimizado y su contraparte comprimida (file.js - file.js.gz o file.js.min - file.js.min.gz)

No es necesario que exista el archivo original, si se encuentra el archivo minimizado.

Ventajas y desventajas

Al enviarse archivos previamente minimizados y/o comprimidos se obtienen las siguientes ventajas

• Menor uso de CPU, al no requerirse comprimir en cada petición
• Menor ancho de banda, al enviarse el archivo minimizado y comprimido.

Y desventajas

• Mayor uso de disco duro
• Administrar al menos el doble de archivos
• Manejo de actualizaciones manual (para actualizar un archivo, es necesario borrar los generados)

Necesidad de