Migrar Cargas de Trabalho Usando o WebLogic Deploy Tooling

Implantar todos os recursos e aplicativos em um domínio provisionado por vez, em vez de individualmente.

Usando o WLDT ("Deploy Tooling", Ferramento de implantação do WebLogic), você atualizará o arquivo do modelo do domínio de origem para direcionar as várias aplicações e recursos para os novos servidores do domínio e atualizar as conexões do banco de dados de acordo com os bancos de dados migrados para o Oracle Cloud Infrastructure.

Antes de começar, observe o seguinte:

O nome de domínio criado para a imagem do Oracle WebLogic Server para Oracle Cloud Infrastructure é o prefixo fornecido durante o provisionamento com o sufixo adicionado _domain, por exemplo, test_domain.
Os nomes de servidores gerenciados seguem o padrão <prefix>_server_<index>, por exemplo, test_server_1, test_server_2, test_server_n onde n é o número de nós provisionados.
O servidor Administrador é denominado <prefix>_adminserver, por exemplo, test__adminserver.
Se você tiver provisionado o WebLogic Enterprise Edition, um cluster chamado <prefix>_cluster será provisionado que inclui todos os servidores gerenciados.
Você precisará da string de conexão do banco de dados criado anteriormente.
Se os arquivos do aplicativo estiverem sob a estrutura de pastas ORACLE_HOME, eles não serão selecionados pela WebLogic Deploy Tooling e deverão ser movidos manualmente. Como alternativa, você pode empacotar os arquivos do aplicativo em um arquivo zip com a estrutura de pastas similar a wlsdeploy/applications/<app.ear> e alterar o SourcePath para o mesmo caminho, portanto, a Implantação de Ferramentas do WebLogic será implantada na pasta padrão no destino.

Como o usuário apropriado do WebLogic (normalmente oracle) e com um JAVA_HOME configurado corretamente, instale o WebLogic Deploy Tooling (WLDT) no domínio de origem.

# 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

Descubra o domínio de origem.

-domain_type adota como padrão o WLS para que ele possa ser omitido para um domínio do WLS. Quando -domain_type JRF, o comando de descoberta filtra todos os componentes JRF, que são reprovisionados pela imagem do marketplace no caso de um domínio JRF. Usando JRF é um bom default para descoberta de todos os domínios.

Este exemplo usa source para os arquivos .yaml, .zip e .properties. Você pode usar qualquer nome de arquivo 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.

Mova os arquivos para o servidor do Administrador no ambiente 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 o WebLogic Deploy Tooling no servidor do Administrador do WLS no 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 o arquivo do modelo de domínio de origem para corresponder à topologia do domínio de destino.
- source.yaml: arquivo de modelo que descreve o domínio, sua topologia (servidores, clusters etc.), recursos e implantações de aplicativos.
- source.zip: contém os arquivos da aplicação.
- source.properties: contém os placeholders das credenciais que não podem ser portas.
Observação:
Ao editar o arquivo yaml, certifique-se de usar espaços, as guias ou o parsing falhará. Observe também que, em YAML, o recuo representa aninhamento, portanto, ao remover uma chave de nível superior, você deve remover tudo aninhado na chave até a próxima chave no mesmo nível.
1. Edite o arquivo .yaml para manter somente os recursos das seções e o appDeployments.
  - Remova toda a seção domainInfo.
  - Remova toda a seção topology.
  - WebLogic Server Enterprise Edition: Para cada aplicativo aninhado em resources, então JDBCSystemResource e, em seguida, appDeployment, edite a chave Target para corresponder ao nome do cluster no Oracle Cloud Infrastructure no qual o nome do cluster é <domain_prefix>_cluster, por exemplo, ee_cluster.
  - WebLogic Server Standard Edition: Para cada aplicativo aninhada em resources, JDBCSystemResource e, em seguida, appDeployment, edite a chave Target para corresponder à lista de nomes de servidores gerenciados no Oracle Cloud Infrastructure que a aplicação deve direcionar usando o padrão, <domain_prefix>_server_<id>. Separe as entradas da lista com uma vírgula e coloque a lista entre aspas simples ou duplas. Por exemplo, 'se_server_0,se_server_1,se_server_3'
2. Edite os URLs das origens de dados em cada chave do JDBCDriverParams.
  O URL deve seguir o padrão:
```
'jdbc:oracle:thin:@//<hostname>:<port>/<your_pdb_name>.<subdomain_name>'
```
  Onde hostname, port e subdomain_name são da string de conexão do banco de dados e your_pdb_name é o nome do PDB que hospeda o banco de dados (não o nome raiz do CDB).
  - String de conexão de nó único: <hostname>:<port>/<cdb_root_name>.<db_subnet_domain_name>
  - String de conexão com vários nós: <hostname>-scan:<port>/<cdb_root_name>.<db_subnet_domain_name>
  Use um dos dois forms se o banco de dados consistir somente em um nó. No entanto, recomendamos que você inclua o componente -scan para garantir a descoberta adequada e para dar suporte à escala futura.
3. Adicione a chave StagingMode se estiver faltando
  
  Para cada aplicativo no appDeployments, certifique-se de que a chave StagingMode esteja definida como stage ou adicione-a, se não estiver presente. Esta definição implanta automaticamente os arquivos nos outros servidores gerenciados ou servidores gerenciados de destino do cluster. Sem essa definição, você deverá implantar manualmente o arquivo em cada servidor.
4. Edite o arquivo source.properties e atualize a senha ou senhas da conexão JDBC para o banco de dados ou o banco de dados que você migrou.
Execute o script WebLogic Deploy Tooling updateDomain para atualizar o domínio.
```
# 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
```
Observações sobre este exemplo:
- O -domain_type não é usado aqui, pois é apenas uma atualização. O uso da opção -domain_type JRF (mesmo para um domínio JRF) causa problemas de atualização com o WLDT para atualizações on-line.
- O -admin_url requer o protocolo t3 com o IP privado local do servidor do Administrador conforme extraído pelo comando hostname -i. HTTP ou HTTPS por meio do IP público não funcionam.
- Fornecer o -admin_url neste comando garante que o domínio seja atualizado on-line. Nem todos os domínios podem ser atualizados on-line, mas a menos que a topologia seja modificada (o que não é o caso aqui), ela deve funcionar na maioria dos domínios.
- A atualização on-line permite implantar os aplicativos e recursos sem reiniciar os servidores. Se você executar a atualização off-line, remova a opção -admin_url e, em seguida, interrompa e reinicie o servidor do WebLogic usando os scripts stopWebLogic.sh e startWebLogic.sh. Use startWeblogic.sh &! para enviar o comando ao plano de fundo e deslhe mesmo; portanto, ele sobrevive a saída do terminal.
- Se você executar a atualização off-line, deverá interromper e reiniciar o servidor duas vezes para que o indicador StagingMode=stage entre em vigor. A primeira reinicialização atualiza a configuração e a segunda reinicialização permite a implantação do StagingMode.