Curso de Jboss Application Server Dia2

Curso de Jboss Application Server

Día 2

2

Revisión de Unidad 1

� ¿Que es JAVA?

� ¿Que es JBOSS?

� ¿Cómo es la estructura de directorios de Jboss?

� ¿Cuáles son las diferentes instancias?

� ¿Cómo es la estructura de directorios de una instancia?

3

Revisión de Unidad 1 - Respuestas

� ¿Que es JAVA?

� Es un lenguaje de programación orientado a objetos. Nos

permite tener independencia de la plataforma para las

aplicaciones que ejecutemos sobre él.

� ¿Que es JBOSS?

� Es un Servidor de Aplicaciones J2EE open source que se

ejecuta sobre java.

4


� ¿Cómo es la estructura de directorios de Jboss?

� Bin: scripts de inicio/parada y administración.

Client: archivos .JAR de aplicaciones cliente servidor. (Se puede borrar)

Common: librerías comunes a todas las instancias.

Docs: documentación y archivos de configuración de ejemplo (Data Sources)

Server: Contiene todas las instancias del servidor.

� ¿Cuáles son las diferentes instancias?

All: Incluye todos los servicios posibles (clustering).

Default: Instancia mas utilizada por desarrolladores.

Minimal: Servicios mínimos (Micro container) permite implementar servicios desde cero.

Standard: Sigue las normas del estándar J2EE. No proporciona agregados y mejoras de JBOSS.

Web: Contiene servicios para aplicaciones web (Servlet y JSP). No cumple el estándar J2EE.

5


� ¿Cómo es la estructura de directorios de una instancia?

Conf:: Archivos de configuración leídos por el servidor de aplicaciones en el inicio (salvo jboss-

log4j.xml)

Data: Directorio utilizado por servicios para lograr persistencia (Ej. Hipersonic)

Deploy: Directorio donde se ubican los archivos de aplicaciones por desplegar por Jboss.

Deployers: Aplicaciones que realizan los despliegues. (jbossweb.deployer)

Lib: Librerías especificas de cada instancias

Log: Directorio por defecto de ubicación de logs.

| Tmp: Directorio temporal de las aplicaciones que están en ejecución.

| Work: Carpeta temporal utilizada para compilar archivos JSP.

6


� Como instalar Jboss / Prerrequisitos

� ¿Cómo controlar Jboss?

7


� Como instalar Jboss / Prerrequisitos

� Verificar version requerida de Java

� Definir la variable JAVA_HOME

� Instalar la java requerida

� Descomprimir Jboss

� ¿Cómo controlar Jboss?

� ./run.sh -c <nombre de instancia> -b <IP>

� ./shutdown.sh –s jnp://localhost:1009

8


� Archivos de Configuración:

� Run.conf

� Jboss-log4j.xml

� Loggin-config.xml

� *-ds.xml

9


Archivo Run.conf

Contiene todos los parámetros de configuración

de la instancia al momento del inicio:

� -Xms256m tamaño mínimo del heap para la jvm

� -Xmx512m tamaño máximo del heap para la jvm

� java.lang.OutOfMemoryError: requested 894664 bytes for …

� -XX:PermSize=512m tamaño del espacio Perm.

� java.lang.OutOfMemoryError: PermGen space

10


� Archivo Jboss-log4j.xml

Permite ajustar el nivel de log de una aplicación o

servicios.

� Archivo loggin-config.xml

Contiene la lista de Security Domain utilizado para

segurizar las aplicaciones. (Ej. La consola de

administración)

� Archivos *-ds.xml

Archivos de configuración de conexiones a BBDD

utilizados por diferentes aplicaciones.

11

Unidad 4

� Desplegando aplicaciones

� Hot Deployment

� Expanded Deploy

� Múltiples instancias

� Configuración de run.sh

� Configuración de puertos

� Instalación/configuración de una aplicación con

Expanded Deploy

12

Tipo de Deploys

Hot Deployment� El servicio de hot deployment es el encargado de buscar

cada cierto periodo de tiempo cambios en la carpeta ./deploy

� Este servicio es utilizado en entornos de desarrollo ya que

permite desplegar y replegar aplicaciones fácilmente sin

detener el servidor.

� Esta ubicado en la carpeta ../deploy/

� El archivo que se encarga de configurar este servicio es:

hdscanner-jboss-beans.xml

� No es aconsejable la implementación del mismo en el

entorno productivo.

13

Tipo de Deploys

Expanded Deploy� Además de aplicaciones empaquetadas (ZIP) el jboss

permite instalar aplicaciones que estén completamente

expandidas.

� Como ya mencionamos existen los archivos empaquetas (*.war *.ear *.sar *.jar) estos archivos son faciles de distribuir pero no nos permiten de modificar el contenido de la aplicación fácilmente.

� El jboss durante el inicio realiza la descompresion de todos paquetes de cada aplicación (*.WAR).

� Se realiza un Expanded Deploy cuando la aplicación es lo suficientemente grande para afectar la performance durante el deploy.

14

Deploy de Aplicaciones

� El despliegue de una aplicación se realiza copiando un archivo (WAR) o, en caso de Expanded Deploy, la estructura de directorio de la aplicación a la carpeta ../deploy.

� Este mismo procedimiento se utiliza para los archivos de datasource y otros servicios.

� Luego se procede a comprobar el server.log

� Para la desinstalacion se debe eliminar o mover la aplicación fuera del directorio ../deploy

15

Problemas frecuentes en Deploy

� Problema entre librerías. Las propias del jboss con las

desarrollada en la aplicación.

� Problemas de permisos.

� Empaquetado incorrecto de aplicaciones.

� Empaquetados corruptos.

� Falta de espacio en el FS.

� Falta de permisos en los directorios temporales.

� No validar correctamente los requiesitos de la aplicacion,.

� No realizar la conexión de Base de Datos.

16

Múltiples instancias� Cuando cada vez hay mas aplicaciones o mas accesos

sobre la misma, lo recomendable es crecer horizontalmente.

� Crecer Horizontalmente: Generar nuevas instancias que compartan la carga de una misma aplicación u otra.

� Ventajas de Crecer Horizontalmente versus una única instancia con varias aplicaciones:

� Una aplicación que falle puede afectar parcial o totalmente el desempeño de la JVM. En consecuencia dejar el resto de las aplicaciones dentro de la instancia de Jboss indisponibles.

� Permitir configurar cada aplicación con los requerimientos específicos de la misma(Librerías, tamaños de memoria, etc.)

� Es recomendable no superar los 2 GB de memoria Heap ya que cada Garbage Collection demoraría mucho tiempo congelando la aplicación hasta que los mismos concluyan.

17

Múltiples instancias

Consideraciones previas:

� Para que cada instancia tenga parametros de memoria

distintos se deben generar diferentes scripts de arranque

(run.sh).

� Cada run.sh de instancia debe especificar en la variable

RUN_CONF la ruta completa del archivo run.conf de esa

instancia.

� Se debe tener especial cuidado en la elección de puertos

evitando el solapamiento de instancias.

� Verificar las políticas de logueo si se desea almacenar los

logs de múltiples instancias en un mismo directorio.

18

Múltiples instancias

<instancia>/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml

� Archivo de configuración que contiene los BindingSet que luego pueden asignarse a diferentes instancias.

� Los mismos definen la variación o offset de los puertos por defecto.

� El archivo ya contiene 3 BindingSet que permiten ejecutar múltiples instancias sin necesidad de crearlos.

19

bindings-jboss-beans.xml� Estándar Modificado

� Para Crear un BindingSet diferentes a los estandaresdebemos:

� Incorporar tantas lineas como BindingSet se desee crear:

<inject bean=“Nombre del BindingSet"/>

20

bindings-jboss-beans.xml� Estándar Modificado

� En el ejemplo incorporamos 2 nuevos BindingSet llamados P1Binding y P2Binding.

21

bindings-jboss-beans.xml

� Agregamos al archivo de configuración dos nuevos bloques de Binding. Tenemos que tener en cuenta 3 valores:

� Respetar el nombre del bindingSet declarado al inicio. (1)

� Fijar un nombre del set. (2)

� Definir una diferencia entre este set y los puertos default. (3)

22

bindings-jboss-beans.xml� La definición de los parámetros anteriores dentro del archivo

solo es útil si la instancia hace uso de esos nuevos BindingSet. Para ello existen 2 formas de realizarlo:

� 1. Por parámetro al momento de inicio:

� 2. Modificar la línea del archivo bindings-jboss-beans.xml

� NOTA: Tener en cuenta el nombre del bloque de Binding, No el valor Inject bean

23

Consolas de las 2 instancias

Consola de Instancia .

D1

Consola de Instancia .

D2

24

Instalación aplicación JamWiki

� Descargar el archivo jamwiki-1.0.4.war de http://jamwiki.org� Descargar el Xampp (Apache+Mysql+phpMyAdmin) de

http://www.apachefriends.org/en/xampp-linux.html

� Crear una instancia para esta aplicación (jamwiki)� Modificar los puertos de la instancia con un offset de 100

� Descomprimir el WAR (jamwiki-1.0.4.war a jamwiki.war)� Mover el dir jamwiki.war al /deploy

� Copiar la librería mysql-connector-java-5.1.6.jar� Crear un usuario y BBDD en Mysql con phpMyAdmin

� Iniciar la instancia y configurar Jamwiki

25

Revisión de Unidad 4� ¿Cuantos tipos de Deploy Existen?

� Si configuro Hot Deploy no puedo tener aplicaciones instaladas Expanded Deploy. V / F

� Explique el procedimiento para instalar, comprobar y desinstalar una aplicación.

� ¿Qué archivo permite configurar los puertos de binding del servidor de aplicación y donde esta ubicado?

� Teniendo en cuenta la siguiente imagen responda:

� El puerto de conexión web es 8480 V / F

� En caso de ser falso: ¿Como verificaría los puertos? Al menos 2 alternativas.

26

Revisión de Unidad 4 - Respuestas� ¿Cuantos tipos de Deploy Existen?

� Dos tipos de Deploy:

� Hot Deploy: Servicio que escanea y actualiza el listado de aplicaciones en base a modificaciones del directorio /deploy.

� Expanded Deploy: Caracteristica de Jboss que permite instalar aplicaciones comprimidas .WAR .JAR como también expandidas.

� Si configuro Hot Deploy no puedo tener aplicaciones instaladas Expanded Deploy. V / F

� Falso : Son dos configuraciones independientes.

27

Revisión de Unidad 4 - Respuestas� Explique el procedimiento para instalar, comprobar y

desinstalar una aplicación.

� Los pasos para instalar son:

� Copiar la carpeta (en caso de Extended DEploy) o el archivo a la carpeta /deploy de la instancia.

� Analizar los logs para comprobar el correcto deploy de la misma.

� Para desintalar:

� Eliminar la aplicación (Directorio o archivo).

� Aguardar la línea del log de undeploy sucefully

� ¿Qué archivo permite configurar los puertos de binding del servidor de aplicación y donde esta ubicado?

� El archivo es el bindings-jboss-beans.xml y esta dentro de <instancia>/conf/bindingservice.beans/META-INF/

28

Revisión de Unidad 4 - Respuestas� Teniendo en cuenta la siguiente imagen responda:

� El puerto de conexión web es 8480 V / F

Falso: El nombre asociado al parámetro

-Djboss.service.binding.set=ports-8480 solo es un nombre de Binding Set puede tener cualquier valor de puerto.

� En caso de ser falso: ¿Como verificaría los puertos?

� Verificar el archivo bindings-jboss-beans.xml

� Netstat –nap|grep <PID de JBOSS>

� Logs de arranque del jboss.

� Documentación del entorno.

29

Fin Unidad 4

30

Unidad 5

� Mod_JK

� Funcionalidad

� Descargando Mod_JK

� Apache-Tomcat

� Configurando Mod_JK en Apache Http Server

� Cargando el modulo mod_jk

� Que es un Worker

� Generando un Virtual Host

� Conexión con Jboss

31

Mod_JK

� El mod_jk es un conector que permite al web containerJakarta Tomcat interactuar con diferentes servidores web usando el protocolo AJP.

� Apache

� Netscape

� iPlanet

� SunOne

� IIS

32

Mod_JK

� La principal funcionalidad de este módulo es permitir a servidores de aplicaciones o al servidor Jakarta Tomcatenlazarse con un servidor web.

� Este servidor web, típicamente el servidor HTTP Apache, introduce una mayor gestión en las conexiones de los clientes y mayor seguridad en las transacciones del sistema.

� Así mismo se puede enlazar varias instancias al servidor web permitiendo una mayor tolerancia a errores y aligerar la carga en los servidores de aplicación.

33

Protocolo AJP

� El Apache JServ Protocol (AJP) es, en el contexto de la World

Wide Web un protocolo binario que permite enviar solicitudes

desde un servidor web a un servidor de aplicaciones que se

encuentra detrás del servidor web.

� También permite monitoreo dado que el servidor web puede

enviar un ping al servidor de aplicación.

34

Protocolo AJP

� Esquema del proceso de comunicación entre el HTTP Server y

el App Server

35

Descargando Mod_JK

� Mod_jk fue diseñado para ser utilizado por el webcontainerApache-Tomcat.

� Jboss al incluir como web container a Apache Tomcat puede utilizar el protocolo AJP para realizar el enlace con Apache Http Server.

� El modulo de conector lo obtenemos del Website de TomcatConectors:

http://tomcat.apache.org/download-connectors.cgi

� Allí encontraremos todas las versiones disponibles (Fuentes, Binarios, Versiones antiguas)

36

Descargando Mod_JK

� Nosotros utilizaremos la versión Binaria correspondiente a nuestro S.O. y la versión de apache que utilizamos.

http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/linux/jk-1.2.30/i586/

� Este archivo lo dejaremos en el directorio donde apache aguarda sus modulos ( /opt/lampp/modules ) y lo renombraremos a mod_jk.so

37

Configurando mod_jk en Apache Http Server

Cargando el modulo mod_jk

� Para esto lo mas conveniente es generar un archivo de configuración solo para mod_jk.

� Al mismo lo llamaremos mod_jk.conf y luego lo incluiremos el archivo httpd.conf

� Los parametros mas utilizados en la configuración del modulo son los siguientes :

LoadModuleJkWorkersFileJkLogFileJkLogLevelJkLogStampFormat

38

Mod_JK.conf

� LoadModule jk_module modules/mod_jk.so

Se encargara de indicarle al apache donde se encuentra el modulo mod_jk que tiene que iniciar

� JkWorkersFile etc/workers.properties

Indica al modulo la ubicacion del archivo donde se definen los workers (workers.properties)

� JkLogFile logs/mod_jk.log

Especifica la ubicación del archivo donde se almacenaran los logsdel modulo mod_jk.

39

Mod_JK.conf

� JkLogLevel info

Establece el nivel de log del modulo a info

� JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

Establece el formato de en el que se registraran los logs

� Una vez definidos todos estos parametros en el mod_jk.conftendremos que editar el archivo httpd.conf y agregar la siguiente linea.

� Include etc/mod_jk.conf

40

Que es un Worker

� Un worker es una instancia de Jboss que está esperando para ejecutar servlets por cuenta de algún servidor web.

� Por ejemplo, podemos tener un servidor web como Apache reenviando peticiones servlets a un proceso Tomcat (el workerque se ejecuta detrás de él)

� Por ende por cada instancia de Jboss que deseemos conectar al apache es necesario definir un Worker.

41

Generando el archivo Worker.properties

� Los Worker se definen en el archivo worker.properties.

� Para definir los workers necesitamos agregar las siguientes lineas al archivo :

� worker.list=jboss1

Se especifica una lista de todos workers que contaran el apache.

Recordemos que se usa un worker por cada instancia de Jboss, por lo tanto si tenemos diferentes intancias debemos definir el nombre de los worker aquí.También es donde se definen los workers para el balanceo de carga.

42


Luego Definimos un worker.

� worker.jboss1.port=8009

Emplea al puerto predeterminado 8009 para Jboss. Es donde el Jboss escuchara las peticiones AJP

� worker.jboss1.host=localhost

Especifica el hostname o ip del servidor donde corre la instancia de Jboss. Emplea localhost para escenarios de una-capa (single-tier).

� worker.jboss1.type=ajp13

Establece la versión usada de AJP

43


� Estos parámetros son los básicos en caso de necesitar afinar la configuración se puede encontrar una lista completa de parámetros disponible para los workers en:

http://tomcat.apache.org/connectors-doc/reference/workers.html

� Cuando iniciamos el apache en el fichero de log mod_jk.log podemos verificar que el modulo se a iniciado correctamente

[info] init_jk::mod_jk.c (3189): mod_jk/1.2.30 initialized

44

Generando un Vhost para la aplicación JamWiki

� En este momento ya contamos con la aplicación jamwiki instalada en nuestra instancia de Jboss.

Para que esta misma aplicación sea publicada por medio del servidor apache http server por la url http://www.jamwikitest.comdebemos realizar los siguientes pasos:

� En nuestro archivo /etc/hosts agregamos la linea:

127.0.1.1 www.jamwikitest.com

� Para comprobar que los cambios se han tomado debemos ejecutar el comando: ping www.jamwikitest.com

45


� Luego en el archivo /opt/lampp/etc/extra/httpd-vhosts.confdefinimos nuestro virtualhost

<VirtualHost *:80>ServerAdmin [email protected] /www/docs/dummy-host2.example.comServerName www.jamwikitest.comErrorLog logs/www.jamwikitest.com-error_logCustomLog logs/www.jamwikitest.com-access_log commonJkMount /jamwiki/* jboss1

</VirtualHost>

� Como vemos se define el worker que servirá dicho contenido ( jboss1).

En caso que otra instancia sea la que sirve esta aplicación debemos modificarlo por el worker correspondiente

46


� Prestar atención a la linea JkMount. en ella definimos el contexto de la aplicación que corre en Jboss.

<VirtualHost *:80>ServerAdmin [email protected] /www/docs/dummy-host2.example.comServerName www.jamwikitest.comErrorLog logs/www.jamwikitest.com-error_logCustomLog logs/www.jamwikitest.com-access_log commonJkMount /jamwiki/* jboss1

</VirtualHost>

Por ejemplo si queremos que publicar la aplicación admin-consoledebemos modificar la linea por:

JkMount /admin-console/* jboss1

47


� Ademas para que XAMPP tome los virtualhost configurados debemos agregar al fichero httpd.conf la linea:

Include etc/extra/httpd-vhosts.conf

� Luego procedemos a iniciar el servidor Apache-http-Server

/opt/lampp/lampp startapache

48

Fin Unidad 5

49

Unidad 6

� SSL

� Introducción a SSL

� Sus principales características

� Proceso de HandShake SSL

� Los pasos para establecer una conexión SSL

� SSL sobre WebContainer de Jboss

50

Introducción a SSL� ¿Qué es SSL?

� SSL (Secure Socket Layers) es un proceso que garantiza un canal de comunicación seguro entre 2 equipos distantes previo a un proceso de autenticación.

� Sus principales características son:

� Independiente del Protocolo segurizado (HTTP, POP, FTP,SMTP)

� Se basa en el concepto de clave publica y privada.

� Genera un túnel de comunicación seguro.

� Es transparente para el usuario.

� Su implementación es simple.

� Es un estándar desde 2001 de la IETF (Internet Engineering Task Force)

pasándose a llamar TLS (Transport Layer Security).

51

Proceso de HandShake SSL� Los pasos para establecer una conexión SSL son:

1. El cliente envía la petición al servidor segurizado. En ese mismo envío se adjuntan los

modos que soporta el cliente para encriptar/desencriptar los datos.

2. El Servidor al recibir la petición del cliente envía el certificado publico firmado por una

Entidad Certificadora Reconocida junto con el modo elegido. Como es lógico se elige

el modo mas seguro compatible entre cliente y servidor.

3. El cliente verifica la validez del certificado (en consecuencia la confianza del servidor al

que se enviaran los datos). Luego genera una clave aleatoria que es cifrada por el

certificado publico que envió el servidor al cliente en el paso 2.

4. El servidor recibe esta información encriptada, pero es el único capaz de desencriptarla

haciendo uso de la clave privada.

5. De aquí en adelante ambos se comunican por el canal seguro ya que ambos comparten

una clave que solo ellos conocen.

52

SSL sobre WebContainer de Jboss

� Generar un Certificado usando la herramienta keytool:

keytool -genkey -alias serverkeys -keyalg RSA -keystore

FedoraVM.keystore -storepass lablab -keypass lablab -dname

"CN=FedoraVM, OU=MiOU, O=MiORG, L=MiCiudad, ST=MiEstado, C=AR"

� Copiar el certificado al conf dentro de la instancia a instalar:

mv FedoraVM.keystore <instancia>/conf

� Modificar el archivo de configuración del Webcontainer:

<instancia>/server/default/deploy/jbossweb.sar/server.xml

53

Navegando Seguro

� Acceso a la web por puerto seguro https://<ip>:8443/

� Se registra la siguiente advertencia porque el certificado no cumple todos lo requisitos para ser confiable.

54

Navegando Seguro

� El cliente se basa en los siguientes puntos para determinar que un certificado es valido y por consiguiente se debe confiar en la contraparte:

� Fecha de Vencimiento del certificado

� Persona o empresa que firmo el certificado.

� El Dominio de emisión del certificado debe coincidir al visitado.

En este caso la entidad

certificadora no es segura

(AUTOFIRMADO)

Y el dominio no es correcto.

55

Navegando Seguro

� Para solventar el error del Dominio, en vista que el acceso se realizo por IP y no por hostname:

https://192.168.104.70:8443/

� Agregamos el host FedoraVM dentro

de nuestro archivo hosts:

� Ahora podremos acceder a la web desde

la siguiente url:

https://FedoraVM:8443/

De esta forma el browser solo nos reportará el problema de autofirmado.

NOTA: Esto no altera la encriptación, los datos viajan seguros pero el cliente reporta que no confía en la contraparte.

56

Navegando Seguro

Para aprobar el uso de esta conexión verificamos los datos del certificado y aceptamos la excepción:

57

Navegando Seguro

� Todos los datos trasmitidos por la aplicación son encriptados por el certificado generado.

� Es común que empresas posean entidades certificadoras internas (que certifican webs de su intranet).

� Suelen incorporar los certificados como CA confiables en los repositorios del Sistema Operativo de las maquinas cliente, de esa forma cualquier certificado firmado internamente es confiable.

58

Fin Unidad 6

Documents

Curso de Jboss Application Server Dia2