Digital Developer Conference: Hybrid Cloud 2021 | Capacitaciones gratuitas por expertos y partners | 21 de Setiembre ¡Inscríbete Ahora!

Cómo migrar la aplicación en la nube

Introducción

La Parte 1 de esta serie se mostró como migrar la aplicación Daytrader3 desde IBM® WebSphere® Application Server Liberty 8.5.5.0 a la versión más reciente del servidor Liberty. Ahora, en la Parte 2, usted migra la aplicación Daytrader3 que se está ejecutando en un servidor Liberty 17.0.0.2 local a las plataformas de nube IBM Cloud Private (con Docker y Kubernetes) e IBM Cloud Public (con Cloud Foundry). Este tutorial examina los cambios de código que se necesitan para habilitar para la nube de la aplicación Daytrader3. Usted también configura y despliega la aplicación en cada plataforma.

La fidelidad se mantiene mayormente entre el tiempo de ejecución de Liberty local y el basado en la nube. Debido a la naturaleza dinámica del entorno en nube (por ejemplo, IP no estática o sistemas de nombre de host y de archivos transitorios), usted debe adaptar una aplicación local tradicionalmente más estática. Este tutorial también demuestra algunas de las herramientas, configuraciones y métodos que se utilizan para desplegar una aplicación a la nube.

Para continuar con la Parte 2, usted debe haber completado los pasos de la Parte 1 de esta serie. Esta parte depende del espacio de trabajo y del servidor WebSphere Liberty que creó en la Parte 1. Si usted no completó esos pasos, puede descargar la copia final del espacio de trabajo y del servidor configurado de la Parte 1 antes de continuar con la Parte 2.

Requisitos previos

1

Configurar el entorno de desarrollo

Si tiene que desplegar la aplicación DayTrader a IBM Cloud Public (Cloud Foundry), siga las instrucciones para descargar e instalar la IBM Cloud CLI.

Si tiene que desplegar la aplicación DayTrader a contenedores de Docker y a IBM Cloud Private, deben tener acceso a un entorno de IBM Cloud Private. Nosotros utilizamos Docker Community Edition (CE) para crear y gestionar localmente las imágenes de Docker. Descargue e instale Docker CE para su sistema operativo. Si está utilizando versiones más antiguas de macOS® o de Microsoft® Windows®, es posible que tenga que utilizar Docker Toolbox y y crear su propia máquina de Docker.

En la Parte 1, usted creó un conjunto de proyectos de DayTrader y tiene la configuración del servidor Liberty y el espacio de trabajo necesarios. Si usted descargó el archivo Part1Finish.zip de GitHub, tiene que importar estos proyectos:

1- Importe los proyectos de DayTrader del archivo ZIP descargado: a. Desde el menú de Eclipse, seleccione Archivo -> Importar. b. En la ventana de Importar, expanda General, y seleccione Proyectos Existentes al Espacio de Trabajo. Haga clic en Siguiente.

<figure> <img alt="El asistente de importación" height="427" src="https://developer.ibm.com/developer/default/tutorials/mw-1709-mulley2-bluemix/images/Figure4.png" width="790"></img></figure>

2- En la ventana de Importar Proyectos, haga clic en Explorar, y encuentre y seleccione el archivo ZIP que descargó para la Parte 1, lo que incluye los proyectos daytrader3-ee6, dt-ejb, Resty web . Haga clic en Finalizar para empezar a importar los proyectos al espacio de trabajo.

Importar los proyectos al espacio de trabajo

Después de que haya finalizado la importación del proyecto, es posible que comience la migración del proceso del espacio de trabajo. 3- En la ventana Migración de Espacio de Trabajo, seleccione los cuatro proyectos (daytrader3-ee6, dt-ejb, Resty web), y haga clic en Siguiente.

<figure> <img alt="Ventana de Migración de Espacio de Trabajo" height="477"         src="https://developer.ibm.com/developer/default/tutorials/mw-1709-mulley2-bluemix/images/Figure6.png" width="651"></img></figure>

4- En la ventana de Tiempo de Ejecución de Servidor no Definido, asegúrese de que el tiempo de ejecución del servidor WLP-17.0.0.2 esté seleccionado para todos los proyectos. Haga clic en Siguiente.

<figure> <img alt="Ventana de tiempo de ejecución del servidor no definido" height="268" src="https://developer.ibm.com/developer/default/tutorials/mw-1709-mulley2-bluemix/images/Figure7.png" width="913"></img></figure>

5- Haga clic en Finalizar para completar la migración del espacio de trabajo.

Ya importó los proyectos de la Parte 1, y puede continuar con su migración a la nube.

2

Ejecute el WebSphere Application Server Migration Toolkit

El plug-in The WebSphere Application Server Migration Toolkit Eclipse analiza los archivos de código fuente y de configuración para los problemas conocidos de la migración. En este paso, se utiliza la herramienta de migración para buscar problemas conocidos cuando se migra desde Liberty a IBM Cloud Public o Docker:

1- Abra el espacio de trabajo de la aplicación DayTrader en Eclipse. 2- Ejecute el WebSphere Application Server Migration Toolkit. Haga clic en Ejecute -> Análisis. 3- En la ventana de Configuraciones del Analizador de Software, seleccione Analizador de Software en la columna de la izquierda y, después, haga clic en el icono Nuevo (primer icono del lado izquierdo, encima de la caja de filtrado. En el panel de la derecha, para el campo Nombre introduzca un nombre adecuado para la configuración. En la pestaña Alcance , haga clic en Analizar todo el espacio de trabajo.

Crear, administrar y ejecutar configuraciones - pestaña Scope

4- En la pestaña Reglas , en Conjuntos de Reglas, seleccione Migración de Aplicación a la Nube, y después haga clic en Establecer.

Crear, administrar y ejecutar configuraciones - pestaña Rules

Importante: Si usted está siguiendo los pasos para la migración a IBM Cloud Public y a Cloud Private, solo realice el análisis para IBM Cloud Public. Los resultados de IBM Cloud Public son un superconjunto de los resultados de Docker, y la modificación de código final que se necesita para ambos es la misma.

5- En la ventana de configuración del conjunto de reglas, para migrar a IBM Cloud Public para Cloud Foundry, haga los siguientes cambios: a. Para Servidor de aplicaciones de destino, seleccione Liberty. b. Para Tiempo de ejecución de nube de destino, seleccione IBM Cloud Instant Runtimes (Cloud Foundry). c. Para Versión de Java de destino, seleccione IBM Java 8. d. Haga clic en OK. Para migrar a IBM Cloud Private para Docker, haga los siguientes cambios: a. Para Servidor de aplicaciones de destino, seleccione Liberty. b. Para Tiempo de ejecución de nube de destino, seleccione Docker (IBM Containers). c. Para Versión de Java de destino, seleccione IBM Java**8. d. Haga clic en OK**.

6- De vuelta a la ventana de Configuraciones del Analizador de Software, haga clic en Aplicar para guardar los cambios y, después, haga clic en Analizar para iniciar el análisis.

Selección de reglas

Cuando el análisis haya finalizado, la ventana de Resultados del Analizador de Software muestra las pestañas Revisión de Archivo XML, Revisión de Archivo y Revisión de Código Java.

Ventana de Resultados del Analizador de Software
3

Resuelva los problemas de código Java, código JSP, archivo XML y archivo

Para resolver los problemas de revisión de código Java, vaya al panel de Resultados del Analizador de Software, en la pestaña Revisión de Código Java y expanda el árbol Migración a nube. Como se muestra en la siguiente imagen, usted verá los problemas de código Java para archivos de código específicos.

Problemas de código Java

Haga doble clic en los archivos del árbol para ir al código en el que se detectó el problema de migración. También es posible seleccionar Ayuda -> Mostrar Ayuda Contextual para abrir la ventana de Ayuda y ver una explicación del problema de la migración. Para obtener más información acerca del problema y de soluciones recomendadas, haga clic en el enlace Ayuda Detallada.

Ayuda detallada del problema de migración

Las siguientes secciones le ayudan a entender cada uno de los problemas de la migración que el escáner identifica. Después, podrá implementar la solución recomendada para migrar la aplicación para el despliegue en la nube. Estas soluciones abarcan los resultados del escaneo para los problemas de migraciones de IBM Cloud Public (Cloud Foundry) y Docker. Cuando corresponda, se explicará un análisis diferente, y se especificarán las soluciones para cada plataforma.

Regla de la migración: valide el host de la URL y el puerto para el acceso a la nube

La regla de validar el host de la URL y el puerto para el acceso a la nube le avise de que en el código hay un literal de una cadena de caracteres Java que incluye un host y un puerto. Si esos host y puerto están en un sistema externo, es posible que experimente problemas de conectividad. Las plataformas afectadas son IBM Cloud Public (Cloud Foundry) e IBM Cloud Private (Docker/Kubernetes).

Análisis

Si hace doble clic en el archivo PingServlet2PDF.java del panel de Revisión de Código de Java para abrir el archivo, verá el URL http://localhost:9080/daytrader/WAS_V7_64-bit_performance.pdf. Este URL hace referencia a un PDF que es interno para la aplicación. Este PDF se moverá a la nube con la aplicación Daytrader3. Sin embargo, el URL será diferente en la nube. Por lo tanto, tiene que hacer algunos cambios en el código.

Solución

Para solucionar este problema, cambie el código para poner el URL correcto o, mejor aún, externalice el URL y búsquelo desde la aplicación. Al utilizar la última opción puede cambiar el URL sin tener que cambiar el código fuente de la aplicación. Para externalizar el URL hay las siguientes opciones:

  • Definir el URL en la variable de entorno del sistema, y leerla con la propiedad System.getenv(). IBM Cloud Public (Cloud Foundry). Es posible establecer las variables de entorno con el archivo manifest.yml durante el despliegue. Como alternativa, se puede establecer después del despliegue mediante el comando bx cf set-env. Docker. Es posible establecer las variables de entorno con las opciones -e o -env en el comando docker run. Como alternativa, puede utilizar la opción --env-file en el comando docker run con un archivo an env.list. Para obtener más información, vea la referencia del comando docker run. IBM Cloud Private. Es posible establecer las variables de entorno con la consola administrativa de Kubernetes (se muestra más tarde en este tutorial) o con la CLI de kubectl . Para obtener información acerca del uso de la CLI de kubectl, vea los ejemplos de Definir Variables de Entorno para un Contenedor y Exponer Información de Módulos a los Contenedores a través de Variables de Entorno Variables.
  • Definir el URL en el archivo jvm.options, y leerlo con la propiedad System.getProperty().
  • Definir el URL en la env-entry de Java Naming and Directory Interface (JNDI) del archivo server.xml, y buscarlo con el JNDI.
  • Definir el URL en un archivo de propiedades de la carpeta ${server.config.dir}/resources, añadir referencias al archivo de propiedades en el archivo server.xml y cargar las propiedades desde la ruta de la clase con la propiedad Class.getResourcesStream().

La mejor práctica es que la aplicación lea una variable de entorno, lo que se logra utilizando la opción para definir un URL en la variable de entorno del sistema. Describimos la construcción del archivo YAML (.yml) para Cloud Foundry más tarde en el Paso 4. Solo externalizamos el punto final y la parte de la raíz del contexto del URL porque la ubicación real del archivo PDF dentro de la propia aplicación será constante con independencia de donde lo despleguemos.

Para implementar el cambio de código para la primera opción (para definir el URL en la variable de entorno del sistema), en Eclipse:

  1. En Enterprise Explorer, abra el archivo /Java Resources/src/com.ibm.websphere.samples.daytrader.web.prims/PingServlet2PDF.java si no está ya abierto.
  2. Cambie la siguiente línea de código en el método doGet():
     String fileURL = "http://localhost:9080/daytrader/WAS_V7_64‑bit_performance.pdf")
    Cámbiela tal como se muestra aquí:
     String fileURL = System.getenv("DAYTRADER3_CONTEXT_ROOT_URL") + "/WAS_V7_64‑bit_performance.pdf";
  3. Guarde y cierre el archivo.

Regla de la migración: capture la información del registro

La regla Capture la información del registro detecta el uso de Apache Commons Logging. Le avisa de que se podrán perder los mensajes del registro que se escriben en el archivo local porque el sistema de archivos local es efímero. La regla se aplica si la aplicación se está ejecutando. La regla no se aplica si la aplicación se para. La plataforma afectada es IBM Cloud Public (Cloud Foundry).

Análisis

La aplicación Daytrader3 utiliza el registrador predeterminado simple. Escribe mensajes de registro en SYSERR. El registro de IBM Cloud recopila automáticamente los mensajes que se escriben en SYSERR.

Solución

La regla Capture información de registro informa de un falso positivo. Por lo tanto, _n_o son necesarios cambios.

Reglas de la migración: persistencia de la sesión HTTP

El problema o problema potencial con la regla de la persistencia de la sesión HTTP es que las sesiones HTTP no persisten ni se replican en las plataformas de nubes. Esta regla de la migración afecta a IBM Cloud Public (Cloud Foundry).

Análisis

Las sesiones locales afectan a la capacidad de conmutación por error sin perder la sesión. Si la aplicación Daytrader3 requiere persistencia de la sesión HTTP, puede configurarla para que utilice el servicio SessionCache o un servicio de una base de datos relacional para almacenar los datos de la sesión.

Solución

La aplicación no requiere de sesiones distribuidas. Este problema se puede ignorar.

Regla de la migración: transacciones con confirmaciones de dos fases

La regla de las transacciones con confirmaciones de dos fases avisa de que la aplicación está utilizando la confirmación de dos fases. También avisa de que el archivo de registro de transacciones se perderá si el archivo de la transacción se escribe en el sistema de archivos local. La plataforma afectada es IBM Cloud Public (Cloud Foundry).

Análisis

Un registro de transacciones perdido afecta a la capacidad de recuperación de la base de datos. Si la aplicación Daytrader3 requiere de recuperación de transacciones después de fallos, puede configurarla para que escriba su propio archivo de registro de transacciones en una base de datos relacional en vez de en el sistema de archivos local. Para obtener más información, vea el tema Liberty: almacenamiento del archivo de registro transaccional en una base de datos relacional en la documentación WebSphere Application Server for z/OS Liberty del IBM Knowledge Center.

Solución

Esta aplicación está diseñada para rellenar las tablas antes de cada ejecución. Por lo tanto, esta aplicación no requiere de una base de datos duradera. Por esa razón, pueden ignorar tranquilamente este problema.

Regla de la migración: Java Message Service y Message-Driven Beans

La regla Java Message Service (JMS) y Message-Driven Bean (MDB) avisa que la aplicación está utilizando un proveedor de mensajería que se puede dejar on-premises. En este caso, es posible que usted tenga que mover el proveedor de mensajería a la nube o establecer una conexión desde la nube hasta el proveedor de mensajería. Las plataformas afectadas son IBM Cloud Public (Cloud Foundry) e IBM Cloud Private (Docker/Kubernetes).

Análisis

La aplicación Daytrader3 ejecuta el proveedor JMS en el mismo contenedor de Liberty que la aplicación. La aplicación se conecta al motor de mensajería a través de llamadas a la API. En esta configuración no hay que resolver ningún problema de conectividad cuando el proveedor de mensajería se mueve a la nube.

También, la aplicación Daytrader3 almacena los mensajes en el sistema de archivos local del contenedor de Liberty. Cuando el contenedor para, se elimina el almacén de mensajes y los mensajes se pierden. Si la aplicación DayTrader necesita un almacén de mensajes más duradero, puede configurarlo para que utilice IBM MQ Light o cualquier otro proveedor de mensajería.

Solución

Puede restablecer DayTrader antes de cada ejecución para que el problema no afecte al uso esperado de la aplicación. Por lo tanto, puede ignorar tranquilamente este problema.

Regla de la migración: Base de datos

Las reglas de la migración de bases de datos alerta acerca de un potencial problema de conectividad para un servidor de bases de datos remotas. Si la base de datos no se mueve con la aplicación, debe cambiar la configuración del servidor y resolver los problemas de conectividad. Las plataformas afectadas son IBM Cloud Public (Cloud Foundry) e IBM Cloud Private (Docker/Kubernetes).

Análisis

La aplicación Daytrader3 utiliza la base de datos incorporada. Por lo tanto, el servidor de bases de datos se ejecuta en el mismo contenedor de Liberty que la aplicación. Usted no tiene que resolver ningún problema de conectividad.

También, el contenido Derby de la base de datos también se almacena en la carpeta de configuración del servicio Liberty. Esta carpeta solo existe si la aplicación se está ejecutando. Si la aplicación se para, se pierde la carpeta y la base de datos que está en ella. Si la aplicación DayTrader3 necesita una base de datos más duradera, puede configurarla para que utilice DashDB una base de datos similar.

Solución

La aplicación está diseñada para rellenar las tablas antes de cada ejecución. Este problema no afecta al uso esperado de la aplicación. Así que, se puede ignorar tranquilamente.

Nota de la implementación: los pasos 4 y 5 de la Parte 2 explican cómo ejecutar la aplicación DayTrader3. Si la está ejecutando en IBM Cloud Public con Cloud Foundry, complete el Paso 4. Si la está ejecutando en IBM Cloud Private con Docker/Kubernetes, complete el Paso 5. Si su propósito es ejecutar la aplicación DayTrader en IBM Cloud Public y en IBM Cloud Private, complete los Pasos 4 y 5.

4

Ejecute DayTrader en IBM Cloud Public (Cloud Foundry)

Este paso explica cómo implementar y ejecutar la aplicación DayTrader en IBM Cloud Public (Cloud Foundry). Se enseña cómo construir el paquete implementable; utilizar las interfaces de comandos; configurar IBM Cloud Public (Cloud Foundry); y probar, resolver problemas y gestionar la aplicación en IBM Cloud Public (Cloud Foundry).

4a

Cree el archivo manifest.yml

Para que la implementación al entorno de nubes de Cloud sea más coherente y reproducible, hay que crear un manifest.yml para definir las configuraciones de la implementación. Para simplificar, el archivo manifest.yml está en el proyecto Eclipse para la aplicación DayTrader. Complete los siguientes pasos en Eclipse:

1- Cree una carpeta de configuración en el proyecto daytrader3-ee6 EAR. 2- Haga clic derecho en la carpeta config , y seleccione Nuevo -> Archivo. 3- En el campo Nombre del archivo de la ventana de Nuevo Archivo, ingrese manifest.yml, y haga clic en Finalizar.

Crear el archivo manifest.yml

4- Copie los siguientes valores de opciones al archivo manifest.yml. Para obtener más información acerca de las diferentes opciones soportadas en IBM Cloud, vea el tema Manifiesto de la aplicación en IBM Cloud Docs. Usted debe implementar todas las aplicaciones en un subdominio único que esté definido por la opción host. Seleccione un nombre de host único e introdúzcalo en el archivo manifest.yml (por ejemplo: daytrader-ee6-<iniciales>, daytrader-ee6-<nombre_apellido>).

 
            applications:
            ‑ name: daytrader‑ee6
              memory:  512M
              disk_quota:  1024M
              instances:  1
              domain: mybluemix.net
              host: <subdominio_unico>
              disk_quota:  1024M
              env:
                DAYTRADER3_CONTEXT_ROOT_URL: "https://<subdominio_unico>.mybluemix.net/daytrader"

Observe la variable de entorno DAYTRADER3_CONTEXT_ROOT_URL que se establece y cómo corresponde al nombre del host y del dominio. El código migrado utilizará esta nueva variable de entorno (vea la Regla de la migración: valide el host de la URL y el puerto para el acceso a la nube).

5- Guarde y cierre el archivo.

4b

Exporte el archivo implementarle

Debido a que el código de la migración cambia, debe exportar un nuevo archivo implementable antes de implementar la aplicación en la nube. Complete los siguientes pasos en Eclipse:

1- En la vista Enterprise Explore, pulse con el botón derecho el proyectodaytrader3-ee6 , y seleccione Exportar -> Archivo EAR.

2- Haga clic en Explorar y navegue a %HOMEPATH%/wlp/usr/servers/Daytrader3Sample/
dropins
.

3- En la Ventana Exportar EAR, en Destino, seleccione el archivo daytrader3-ee6.ear existente. Después, seleccione Sobrescribir archivo existente, y haga clic en Finalizar.

Exportar el archivo DayTrader EAR

Este paso reemplaza el archivo EAR implementado anteriormente con un nuevo archivo y con las actualizaciones de código.

4c

Inicie sesión en IBM Cloud

  1. Abra una ventana de comandos de DOS (SO Windows) o una ventana del Terminal (Linux, UNIX o macOS).
  2. Conéctese a IBM Cloud Public (Cloud Foundry) mediante la utilización del comando bx api. Corrija la URL del punto final para la región de IBM Cloud en la que usted está. (Para obtener más información, vea el tema Regiones de IBM Cloud Docs.)
    bx api https://api.ng.bluemix.net
  3. Inicie sesión en su cuenta de IBM Cloud con el comando bx login: Si está iniciando sesión con un IBMid, utilice el comando -u :
    bx login ‑u <nombre_de_usuario> ‑o <organización> ‑s <espacio>
    Si está iniciando sesión con un ID Federado, utilice la opción -sso:
    bx login ‑u <nombre_de_usuario> ‑o <organización> ‑s <espacio> ‑sso
    Cuando se le solicite que finalice el inicio de sesión, introduzca la contraseña de su cuenta.
4d

Implemente la aplicación en IBM Cloud (Cloud Foundry)

La aplicación se puede implementar en IBM Cloud con el comando bx cf push:

bx cf push ‑f <ruta_del_manifiesto> ‑p <ruta_del_implementable>

Para esta aplicación, el comando se parece al siguiente ejemplo:

bx cf push –f %WORKSPACE%/daytrader3‑ee6/config/manifest.yml –p %HOMEPATH%/wlp/usr/servers/Daytrader3Sample

Este comando envía el directorio del servidor Liberty, que incluye la aplicación y la base de datos para IBM Cloud. La aplicación se puede implementar en IBM Cloud de otras maneras, pero el paquete del servidor ayuda a mover el servidor y su aplicación con un único comando. Para obtener más información acerca de esas otras opciones, vea las Opciones para enviar aplicaciones de Liberty en IBM Cloud Docs.

4e

Confirme la implementación

Para confirmar la implementación:

  1. Descargue el archivo messages.log con el comando bx cf ssh para confirmar que la aplicación se inició:
    bx cf ssh <nombre_de_aplicación> ‑c "cat logs/messages.log" > messages.log
  2. Confirme que la aplicación se inició buscando el siguiente mensaje en el archivo messages.log:
    CWWKZ0001I: La aplicación daytrader3-ee6 se inició en XX,XX segundos.

Se deben resolver todos los problemas de la implementación, por ejemplo, que la aplicación no se inicie o que haya errores en el archivo messages.log.

Resuelva los problemas de la implementación

Si ve el siguiente mensaje en el archivo messages.log, la biblioteca Derby no se encuentra en la ruta de clase. La aplicación la añadió al directorio /shared/resources en Liberty, lo que funciona localmente. Sin embargo, ese directorio no se envía a IBM Cloud. Por lo tanto, usted recibe el siguiente mensaje ClassNotFoundException:_
DSRA4000E: No se encontró una clase de implementación del controlador de JDBC válida para el jdbcDriver jdbcDriver[DerbyEmbedded] que utiliza la biblioteca DerbyLib

Para corregir este problema, en la vista Eclipse Enterprise Explorer:

  1. Vaya a la carpeta /WLP-17.0.0.2/servers/Daytrader3Sample y cree una carpeta nueva llamada resources. Después, haga clic en Finalizar.
Carpeta resources

2- Vaya a la carpeta /WLP-17.0.0.2/shared/resources , haga clic derecho en la carpeta data , y seleccione Mover . 3- En la ventana Elegir destino para ‘data’, seleccione /WLP-17.0.0.2/servers/Daytrader3Sample/resources, y después haga clic en OK.

Mover la carpeta data

4- Repita los pasos 2 y 3 para la carpeta Daytrader3SampleDerbyLibs que está bajo la carpeta /WLP-17.0.0.2/servers/Daytrader3Sample/resources. 5- Expanda la carpeta /WLP-17.0.0.2/servers/Daytrader3Sample, y haga doble clic en el archivo server.xml. 6- Desde el menú de Eclipse, seleccione Editar -> Encontrar/Reemplazar. En el campo Encontrar de la ventana Encontrar/Reemplazar introduzca {shared.resource.dir}, y en el campo Reemplazar, introduzca {server.config.dir}/resources. Después, haga clic en Reemplazar Todo para modificar todas las ocurrencias.

Ventana Encontrar/Reemplazar

7- Cierre de la ventana de Encontrar/Reemplazar. Después, guarde y cierre el archivo server.xml.

Vuelva a implementar la aplicación en IBM Cloud

Repita las instrucciones de los pasos 4c, 4d y el principio del 4e para volver a implementar el paquete del servidor en IBM Cloud Public (Cloud Foundry). Ya no debería ver más ClassNotFoundExceptions en el archivo messages.log.

4f

Confirme que la aplicación esté funcionando

1- Ejecute la aplicación en IBM Cloud. Ingrese el siguiente URL en el navegador. Reemplace con el nombre de host que usted estableció anteriormente en el archivo YAML:
https://<subdominio_unico>.mybluemix.net/daytrader/

Usted debería poder ver la página de inicio de DayTrader (vea el Paso 6 de la Parte 1.

2- Ejecute una prueba más para asegurarse de que el cambio que realizó para externalizar el URL esté funcionando. Ingrese el siguiente URL. De nuevo, reemplace con su propio nombre de host:

https://<subdominio_unico>.mybluemix.net/daytrader/servlet/PingServlet2PDF

Ya debería poder ver el PDF tal como se muestra en la siguiente imagen.

Archivo PingServlet2PDF

Si el PDF no se muestra, resuelva los problemas de tiempo de ejecución tal como se explica en la siguiente sección.

Para probar más la implementación de IBM Cloud de la aplicación DayTrader, siga las instrucciones del «Paso 6: Ejecutar la aplicación DayTrader» de la Parte 1. Si recibe algún error de tiempo de ejecución, resuélvalo tal como se explica a continuación.

Resolver los problemas de tiempo de ejecución

Si usted siguió las opciones de este tutorial, en este punto ya no debería tener ningún problema adicional de tiempo de ejecución. Sin embargo, si encontrase más problemas, debe recopilar los datos de resolución de problemas de IBM Cloud Public (Cloud Foundry):

Como poco, descargue y revise el archivo messages.log de IBM Cloud con el comando bx:

 bx cf ssh <nombre_de_aplicación> ‑c "cat logs/messages.log" > messages.log

También vea el tutorial Recopilar datos de la resolución de problemas para Webhere Liberty for Java en IBM Cloud de developerWorks.

Ahora está ejecutando la aplicación en IBM Cloud Public con Cloud Foundry. Si usted también tiene planes de ejecutar la aplicación DayTrader en IBM Cloud Private con Docker/Kubernetes, continúe con el Paso 5. En caso contrario, la implementación finalizó.

5

Ejecutar DayTrader en IBM Cloud Private (Docker/Kubernetes)

En este paso, usted implementa y ejecuta la aplicación DayTrader en IBM Cloud Private (Docker/Kubernetes). Antes de que implemente en un entorno de IBM Cloud Private, tiene que construir una imagen de Docker para la aplicación DayTrader y probarla localmente en el entorno de Docker. Estos pasos de Docker son compatibles con todas las plataformas de motores de contenedores que se basan en Docker (por ejemplo: Docker CE, Docker EE e IBM Cloud Container Service). Después, tiene que propagar la imagen de Docker en funcionamiento al entorno IBM Cloud Private y exponerla para su acceso público.

IBM publicó una imagen oficial de Liberty para usuarios de IBM WebSphere Application Server for Developers que quieran ejecutar sus aplicaciones de Liberty en Docker. La imagen básica de WebSphere Liberty se puede personalizar de diferentes formas para ejecutar la aplicación DayTrader. En este caso, se utiliza Dockerfile para poder construir una imagen personalizada de forma repetida y con consistencia. Se enseña cómo utilizar las interfaces de comandos, cómo utilizar las consolas administrativas de la GUI, y cómo probar y gestionar la aplicación en Cloud Private.

5a

Preparar el código fuente

La migración de código que es necesaria para Docker es un subconjunto de la migración de código que es necesaria para IBM Cloud Public (Cloud Foundry). Por lo tanto, si usted completó el Paso 4, puede saltarse este paso de preparación. Si usted se saltó el Paso 4, debe modificar los artefactos implementables antes de continuar con los pasos que faltan de esta sección.

En la vista Eclipse Enterprise Explorer:

1- Vaya a la carpeta /WLP-17.0.0.2/servers/Daytrader3Sample , y cree una carpeta nueva llamada resources.

Carpeta resources

2- Vaya a la carpeta /WLP-17.0.0.2/shared/resources , haga clic derecho en la carpeta data , y haga clic en Mover. 3- En la ventana Elegir destino para ‘data’, seleccione /WLP-17.0.0.2/servers/Daytrader3Sample/resources, y haga clic en OK. Mover la carpeta data DerbyDB 4- Repita los pasos 2 y 3 para la carpeta Daytrader3SampleDerbyLibs que está bajo la carpeta /WLP-17.0.0.2/servers/Daytrader3Sample/resources. 5- Ampliar/WLP-17.0.0.2/servers/Daytrader3Sample y haga doble clic en el archivo server.xml. 6- Desde el menú de Eclipse, seleccione Editar -> Encontrar/Reemplazar. En el campo Encontrar de la ventana Encontrar/Reemplazar introduzca {shared.resource.dir}, y en el campo Reemplazar con, introduzca {server.config.dir}/resources. Después, haga clic en Reemplazar Todo para modificar todas las ocurrencias.

Ventana Encontrar/Reemplazar

7- Cierre de la ventana de Encontrar/Reemplazar. Después, guarde y cierre el archivo server.xml.

Ahora está listo para continuar con la implementación en Docker.

5b

Cree un Dockerfile

El Dockerfile describe los comandos que usted puede ejecutar para crear una nueva imagen de Docker con un conjunto de configuraciones particular. Para crear un Dockerfile que especifique las configuraciones para la imagen de DayTrader Docker en este tutorial:

1- Cree una carpeta de configuración en el proyecto daytrader3-ee6 EAR, si todavía no existe. 2- Haga clic derecho en la carpeta config , y seleccione Nuevo -> Archivo. 3- En el campo Nombre del archivo de la ventana de Nuevo Archivo, ingrese Dockerfile, y haga clic en Finalizar.

Crear el archivo Dockerfile

4- Si se le solicita que seleccione un editor para Dockerfile, seleccione el editor que quiere utilizar. El Editor de Texto sirve para nuestros propósitos. Haga clic en OK.

Editor Dockerfile

Si el nuevo Dockerfile no se abre para su edición, haga doble clic en el árbol de Enterprise Explorer para abrirlo.

5- Copie las siguientes instrucciones de Dockerfile en el archivo.


 FROM websphere‑liberty:kernel
 COPY wlp/usr/servers/Daytrader3Sample/opt/ibm/wlp/usr/servers/defaultServer
 RUN installUtility install ‑‑acceptLicense defaultServer
La instrucción FROM de la primera línea indica al demonio de Docker que esta nueva imagen utilizará la imagen websphere-liberty:kernel como imagen base. Esta imagen está formada por un entorno de Docker que tiene instalado un servidor Liberty e IBM JDK. Para obtener más información acerca de la imagen websphere-liberty, vea el tema websphere-liberty en el centro de Docker. La instrucción COPY toma el argumento del origen y de la ruta de destino. La instrucción «here» comunica al demonio de Docker que copie toda la carpeta del servidor Liberty para la aplicación de muestra DayTrader a la carpeta predeterminada del servidor Liberty que se crea en la imagen websphere-liberty:kernel. Este paso es igual que enviar todo el paquete del servidor como se realizó anteriormente en la implementación en IBM Cloud. La instrucción RUN inicia el comando Liberty installUtility para instalar todas las funciones que se especifican en el archivo server.xml file para defaultServer. 6- Guarde y cierre el Dockerfile.

5c

Cree una imagen de Docker para la aplicación DayTrader

1- Compile todos los artefactos implementables, y cópielos al mismo directorio. La construcción de Docker se refiere a esta ubicación como la ruta de contexto. Este directorio puede ser temporal o permanente dependiendo del proceso de gestión de la construcción. Para este tutorial, usted crea un directorio temporal. Utilice su gestor de archivos preferido para crear un directorio en %DOCKERTMPPATH%. 2- Cree una estructura de carpetas anidada de %DOCKERTMPPATH%/wlp/usr/servers%DOCKERTMPPATH%/wlp/usr/servers.

Cree una estructura de carpetas anidada de Docker

3- Copie el directorio %HOMEPATH%/wlp/usr/servers/Daytrader3Sample al directorio %DOCKERTMPPATH%/wlp/usr/servers, que es el servidor DayTrader Liberty local que usted configuró e implementó en Cloud Foundry anteriormente en este tutorial. La ubicación resultante de Daytrader3Sample dentro del directorio %DOCKERTMPPATH% coincide con la ruta de origen que se especifica en la instrucción COPY del Dockerfile.

instrucción COPY del Dockerfile

4- Copie el Dockerfile que ustede creó anteriormente al directorio %DOCKERTMPPATH%.

Copie el Dockerfile creado

5- Abra una ventana de comandos de DOS (para SO Windows) o una ventana del Terminal (para macOS, SO Linux, o SO UNIX).%DOCKERTMPPATH% . Ejecute el siguiente comando básico docker build :

docker build ‑t <tagname>
 <context_path>
El -t <tag_name> crea una etiqueta para la imagen personalizada. Las etiquetas de Docker tienen muchos usos, pero se usan principalmente para clarificar la versión y especificar el registro. Debido a que la imagen se basa en la imagen websphere-liberty:kernel, aquí se establece una etiqueta para clarificar que la imagen es una personalización para la aplicación DayTrader que se está implementando. <context_path> es el directorio raíz en el que obtendrá todos los artefactos de origen que se especifican en el Dockerfile. El contenido del directorio se envía recursivamente al demonio de Docker al principio de cada construcción. En este caso, la ruta de contexto es %DOCKERTMPPATH%%DOCKERTMPPATH%. Debido a que usted está ejecutando el CLI de Docker desde %DOCKERTMPPATH%_%DOCKERTMPPATH%, el comando docker build se parecerá a este ejemplo:
docker build –t wlp‑daytrader‑ee6 .
El resultado del proceso de la construcción es la descarga de la imagen websphere-liberty:kernel, la copia de los archivos y la instalación de las funciones necesarias de Liberty. Al final del proceso de la construcción verá un mensaje similar al ejemplo siguiente.

Resultado de construcción de Docker

6- Ejecute el comando docker images para verificar que la imagen wlp-daytrader-ee6 está disponible. Usted verá de la imagen websphere-liberty:kernel está descargada y disponible.

Imagen Docker wlp-daytrader-ee6

7- Verifique que la imagen construida recientemente se esté ejecutando en un contenedor:


 docker run ‑‑name wlp‑daytrader‑ee6 \
 ‑p 9080:9080 \
 ‑e "DAYTRADER3CONTEXT_ROOT_URL=http://localhost:9080/daytrader" \
 ‑d wlp‑daytrader‑ee6
Observe los siguientes parámetros: --name: El nombre que quiere asignar al contenedor. -p: Para _publicar_el puerto de un contenedor en un puerto de host. En este caso, el puerto 9080 del contenedor está disponible para el host que está usando el puerto 9080. -e: La _variable de entorno se establece en el sistema operativo del contenedor. Establecemos esta variable porque externalizamos el host y la raíz del contexto de la aplicación DayTrader a una variable de entorno cuando migramos la aplicación. -d: Para separar el contenedor para ejecutarlo en el trasfondo e imprimir el ID del contenedor.

Ejecutando el contenedor wlp-daytrader-ee6

8- Verificar que el contenedor se está ejecutando:


                    docker ps –a

El estado del contenedor wlp-daytrader-ee6

9- Muestre el archivo de registro de los contenedores de Docker, que muestra los mensajes del servidor Liberty. Asegúrese de que la aplicación DayTrader se inició correctamente.

docker logs –f –‑tail=all wlp‑daytrader‑ee6

El registro del servidor wlp-daytrader-ee6

10- Pulse CTRL+C para salir de la sesión de la cola de registro. 11- Verifique que puede acceder a la página de inicio de la aplicación DayTrader utilizando el URL en un navegador http://localhost:9080/daytrader. 12- Verifique la aplicación accediendo al URL http://localhost:9080/daytrader/servlet/PingServlet2PDF. Debería poder ver el archivo PingServlet2PDF. 13- Después de que verifique que la imagen DayTrader de docker esté funcionando correctamente en Docker, detenga el contenedor:

docker stop wlp‑daytrader‑ee6

5d

Añada la imagen DayTrader de Docker al registro de Cloud Private

Ahora que tiene una imagen DayTrader de Docker que fue probada en un contenedor local de Docker, lo siguiente es desplegarla en un entorno de IBM Cloud Private. Etiquete y envíe la imagen DayTrader de Docker que creó en las secciones anteriores al registro de Cloud Private Docker:

1- En una ventana de comandos de DOS (SO Windows) o una ventana del Terminal (macOS, SO Linux, o SO UNIX), inicie sesión en el registro de Cloud Private Docker. Asegúrese de que utiliza un usuario con los permisos adecuados.

docker login <host_de_cloud_private:puerto>

Inicie sesión en el registro de Cloud Private

2- Etiquete la imagen wlp-daytrader-ee6 para el registro de Cloud Private Docker:

docker tag wlp‑daytrader‑ee6 <host_de_cloud_private:puerto>/default/wlp‑daytrader‑ee6
3- Envíe la imagen al registro de Cloud Private Docker:
docker push <host_de_cloud_private:puerto>/default/wlp‑daytrader‑ee6

Envíe la imagen al registro de Cloud Private

4- Inicie sesión en su consola de Cloud Private. En la esquina superior izquierda, haga clic en el ícono de Menú, y seleccione Infraestructura -> Imágenes para verificar que su imagen se cargó.

Lista de imagenes
5e

Desplegar la aplicación DayTrader en Cloud Private

Para desplegar la imagen de Docker de la aplicación DayTrader con la consola de IBM Cloud Private:

1- En la esquina superior izquierda, haga clic en el ícono de Menú, y seleccione Cargas de Trabajo -> Aplicaciones. 2- Haga clic en el botón Desplegar Aplicación del lado derecho, encima de la lista de aplicaciones.

Botón Deploy Application

3- En la página Desplegar Aplicación Nueva, en la pestaña General, ingrese el nombre para la aplicación. En este ejemplo, ingresamos wlp-daytrader-ee6.

Ingrese el nombre para la aplicación

4- En la pestaña Ajustes del Contenedor: a. Ingrese el nombre y la imagen del contenedor. El nombre de la imagen debe coincidir con una imagen del registro de Cloud Private Docker. En este caso, la imagen es la que acaba de etiquetar y enviar, y debe tener el siguiente nombre /default/wlp-daytrader-ee6<host_de_cloud_private:puerto>/default/wlp-daytrader-ee6.

Definir la configuración del contenedor

b. Especifique los puertos que quiere que el contenedor exponga para el proxy. Desplácese hacia abajo, y en el campo Puerto del Contenedor, ingrese 80.

Especifique el puerto de contenedor

5- En la pestaña Variables de Entorno, añada una variable llamada DAYTRADER3_CONTEXT_ROOT_URL y que tenga el valor http://localhost:9080/daytrader.

Seleccione las variables de entorno

6- Haga clic en Desplegar en la esquina interior derecha para comenzar el despliegue.

5f

Configure la aplicación DayTrader para su uso externo

Para acceder a la aplicación con un navegador con el proxy, configure el Acceso Externo para generar un servicio para la aplicación.

1- En la consola de Cloud Private, desde el ícono Menú, seleccione Cargas de Trabajo -> Aplicaciones. Observe que la aplicación wlp-daytrader-ee6 ahora está en la lista y se inició. 2- Haga clic en el ícono Ajustes, y haga clic en Exponer.

Opción Expose

3- En la página Exponer Aplicación, bajo el método Exponer, seleccione Acceso. Después, ingrese un mapeo de puertos TCP para el http desde el puerto 80 al puerto de destino 9080. Haga clic en Exponer para completar la creación del servicio.

Página Exponer Aplicación

4- De vuelta a la consola de Cloud Private, desde el ícono Menú, seleccione Cargas de Trabajo -> Servicios. Observe que se muestra el servicio wlp-daytrader-ee6.

Cargas de Trabajo

5- Haga clic en el ícono Menú, y seleccione Cargas de Trabajo -> Aplicaciones. Haga clic en la aplicación wlp-daytrader-ee6 para ver los detalles de la aplicación. 6- En la página Visión general de la aplicación, desplácese hacia abajo hasta la sección Exponer Detalles. Haga clic en el enlace acceder http para abrir la página Bienvenido a Liberty para el servidor Liberty que está alojando la aplicación DayTrader.

El punto final de la aplicación
5g

Confirme que la aplicación esté funcionando

Ahora que la imagen DayTrader de Docker está desplegada y expuesta en el entorno de IBM Cloud Private, está listo para probar la aplicación DayTrader. :

1- Para abrir la aplicación DayTrader que se está ejecutando en el entorno de IBM Cloud Private, anote la ruta del contexto daytrader/ al URL del servidor Liberty expuesto. Verifique que la página principal de DayTrader sea accesible. 2- Verifique la aplicación anexando servlet/PingServlet2PDF al URL de la aplicación DayTrader. Ahora verá el archivo PingServlet2PDF. 3- Siga las instrucciones del «Paso 6: Ejecutar la aplicación DayTrader» de la Parte 1 de esta serie para probar más el despliegue de la aplicación DayTrader en IBM Cloud.

Conclusión

Ya ha migrado la versión local de la aplicación Daytrader3 a un entorno de nube. Como parte de este proceso se necesitaron esfuerzos adicionales para aumentar el código de la aplicación existente para adaptar las naturalezas dinámicas y transitorias de las soluciones de hosting en la nube. También creó nuevos artefactos de despliegue para los nuevos entornos de nube.