Migrar cargas de trabajo mediante el despliegue de herramientas de WebLogic

Despliegue todos los recursos y aplicaciones en un dominio aprovisionado a la vez, en lugar de individualmente.

Con WebLogic Deploy Tooling (WLDT), actualizará el archivo de modelo de dominio de origen para dirigir las distintas aplicaciones y recursos a los servidores del nuevo dominio y actualizar las conexiones a bases de datos para que coincidan con las bases de datos migradas a Oracle Cloud Infrastructure.

Antes de comenzar, tenga en cuenta lo siguiente:

El nombre de dominio creado para la imagen de Oracle WebLogic Server para Oracle Cloud Infrastructure es el prefijo proporcionado durante el provisionamiento con el sufijo agregado _domain, por ejemplo test_domain.
Los nombres de los servidores gestionados siguen el patrón <prefix>_server_<index> por ejemplo test_server_1, test_server_2, test_server_n donde n es el número de nodos aprovisionados.
El servidor del administrador se denomina <prefix>_adminserver, por ejemplo test__adminserver.
Si ha provisionado WebLogic Enterprise Edition, se aprovisiona un cluster denominado <prefijo>_cluster que incluye todos los servidores gestionados.
Necesitará la cadena de conexión para la base de datos creada anteriormente.
Si los archivos de aplicación están en la estructura de carpetas de ORACLE_HOME, WebLogic Deploy Tooling no los selecciona y se deben mover manualmente. También puede empaquetar los archivos de aplicación en un archivo zip con una estructura de carpetas similar a wlsdeploy/applications/<app.ear> y cambiar SourcePath a la misma ruta, de modo que WebLogic Deploy Tooling se desplegará en la carpeta por defecto del destino.

Como usuario adecuado de WebLogic (normalmente oracle) y con un JAVA_HOME configurado correctamente, instale WebLogic Deploy Tooling (WLDT) en el dominio de origen.

# install weblogic-deploy-tooling
# Check for the latest version at:
# https://github.com/oracle/weblogic-deploy-tooling/releases/
WLSDT_VERSION=1.7.0
echo $JAVA_HOME
# download and unzip the package
wget -qO- https://github.com/oracle/weblogic-deploy-tooling/releases/download/weblogic-deploy-tooling-${WLSDT_VERSION}/weblogic-deploy.zip | $JAVA_HOME/bin/jar xv
# make the scripts executable
chmod +x weblogic-deploy/bin/*.sh

Detectar el dominio de origen.

-domain_type define por defecto en WLS, por lo que se puede omitir para un dominio de WLS. Cuando es -domain_type JRF, el comando discovery filtra todos los componentes de JRF, provisionados de nuevo por la imagen del mercado en el caso de un dominio de JRF. El uso de JRF es un buen valor por defecto para la detección de todos los dominios.

Este ejemplo utiliza source para los archivos .yaml, .zip y .properties. Puede utilizar cualquier nombre de archivo válido.

# path to the parent of the wlserver folder (for example /u01/app/oracle/middleware/)
MW_HOME=
# path to the domain folder (i.e. <domain root>/<domain_name>)
DOMAIN_HOME=

weblogic-deploy/bin/discoverDomain.sh \
    -oracle_home $MW_HOME \
    -domain_home $DOMAIN_HOME \
    -archive_file source.zip \
    -model_file source.yaml \
    -variable_file source.properties \
    -domain_type JRF

# even if the domain is not JRF, using JRF domain type will only filter out domain libraries. If they don’t exist, this will not affect the output.

Mueva los archivos al servidor de administrador en el entorno de destino.

SOURCE_IP=<IP of the source WLS server>
ADMIN_SERVER_IP=<IP of the cloud Administrator server>
scp <source_user>@${SOURCE_IP}:~/source.* opc@${ADMIN_SERVER_IP}:~/

# change ownership of the files from opc to oracle 
# and move the file to the oracle user home
ssh opc@${ADMIN_SERVER_IP}
sudo chown oracle:oracle source.*
sudo mv source.* /home/oracle/
# switch to the oracle user
sudo su – oracle

Instale WebLogic Deploy Tooling en el servidor del administrador de WLS en Oracle Cloud Infrastructure.

# As the oracle user, install weblogic-deploy-tooling
WLSDT_VERSION=1.7.0
wget -qO- https://github.com/oracle/weblogic-deploy-tooling/releases/download/weblogic-deploy-tooling-${WLSDT_VERSION}/weblogic-deploy.zip | $JAVA_HOME/bin/jar xv

# make the scripts executable
chmod +x weblogic-deploy/bin/*.sh

Edite el archivo de modelo de dominio de origen para que coincida con la topología de dominio de destino.
- source.yaml: archivo de modelo que describe el dominio, su topología (servidores, clusters, etc.), recursos y despliegues de aplicaciones.
- source.zip: contiene los archivos de aplicación.
- source.properties: contiene los marcadores de posición de las credenciales que no se pueden incluir en el puerto.
Nota:
Al editar el archivo yaml, asegúrese de utilizar espacios, no separadores o el análisis fallará. Tenga en cuenta también que en YAML, la sangría representa la anidación, por lo que al eliminar una clave de nivel superior, debe eliminar todo lo que haya anidado en la clave hasta la siguiente en el mismo nivel.
1. Edite el archivo .yaml para mantener solo los recursos de secciones y appDeployments.
  - Elimine toda la sección domainInfo.
  - Elimine toda la sección topology.
  - WebLogic Server Enterprise Edition: Para cada aplicación anidada en resources, JDBCSystemResource y, a continuación, appDeployment, edite la clave Target para que coincida con el nombre de cluster en Oracle Cloud Infrastructure donde el nombre de cluster es <domain_prefix>_cluster, por ejemplo ee_cluster.
  - WebLogic Server Standard Edition: Para cada aplicación anidada en resources, JDBCSystemResource y, a continuación, appDeployment, edite la clave Target para que coincida con la lista de nombres de servidores gestionados en Oracle Cloud Infrastructure que la aplicación debe utilizar el patrón, <domain_prefix>_server_<id>. Separe las entradas de la lista con una coma y encierre la lista entre comillas simples o dobles. Por ejemplo, 'se_server_0,se_server_1,se_server_3'
2. Edite las URL de los orígenes de datos bajo cada clave de JDBCDriverParams.
  La URL debe seguir el patrón:
```
'jdbc:oracle:thin:@//<hostname>:<port>/<your_pdb_name>.<subdomain_name>'
```
  Donde hostname, port y subdomain_name pertenecen a la cadena de conexión de la base de datos, y your_pdb_name es el nombre de la PDB que aloja la base de datos (no el nombre raíz de la CDB).
  - Cadena de conexión de nodo único: <hostname>:<port>/<cdb_root_name>.<db_subnet_domain_name>
  - Cadena de conexión de varios nodos: <hostname>-scan:<port>/<cdb_root_name>.<db_subnet_domain_name>
  Use cualquiera de las dos formas si la base de datos consta solo de un nodo. Sin embargo, recomendamos que incluya el componente -scan para garantizar la detección adecuada y soportar una escala futura.
3. Agregue la clave de StagingMode si falta
  
  Para cada aplicación de appDeployments, asegúrese de que la clave de StagingMode esté definida en stage o agréguela si no está presente. Este valor despliega automáticamente los archivos en otros servidores gestionados de destino o servidores gestionados del cluster. Sin esta configuración, debe desplegar manualmente el archivo en cada servidor.
4. Edite el archivo source.properties y actualice la contraseña o las contraseñas de conexión JDBC de la base de datos o de la base de datos que ha migrado.
Ejecute el script updateDomain de despliegue de herramientas de WebLogic para actualizar el dominio.
```
# make sure the needed variables are set:
echo $DOMAIN_HOME
echo $MW_HOME

# run WebLogic Deploy Tooling updateDomain script in online mode
weblogic-deploy/bin/updateDomain.sh \
-oracle_home $MW_HOME \
-domain_home $DOMAIN_HOME \
-model_file source.yaml \
-variable_file source.properties \
-archive_file source.zip \
-admin_url t3://$(hostname -i):9071

# domain deployed before 05/19/2020 may need to use port 7001
```
Notas sobre este ejemplo:
- -domain_type no se utiliza aquí, ya que es solo una actualización. El uso de la opción -domain_type JRF (incluso para un dominio de JRF) provoca problemas de actualización con WLDT para actualizaciones en línea.
- -admin_url requiere el protocolo t3 con la IP privada local del servidor de administrador extraído mediante el comando hostname -i. HTTP o HTTPS a través de la IP pública no funcionan.
- Si se proporciona -admin_url en este comando, se asegura de que el dominio se ha actualizado en línea. No todos los dominios se pueden actualizar en línea, pero a menos que la topología se modifique (lo cual no es el caso aquí), debería funcionar para la mayoría de los dominios.
- La actualización en línea permite desplegar las aplicaciones y los recursos sin reiniciar los servidores. Si realiza la actualización fuera de línea, elimine la opción -admin_url y, a continuación, detenga y reinicie el servidor de WebLogic con los scripts stopWebLogic.sh y startWebLogic.sh. Utilice startWeblogic.sh &! para enviar el comando al fondo y descárselo, de modo que sobreviva a la salida del terminal.
- Si realiza la actualización fuera de línea, debe parar y reiniciar el servidor dos veces para que el indicador StagingMode=stage surta efecto. El primer reinicio actualiza la configuración y el segundo reinicio activa el despliegue de StagingMode.