1. Descargar el tar.gz
2. Descomprimirlo
3. Y lanzar $TOMCAT_HOME/bin/startup.sh

Me gustaría compartir con vosotros cómo configuramos nosotros (@klicap) Apache Tomcat con el objetivo de conocer vuestras impresiones y dejar unas notas para que no se olviden. Esta es la configuración que estamos usando en Clinker Virtual Appliance. En las siguientes instrucciones se presupone que estamos usando un S.O. Linux y que la JVM está correctamente configurada.

1. Descargar los binarios del sitio web oficial.
2. Descomprimir el tar.gz en /opt
3. Crear un enlace simbólico /opt/tomcat > /opt/apache-tomcat-6.0.32
4. En $TOMCAT_HOME/bin encontraremos tomcat-native.tar.gz que corresponde con Apache Tomcat Native, una librería que mejora el rendimiento porque delega en APR ciertas funcionalidades que están implementadas de forma nativa.
5. Descomprimimos tomcat-native.tar.gz
6. Configuramos el proyecto y compilamos:

   ./configure \
   --libdir=/usr/local/lib/tomcat-native-1.1.20 \
   --with-java-home=/usr/local/java \
   --with-apr=/usr/bin/apr-1-config

   make && make install

7. Creamos un enlace simbólico /usr/local/lib/tomcat-native > /usr/local/lib/tomcat-native-1.1.20
8. Configuramos la variable de entorno (p.e. en /etc/profile):

   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/tomcat-native

Cuando lancemos Apache Tomcat encontraremos en los logs el siguiente mensaje:

19-abr-2011 13:09:45 org.apache.catalina.core.AprLifecycleListener init
INFO: Cargada la biblioteca nativa APR de Apache Tomcat 1.1.20
19-abr-2011 13:09:45 org.apache.catalina.core.AprLifecycleListener init
INFO: Capacidades APR: IPv6 [true], enviar fichero [true], aceptar filtros [false], aleatorio [true].

En una instalación por defecto hubiéramos encontrado un mensaje similar a este:

org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

En la siguiente entrada veremos cómo configurar commons-daemon con Apache Tomcat.

Teniendo en cuenta este escenario, creo que existen soluciones muy fáciles de implementar y con resultados muy óptimos. A continuación una ilustración para explicar la solución propuesta:

De la ilustración se deduce que la solución se centra en la disponibilidad del contenedor y/o servidor de aplicaciones JEE. De las tres capas, -creo- que es la que más problemas de disponibilidad presenta. Más adelante nos centraremos en el resto de capas. La idea básica de esta solución consiste en tener una instancia de nuestro contenedor y/o servidor de aplicaciones (y aplicaciones) replicado para respaldar al que está funcionando. Nuestro Apache webserver atenderá las peticiones y en función de la petición, estas se reenviarán a SERVER 2. Si por cualquier motivo, el SERVER 2 dejase de funcionar, Apache webserver sabría que tiene que enviar esas mismas peticiones a SERVER 1.

¿Qué conseguimos con esta solución?

1. Evitar prácticas que aislen las aplicaciones problemáticas.
2. Una solución no intrusiva porque no hemos tenido que tocar nada en nuestras aplicaciones, es decir, es una solución válida incluso para aplicaciones antiguas.
3. En entornos virtualizados resulta muy cómodo y fácil de mantener.
4. Si SERVER 1 y SERVER 2 comparten un sistema de ficheros, un más fácil.
5. Evitar prácticas que consistan en reiniciar los sistemas antes de que estos degraden completamente.
6. Si a esta solución le añadimos software como NAGIOS, los administradores de sistemas estarán informados de las caídas y podrán actuar en consecuencia.
7. Aumentar la disponibilidad de nuestro entorno.

¿Qué no conseguimos con esta solución?

1. Compartir las sesiones entre los servidores.
2. Compartir las conexiones de acceso a datos.
3. Alta disponibilidad del entorno completo.

Para conseguir esto necesitamos el conector mod_jk desarrollado dentro del proyecto Apache Tomcat. Suponiendo que ya tenemos nuestro Apache webserver instalado y configurado, veamos qué tenemos que hacer para compilar mod_jk:

1. wget http://www.apache.org/dist/tomcat…
2. cd tomcat-connectors-1.2.26-src/native
3. ./configure –with-apxs=/opt/httpd-2.2.8/bin/apxs (directorio de ejemplo)
4. make
5. cp apache-2.0/.libs/mod_jk.so /opt/httpd-2.2.8/modules

Ahora habilitamos el módulo en Apache webserver:

1. Editamos el archivo: /opt/httpd-2.2.8/conf/httpd.conf
2. Añadimos las líneas:
   1. LoadModule jk_module modules/mod_jk.so
   2. Include conf/extra/mod_jk.conf
      

A continuación creamos los archivos de configuración para el conector:

1. Creamos el archivo mod_jk.conf en /opt/httpd-2.2.8/conf/extra
2. Creamos el archivo workers.properties en /opt/httpd-2.2.8/conf/extra

En el archivo mod_jk.conf configuraremos esas reglas correspondientes a las peticiones que atenderá Apache webserver y las cuales definirán a nuestras aplicaciones desplegadas en Apache Tomcat. Un ejemplo de este archivo sería:

JkLogFile logs/mod_jk.log
JkShmFile logs/mod_jk.shm
JkLogLevel info
JkWorkersFile conf/extra/workers.properties

# Add the jkstatus mount point
JkMount /jkmanager/* jkstatus

JkMount /opina/* router

Básicamente en este archivo se configura el archivo de log, el archivo para compartir información entre los conectores y las aplicaciones que queremos “conectar”. Concretamente jkmanager nos permitirá monitorizar cómo funcionan los conectores.

Y la configuración para los conectores:

# The advanced router LB worker
worker.list=router,jkstatus

# Define a worker using ajp13
worker.worker1.port=8009
worker.worker1.host=192.168.0.3
worker.worker1.type=ajp13
worker.worker1.lbfactor=1
# Define prefered failover node for worker1
worker.worker1.redirect=worker2

# Define another worker using ajp13
worker.worker2.port=8009
worker.worker2.host=192.168.0.4
worker.worker2.type=ajp13
worker.worker2.lbfactor=1
# Disable worker2 for all requests except failover
worker.worker2.activation=disabled

# Define the LB worker
worker.router.type=lb
worker.router.balance_workers=worker1,worker2

# Define a ‘jkstatus’ worker using status
worker.jkstatus.type=status

Con esta configuración todas las peticiones se enviarán al conector worker1, y si algo falla, se enviarán al conector worker2.

Evidentemente en esta solución caben varias mejoras, pero antes de mejorar en esta parte, me centraré en mejorar la publicación de contenido estático. Quizás nuestro amigo Apache webserver tenga que convivir con Cherokee o Lighttpd.

Las sugerencias siempre son bienvenidas.