Computación en la nube con un enfoque basado en patrones

Desarrollo de plugins/patrones de aplicaciones virtuales para una experiencia personalizada en la nube con IBM Workload Deployer

IBM® Workload Deployer es un producto de administración en la nube que proporciona enfoques basados en patrones para implementar y gestionar los entornos de las aplicaciones en la nube. Desde la perspectiva del usuario, el despliegue de entornos de aplicación significativos implica la capacidad de personalizar para cumplir con los requisitos específicos. Con esa necesidad en mente, IBM Workload Deployer proporciona una cantidad de instalaciones que abarcan un amplio rango de necesidades de personalización. Este artículo se centra en las capacidades de personalización presentadas a los usuarios para el nuevo modelo de despliegue de aplicaciones virtuales.

Dustin Amrhein, WebSphere Technical Specialist, IBM

Author photoDustin Amrhein se unió a IBM como parte del equipo de desarrollo para WebSphere Application Server. Mientras ocupaba ese cargo, trabajó en el desarrollo de infraestructura para servicios web y modelos de programación para servicios web. Además, lideró el esfuerzo técnico del desarrollo de un marco de servicios RESTful para Java. En su rol actual, Dustin es Technical Evangelist de tecnologías emergentes en la cartera de WebSphere de IBM. Actualmente se concentra en tecnologías WebSphere que ofrecen capacidades de cloud computing, entre ellas WebSphere CloudBurst Appliance.


Nivel de autor profesional en developerWorks

Ted Kirby, Ingeniero de software sénior, IBM

Ted KirbyTed Kirby desarrolla plug-ins para IBM Workload Deployer Pattern para aplicaciones Web en IBM en Research Triangle Park, Carolina del Norte. Es un miembro del comité de Apache Geronimo y fue desarrollador de WebSphere Application Server Community Edition. Anteriormente, fue un Evangelista Técnico de WebSphere para el Procesamiento de Transacciones Extremas y mejoró y mantuvo los sitios web de comercio en línea y desarrolló sistemas operativos distribuidos, incluido el sistema utilizado por la máquina, Deep Blue.



Brian Stelzer, Staff Software Engineer, IBM

Author photoBrian Stelzer es Ingeniero de Software y Líder de Equipo en el equipo IBM Workload Deployer. En su cargo actual, proporciona capacitación y soluciones arquitectónicas para entornos basados en la nube, enfocándose en IBM Workload Deployer, WebSphere Application Server y tecnologías basadas en VMware. Anteriormente, diseñaba soluciones de migración para WebSphere Application Server y WebSphere Application Server Community Edition.



24-12-2012 (Primera publicación 27-09-2011)

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea Computación en la nube: Cree una política eficaz para la nube

La reducción del tiempo de despliegue, el aumento de la consistencia y fomentar la agilidad son los beneficios que probablemente espere cuando explore los enfoques basados en la nube para los entornos de su aplicación de middleware. Generalmente, los enfoques tradicionales para establecer estos tipos de entornos han consumido mucho tiempo y recursos, al requerir varias semanas y muchas personas para construir.

Además, a menudo, es difícil alcanzar resultados de aprovisionamiento consistentes debido a la cantidad de pasos y la complejidad que implica. Además de contribuir con los costos en aumento en la TI durante los últimos 10 años, estos desafíos evitan que las empresas alcancen el tipo de agilidad que necesitan en los mercados consumidores cambiantes de nuestra era.

Ingresar IBM® Workload Deployer. Esta solución innovadora, basada en su predecesor, WebSphere® CloudBurst Applianc, resuelve estas cuestiones tradicionales haciendo que el despliegue del entorno de middleware en la nube sea rápido, repetitivo y eficiente.

Un enfoque basado en patrones es la base de IBM Workload Deployer y sus beneficios. Mediante la utilización del producto de administración en la nube, construye e implementa patrones que representan sus entornos de aplicaciones totalmente configurados. Estos patrones, originados por imágenes virtuales, le permiten representar sus entornos completos y, a veces, complejos como una única unidad desplegable.

Cuando está preparado para utilizar un entorno de aplicación específico, simplemente tome un patrón y despliéguelo. IBM Workload Deployer automatiza el despliegue, la configuración y la integración de varias máquinas virtuales que forman parte de su entorno y proporciona un producto completo en cuestión de minutos.

Más allá de los beneficios obvios de una velocidad sin precedentes, los patrones consistentes también garantizan resultados consistentes de despliegue a despliegue, permitiéndole centrar más tiempo en sus aplicaciones y menos tiempo en asegurar la configuración correcta del entorno de soporte.

Para fomentar la adopción rápida, IBM Workload Deployer envía con un conjunto de imágenes virtuales pre diseñadas y patrones de aplicaciones virtuales. De inmediato, puede desplegarlas y beneficiarse de un envió rápido y consistente de entornos de aplicaciones de middleware de propósito general.

Sin embargo, la creación de sus propios patrones personalizados mejorará el valor que reciba de este enfoque. En lo que respecta a esto, IBM Workload Deployer proporciona técnicas de personalización integradas para los dos modelos de patrones con los que es compatible.

IBM Workload Deployer heredó los patrones de sistemas virtuales de su predecesor, WebSphere CloudBurst. Aunque el nombre del producto cambió, los conceptos generales y las técnicas para la personalización de este tipo de patrón permanecen bastante intactos. Este artículo no se centra en esas técnicas de personalización, pero puede consultar la serie Personalización con WebSphere CloudBurst de developerWorks para una mirada profunda en los variados enfoques de personalización para este tipo de patrón.

El recordatorio de este artículo se focaliza en la personalización de patrones de aplicaciones virtuales en IBM Workload Deployer y concluye con un ejemplo de dicha personalización.

Personalización de patrones de aplicaciones virtuales

Los patrones de aplicaciones virtuales son nuevos modelos de despliegue por la versión 3 de IBM Workload Deployer . Este tipo de patrón toma de forma decidida un enfoque centrado en la aplicación para la construcción, el despliegue y la gestión de entornos de aplicaciones middleware en la nube.

Usted construye un patrón de aplicaciones virtuales al suministrar su aplicación y al especificar tanto los requisitos funcionales como los no funcionales para esa aplicación. IBM Workload Deployer toma la entrada de datos y la transforma en un entorno de aplicaciones middleware completamente instalado, configurado e integrado como lo grafica la Ilustración 1.

Ilustración 1 Enfoque de aplicación virtual en IBM Workload Deployer
Virtual application approach in IBM Workload Deployer

Como usuario de patrones de aplicaciones virtuales, no necesita saber cómo instalar, configurar o integrar el middleware y las aplicaciones porque el patrón encapsula ese conocimiento. ¿Cómo hacen eso los patrones? Es toda una cuestión de complementos.

El rol de los complementos para los patrones de las aplicaciones virtuales

El ejemplo básico para un IBM Workload Deployer para aplicaciones web en la Ilustración 2 resalta los elementos principales de un patrón de aplicaciones virtuales.

Ilustración 2 Ejemplo de patrón de aplicaciones virtuales
Virtual application pattern

Como puede ver, los patrones de aplicaciones virtuales consisten en componentes, enlaces y políticas:

  • Los componentes representan perfiles funcionales para una carga de trabajo dada. En el caso del patrón de aplicaciones virtuales para las aplicaciones web, existen componentes para las aplicaciones empresariales (archivos EAR), aplicaciones web (archivos WAR), bases de datos, aplicaciones OSGI y más. Estos componentes proporcionan las piezas esenciales del entorno que está intentando construir y desplegar.
  • Los enlaces expresan un punto de integración entre los componentes en un patrón de aplicación virtual. En el patrón que se muestra en la Ilustración 2, el enlace específica que la aplicación de la empresa tiene una dependencia en el componente de la base de datos en el patrón.
  • Las políticas como la Política de Escalamiento que se muestra en la Ilustración 2, le permiten especificar los requisitos funcionales y no funcionales para su entorno de la aplicación. Las políticas dictan tanto los aspectos de la configuración como los de la gestión continua del entorno.

Cuando construye y despliega patrones de aplicaciones virtuales, interactúa con un editor visual en la forma que muestra la Ilustración 2. Desde la perspectiva del usuario final, este hace que sea fácil construir rápidamente e implementar los entornos dinámicos, integrados y configurados basados en la nube.

Algo tiene que proporcionar la función implementada y encapsulada por los patrones de aplicaciones virtuales — que es donde los complementos ingresan la imagen. Toda la funcionalidad de la instalación, la configuración, la integración y la administración que obtiene de un patrón de una aplicación virtual proviene de un complemento o de un conjunto de complementos. Los complementos definen los componentes, los enlaces y las políticas para los usuarios virtuales de un patrón de aplicación virtual y respaldar esos elementos con la funcionalidad necesaria.

La buena noticia es que IBM Workload Deployer tiene un diseño abierto que le permite contribuir con sus propios complementos para el sistema. ¿Por qué es esto importante? Si desea crear su propio tipo de patrón de aplicación virtual para proporcionar una carga de trabajo personalizada en un software personalizado o si desea extender uno de los patrones de aplicación virtual que envía IBM Workload Deployer, necesita desarrollar uno o más complementos.

El enfoque de este artículo es la creación de un complemento personalizado que extienda el IBM Workload Deployer Pattern para las aplicaciones con soporte de WebSphere® Application Server Community Edition. Este ejemplo proporciona un segundo plano sobre la arquitectura de complementos, el uso del Plugin Development Kit de IBM, y los medios mediante los cuales puede agregar sus complementos personalizados al IBM Workload Deployer. ¡Comencemos!


Formación de un complemento

Antes de pasar a la creación de un complemento personalizado compatible con WebSphere Application Server Community Edition, necesita conocer la formación de un complemento. Seis puntos de configuración forman un complemento típico:

  1. Antes del despliegue, la definición general del complemento se define en el archivo config.json.
  2. En el despliegue, el modelo de aplicación se transforma en una topología no resuelta.
  3. La topología que no resulta se transforma en una topología resuelta.
  4. Los recursos necesarios se brindan y la topología resuelta se transforma en una topología final.
  5. El despliegue real se realiza en una nube privada.
  6. El software se instala, configura e inicia en las máquinas virtuales implementadas.

Despliegue previo

La definición general del complemento se define por la configuración del archivo config.json. El archivo config.json contiene información sobre:

  • Paquetes (middleware u otro software) a ser instalados
  • Requisitos másicos de hardware (por ejemplo, 32 bits contra 64 bits del paquete instalado de alojamiento de VM).
  • Nombre del complemento, versión y tipo de patrón asociado.

La herramienta del Creador de Aplicaciones Virtuales se utiliza para construir su patrón de aplicación virtual. Este patrón está conformado por componentes, enlaces y políticas definidas en un archivo de configuración del complemento que se denomina metadata.json. El archivo metadata.json. define lo siguiente para cada componente, enlace y política:

  • El nombre, la descripción y el icono se utilizan para representar gráficamente el plug-in en Virtual Application Builder.
  • Atributos configurables que se utilizan más tarde durante la configuración del paquete en el despliegue de VM.

Despliegue

Virtual Application Builder toma el patrón que creó usted con la información definida en metadata.json y crea un modelo de aplicación; la Ilustración 2 es un ejemplo de una representación gráfica de un modelo de aplicación que se compone de componentes, enlaces y políticas. Entonces, el modelo de la aplicación se elabora de forma progresiva hasta que finalmente tiene lugar el despliegue. IBM Workload Deployer organiza la ejecución de cada uno de esos pasos.

El primer paso en el proceso de implementación consiste en convertir el modelo de aplicación en una topología no resulta. La topología no resuelta es genérica e incluye información, como por ejemplo qué paquete incluir y los requisitos para la memoria y el disco. Esta conversión utilizar la <template>.vm que define.

El segundo paso consiste en tomar la topología no resuelta y convertirla en una topología no resuelta. El archivo config.json contiene los datos de transformación necesarios para completar este proceso. Una parte clave de este proceso consiste en trazar los requisitos del modelo de aplicación (sistema operativo, arquitectura, disco, memoria) para las partes proporcionadas por los complementos.

El tercer paso consiste en crear una topología final. IBM Workload Deployer toma el documento de la topología resuelta, proporciona los recursos requeridos y escribe el documento de la topología final.

El cuarto paso consiste en el despliegue real en la nube privada. El proceso de despliegue y el archivo de configuración correspondiente requerido para el paso se resaltan en la Ilustración 3.

Ilustración 3 Desde la creación del complemento al despliegue del complemento en su nube privada
From plug-in creation to plug-in deployment into your private cloud

El quinto y último paso es instalar, configurar e iniciar el software en las máquinas virtuales implementadas. Esto se alcanza con una serie de secuencias de ciclos de vida que usted define para cada componente de software para instalarse: install.py, configure.py y start.py.

Partes y partes de nodos

Antes de ahondar en la parte de creación de los complementos de este artículo, es conveniente hablar sobre las partes y las partes de los nodos dado que figuran notablemente en las secciones siguientes.

Los paquetes en los complementos contienen partes y nodos de partes. Cada parte o nodo de parte corresponde a dicho artefacto en particular (como un producto de software). Desde una perspectiva técnica, las partes y los nodos de partes son realmente la misma cosa en el sentido de que ambos se utilizan para instalar, configurar e iniciar el software.

Desde una perspectiva lógica, las partes de nodos se utilizan generalmente para instalar, configurar e iniciar el software a nivel del sistema, por ejemplo, un firewall. Las partes se utilizan para instalar, configurar e iniciar el software de tipo middleware, como por ejemplo WebSphere Application Server Community Edition.


Creación de un complemento personalizado

El resto del artículo detalla el proceso de la creación de un complemento personalizado para proporcionar suporte para los archivos de la aplicación empresarial (EAR) y la aplicación web (WAR) ejecutados en WebSphere Application Server Community Edition (WAS CE). Como una visión general, los pasos siguientes cubren:

  1. La definición y el empaque de los artefactos de los complementos.
  2. La definición de componentes de modelos de aplicaciones configurables para exponerlos de forma virtual en Virtual Application Builder.
  3. La definición de plantillas para convertir el modelo visual de la aplicación en un modelo físico.
  4. La definición de las secuencias del ciclo de vida para instalar, configurar e iniciar el software en la máquina virtual implementada.

La definición y el empaque de artefactos de complementos

Las opciones disponibles para el empaque de artefactos de un complemento se describen brevemente, pero no importa qué mecanismo de empaque decide utilizar, debe especificar la información sobre esos artefactos en el archivo config.json dentro del archivo de componentes. El Listado 1 muestra config.json para nuestro complemento WASCE.

Listado 1. Nuestro archivo de definición config.json
{
   "name"    : "wasce",
   "version" : "1.0.0.1",
   "patterntypes": {
      "secondary"  : { "*":"*" }
   },
   "packages" : {
      "WASCE" : [ {
            "requires"  : {
               "arch"   : "x86_64",
               "memory" :  512,
               "disk"   :  300
            },
            "parts":[ {
                  "part"  : "parts/wasce.tgz",
                  "parms" : {
                     "installDir" : "/opt/wasce"
                  }
            } ], 
      "WASCE_SCRIPTS":[ {
            "parts":[ {
                  "part":"parts/wasce.scripts.tgz"
            } ]
      } ]
      } ]
   }
}

El archivo config.json es el único archivo requerido en un complemento. Los elementos name, versiony patterntypes que se necesitan:

  • El elemento name especifica el nombre del complemento.
  • El elemento version define el número de versión del complemento.
  • El elemento patterntypes especifica los tipos de patrones con los que está asociado el complemento.

Nuestro complemento WASCE extiende IBM Workload Deployer for Web Applications para el patrón de aplicaciones web al especificar la aplicación web como el valor de patterntypes . Esto significa que los componentes que está definiendo estarán disponibles cuando cree los patrones desde el patrón de aplicación web enviado con IBM Workload Deployer.

El elemento necesario le proporciona una manera de especificar el sistema operativo necesario y la configuración en bits de la arquitectura para las máquinas virtuales aplicadas para su complemento. Para nuestro complemento, especificamos una arquitectura de 64 bits x86 para las máquinas virtuales.

El elemento memory y disk especifican el disco mínimo y los requisitos de la memoria para cada paquete definido por su complemento. Durante el proceso de aprovisionamiento, IBM Workload Deployer agregará hasta los mínimos valores para cada paquete y la provisión de una máquina virtual que cumpla con los requisitos especificados.

El elemento packages define los paquetes de archivos tanto con los elementos de part y nodepart . Nuestros complementos proporcionan dos paquetes: WASCE y WASCE_SCRIPTS. El paquete WASCE contiene el archivo de parte parts/wasce.tgz. El archivo contiene los binarios requeridos para instalar la edición de la Comunidad del Servidor de Aplicaciones de WebSphere y lo empaquetamos directamente en el complemento.

Hay otras opciones para especificar los binarios requeridos. Puede definir un atributo de archivo y hacer que los administradores carguen los binarios requeridos después de cargar el complemento en IBM Workload Deployer. También puede unirse a un servidor remoto que almacene los artefactos requeridos. El paquete WASCE_SCRIPTS proporciona las secuencias de ciclo de vida para instalar nuestra imagen WASCE en la ubicación deseada para instalar el archivo EAR o WAR e iniciar el servidor.

Definición de los componentes del modelo de aplicación configurable

Ignorar la creación de un icono gráfico es un paso sencillo. Las aplicaciones web y empresariales son componentes que usted quiere mostrar a los usuarios en el Creador de Aplicaciones Virtuales. Como tal, especifique cada uno de ellos en el archivo metadata.json que se encuentra ubicado en el directorio de componentes/modelo de aplicaciones del archivo del complemento. El Listado 2 muestra el JSON para definir el componente del archivo.

Listado 2. Especificación del componente del archivo web
[
 {
        "id"          : "WARCE",
        "label"       : "Web Application (WebSphere Application Server 
                         Community Edition)",
        "description" : "A web application cloud component represents an execution 
                        service for Java EE Web applications (WAR files).",
        "type"        : "component",
        "thumbnail"   : "appmodel/images/WASCE.png",
        "image"       : "appmodel/images/WASCE.png",
        "category"    : "application",
        "attributes"  : [
            {
                "id"          : "archive",
                "label"       : "WAR File",
                "description" : "Specifies the web application (*.war) to 
                                be uploaded.",
                "type"        : "file",
                "required"    : true,
                "extensions"  : [ "war" ] 
            }
        ]
 } 
]

Existe una copia similar para el componente del archivo empresarial para su archivo descargable. El primer tipo de campo de la lista es importante. Las opciones de valores para este campo son component, linko policy y este define el tipo en el modelo de aplicación. El id de nuestro componente es WARCE. Esto puede ser cualquier valor siempre y cuando sea único. La category se refiere a la pestaña debajo de la cual este componente se muestra en la paleta en Virtual Application Builder. Los attributes definen las propiedades para el componente que está definiendo. Los usuarios verán y podrán especificar los valores para esas propiedades cuando utilicen este componente en Virtual Application Builder. El tipo attributeincluyefile, string (que se muestra aquí), number, Boolean, arrayy range.

Defina la plantilla para convertir el modelo visual en un modelo físico.

Los complementos deben proporcionar el conocimiento para saber cómo implementar o darse cuenta del despliegue de los componentes definidos. En nuestro ejemplo, necesitamos especificar qué significa desplegar un componente de Aplicaciones Web o Empresariales.

Para hacerlo, proporcionamos una sola transformación que traduce el modelo de aplicación derivado de lo que los usuarios crean en Virtual Application Builder en una topología concreta. El Listado 3 muestra un fragmento de un archivo JSON utilizado para la transformación. Cada componente y enlace debe tener una transformación. En nuestro complemento, nuestros componentes WARCE y EARCE comparten la misma plantilla de transformación.

Listado 3. Plantilla de transformación
{
   "vm-templates":[
      {
         "name"     : "${prefix}-wasce",
         "packages" : [ "WASCE", "WASCE_SCRIPTS" ],
         "roles"    : [
            {
               "plugin"       : "$provider.PluginScope",
               "name"         : "WASCE",
               "type"         : "WASCE",
               "quorum"       : 1,
               "external-uri" : [{"ENDPOINT":"http://{SERVER}:8080"}],
               "parms":{
                  "ARCHIVE"   : "$provider.generateArtifactPath( $applicationUrl, 
                                ${attributes.archive} )"
               },
               "requires"     : { "memory":512, "disk":300 }
            }
         ],
         "scaling" : { "min":1, "max":1 }
      }
   ]
}

El fragmento de topología es un objeto JSON que contiene un vm-templates elemento que es un conjunto de vm-templates. Una plantilla vm-template es una plantilla virtual de la máquina que define las parts, nodepartsy attributes de una máquina virtual a implementarse. Para este ejemplo, solo necesitamos una plantilla vm-template que contenga cuatro elementos importantes:

  1. name: Un nombre único para una máquina virtual desplegada.
  2. packages: Esto especifica una lista de parts y nodeparts instaladas en cada máquina virtual desplegada. La entrada WASCE indica el uso de nuestra imagen virtual WASCE y la entrada WASCE_SCRIPTS especifica las secuencias del ciclo de vida de WASCE (que discutiremos más tarde).
  3. roles: parts en un complemento invoque una secuencia del ciclo de vida para los roles. Puede tener uno o más roles en su complemento, pero en nuestro caso tenemos un solo rol WASCE. Cuando todos los roles en un nodo pasan al estado RUNNING el nodo pasa al estado RUNNING de color verde.

Definición de las secuencias de los ciclos de vida para instalar, configurar e iniciar el software

Ahora está listo para definir las secuencias del ciclo de vida para su complemento. En total, escriba secuencias para instalar, configurar e iniciar componentes de su complemento. Puede ver secuencias completas en los archivos descargables, pero algunos de los artefactos clave se resaltan aquí.

wasce install.py

La secuencia install.py copia nuestra imagen WASCE desde la ubicación descargable hasta el installDir. También establece el valor installDir en el entorno para las secuencias subsiguientes.

Todas las parts y nodeparts instaladas en el agente de IBM Workload Deployer funcionan como raíces. El comando chown -R virtuser:virtuser cambia la propiedad del archivo de los contenidos instalados para el grupo y usuario deseado.

Finalmente, la secuencia install.py hace que las secuencias en el directorio de WebSphere Application Server Community Edition sean ejecutables. El Listado 4 muestra los contenidos de la secuencia install.py.

Listado 4. Extractos de la secuencia install.py
installDir = maestro.parms['installDir']
maestro.trace_call(logger, ['mkdir', installDir])

if not 'WASCE' in maestro.node['parts']:
    maestro.node['parts']['WASCE'] = {} 
maestro.node['parts']['WASCE']['installDir'] = installDir

# copy files to installDir to install WASCE
this_file = inspect.currentframe().f_code.co_filename
this_dir = os.path.dirname(this_file)
rc = maestro.trace_call(logger, 'cp -r %s/files/* %s' % (this_dir, installDir), 
 shell=True)
maestro.check_status(rc, 'wasce cp install error')

rc = maestro.trace_call(logger, ['chown', '-R', 'virtuser:virtuser', installDir])
maestro.check_status(rc, 'wasce chown install error')

# make shell scripts executable
rc = maestro.trace_call(logger, 'chmod +x %s/bin/*.sh' % installDir, shell=True)
maestro.check_status(rc, 'wasce chmod install error')

El Listado 4 muestra cómo las secuencias hacen uso del módulo maestro proporcionado dentro del marco de trabajo del complemento. Este módulo proporciona varios métodos del ayudante que son útiles durante la instalación y demás.

Wasce.scripts install.py

La parte wasce.scripts también contiene una secuencia install.py. Esta secuencia instala nuestras secuencias del ciclo de vida de la WebSphere Application Server Community Edition.

Listado 5. Extractos de la secuencia install.py
# Prepare (chmod +x, dos2unix) y copie los guiones al agente scriptdir
maestro.install_scripts('scripts')

wasce.scripts configure.py

La secuencia configure.py en la parte wasce.scripts instala la aplicación proporcionada por el usuario a WebSphere Application Server Community Edition. La secuencia toma ventaja de la capacidad de gran implementación de WebSphere Application Server Community Edition y simplemente copia los binarios de la aplicación a un directorio monitoreado. El Listado 6 muestra los contenidos de la secuencia configure.py script.

Listado 6. Extractos de la secuencia configure.py
installDir = maestro.node['parts']['WASCE']['installDir']

ARCHIVE = maestro.parms['ARCHIVE']
archiveBaseName = ARCHIVE.rsplit('/')[-1]
# Use hot deploy
deployDir = os.path.join(installDir, 'deploy')
if os.path.exists(deployDir) == False:
        # Make directories
        os.makedirs(deployDir) 
deployFile = os.path.join(deployDir, archiveBaseName)

# Download WASCE archive file
maestro.download(ARCHIVE, deployFile)

wasce.scripts start.py

La secuencia start.py en la parte wasce.scripts es responsable de la iniciación del proceso de WebSphere Application Server Community Edition. Después de iniciar el proceso, las actualizaciones de la secuencia actualizan el estado del rol a RUNNING. Una vez que el despliegue se encuentra en el estado RUNNING , puede acceder al entorno de aplicación desplegado. El Listado 7 muestra el uso del comando geronimo.sh start para iniciar la Edición de WebSphere Application Server Community Edition así como el uso del comando gsh.sh para esperar el inicio.

Listado 7. Extractos de la secuencia start.py
wait_file = os.path.join(maestro.node['scriptdir'], 'WASCE', 'wait-for-server.txt')

installDir = maestro.node['parts']['WASCE']['installDir']

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir + 
  '/bin/geronimo.sh', 'start'])
maestro.check_status(rc, 'WASCE start error')

logger.info('wait for WASCE server to start')

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir + '/bin/gsh.sh', 
  'source', wait_file])
maestro.check_status(rc, 'wait for WASCE server to start error')

maestro.role_status = 'RUNNING'

logger.info('set WASCE role status to RUNNING')  

logger.debug('Setup and start iptables')
maestro.firewall.open_tcpin(dport=1099)
maestro.firewall.open_tcpin(dport=8080)
maestro.firewall.open_tcpin(dport=8443)

Hay otras secuencias y artefactos para crear el comando, pero son las más importantes. Puede explorar todos los contenidos del complemento al descargar los complementos en la parte inferior del artículo.

Resumen del plug-in de Eclipse

La Ilustración 4 muestra todas las partes de nuestro complemento WASCE desde la vista del Explorador de Paquetes en Eclipse.

Ilustración 4 Todas las partes del complemento wasce
All the parts of the wasce plug-in

Instalación y uso del complemento

La construcción del plug-in de WebSphere Application Server Community Edition empaqueta sus contenidos en un archivo .tgz. Una vez empaquetado, usted está listo para cargar el nuevo complemento en el repositorio del IBM Workload Deployer. Después de cargarlo, también puede utilizar los componentes en el nuevo complemento para construir y desplegar un patrón de aplicación virtual. (Ver el Workload Plugin Development Kit de IBM en la sección Recursos para las instrucciones sobre la obtención y el uso del Workload Plugin Development Kit gratuito para llevar a cabo este paso).

Cargando complementos

Para cargar el complemento:

  1. Abra la interfaz de usuario de IBM Workload Deployer.
  2. Desde los menús en la parte superior de la página, seleccione el menú Cloud y haga clic en el enlace System Plug-ins.
  3. Haga clic en el ícono verde + y cargue el archivo .tgz. Después de cargar el archivo, puede ver los atributos de los complementos como se muestra en la Ilustración 5.
    Ilustración 5 Definición del complemento importado
    The imported plug-in definition

Como puede ver en la Ilustración 5, el complemento de wasce muestra tanto los componentes de la Aplicación Empresarial como los de la Aplicación Web que definió.

Utilización del nuevo complemento

Ahora que ya cargó el nuevo complemento, puede utilizar sus componentes para construir un nuevo patrón de aplicaciones virtuales. Para hacerlo, utilice el Virtual Application Builder en IBM Workload Deployer.

  1. Haga clic en el menú Patterns en la parte superior de barra de herramientas y luego haga clic en el enlace Virtual Applications.
  2. Haga clic en el ícono verde + para crear un nuevo patrón. Como lo muestra la Ilustración 6, asegúrese de que el tipo de patrón sea la Web Application y seleccione una plantilla en blanco.
    Ilustración 6 Creación de un nuevo patrón de aplicación virtual
    Creating a new virtual application pattern
  3. Haga clic en el botón Start Building para ingresar al Virtual Application Builder.
  4. Una vez en el creador, expanda la sección Application Components. Debería ver los componentes de la Aplicación Empresarial y la Aplicación web según el servidor de WebSphere Application Server Community Edition. Puede arrastrar y soltar esos componentes en el área de trabajo para agregarlos a su patrón. La Ilustración 7 muestra el uso de un nuevo componente de la aplicación web.
    Ilustración 7 Utilización de nuevos componentes
    Using the new components
  5. Según la definición del componente en el complemento, hay propiedades Name y WAR File. Ambas propiedades son necesarias, y la propiedad del archivo WAR contiene un diálogo de carga del archivo. Después de finalizar la creación de su nuevo patrón, guárdelo al hacer clic en el botón Save o Save As en la parte superior del Creador de Aplicaciones Virtuales. En este punto, ya está preparado para desplegar un nuevo patrón. (Para más información sobre este tema, consulte la descarga de los conjuntos de instalación de ejemplos de wasce en Recursos).

Despliegue del patrón de aplicación virtual personalizado

  1. Regrese a la página del patrón de aplicación virtual al seleccionar el menú de Patterns y al hacer clic en el enlace Virtual Applications.
  2. Seleccione su propio patrón de aplicación virtual de la lista en el lado izquierdo de la pantalla.
  3. Haga clic en el ícono Deploy to Cloud, seleccione el grupo adecuado de la nube y luego haga clic en Ok.

IBM Workload Deployer inicia el despliegue del entorno e invoca automáticamente las secuencias de los ciclos de vida que proporcionó en el complemento para instalar, configura e inicia el entorno.

Visualización de la aplicación desplegada

Para supervisar el proceso de despliegue, seleccione el menú Instances y luego haga clic en el enlace Virtual Applications. Cada máquina virtual en el despliegue tiene un estado asociado. Para una aplicación web o una máquina virtual de aplicaciones empresariales, debería aparecer un enlace de un punto final una vez que el estado de despliegue alcance el estado RUNNING, como lo muestra la Ilustración 8.

Ilustración 8 Supervisión del proceso de despliegue
Monitoring the deployment process

Si hace clic en el enlace Endpoint, aparece un diálogo emergente que muestra la URL para su aplicación desplegada. Haga clic en la URL para acceder a su aplicación.


En conclusión

Los patrones de aplicaciones virtuales representan un gran paso hacia una experiencia en la nube más centrada en las aplicaciones. Como los patrones de los sistemas virtuales, el diseño de IBM Workload Deployer permite la personalización extensiva de este artefacto de despliegue. Al crear complementos, puede permitir la creación de patrones de aplicaciones virtuales altamente personalizados y, de esa forma, crear despliegues basados en la nube según sus necesidades. Manténgase actualizado con más artículos en esta serie para conocer más sobre las técnicas de personalización de los patrones de aplicaciones virtuales y de complementos.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing, WebSphere
ArticleID=853045
ArticleTitle=Computación en la nube con un enfoque basado en patrones
publish-date=12242012