Tema 3: Administración del servidor de aplicaciones

3.3. Despliegue de aplicaciones

Una aplicación web es un conjunto de recursos en la parte del servidor que crean una aplicación interactiva. Estos recursos pueden contener todos o algunos de los siguientes componentes: servlets, JavaServer Pages, documentos estáticos (páginas HTML, imágenes, documentos PDF, etc.), clases, applets y beans en la parte del servidor. Una aplicación web se nos puede presentar de dos formas:

• Un fichero comprimido .war
• Una estructura de directorios expandida manteniendo la siguiente estructura:
  • NombreAplicación (nombre de la aplicación y documento raíz de la aplicación)
    • META-INF (información para herramientas de archivo)
    • Ficheros .html, .jsp
    • WEB-INF (directorio que contiene ficheros que no son servidos a clientes)
      • classes (directorio que contiene clases, servlets y applets)
      • lib (directorio con ficheros .jar usados en la aplicación)
      • web.xml (fichero descriptor de despliegue de la aplicación)
      • weblogic.xml (fichero descriptor para mapear recursos propios de Weblogic)

3.3.1. Despliegue de una aplicación en un fichero war

Para descargar una aplicación contenida en un fichero war se procede de la siguiente manera. Primero pinchamos en el icono de Web applications. Nos aparecerá una figura como la siguiente en la cual se nos muestra las aplicaciones disponibles y se nos permite configurar nuevas. Vamos a pinchar en Configure a new Web Application.

El primer paso es localizar el fichero que contendrá nuestra aplicación. Hablamos de ficheros .war pero podemos desplegar cualquiera de los tipos mostrados: .jar, .war, .rar y .ear. Pinchamos en el paso 1: upload it through your browser.

Nos aparece la siguiente figura en la que se nos permite buscar el fichero en nuestra máquina local. Seleccionamos el fichero y pinchamos en Upload.

Nos vuelve a aparecer la anterior página, en la cual debemos realizar el paso 2 que consiste en seleccionar la aplicación que queremos desplegar. Pinchamos en la aplicación recién descargada.

Pasamos entonces al paso 3. Se nos advierte qué fichero estamos configurando y nos permite asignar la aplicación a uno o varios servidores o a todo un cluster. Por último le asignamos un nombre a la aplicación. Este nombre tiene un carácter informativo. Una vez introducidos los datos pinchamos en Configure and Deploy para que se realice el despliegue.

Una vez hemos pinchado en Configure and Deploy nos aparecerá una ventana como la siguiente. Se nos muestra información de la actividad de despliegue. Al cabo de un tiempo nos aparecerá el resultado del despliegue. Si hemos conseguido desplegar la aplicación aparecerá true en la columna Deployed del servidor correspondiente. Si ha habido algún problema podemos consultar el log del servidor correspondiente.

3.3.1. Despliegue de una aplicación en un directorio

En modo desarrollo y cuando estamos implementando una aplicación es normal que tengamos que modificar muy a menudo el código de la aplicación. Por ello es conveniente tener dicha aplicación en un directorio, no en un fichero. La aplicación sin comprimir la podemos dejar en cualquier directorio del sistema, pero es conveniente dejarla en el directorio applications del dominio. Dentro de ese directorio dejaremos uno nuevo que contendrá nuestra aplicación. Para configurar esta aplicación debemos realizar los siguientes pasos. En el paso que realizamos anteriormente cuando desplegábamos una aplicación en un fichero, seleccionamos el paso 2 el directorio applications (que será donde habremos dejado nuestra aplicación) pinchando sobre su nombre.

Nos aparecerá el nombre de nuestra aplicación (faqs) que es un directorio. Ahora pinchamos en select para seleccionar dicho directorio.

Ya podemos seguir los pasos vistos en la sección anterior para configurar la aplicación (selección de targets, nombre de la aplicación, etc.).

Una herramienta bastante útil es el editor del descriptor de la aplicación. Nos permite editar el fichero web.xml y modificar los datos allí contenidos. Para acceder a esta herramienta pinchamos en el nombre de una aplicación y luego pinchamos en el enlace Edit Web Application ... mostrado en la figura.

La siguiente figura muestra un ejemplo en la edición de un descriptor.

3.4. Gestión de seguridad

En la carpeta Security del applet de la izquierda tenemos todo lo referente a la gestión de seguridad. Tenemos creado un Realm por defecto que es el que se utiliza para guardar los usuarios que vamos creando. Podemos crear nuevos usuarios, grupos y roles. En Weblogic 7.0 la seguridad se maneja mediante políticas de seguridad. Las políticas de seguridad permiten definir quién tiene acceso a un determinado recurso. Adicionalmente podemos definir una restricción de tiempo de acceso a un recurso (de qué hora a qué hora se tiene acceso a un recurso). Por defecto un recurso no tiene protección hasta que el administrador le asigna una determinada política de seguridad. Los recursos a los que se pueden imponer políticas de seguridad son: la consola de administración, recursos de aplicación (web, EJB, ear, jar, etc.), JDBC, JNDI, EIS, JMS.

Un usuario puede ser una persona o una entidad software (cliente java). El usuario es único dentro del sistema y se identifica con su nombre y una contraseña. No existe el usuario invitado (Guest). Puede ser creado pero se recomienda no hacerlo por riesgo en la seguridad del sistema. Para crear un nuevo usuario pinchamos en Users y nos aparecerá una página como la de la siguiente figura. Se nos muestra los usuarios creados y tenemos un enlace para crear un nuevo usuario. También se nos informa de si un usuario está bloqueado y podemos eliminar el usuario.

Al pinchar en Configure a new User nos aparece la siguiente figura. Los datos indicados son el nombre del usuario, una breve descripción y la contraseña. Una vez introducidos estos datos pinchamos en Create.

Una vez creado el usuario podemos asignarlo a un grupo. Un grupo es una agrupación de usuarios con alguna característica en común. Un usuario puede pertenecer a más de un grupo. Si asignamos una determinada política de seguridad a un grupo, dicha política es asignada a todos los usuarios del grupo. Por defecto existen seis grupos:

• Users: todos los usuarios identificados pertenecen a este grupo.
• Everyone: incluye el anterior más los usuarios no identificados.
• Administrators: es el grupo que permite administrar el dominio: arrancar y parar el sistema, visualizar y modificar todos los recursos.
• Deployers: los miembros de este grupo pueden desplegar aplicaciones.
• Monitors: sólo se permite la monitorización del sistema.
• Operators: permite cualquier operación con los servidores.

Al crear un usuario se nos permite asignarlo a un grupo.

También podemos crear y configurar nuevos grupos. Para crear un nuevo grupo pinchamos en el icono Groups y nos aparece la siguiente figura en la que podemos modificar un grupo ya existente o bien crear uno nuevo pinchando en Configure a new Group.

Damos el nombre y una breve descripción al grupo y pinchamos en Apply. En la solapa Membership podemos incorporar otros grupos como miembros de este.

El último apartado de la seguridad son los roles. Un rol es una asociación entre usuarios y recursos que permite establecer qué usuario tiene acceso a qué recurso. Un grupo es una agrupación estática (los usuarios están agrupados siempre de la misma forma). Un rol es dinámico, porque dependiendo de quién esté accediendo a un recurso y dependiendo de a qué recurso quiera acceder, tendrá permiso o no. Se recomienda agrupar usuarios en grupos y crear roles para luego asignar los roles a los grupos. Por defecto existen los siguientes roles:

• Admin: permite realizar cualquier operación dentro del sistema: despliegues, modificar recursos, etc.
• Deployer: permite ver la configuración del sistema y realizar despliegues de aplicaciones.
• Operator: permite ver la configuración del sistema y realizar operaciones con los servidores.
• Monitor: sólo permite visualizar la configuración de los servidores.
• Anonymous: es el rol más restrictivo y es asignado a todos los usuarios.

Cada uno de estos roles está asignado al grupo correspondiente (Admin al de Administrator, Deployer al de Deployers, etc.). Para crear un nuevo rol pinchamos en Configure a new role.

Las políticas de seguridad por defecto asociadas a los recursos de WebLogic se muestran en la siguiente tabla:

WebLogic, en su versión 7.0, sigue manteniendo la asignación de seguridad en los ficheros web.xml y weblogic.xml. La secuencia a seguir para asignar seguridad (restringir el acceso a determinados usuarios) a un recurso es el siguiente:

• Declarar un patrón URL en el fichero web.xml.
• Declarar un rol.
• Asociar el patrón con el rol.
• Mapear el rol con usuarios o grupos en el fichero weblogic.xml

Un ejemplo de la información que podemos poner en el fichero web.xml (además de la de mapeado utilizada hasta ahora) es la siguiente:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>nombre aplicacion</web-resource-name>
		<url-pattern>url a proteger</url-pattern>
	</web-resource-collection>
 	<auth-constraint>
  		<role-name>nombre del rol</role-name>
  	</auth-constraint>
 	<user-data-constraint>
  		<description>SSL not required</description>
  		<transport-guarantee>NONE</transport-guarantee>
  	</user-data-constraint>
</security-constraint>

<security-role>
  	<role-name>nombre del rol</role-name>
</security-role>
<login-config>
	<auth-method>BASIC</auth-method>
</login-config>

En nombre aplicación debemos poner el nombre de nuestra aplicación que queremos proteger. En url a proteger especificamos la url (directorios, jsp, html, etc.) Por ejemplo, /manager/* protegería todo el directorio manager de nuestra aplicación (cualquier fichero por debajo del directorio). Lo anterior define un recurso web y lo asociamos a un rol. Debemos especificar el nombre del rol y la etiqueta security-role crea el rol. La última etiqueta, login-config, permite especificar el método de autentificación: BASIC pide el nombre de usuario y contraseña mediante una ventana; FORM permite pedir la autentificación mediante un formulario y CLIENT-CERT mediante un certificado.

Por último debemos asociar el rol creado con un grupo o usuario de WebLogic. Para ello disponemos del fichero weblogic.xml.

<weblogic-web-app>
	<security-role-assignment>
		<role-name>nombre del rol</role-name>
		<principal-name>nombre de grupo o usuario</principal-name>
	</security-role-assignment>
</weblogic-web-app>

En nombre del rol pondremos el rol previamente definido en el fichero web.xml. Como nombre de grupo o usuario debemos poner uno válido (definido) dentro de WebLogic.

3.5. Administración desde línea de comandos

La administración desde línea de comandos es una herramienta útil para el control del sistema. Nos permite realizar varias tareas de monitorización y comprobación del sistema. También es útil en modo producción, pues normalmente se deshabilita la consola de administración por motivos de seguridad.

El comando a ejecutar es el siguiente:

java -cp $BEA_HOME/weblogic700/server/lib/weblogic.jar weblogic.Admin -url URL 
   -username usuario -password contraseña COMANDO argumentos

El comando no es más que una llamada a la clase weblogic.Admin que se encuentra en el fichero weblogic.jar proporcionado por BEA. El parámetro URL especifica la dirección URL del servidor de administración o bien del servidor contra el que vayamos a realizar el comando. Debemos especificar también el puerto en la dirección. El usuario y su contraseña asociada deben ser válidos para el comando que vamos a ejecutar. Los posibles comandos a utilizar pueden ser algunos de los siguientes:

Existen otros comandos y utilidades adicionales que se detallan a continuación. En todos ellos hace falta incluir el fichero weblogic.jar en el classpath.