Distribuire un'applicazione Java con WebLogic Server in un cluster del servizio Azure Kubernetes

Articolo
03/28/2024

Questo articolo illustra come:

Eseguire Java, Java EE o Jakarta EE in Oracle WebLogic Server (WLS).
Configurare un cluster WLS usando l'offerta di Azure Marketplace.
Compilare l'immagine Docker dell'applicazione da usare come immagine ausiliaria per fornire modelli e applicazioni WdT (WebLogic Deploy Tooling).
Distribuire l'applicazione in contenitori nel cluster WLS esistente nel servizio Azure Kubernetes con connessione a Microsoft Azure SQL.

Questo articolo usa l'offerta di Azure Marketplace per WLS per accelerare il percorso verso il servizio Azure Kubernetes. L'offerta effettua automaticamente il provisioning di diverse risorse di Azure, incluse le risorse seguenti:

Un'istanza di Registro Azure Container
Un cluster del servizio Azure Kubernetes
Istanza del controller di ingresso (AGIC) del gateway applicazione di Azure
Operatore WebLogic
Immagine del contenitore che include il runtime WebLogic
Un cluster WLS senza un'applicazione

Questo articolo presenta quindi la creazione di un'immagine ausiliaria dettagliata per aggiornare un cluster WLS esistente. L'immagine ausiliaria fornisce modelli di applicazione e WDT.

Per l'automazione completa, è possibile selezionare l'applicazione e configurare la connessione origine dati dal portale di Azure prima della distribuzione dell'offerta. Per visualizzare l'offerta, visitare il portale di Azure.

Per indicazioni dettagliate sulla configurazione di WebLogic Server nel servizio Azure Kubernetes, vedere la documentazione ufficiale di Oracle nel servizio Azure Kubernetes.

Prerequisiti

Se non si ha una sottoscrizione di Azure, creare un account Azure gratuito prima di iniziare.
Verificare che l'identità di Azure usata per accedere e completare questo articolo abbia il ruolo Proprietario nella sottoscrizione corrente o i ruoliCollaboratore e Amministratore accesso utenti nella sottoscrizione corrente. Per una panoramica dei ruoli di Azure, vedere Che cos'è il controllo degli accessi in base al ruolo di Azure? Per informazioni dettagliate sui ruoli specifici richiesti da WLS nel servizio Azure Kubernetes, vedere Ruoli predefiniti di Azure.
Avere le credenziali per un account Oracle Single Sign-On (SSO). Per crearne uno, vedere Creare l'account Oracle.
Accettare le condizioni di licenza per WLS.
- Visitare il Registro Contenitori Oracle ed eseguire l'accesso.
- Se si dispone di un diritto di supporto, selezionare Middleware, quindi cercare e selezionare weblogic_cpu.
- Se non si ha un diritto di supporto da Oracle, selezionare Middleware, quindi cercare e selezionare weblogic.
  
  Nota
  
  Ottenere un diritto di supporto da Oracle prima di passare all'ambiente di produzione. In caso contrario, l'esecuzione di immagini non sicure che non vengono applicate patch per errori di sicurezza critici. Per altre informazioni sugli aggiornamenti critici delle patch di Oracle, vedere Aggiornamenti critici delle patch, avvisi di sicurezza e bollettini di Oracle.
- Accetta il Contratto di licenza
Preparare un computer locale con sistema operativo simile a Unix installato (ad esempio Ubuntu, Azure Linux, macOS, Sottosistema Windows per Linux).
- Interfaccia della riga di comando di Azure. Usare az --version per verificare se az funziona. Questo documento è stato testato con la versione 2.55.1.
- Docker. Questo documento è stato testato con Docker versione 20.10.7. Usare docker info per verificare se il daemon Docker è in esecuzione.
- kubectl. Usare kubectl version per verificare se kubectl funziona. Questo documento è stato testato con la versione 1.21.2.
- Java JDK compatibile con la versione di WLS che si intende eseguire. L'articolo indica di installare una versione di WLS che usa JDK 11. Azure consiglia Microsoft build di OpenJDK. Assicurarsi che la JAVA_HOME variabile di ambiente sia impostata correttamente nelle shell in cui si eseguono i comandi.
- Maven 3.5.0 o versione successiva.
- Assicurarsi di avere installato l'utilità zip/unzip. Usare zip/unzip -v per verificare se zip/unzip funziona.
Tutti i passaggi descritti in questo articolo, ad eccezione di quelli che coinvolgono Docker, possono essere eseguiti anche in Azure Cloud Shell. Per altre informazioni su Azure Cloud Shell, vedere Che cos'è Azure Cloud Shell?

Distribuire WLS nel servizio Azure Kubernetes

I passaggi descritti in questa sezione consentono di distribuire WLS nel servizio Azure Kubernetes nel modo più semplice possibile. WLS nel servizio Azure Kubernetes offre un'ampia e completa selezione di integrazioni di Azure. Per maggiori informazioni, vedere Quali sono le soluzioni per eseguire Oracle WebLogic Server nel servizio Azure Kubernetes?

I passaggi seguenti illustrano come trovare l'offerta WLS nell'offerta servizio Azure Kubernetes e compilare il riquadro Informazioni di base.

Nella barra di ricerca nella parte superiore del portale di Azure immettere weblogic. Nella sezione Marketplace dei risultati della ricerca suggeriti automaticamente selezionare WebLogic Server nel servizio Azure Kubernetes.

È anche possibile passare direttamente all'offerta WebLogic Server nel servizio Azure Kubernetes.
Nella pagina dell'offerta selezionare Creare.
Nel riquadro Informazioni di base verificare che il valore visualizzato nel campo Sottoscrizione sia lo stesso a cui è stato eseguito l'accesso in Azure. Assicurarsi di avere i ruoli elencati nella sezione prerequisiti.
È necessario distribuire l'offerta in un gruppo di risorse vuoto. Nel campo Gruppo di risorse selezionare Crea nuovo e quindi immettere un valore per il gruppo di risorse. Poiché i gruppi di risorse devono essere univoci all'interno di una sottoscrizione, selezionare un nome univoco. Un modo semplice per avere nomi univoci consiste nell'usare una combinazione di iniziali, data odierna e un identificatore, ad esempio ejb0723wls.
In Dettagli istanza selezionare l'area per la distribuzione. Per un elenco delle aree di Azure in cui è disponibile il servizio Azure Kubernetes, vedere Disponibilità dell'area del servizio Azure Kubernetes.
In Credentials for WebLogiclasciare il valore predefinito per Username for Amministratore WebLogic.
RiempirewlsAksCluster2022 per password per amministratore WebLogic. Usare lo stesso valore per i campi di conferma e Password per crittografia del modello WebLogic.
Scorrere fino alla fine del riquadro Informazioni di base e notare i collegamenti utili per la documentazione, il supporto della community e come segnalare i problemi.
Selezionare Avanti.

I passaggi seguenti illustrano come avviare il processo di distribuzione.

Scorrere fino alla sezione etichettata Fornire un account Oracle Single Sign-On (SSO). Compilare le credenziali di Oracle SSO dalle precondizioni.
Seguire la procedura descritta nella casella delle informazioni a partire da Prima di procedere, è necessario accettare le condizioni e le restrizioni standard Oracle.
A seconda che l'account Oracle SSO disponga o meno di un diritto di supporto Oracle, selezionare l'opzione appropriata per Selezionare il tipo di WebLogic Server Images. Se l'account ha un diritto di supporto, selezionare Immagini di WebLogic Server con patch. In caso contrario, selezionare Immagini generali di WebLogic Server.
Lasciare il valore in Selezionare la combinazione desiderata di WebLogic Server... nel valore predefinito. Sono disponibili un'ampia gamma di opzioni per WLS, JDK e versione del sistema operativo.
Nella sezione Applicazione, accanto a Distribuire un'applicazione?selezionare No.

I passaggi seguenti lo rendono quindi la console di amministrazione WLS e l'app di esempio vengono esposte a Internet pubblico con un componente aggiuntivo in ingresso del gateway applicazione predefinito. Per altre informazioni, vedere Cos’è un controller di ingresso del gateway applicazione?

Selezionare Avanti per visualizzare il riquadro TLS/SSL.
Selezionare Avanti per visualizzare il riquadro Bilanciamento del carico.
Accanto a Opzioni di bilanciamento del carico selezionare Controller di ingresso del gateway applicazione.
In Controller di ingresso del gateway applicazione verranno visualizzati tutti i campi prepopolati con le impostazioni predefinite perRete virtuale eSubnet. Lasciare invariati i valori predefiniti.
Per Crea ingresso per la console di amministrazione selezionare Sì.
Lasciare i valori predefiniti per altri campi.
Selezionare Rivedi e crea. Verificare che la convalida non riesca. In caso di errore, correggere eventuali problemi di convalida e quindi selezionare nuovamente Rivedi e crea.
Seleziona Crea.
Tenere traccia dello stato di avanzamento della distribuzione nella pagina Distribuzione in corso.

A seconda delle condizioni di rete e di altre attività nell'area selezionata, il completamento della distribuzione potrebbe richiedere fino a 50 minuti.

È possibile eseguire i passaggi nella sezione Creare un database SQL di Azure durante l'attesa. Tornare a questa sezione al termine della creazione del database.

Esaminare l'output della distribuzione

Usare i passaggi descritti in questa sezione per verificare che la distribuzione abbia avuto esito positivo.

Se ci si è allontanati dalla pagina Distribuzione in corso, i passaggi seguenti mostrano come tornare a quella pagina. Se si è ancora nella pagina che mostra il messaggio Distribuzione completata, è possibile passare al passaggio 5 dopo lo screenshot successivo.

Nell’angolo di una pagina qualsiasi del portale di Microsoft Azure, selezionare il menu hamburger e selezionare Gruppi di risorse.
Nella casella con il testo Filtra per qualsiasi campoimmettere i primi caratteri del gruppo di risorse creato in precedenza. Se è stata seguita la convenzione consigliata, immettere le iniziali, quindi selezionare il gruppo di risorse appropriato.
Nella sezione Impostazionidel riquadro di spostamento selezionare Distribuzioni. Viene visualizzato un elenco ordinato delle distribuzioni in questo gruppo di risorse, con quello più recente.
Scorrere fino alla voce meno recente in questo elenco. Questa voce corrisponde alla distribuzione avviata nella sezione precedente. Selezionare la distribuzione meno recente, come illustrato nello screenshot seguente.
Nel riquadro di spostamento selezionare Outout. Questo elenco mostra i valori di output della distribuzione. Informazioni utili sono incluse negli output.
Il valore adminConsoleExternalUrl è il collegamento visibile a Internet pubblico completo alla console di amministrazione WLS per questo cluster del servizio Azure Kubernetes. Selezionare l'icona di copia accanto al valore del campo per copiare il collegamento negli Appunti. Salvare questo valore per un secondo momento.
Il valore clusterExternalUrl è il collegamento visibile a Internet pubblico completo all'app di esempio distribuita in WLS in questo cluster del servizio Azure Kubernetes. Selezionare l'icona di copia accanto al valore del campo per copiare il collegamento negli Appunti. Salvare questo valore per un secondo momento.
Il valore shellCmdtoOutputWlsImageModelYaml è la stringa base64 del modello WDT compilato nell'immagine del contenitore. Salvare questo valore per un secondo momento.
Il valore shellCmdtoOutputWlsImageProperties è una stringa base64 delle proprietà del modello WDT compilate nell'immagine del contenitore. Salvare questo valore per un secondo momento.
Il valore shellCmdtoConnectAks è il comando dell'interfaccia della riga di comando di Azure per connettersi a questo cluster del servizio Azure Kubernetes specifico. In questo modo è possibile usare kubectl per amministrare il cluster.

Gli altri valori negli output non rientrano nell'ambito di questo articolo, ma sono descritti in dettaglio nella Guida per l'utente di WebLogic nel servizio Azure Kubernetes.

Creare un database SQL di Azure

Per creare un database singolo database SQL di Azure da usare con l'app, seguire la procedura descritta in Avvio rapido: Creare un database singolo in database SQL di Azure. Annotare attentamente le differenze seguenti:

Nel passaggio Informazioni di base annotare i valori per Gruppo di risorse, Nome database, <nome-server.database.windows.net>, account di accesso amministratore del server e Password. Questo articolo fa riferimento al valore del gruppo di risorse del database come <db-resource-group>.
Nel passaggio Rete impostare il metodoConnessione ivity su Endpoint pubblico, impostare Consenti ai servizi e alle risorse di Azure di accedere a questo server su Sì e impostare Aggiungi indirizzo IP client corrente su Sì.

Nota

Il livello di calcolo serverless selezionato per questo database consente di risparmiare denaro mettendo il database in sospensione durante i periodi di inattività. L'app di esempio avrà esito negativo se il database è in stato di sospensione all'avvio dell'app.

Per forzare la riattivazione del database, è possibile eseguire una query usando l'editor di query. Seguire la procedura descritta in Eseguire query sul database. Ecco una query di esempio: SELECT * FROM COFFEE;.

Creare uno schema per l'applicazione di esempio. Seguire Eseguire una query sul database per aprire il riquadroEditor di query. Immettere ed eseguire la query seguente:
```
CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));
INSERT INTO SEQUENCE VALUES ('SEQ_GEN',0);
```
Dopo un'esecuzione riuscita, verrà visualizzato il messaggio Query completata: Righe interessate: 0. Se questo messaggio non viene visualizzato, risolvere e risolvere il problema prima di procedere.

Vengono creati database, tabelle, cluster del servizio Azure Kubernetes e cluster WLS. Se si vuole, è possibile esplorare la console di amministrazione aprendo un browser e passando all'indirizzo di adminConsoleExternalUrl. Accedere con i valori immessi durante la distribuzione del servizio Azure Kubernetes.

È possibile procedere alla preparazione del servizio Azure Kubernetes per ospitare l'applicazione WebLogic.

Configurare e distribuire l'applicazione di esempio

L'offerta effettua il provisioning del cluster WLS tramite il modello nell'immagine. Attualmente, il cluster WLS non ha alcuna applicazione distribuita.

Questa sezione aggiorna il cluster WLS distribuendo un'applicazione di esempio usando un'immagine ausiliaria.

Consultare l'applicazione

In questa sezione si clona il codice di esempio per questa guida. L'esempio si trova in GitHub nel repository weblogic-on-azure nella cartella javaee/weblogic-café/. Ecco la struttura di file dell'applicazione.

weblogic-cafe
├── pom.xml
└── src
    └── main
        ├── java
        │   └── cafe
        │       ├── model
        │       │   ├── CafeRepository.java
        │       │   └── entity
        │       │       └── Coffee.java
        │       └── web
        │           ├── rest
        │           │   └── CafeResource.java
        │           └── view
        │               └── Cafe.java
        ├── resources
        │   ├── META-INF
        │   │   └── persistence.xml
        │   └── cafe
        │       └── web
        │           ├── messages.properties
        │           └── messages_es.properties
        └── webapp
            ├── WEB-INF
            │   ├── beans.xml
            │   ├── faces-config.xml
            │   └── web.xml
            ├── index.xhtml
            └── resources
                └── components
                    └── inputPrice.xhtml

Seguire i comandi seguenti per clonare il repository:

cd <parent-directory-to-check-out-sample-code>
export BASE_DIR=$PWD
git clone --single-branch https://github.com/microsoft/weblogic-on-azure.git --branch 20240201 $BASE_DIR/weblogic-on-azure

Se viene visualizzato un messaggio relativo allo stato "HEAD scollegato", questo messaggio può essere tranquillamente ignorato. Significa semplicemente che è stato estratto un tag.

Usare il comando seguente per compilare javaee/weblogic-café/:

mvn clean package --file $BASE_DIR/weblogic-on-azure/javaee/weblogic-cafe/pom.xml

Il pacchetto deve essere generato correttamente e situato in $BASE_DIR/weblogic-on-azure/javaee/weblogic-café/target/weblogic-café.war. Se il pacchetto non viene visualizzato, è necessario risolvere il problema prima di continuare.

Usare Docker per creare un'immagine ausiliaria

I passaggi di questa sezione illustrano come creare un'immagine ausiliaria. Questa immagine include i componenti seguenti:

Il file modello di Modello di immagine
Applicazione
File di archivio del driver JDBC
Installazione degli strumenti di distribuzione WebLogic

Un'immagine ausiliaria è un'immagine del contenitore Docker contenente l'app e la configurazione. L'operatore Kubernetes WebLogic combina l'immagine ausiliaria con domain.spec.image nel cluster del servizio Azure Kubernetes che contiene WebLogic Server, JDK e sistema operativo. Per altre informazioni sulle immagini ausiliarie, vedere Immagini ausiliarie nella documentazione di Oracle.

Questa sezione richiede un terminale Linux con l'interfaccia della riga di comando di Azure e kubectl installato.

Per compilare l'immagine, seguire questa procedura:

Usare i comandi seguenti per creare una directory per preparare i modelli e l'applicazione:
```
mkdir -p ${BASE_DIR}/mystaging/models
cd ${BASE_DIR}/mystaging/models
```

Copiare il valore shellCmdtoOutputWlsImageModelYaml salvato dagli output della distribuzione, incollarlo nella finestra Bash ed eseguire il comando. Il comando dovrebbe essere simile all'esempio seguente:

echo -e IyBDb3B5cmlna...Cgo= | base64 -d > model.yaml

Questo comando genera un file ${BASE_DIR}/mystaging/models/model.yaml con contenuto simile all'esempio seguente:

# Copyright (c) 2020, 2021, Oracle and/or its affiliates.
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.

# Based on ./kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-images/model-in-image__WLS-v1/model.10.yaml
# in https://github.com/oracle/weblogic-kubernetes-operator.

domainInfo:
  AdminUserName: "@@SECRET:__weblogic-credentials__:username@@"
  AdminPassword: "@@SECRET:__weblogic-credentials__:password@@"
  ServerStartMode: "prod"

topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  SelfTuning:
    MinThreadsConstraint:
      SampleMinThreads:
        Target: "cluster-1"
        Count: 1
    MaxThreadsConstraint:
      SampleMaxThreads:
        Target: "cluster-1"
        Count: 10
    WorkManager:
      SampleWM:
        Target: "cluster-1"
        MinThreadsConstraint: "SampleMinThreads"
        MaxThreadsConstraint: "SampleMaxThreads"

In modo analogo, copiare il valore shellCmdtoOutputWlsImageProperties, incollarlo nella finestra Bash ed eseguire il comando. Il comando dovrebbe essere simile all'esempio seguente:

echo -e IyBDb3B5cml...pFPTUK | base64 -d > model.properties

Questo comando genera un file ${BASE_DIR}/mystaging/models/model.properties con contenuto simile all'esempio seguente:

# Copyright (c) 2021, Oracle Corporation and/or its affiliates.
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.

# Based on ./kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-images/model-in-image__WLS-v1/model.10.properties
# in https://github.com/oracle/weblogic-kubernetes-operator.

CLUSTER_SIZE=5

Usare la procedura seguente per creare il file del modello di applicazione.

Usare i comandi seguenti per copiare weblogic-café.war e salvarlo in wlsdeploy/applications:

mkdir -p ${BASE_DIR}/mystaging/models/wlsdeploy/applications
cp $BASE_DIR/weblogic-on-azure/javaee/weblogic-cafe/target/weblogic-cafe.war ${BASE_DIR}/mystaging/models/wlsdeploy/applications/weblogic-cafe.war

Usare i comandi seguenti per creare il file del modello di applicazione con il contenuto illustrato. Salvare il file del modello in ${BASE_DIR}/mystaging/models/appmodel.yaml.

cat <<EOF >appmodel.yaml
appDeployments:
  Application:
    weblogic-cafe:
      SourcePath: 'wlsdeploy/applications/weblogic-cafe.war'
      ModuleType: ear
      Target: 'cluster-1'
EOF

Usare i comandi seguenti per scaricare e installare il driver JDBC di Microsoft SQL Server in wlsdeploy/externalJDBCLibraries:

export DRIVER_VERSION="10.2.1.jre8"
export MSSQL_DRIVER_URL="https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/${DRIVER_VERSION}/mssql-jdbc-${DRIVER_VERSION}.jar"

mkdir ${BASE_DIR}/mystaging/models/wlsdeploy/externalJDBCLibraries
curl -m 120 -fL ${MSSQL_DRIVER_URL} -o ${BASE_DIR}/mystaging/models/wlsdeploy/externalJDBCLibraries/mssql-jdbc-${DRIVER_VERSION}.jar

Usare quindi i comandi seguenti per creare il file del modello di connessione alle banche dati con il contenuto illustrato. Salvare il file del modello in ${BASE_DIR}/mystaging/models/dbmodel.yaml. Il modello usa segnaposto (segreto sqlserver-secret) per nome utente, password e URL del database. Assicurarsi che i campi seguenti siano impostati correttamente. Il modello seguente assegna un nome alla risorsa con jdbc/WebLogicCafeDB.

Nome elemento	Campo	valore
Nome JNDI	`resources.JDBCSystemResource.<resource-name>.JdbcResource.JDBCDataSourceParams.JNDIName`	`jdbc/WebLogicCafeDB`
Nome del driver	`resources.JDBCSystemResource.<resource-name>.JDBCDriverParams.DriverName`	`com.microsoft.sqlserver.jdbc.SQLServerDriver`
Url database	`resources.JDBCSystemResource.<resource-name>.JDBCDriverParams.URL`	`@@SECRET:sqlserver-secret:url@@`
Password database	`resources.JDBCSystemResource.<resource-name>.JDBCDriverParams.PasswordEncrypted`	`@@SECRET:sqlserver-secret:password@@`
Nome utente database	`resources.JDBCSystemResource.<resource-name>.JDBCDriverParams.Properties.user.Value`	`'@@SECRET:sqlserver-secret:user@@'`

cat <<EOF >dbmodel.yaml
resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:sqlserver-secret:url@@'
          PasswordEncrypted: '@@SECRET:sqlserver-secret:password@@'
          Properties:
            user:
              Value: '@@SECRET:sqlserver-secret:user@@'
        JDBCConnectionPoolParams:
          TestTableName: SQL SELECT 1
          TestConnectionsOnReserve: true
EOF

Usare i comandi seguenti per creare un file di archivio dell'applicazione e quindi rimuovere la cartella wlsdeploy, che non è più necessaria:
```
cd ${BASE_DIR}/mystaging/models
zip -r archive.zip wlsdeploy

rm -f -r wlsdeploy
```

Usare i comandi seguenti per scaricare e installare WebLogic Deploy Tooling (WDT) nella directory di staging e rimuovere i file weblogic-deploy/bin/*.cmd, che non vengono usati negli ambienti UNIX:

cd ${BASE_DIR}/mystaging
curl -m 120 -fL https://github.com/oracle/weblogic-deploy-tooling/releases/latest/download/weblogic-deploy.zip -o weblogic-deploy.zip

unzip weblogic-deploy.zip -d .
rm ./weblogic-deploy/bin/*.cmd

Usare il comando seguente per rimuovere il programma di installazione di WDT:
```
rm weblogic-deploy.zip
```

Usare i comandi seguenti per compilare un'immagine ausiliaria usando Docker:

cd ${BASE_DIR}/mystaging
cat <<EOF >Dockerfile
FROM busybox
ARG AUXILIARY_IMAGE_PATH=/auxiliary
ARG USER=oracle
ARG USERID=1000
ARG GROUP=root
ENV AUXILIARY_IMAGE_PATH=\${AUXILIARY_IMAGE_PATH}
RUN adduser -D -u \${USERID} -G \$GROUP \$USER
# ARG expansion in COPY command's --chown is available in docker version 19.03.1+.
# For older docker versions, change the Dockerfile to use separate COPY and 'RUN chown' commands.
COPY --chown=\$USER:\$GROUP ./ \${AUXILIARY_IMAGE_PATH}/
USER \$USER
EOF

Eseguire il docker buildx build comando usando ${BASE_DIR}/mystaging/Dockerfile, come illustrato nell'esempio seguente:

cd ${BASE_DIR}/mystaging
docker buildx build --platform linux/amd64 --build-arg AUXILIARY_IMAGE_PATH=/auxiliary --tag model-in-image:WLS-v1 .

Quando si compila correttamente l'immagine, l'output è simile all'esempio seguente:

[+] Building 12.0s (8/8) FINISHED                                   docker:default
=> [internal] load build definition from Dockerfile                          0.8s
=> => transferring dockerfile: 473B                                          0.0s
=> [internal] load .dockerignore                                             1.1s
=> => transferring context: 2B                                               0.0s
=> [internal] load metadata for docker.io/library/busybox:latest             5.0s
=> [1/3] FROM docker.io/library/busybox@sha256:6d9ac9237a84afe1516540f40a0f  0.0s
=> [internal] load build context                                             0.3s
=> => transferring context: 21.89kB                                          0.0s
=> CACHED [2/3] RUN adduser -D -u 1000 -G root oracle                        0.0s
=> [3/3] COPY --chown=oracle:root ./ /auxiliary/                             1.5s
=> exporting to image                                                        1.3s
=> => exporting layers                                                       1.0s
=> => writing image sha256:2477d502a19dcc0e841630ea567f50d7084782499fe3032a  0.1s
=> => naming to docker.io/library/model-in-image:WLS-v1                      0.2s

Se l'immagine è stata creata correttamente, dovrebbe trovarsi nel repository Docker del computer locale. È possibile verificare la creazione dell'immagine usando il comando seguente:
```
docker images model-in-image:WLS-v1
```
Questo comando dovrebbe produrre un output simile all'esempio seguente:
```
REPOSITORY       TAG       IMAGE ID       CREATED       SIZE
model-in-image   WLS-v1    76abc1afdcc6   2 hours ago   8.61MB
```
Dopo aver creato l'immagine, i file eseguibili WDT devono essere in /auxiliary/weblogic-deploye nei file di archiviazione, proprietà e modello WDT in /auxiliary/models. Usare il comando seguente nell'immagine Docker per verificare questo risultato:
```
docker run -it --rm model-in-image:WLS-v1 find /auxiliary -maxdepth 2 -type f -print
```
Questo comando dovrebbe produrre un output simile all'esempio seguente:
```
/auxiliary/models/model.properties
/auxiliary/models/dbmodel.yaml
/auxiliary/models/model.yaml
/auxiliary/models/archive.zip
/auxiliary/models/appmodel.yaml
/auxiliary/Dockerfile
/auxiliary/weblogic-deploy/LICENSE.txt
/auxiliary/weblogic-deploy/VERSION.txt
```
Usare la procedura seguente per eseguire il push dell'immagine ausiliaria in Registro Azure Container:
1. Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WSL nel servizio Azure Kubernetes.
2. Selezionare la risorsa di tipo Registro contenitori dall'elenco delle risorse.
3. Passare il puntatore del mouse sul valore accanto a Server di accesso e selezionare l'icona di copia accanto al testo.
4. Salvare il valore nella variabile di ambiente ACR_LOGIN_SERVER usando il comando seguente:
```
export ACR_LOGIN_SERVER=<value-from-clipboard>
```
5. Eseguire i comandi seguenti per contrassegnare ed eseguire il push dell'immagine. Assicurarsi che Docker sia in esecuzione prima di eseguire questi comandi.
```
export ACR_NAME=$(echo ${ACR_LOGIN_SERVER} | cut -d '.' -f 1)
az acr login -n $ACR_NAME
docker tag model-in-image:WLS-v1 $ACR_LOGIN_SERVER/wlsaks-auxiliary-image:1.0
docker push $ACR_LOGIN_SERVER/wlsaks-auxiliary-image:1.0
```
6. È possibile eseguire az acr repository show per verificare se l'immagine viene inserita correttamente nel repository remoto, come illustrato nell'esempio seguente:
```
az acr repository show --name ${ACR_NAME} --image wlsaks-auxiliary-image:1.0
```
  Questo comando dovrebbe produrre un output simile all'esempio seguente:
```
{
  "changeableAttributes": {
    "deleteEnabled": true,
    "listEnabled": true,
    "readEnabled": true,
    "writeEnabled": true
  },
  "createdTime": "2024-01-24T06:14:19.4546321Z",
  "digest": "sha256:a1befbefd0181a06c6fe00848e76f1743c1fecba2b42a975e9504ba2aaae51ea",
  "lastUpdateTime": "2024-01-24T06:14:19.4546321Z",
  "name": "1.0",
  "quarantineState": "Passed",
  "signed": false
}
```

Applicare l'immagine ausiliaria

Nei passaggi precedenti è stata creata l'immagine ausiliaria, inclusi i modelli e WDT. Prima di applicare l'immagine ausiliaria al cluster WLS, seguire questa procedura per creare il segreto per l'URL, il nome utente e la password dell'origine dati. Il segreto viene usato come parte del segnaposto in dbmodel.yaml.

Connettersi al cluster del servizio Azure Kubernetes copiando il valore shellCmdtoConnectAks salvato in precedenza, incollandolo nella finestra Bash, quindi eseguendo il comando. Il comando dovrebbe essere simile all'esempio seguente:
```
az account set --subscription <subscription>; 
az aks get-credentials \
    --resource-group <resource-group> \
    --name <name>
```
L'output dovrebbe essere simile all'esempio seguente. Se questo output non viene visualizzato, risolvere e risolvere il problema prima di continuare.
```
Merged "<name>" as current context in /Users/<username>/.kube/config
```

Usare la procedura seguente per ottenere i valori per le variabili illustrate nella tabella seguente. Questi valori verranno usati in un secondo momento per creare il segreto per la connessione all'origine dati.

Variabile	descrizione	Esempio
`DB_CONNECTION_STRING`	Stringa di connessione di SQL Server.	`jdbc:sqlserver://sqlserverforwlsaks.database.windows.net:1433;database=wlsaksquickstart0125`
`DB_USER`	Nome utente per accedere a SQL Server.	`welogic@sqlserverforwlsaks`
`DB_PASSWORD`	Password per accedere al server sQL.	`Secret123456`

Visitare la risorsa del database SQL nel portale di Azure.
Nel riquadro di spostamento, in Impostazioniselezionare Stringhe di connessione.
Selezionare la scheda JDBC.
Selezionare l'icona copia per copiare la stringa di connessione negli Appunti.
Per DB_CONNECTION_STRING, usare l'intera stringa di connessione, ma sostituire il segnaposto {your_password_here} con la password del database.
Per DB_USER, usare la parte della stringa di connessione da azureuser in poi, ma non includere ;password={your_password_here}.
Per DB_PASSWORD, usare il valore immesso al momento della creazione del database.

Usare i comandi seguenti per creare il segreto Kubernetes. Questo articolo usa il nome sqlserver-secret del segreto per il segreto della connessione all'origine dati. Se si usa un nome diverso, assicurarsi che il valore sia uguale a quello in dbmodel.yaml.

Nei comandi seguenti assicurarsi di impostare le variabili DB_CONNECTION_STRING, DB_USERe DB_PASSWORD sostituendo correttamente gli esempi segnaposto con i valori descritti nei passaggi precedenti. Assicurarsi di racchiudere il valore delle variabili DB_ tra virgolette singole per impedire che la shell interferisca con i valori.
```
export DB_CONNECTION_STRING='<example-jdbc:sqlserver://sqlserverforwlsaks.database.windows.net:1433;database=wlsaksquickstart0125>'
export DB_USER='<example-welogic@sqlserverforwlsaks>'
export DB_PASSWORD='<example-Secret123456>'
export WLS_DOMAIN_NS=sample-domain1-ns
export WLS_DOMAIN_UID=sample-domain1
export SECRET_NAME=sqlserver-secret

kubectl -n ${WLS_DOMAIN_NS} create secret generic \
    ${SECRET_NAME} \
    --from-literal=password="${DB_PASSWORD}" \
    --from-literal=url="${DB_CONNECTION_STRING}" \
    --from-literal=user="${DB_USER}"

kubectl -n ${WLS_DOMAIN_NS} label secret \
    ${SECRET_NAME} \
    weblogic.domainUID=${WLS_DOMAIN_UID}
```
Prima di continuare, è necessario visualizzare l'output seguente. Se questo output non viene visualizzato, risolvere e risolvere il problema prima di continuare.
```
secret/sqlserver-secret created
secret/sqlserver-secret labeled
```

Applicare l'immagine ausiliaria applicando patch alla definizione della risorsa personalizzata del dominio usando il comando kubectl patch.

L'immagine ausiliaria è definita in spec.configuration.model.auxiliaryImages, come illustrato nell'esempio seguente. Per altre informazioni, vedere Immagini ausiliarie.

spec:
  clusters:
  - name: sample-domain1-cluster-1
  configuration:
    model:
      auxiliaryImages:
      - image: wlsaksacrafvzeyyswhxek.azurecr.io/wlsaks-auxiliary-image:1.0
        imagePullPolicy: IfNotPresent
        sourceModelHome: /auxiliary/models
        sourceWDTInstallHome: /auxiliary/weblogic-deploy

Usare i comandi seguenti per aumentare il valore restartVersion e usare kubectl patch per applicare l'immagine ausiliaria al dominio CRD usando la definizione illustrata:

export VERSION=$(kubectl -n ${WLS_DOMAIN_NS} get domain ${WLS_DOMAIN_UID} -o=jsonpath='{.spec.restartVersion}' | tr -d "\"")
export VERSION=$((VERSION+1))

cat <<EOF >patch-file.json
[
  {
    "op": "replace",
    "path": "/spec/restartVersion",
    "value": "${VERSION}"
  },
  {
    "op": "add",
    "path": "/spec/configuration/model/auxiliaryImages",
    "value": [{"image": "$ACR_LOGIN_SERVER/wlsaks-auxiliary-image:1.0", "imagePullPolicy": "IfNotPresent", "sourceModelHome": "/auxiliary/models", "sourceWDTInstallHome": "/auxiliary/weblogic-deploy"}]
  },
  {
    "op": "add",
    "path": "/spec/configuration/secrets",
    "value": ["${SECRET_NAME}"]
  }
]
EOF

kubectl -n ${WLS_DOMAIN_NS} patch domain ${WLS_DOMAIN_UID} \
    --type=json \
    --patch-file patch-file.json

kubectl get pod -n ${WLS_DOMAIN_NS} -w

Attendere che il server di amministrazione e i server gestiti visualizzino i valori nel blocco di output seguente prima di procedere:
```
NAME                             READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server      1/1     Running   0          20m
sample-domain1-managed-server1   1/1     Running   0          19m
sample-domain1-managed-server2   1/1     Running   0          18m
```
Potrebbero essere necessari 5-10 minuti prima che il sistema raggiunga questo stato. L'elenco seguente offre una panoramica delle operazioni che si verificano durante l'attesa:
- Dovrebbe essere visualizzata l’esecuzione di sample-domain1-introspector innanzitutto. Questo software cerca le modifiche apportate alla risorsa personalizzata del dominio in modo che possa eseguire le azioni necessarie nel cluster Kubernetes.
- Quando vengono rilevate modifiche, l'introspezione del dominio termina e avvia nuovi pod per implementare le modifiche.
- Verrà quindi visualizzato il termine e il riavvio del pod sample-domain1-admin-server.
- Verranno quindi visualizzati i due server gestiti terminano e si riavviano.
- Solo quando tutti e tre i pod mostrano lo stato 1/1 Running è possibile procedere.

Verificare la funzionalità della distribuzione

Usare la procedura seguente per verificare la funzionalità della distribuzione visualizzando la console di amministrazione di WLS e l'app di esempio:

Incollare il valore adminConsoleExternalUrl nella barra degli indirizzi di un Web browser connesso a Internet. Verrà visualizzata la schermata di accesso familiare della console di amministrazione di WLS.
Accedere con il nome utente weblogic e la password immessi durante la distribuzione di WLS dal portale di Azure. Tenere presente che questo valore è wlsAksCluster2022.
Nella casella Struttura dominio selezionare Servizi.
In Serviziselezionare Origini dati.
Nel pannelloRiepilogo delle origini dati JDBC selezionare Monitoraggio. La schermata dovrebbe essere simile all’esempio seguente. Lo stato dell'origine dati è in esecuzione nei server gestiti.
Nella casella Struttura dominio selezionare Distribuzioni.
Nella tabella Distribuzioni deve essere presente una riga. Il nome deve essere lo stesso valore del valore Application nel file appmodel.yaml. Selezionare il nome.
Nel pannello Impostazioni selezionare la scheda Test.
Selezionare weblogic-café.
Nel panello Impostazioni per weblogic-café selezionare la scheda Test.
Espandere l'icona + accanto a weblogic-café. La schermata dovrebbe essere simile all’esempio seguente. In particolare, verranno visualizzati valori simili a http://sample-domain1-managed-server1:8001/weblogic-cafe/index.xhtml nella colonna Punto di test.

Nota

I collegamenti ipertestuali nella colonna Punto di test non sono selezionabili perché non è stata configurata la console di amministrazione con l'URL esterno in cui è in esecuzione. Questo articolo illustra semplicemente la console di amministrazione WLS tramite una dimostrazione. Non usare la console di amministrazione WLS per eventuali modifiche di configurazione durevoli durante l'esecuzione di WLS nel servizio Azure Kubernetes. La progettazione nativa del cloud di WLS nel servizio Azure Kubernetes richiede che qualsiasi configurazione durevole debba essere rappresentata nelle immagini Docker iniziali o applicata al cluster del servizio Azure Kubernetes in esecuzione usando tecniche CI/CD come l'aggiornamento del modello, come descritto nella documentazione di Oracle.
Comprendere il valore context-path dell'app di esempio distribuita. Se è stata distribuita l'app di esempio consigliata, context-path è weblogic-cafe.
Costruire un URL completo per l'app di esempio aggiungendo l'oggetto context-path al valore clusterExternalUrl. Se è stata distribuita l'app di esempio consigliata, l'URL completo deve essere simile a http://wlsgw202401-wls-aks-domain1.eastus.cloudapp.azure.com/weblogic-cafe/.
Incollare l'URL completo in un Web browser connesso a Internet. Se è stata distribuita l'app di esempio consigliata, verranno visualizzati risultati simili allo screenshot seguente:

Pulire le risorse

Per evitare addebiti per Azure, è necessario eliminare le risorse non necessarie. Quando il cluster non è più necessario, usare il comando az group delete. Il comando seguente rimuove il gruppo di risorse, il servizio contenitore, il registro contenitori e tutte le risorse correlate:

az group delete --name <resource-group-name> --yes --no-wait
az group delete --name <db-resource-group-name> --yes --no-wait

Passaggi successivi

Per altre informazioni sull'esecuzione di WLS in servizio Azure Kubernetes o nelle macchine virtuali, vedere i collegamenti seguenti:

WLS nel servizio Azure Kubernetes

Eseguire la migrazione di applicazioni WebLogic Server al servizio Azure Kubernetes

WLS nelle macchine virtuali

Share via