Archive for the ‘Java’ Category

Apache y JBOSS AS (puerto 80)

Posted on Mayo 8th, 2009 in Java | 1 Comment »

Para seguir con los ejemplos de clusterización nos vamos a centrar en el uso de un cluster en un entorno web para poder crear la siguiente arquitectura:

clustering-web

Esta estructura es interesante cuando nos queremos tener en un entorno web múltiples instancias de JBOSS sobre la misma url (http://www.duroty.com). En la figura se observa que todas las peticiones de los usuarios de internet son procesadas por Apache y este las distribuye sobre los servidores de aplicaciones que a su vez se encargan de ejecutar la lógica de negocio de la aplicación y devuelven (o no) las respuesta adecuada. Esta arquitectura es una de las más utilizadas y existen buenos tutoriales en red que permiten parametrizar muchos detalles (http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/Server_Configuration_Guide/index.html)

Descargar Apache 2.2

Para seguir con el montaje necesitamos un servidor Apache 2.2, una vez descargado vamos a suponer que está en el path /etc/httpd/….

Existen dos maneras de montar el proxy apache sobre cada servidor de aplicaciones del cluster:

  1. Usando mod_jk 1.2.x
  2. Usando mod_proxy con JBoss bundle y Apache2.2.x

Configurar mod_proxy en httpd.conf

Por la sencillez, robustez y estabilidad vamos a escoger la opción 2. Y empezamos habilitando el módulo correspondiente en la configuración del apache, para ello:

> vi /etc/httpd/conf/httpd.conf

Y descomentar las siguientes líneas en el apartado “Dynamic Shared OBject (DSO) Support”

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Con esto es suficiente para cargar el balanceador http en el apache.

Es siguiente paso es registrar nuestro cluster de dos nodos en el apache editando:

> vi /etc/httpd/conf/httpd.conf

y pegando el siguiente código al final del fichero (recordar las configuraciones de red de los servidores de aplicaciones):

##### balancer://jbosscluster es el nombre del balanceador apache sobre nuestro cluster node1 y node2
<Proxy balancer://jbosscluster>
# cluster member 1
BalancerMember http://10.0.0.1:8080 route=node1
# cluster member 2
BalancerMember http://10.0.0.2:8080 route=node2
ProxySet stickysession=JSESSIONID|jsessionid
ProxySet lbmethod=byrequests
ProxySet nofailover=Off
</Proxy>

<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow

Deny from all
## Introducir las IPs permitidas separadas por espacios para monitorizar el balanceador.
Allow from 127.0.0.1
</Location>

En la documentación oficial de apache se puede encontrar la definición de todos los parametros que acepta el balanceador (Apache Module mod_proxy)

Destacar que para tener una buena arquitectura WEB es importante que los servidores de aplicaciones NO presenten una dirección IP pública. Como se refleja en el dibujo del inicio de este post los servidores de aplicaciones sólo son visibles por el servidor web a través de un firewall. El elemento publicado a internet será Apache.

Un parámetro importante en el balanceo a través de apache es la sesión de usuario, para esto se utiliza ProxySet stickysession=JSESSIONID|jsessionid, que veremos en más detalle en los próximos puntos. 

Habilitar un virtual host (no publicar aplicaciones en el context-root)

Por defecto el servidor de aplicaciones JBOSS presenta diferentes aplicaciones web para configuración, monitoreo, servicios, etc. con lo que tenemos que asegurarnos de no clusterizar/balancear estos servicios. Para ello vamos a crear un virtual-host en apache sobre el dominio donde montemos nuestra aplicación web.

Nuestra aplicación de ejemplo se publicará bajo el dominio www.duroty.com, escogemos como contexto de aplicación un nombre que no esté reservado por el servidor de aplicaciones, por ejemplo durotyWeb.

Con los nombres anteriores y sin un apache y sin un cluster el acceso a la aplicación sería con:

http://www.duroty.com:8080/durotyWeb/

En el caso de nuestro cluster será:

http://10.0.0.1:8080/durotyWeb/

http://10.0.0.2:8080/durotyWeb/

Normalmente el contexto de aplicación (/durotyWeb) no es muy atractivo para que aparezca en nuestras URLs (sobre todo con la que está cayendo en temas de SEO). Lo que nos interesa es poder publicar la aplicación en context-root y para esto lo que haremos es crear un virtual-host en apache.

Voy a suponer que tenemos bien organizada la configuración del apache y que los virtual-host los tenemos en:

> /etc/htttpd/cond.f/[VIRTUAL-HOST]

Voy a crear el virtual-host para www.duroty.com:

> vi /etc/htttpd/cond.f/www_duroty_com.conf

## La ip pública del apache es 66.249.66.1

<VirtualHost 66.249.66.1:80>
ServerName www.duroty.com
ServerAdmin admin@test.com
DocumentRoot /htdocs/www-duroty-com

ErrorLog logs/www-duroty-com-error_log
CustomLog logs/www-duroty-com-access_log combined

ProxyPreserveHost On
## Paths que no quiero enviar a los servidores de aplicaciones, como por ejemplo contenidor estático js, css, img…
ProxyPass /static !
##
ProxyPass / balancer://jbosscluster/durotyWeb/
## Proxy pass reverse sobre node1
ProxyPassReverse /durotyWeb http://10.0.0.1:8080
## Proxy pass reverse sobre node2
ProxyPassReverse /durotyWeb http://10.0.0.2:8080

<Directory  “/htdocs/www-duroty-com”>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Con la configuración anterior voy a conseguir los siguiente:

http://www.duroty.com/static/* >> el apache se encarga de servir todo el contenido de /htdocs/www-duroty-com/static/*

http://www.duroty.com/* se passa a http://10.0.0.[1/2]:8080/durotyWeb/*

Con lo que ya somos capaces de balancear las peticiones http sobre dos nodos JBOSS

Aún no está completada la configuración final del cluster, ya que para aplicaciones que necesiten mantener la sesión de usuario entre los nodos hay que parametrizar los servidores de aplicaciones y más. Pero esto lo dejo para el siguiente post.

VN:F [1.0.9_379]
Rating: 5.0/5 (5 votes cast)

Configuración de un JBOSS – single node

Posted on Mayo 6th, 2009 in J2EE, jboss | 2 Comments »

Configuración “all” en JBOSS (modalidad cluster)

En el post anterior se ha visto como arrancar y parar un servidor de aplicaciones JBOSS.

> /opt/jboss/bin/run.sh -c default

> /opt/jboss/bin/shutdown.sh -S

Para aproximarnos a un entorno real hay que añadir otros parámetros en el comando de arrancada. Además en este post se utiliza la configuración all para preparar un entorno clusterizable.

Para ver los posibles valores de arranca del servidor de aplicaciones podemos ejecutar los siguiente:

> /opt/jboss/bin/run.sh –help

Que devuelve las posibles opciones de arranque:

options:
-h, –help                    Show this help message
-V, –version                 Show version information
-D<name>[=<value>]            Set a system property
-d, –bootdir=<dir>           Set the boot patch directory; Must be absolute or url
-p, –patchdir=<dir>          Set the patch directory; Must be absolute or url
-n, –netboot=<url>           Boot from net with the given url as base
-c, –configuration=<name> Set the server configuration name
-B, –bootlib=<filename>      Add an extra library to the front bootclasspath
-L, –library=<filename>      Add an extra library to the loaders classpath
-C, –classpath=<url>         Add an extra url to the loaders classpath
-P, –properties=<url>        Load system properties from the given url
-b, –host=<host or ip> Bind address for all JBoss services
-g, –partition=<name> HA Partition name (default=DefaultDomain)
-u, –udp=<ip> UDP multicast address
-l, –log=<log4j|jdk>         Specify the logger plugin type

Como el propósito del ejemplo es montar un cluster empezamos utilizando la configuración all (que permite arrancar el servidor de aplicaciones en modo cluster, arrancar los web services, HA-JNDI, y otros).

Para arrancar el servidor de aplicaciones con las funcionalidades de cluster:

> /opt/jboss/bin/run.sh -c all

-b <host or ip>, –host=<host or ip>

Este parámetro es importante tenerlo en cuenta pues cambia dos propiedades del sistema jboss.bind.address y bind.address. JGroups -estos parámetros sobreescriben los por defecto en la configuración xml del propio servidor-

jboss.bind.address: indica la dirección donde los servicios Tomcat, jrmp/pooled invokers services,…etc escucharán.

bind.address. JGroups: utilizada para indicar a JGroups (JGroups is a toolkit for reliable multicast communication.) con que IP se hace el bind del cluster.

Se puede fijar a 0.0.0.0 como dirección IP para bindar a todas las direcciones. Existe más información en http://www.jboss.org/community/docs/DOC-9730

Para nuestro ejemplo utilizamos la ip 10.0.0.1 para levantar los servicios:

> /opt/jboss/bin/run.sh -c all -b 10.0.0.1

Finalmente podemos probar en el navegador si el arranque ha sido correcto con http://10.0.0.1:8080

Para parar el servidor de aplicaciones hay que indicar en que dirección IP está arrancado con el parametro -s y utilizar -S para indicar el shutdown:

> /opt/jboss/bin/shutdown.sh -s 10.0.0.1 -S

VN:F [1.0.9_379]
Rating: 4.0/5 (1 vote cast)

Instalación de un JBOSS AS

Posted on Febrero 2nd, 2009 in J2EE | 3 Comments »

La primera cosa necesaria para la instalación del JBOSS AS es una distribución del mismo. Para todos los ejemplos J2EE que publicaré se ha utilizado la versión JBoss 4.2.0.GA,  pero deberian funcionar para las versiones posteriores.

La descarga de JBOSS AS se puede entrontrar a través de GOOGLE o en la página web oficial http://jboss.org/jbossas/downloads/.

Comprovar la versión de la JDK

Para la instalación del servidor de aplicaciones es necesario como mínimo la versión de jdk 1.5. Se puede comprobar la versión instalada con el siguiente comando:

> java -version
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56)
Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing)

En caso de no disponer de la versión se puede realizar la descarga directamente de la página de sun para la plataforma que mas convenga – http://java.sun.com/javase/downloads/index.jsp

Estructura de directorios

Para todos los ejemplos voy a suponer que el directorio de trabajo es /opt/jboss/*. Por lo tanto una vez descomprimido el servidor de aplicaciones dentro de /opt/jboss queda una estructura de directorios com la siguiente:

jboss directory structure

En la imagen se muestra que el directorio raiz es jboss-4.0-4, es importante y muy útil crear un alias “jboss” para acceder a cualquier versión que se tenga instalada de esta manera todos los scripts u otras aplicaciones no se verán afectados en el caso de una actualización del servidor de aplicaciones. Por lo tanto, para el ejemplo de la imagen anterior la ruta /opt/jboss/ será un alias a /opt/jboss-4.0-4 o /opt/jboss-XXX/

En la documentación oficial de jboss (http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch01.html) existe una tabla que describe cada directorio. Aquí va un extracto:

The JBoss top-level directory structure

Directory Description
bin All the entry point JARs and start scripts included with the JBoss distribution are located in the bin directory.
client The JARs that are required for clients that run outside of JBoss are located in the client directory.
server The JBoss server configuration sets are located under the server directory. The default server configuration set is the server/default set. JBoss ships with minimal, default and all configuration sets. The subdirectories and key configuration files contained default configuration set are discussed in more detail in Section 1.3, “The Default Server Configuration File Set”
lib The lib directory contains startup JARs used by JBoss. Do not place your own libraries in this directory.

The JBoss server configuration directory structure

Directory Description
conf The conf directory contains the jboss-service.xml bootstrap descriptor file for a given server configuration. This defines the core services that are fixed for the lifetime of the server.
data The data directory is available for use by services that want to store content in the file system.
deploy The deploy directory is the default location the hot deployment service looks to for dynamic deployment content. This may be overridden through the URLDeploymentScanner URLs attribute.
lib The lib directory is the default location for static Java libraries that should not be hot deployed. All JARs in this directory are loaded into the shared classpath at startup.
log The log directory is the directory log files are written to. This may be overridden through the conf/log4j.xml configuration file.
tmp The tmp directory is used by JBoss to store temporarily files such as unpacked deployments.

Por defecto JBOSS AS presenta tres posibles configuraciones (se pueden modificar y crear las que se crean convenientes en función de configuraciones, clusters, etc.):

  • minimal
    que arranca un microkernel JMX mínimo
  • default
    arranca un servidor de aplicaciones completo pero sin funcionalidades de cluster, webservices, etc
  • all
    como su nombre indica es la configuración completa con servidor de aplicaciones J2EE full, con clustering, webservices,  rmi-iiop, etc.

Para los que trabajan en windows y quieren simular un entorno linux os recomiendo la descarga cygwin.

Arrancando y parando el servidor de aplicaciones

Para arrancar el JBOSS con la configuración por defecto (default)

> /opt/jboss/bin/run.sh -c default

Probar en el navegador http://localhost:8080

Para parar una instancia de JBOSS

> /opt/jboss/bin/shutdown.sh -S

Los comandos anteriores nos permiten arrancar y parar el servidor de aplicaciones, pero para poder operar y trabajar correctamente hay que configurar un poco más. En las próximas entregas veremos como arrancar el servidor de aplicaciones sobre una IP, como arrancar todos los servicios a través de la configuración “all”, como preparse para la escalabilidad y clusterización, como instalar el servidor de aplicaciones como un servicio en linux, seguridad, accesos en el puerto 80, etc.

VN:F [1.0.9_379]
Rating: 3.4/5 (5 votes cast)

Servidores de Aplicaciones – JBOSS AS

Posted on Febrero 2nd, 2009 in J2EE | No Comments »

Empezaré las entregas sobre J2EE con la introducción a los servidores de aplicaciones. Existe en la Wikipedia una buena definición que os reescribo parcialmente aquí.

Mu gusta destacar que hablar de servidores de aplicaciones normalmente está directamente relacionado con J2EE – JAVA.


Extracto de http://es.wikipedia.org/wiki/Servidor_de_aplicaciones

En informática se denomina servidor de aplicaciones a un servidor en una red de computadores que ejecuta ciertas aplicaciones.

Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. Si bien el término es aplicable a todas las plataformas de software, hoy en día el término servidor de aplicaciones se ha convertido en sinónimo de la plataforma Java EE (antes J2EE) de Sun Microsystems.

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones Java EE. WebSphere (IBM) y WebLogic (Oracle, antes BEA Systems) están entre los servidores de aplicación Java EE privativos más conocidos. EAServer (Sybase Inc.) es también conocido por ofrecer soporte a otros lenguajes diferentes a Java, como PowerBuilder. El servidor de aplicaciones JOnAS, desarrollado por el consorcio ObjectWeb, fue el primer servidor de aplicaciones libre en lograr certificación oficial de compatibilidad con J2EE. JBoss es otro servidor de aplicaciones libre y muy popular en la actualidad, así como el GlassFish de SUN. Mucha gente confunde a Tomcat (The Apache Software Foundation) con un servidor de aplicaciones, sin embargo es sólamente un contenedor de servlets [1].

Java EE provee estándares que le permiten a un servidor de aplicaciones servir como “contenedor” de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSPs) y Enterprise JavaBeans (EJBs) y permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas.

La portabilidad de Java también ha permitido que los servidores de aplicación Java EE se encuentren disponibles sobre una gran variedad de plataformas, como Unix, Microsoft Windows y GNU/Linux.


Existen diferentes servidores de aplicaciones que cumplen el estándar J2EE en el mercado, pero me centraré en las próximas entregas y ejemplos en el que me “ha salvado la vida” en la mayoría de ocasiones y que es de código libre, el gran JBOSS AS. Un servidor de aplicaciones puro JAVA, que cumple los estándares J2EE 1.4, clusterizable, con soporte completo para JMX, EJB, JMS, etc.

VN:F [1.0.9_379]
Rating: 2.0/5 (1 vote cast)