Distribuire un'applicazione Java con Open Liberty o WebSphere Liberty in un cluster del servizio Azure Kubernetes

  • Articolo

Questo articolo illustra come:

  • Eseguire l'applicazione Java, Java EE, Jakarta EE o MicroProfile nel runtime Open Liberty o IBM WebSphere Liberty.
  • Compilare l'immagine Docker dell'applicazione usando immagini del contenitore Open Liberty o WebSphere Liberty.
  • Distribuire l'applicazione in contenitori in un cluster del servizio Azure Kubernetes usando Open Liberty Operator o WebSphere Liberty Operator.

Open Liberty Operator semplifica la distribuzione e la gestione delle applicazioni in esecuzione nei cluster Kubernetes. Con Open Liberty Operator o WebSphere Liberty Operator, è anche possibile eseguire operazioni più avanzate, ad esempio la raccolta di tracce e dump.

Questo articolo usa l'offerta di Azure Marketplace per Open Liberty o WebSphere Liberty per accelerare il percorso verso il servizio Azure Kubernetes. L'offerta effettua automaticamente il provisioning di alcune risorse di Azure, tra cui:

  • Un'istanza di Registro Azure Container.
  • Un cluster servizio Azure Kubernetes.
  • Un’istanza del controller di ingresso del gateway applicazione (AGIC).
  • Open Liberty Operator e WebSphere Liberty Operator.
  • Facoltativamente, un'immagine del contenitore che include Liberty e l'applicazione.

Se si preferiscono indicazioni dettagliate manuali per l'esecuzione di Liberty nel servizio Azure Kubernetes, vedere Distribuire manualmente un'applicazione Java con Open Liberty o WebSphere Liberty in un cluster del servizio Azure Kubernetes.

Questo articolo è progettato per facilitare rapidamente la distribuzione. Prima di passare alla produzione, è consigliabile esplorare la documentazione di IBM sull'ottimizzazione di Liberty.

Se si è interessati a fornire commenti e suggerimenti o lavorare sugli scenari di migrazione in stretta collaborazione con il team di progettazione che sviluppa WebSphere nelle soluzioni di Azure, compilare questo breve sondaggio sulla migrazione di WebSphere e includere le informazioni di contatto. Il team di responsabili del programma, architetti e ingegneri si metterà immediatamente in contatto con l'utente per avviare una stretta collaborazione.

Prerequisiti

Creare una distribuzione liberty nel servizio Azure Kubernetes usando il portale

La procedura seguente illustra come creare un runtime Liberty nel servizio Azure Kubernetes. Dopo aver completato questi passaggi, si avrà un'istanza del Registro Container e un cluster del servizio Azure Kubernetes per la distribuzione dell'applicazione in contenitori.

  1. Vai al portale di Azure. Nella casella di ricerca nella parte superiore della pagina immettere IBM Liberty nel servizio Azure Kubernetes. Quando vengono visualizzati i suggerimenti, selezionare l'unica corrispondenza nella sezione Marketplace.

    Se si preferisce, è possibile passare direttamente all'offerta.

  2. Seleziona Crea.

  3. Nel riquadro delle informazioni di base:

    1. Creare un nuovo gruppo di risorse. Poiché i gruppi di risorse devono essere univoci all'interno di una sottoscrizione, scegliere un nome univoco. Un modo semplice per avere nomi univoci consiste nell'usare una combinazione di iniziali, data odierna e un identificatore, ad esempio ejb0913-java-liberty-project-rg.

    2. In Area selezionare Stati Uniti orientali.

    3. Creare una variabile di ambiente nella shell per i nomi dei gruppi di risorse per il cluster e il database:

      export RESOURCE_GROUP_NAME=<your-resource-group-name>

  4. Selezionare Avanti. Nel riquadro servizio Azure Kubernetes è possibile selezionare facoltativamente un cluster del servizio Azure Kubernetes esistente e un'istanza del Registro Azure Kubernetes, anziché causare la creazione di nuove istanze della distribuzione. Questa scelta consente di usare il modello sidecar, come illustrato nel Centro architettura di Azure. È anche possibile modificare le impostazioni per le dimensioni e il numero delle macchine virtuali nel pool di nodi del servizio Azure Kubernetes.

    Ai fini di questo articolo, è sufficiente mantenere tutte le impostazioni predefinite in questo riquadro.

  5. Selezionare Avanti. Nel riquadro bilanciamento del carico, accanto a Connetti al gateway applicazione di Azure?, selezionare Sì. In questa sezione, è possibile personalizzare le opzioni di distribuzione seguenti:

    • Per rete virtuale e Subnet, è possibile personalizzare facoltativamente la rete virtuale e la subnet in cui la distribuzione inserisce le risorse. Non è necessario modificare i valori rimanenti rispetto alle impostazioni predefinite.

    • Per il certificato TLS/SSL, è possibile fornire il certificato TLS/SSL dal gateway applicazione di Azure. Lasciare i valori predefiniti per fare in modo che l'offerta generi un certificato autofirmato.

      Non passare all'ambiente di produzione con un certificato autofirmato. Per altre informazioni sui certificati autofirmato, vedere Creare un certificato pubblico autofirmato per autenticare l'applicazione.

    • È possibile selezionare Abilita affinità basata su cookie, nota anche come sessioni permanenti. Questo articolo usa sessioni permanenti, quindi assicurarsi di selezionare questa opzione.

  6. Selezionare Avanti. Nel riquadro Operatore e applicazione questo articolo usa tutte le impostazioni predefinite. Tuttavia, è possibile personalizzare le opzioni di distribuzione seguenti:

    • È possibile distribuire WebSphere Liberty Operator selezionando Sì per l'opzione IBM supportata?. Lasciando l'impostazione predefinita No distribuisce Open Liberty Operator.
    • È possibile distribuire un'applicazione per l'operatore selezionato selezionando Sì per l'opzione Distribuisci un'applicazione?. Se si lascia il valore predefinito No, non viene distribuita alcuna applicazione.

  7. Selezionare Rivedi e crea per convalidare le opzioni selezionate. Nel riquadro Rivedi e crea, quando viene visualizzato Crea diventano disponibili dopo il passaggio della convalida, selezionarlo.

    La distribuzione può richiedere fino a 20 minuti. Durante l'attesa del completamento della distribuzione, è possibile seguire la procedura descritta nella sezione Creare un’istanza database SQL di Azure. Dopo aver completato questa sezione, tornare qui e continuare.

Acquisire le informazioni selezionate dalla distribuzione

Se ci si è spostati dal riquadro Distribuzione in corso, i passaggi seguenti mostrano come tornare a quel riquadro. Se si è ancora nel riquadro che mostra La distribuzione è stata completata, passare al gruppo di risorse appena creato e passare al terzo passaggio.

  1. Nell'angolo di qualsiasi pagina del portale selezionare il pulsante di menu e quindi selezionare Gruppi di risorse.

  2. Nella casella con il testo Filtra per qualsiasi campo, immettere i primi caratteri del gruppo di risorse creato in precedenza. Se è stata seguita la convenzione consigliata, immettere le iniziali, e quindi selezionare il gruppo di risorse appropriato.

  3. Nell'elenco delle risorse nel gruppo di risorse selezionare la risorsa con il valore Tipo di registro contenitori.

  4. Nel riquadro di spostamento, in Impostazioni selezionare Chiavi di accesso.

  5. Salvare i valori per server di accesso, nome del registro, nome utente e password. È possibile usare l'icona di copia accanto a ogni campo per copiare il valore negli Appunti di sistema.

  6. Tornare al gruppo di risorse in cui sono state distribuite le risorse.

  7. Nella sezione Impostazioni selezionare Distribuzioni.

  8. Selezionare la distribuzione più in basso nell'elenco. Il valore Nome distribuzione corrisponde all'ID editore dell'offerta. Contiene la stringa ibm.

  9. Nel riquadro di spostamento selezionare Outout.

  10. Usando la stessa tecnica di copia dei valori precedenti, salvare i valori per gli output seguenti:

    • cmdToConnectToCluster
    • appDeploymentTemplateYaml se la distribuzione non include un'applicazione. Ciò significa che è stato selezionato No per Distribuire un'applicazione? quando è stata distribuita l'offerta Marketplace.
    • appDeploymentYaml se la distribuzione include un'applicazione. Vale a dire, è stato selezionato Sì per Distribuisci un'applicazione?.

    Incollare il valore di appDeploymentTemplateYaml o appDeploymentYaml in una shell Bash, aggiungere | grep secretName ed eseguire il comando.

    L'output di questo comando è il nome del segreto TLS in ingresso, ad esempio - secretName: secret785e2c. Salvare a parte il valore secretName.

Questi valori vengono usati più avanti nell'articolo. Gli output elencano diversi altri comandi utili.

Creare un'istanza del database SQL di Azure

Per creare un database singolo del database SQL di Azure da usare con l'app, seguire la procedura descritta in Guida introduttiva: Creare un database singolo nel database SQL di Azure. Tenere presenti 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 server e Password. Questo articolo fa riferimento al valore del Gruppo di risorse del database come <db-resource-group>.

  • Nel passaggio Rete impostare Metodo di connettività suEndpoint pubblico, Consenti alle risorse e ai servizi di Azure di accedere a questo server su Sì e Aggiungi indirizzo IP client corrente su Sì.

    Screenshot del portale di Azure che mostra la scheda Rete della pagina Crea database SQL con le impostazioni Metodo di connettività e Regole del firewall evidenziate.

Nota

Il livello di elaborazione 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;.

Usare quindi il comando seguente per creare una variabile di ambiente nella shell per il nome del gruppo di risorse per il database:

export DB_RESOURCE_GROUP_NAME=<db-resource-group>

Ora che il database e il cluster del servizio Azure Kubernetes sono stati creati, è possibile procedere alla preparazione del servizio Azure Kubernetes per ospitare l'applicazione Open Liberty.

Configurare e distribuire l'applicazione di esempio

Seguire i passaggi descritti in questa sezione per distribuire l'applicazione di esempio nel runtime Liberty. Questi passaggi usano Maven.

Consultare l'applicazione

Clonare il codice di esempio per questo articolo. L'esempio è disponibile in GitHub.

Nel repository sono disponibili alcuni esempi. Questo articolo usa java-app/. Eseguire i comandi seguenti per ottenere l'esempio:

git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240220

Se viene visualizzato un messaggio sullo stato "HEAD scollegato", è possibile ignorarlo in modo sicuro. Il messaggio significa semplicemente che è stato estratto un tag.

Ecco la struttura di file dell'applicazione:

java-app
├─ src/main/
│  ├─ aks/
│  │  ├─ db-secret.yaml
│  │  ├─ openlibertyapplication-agic.yaml
│  │  ├─ openlibertyapplication.yaml
│  │  ├─ webspherelibertyapplication-agic.yaml
│  │  ├─ webspherelibertyapplication.yaml
│  ├─ docker/
│  │  ├─ Dockerfile
│  │  ├─ Dockerfile-wlp
│  ├─ liberty/config/
│  │  ├─ server.xml
│  ├─ java/
│  ├─ resources/
│  ├─ webapp/
├─ pom.xml

Le directory java, resources e webapp contengono il codice sorgente dell'applicazione di esempio. Il codice dichiara e usa un'origine dati denominata jdbc/JavaEECafeDB.

Nella directory del servizio Azure Kubernetes sono presenti cinque file di distribuzione:

  • db-secret.xml: usare questo file per creare segreti Kubernetes con le credenziali di connessione del database.
  • openlibertyapplication-agic.yaml: usare questo file per distribuire l'applicazione Open Liberty con AGIC. In questo articolo si presuppone che si usi questo file.
  • openlibertyapplication.yaml: usare questo file se si vuole distribuire l'applicazione Open Liberty senza AGIC.
  • webspherelibertyapplication-agic.yaml: usare questo file per distribuire l'applicazione WebSphere Liberty con AGIC se è stato distribuito WebSphere Liberty Operator in precedenza in questo articolo.
  • webspherelibertyapplication.yaml: usare questo file per distribuire l'applicazione WebSphere Liberty senza AGIC se è stato distribuito WebSphere Liberty Operator in precedenza in questo articolo.

Nella directory docker sono disponibili due file per creare l'immagine dell'applicazione:

  • Dockerfile: usare questo file per compilare l'immagine dell'applicazione con Open Liberty in questo articolo.
  • Dockerfile-wlp: usare questo file per compilare l'immagine dell'applicazione con WebSphere Liberty se è stato distribuito WebSphere Liberty Operator in precedenza in questo articolo.

Nella directory liberty/config si usa il file server.xml per configurare la connessione di database per il cluster Open Liberty e WebSphere Liberty.

Compilare il progetto

Ora che sono disponibili le proprietà necessarie, è possibile compilare l'applicazione. Il file POM per il progetto legge molte variabili dall'ambiente. Come parte della compilazione Maven, queste variabili vengono usate per popolare i valori nei file YAML che si trovano in src/main/aks. Se si preferisce, è possibile eseguire operazioni simili per l'applicazione all'esterno di Maven.

cd $BASE_DIR/java-app
# The following variables are used for deployment file generation into the target.
export LOGIN_SERVER=<Azure-Container-Registry-Login-Server-URL>
export REGISTRY_NAME=<Azure-Container-Registry-name>
export USER_NAME=<Azure-Container-Registry-username>
export PASSWORD='<Azure-Container-Registry-password>'
export DB_SERVER_NAME=<server-name>.database.windows.net
export DB_NAME=<database-name>
export DB_USER=<server-admin-login>@<server-name>
export DB_PASSWORD='<server-admin-password>'
export INGRESS_TLS_SECRET=<ingress-TLS-secret-name>

mvn clean install

(Facoltativo) Testare il progetto in locale

Eseguire e testare il progetto in locale prima di eseguire la distribuzione in Azure. Per praticità, questo articolo usa liberty-maven-plugin. Per altre informazioni su liberty-maven-plugin, vedere l'articolo Creazione di un'applicazione Web con Maven.

Per l'applicazione, è possibile eseguire operazioni simili usando qualsiasi altro meccanismo, ad esempio l'ambiente di sviluppo locale. È anche possibile prendere in considerazione l'uso dell'opzione liberty:devc destinata allo sviluppo con i contenitori. Per altre informazioni su liberty:devc, vedere la documentazione di Open Liberty.

  1. Avviare l'applicazione usando liberty:run. liberty:run usa anche le variabili di ambiente definite in precedenza.

    cd $BASE_DIR/java-app
mvn liberty:run

  2. Se il test ha esito positivo, nell'output del comando viene visualizzato un messaggio simile a [INFO] [AUDIT] CWWKZ0003I: The application javaee-cafe updated in 1.930 seconds. Passare a http://localhost:9080/ nel browser e verificare che l'applicazione sia accessibile e che tutte le funzioni funzionino.

  3. Selezionare CTRL+C per arrestare.

Compilare l'immagine per la distribuzione del servizio Azure Kubernetes

È ora possibile eseguire il comando docker build per compilare l'immagine:

cd $BASE_DIR/java-app/target

docker buildx build --platform linux/amd64 -t javaee-cafe:v1 --pull --file=Dockerfile .

(Facoltativo) Testare l'immagine Docker in locale

Usare la procedura seguente per testare l'immagine Docker in locale prima di eseguire la distribuzione in Azure:

  1. Eseguire l'immagine usando il comando seguente. Questo comando usa le variabili di ambiente definite in precedenza.

    docker run -it --rm -p 9080:9080 \
   -e DB_SERVER_NAME=${DB_SERVER_NAME} \
   -e DB_NAME=${DB_NAME} \
   -e DB_USER=${DB_USER} \
   -e DB_PASSWORD=${DB_PASSWORD} \
   javaee-cafe:v1

  2. Dopo l'avvio del contenitore, passare a http://localhost:9080/ nel browser per accedere all'applicazione.

  3. Selezionare CTRL+C per arrestare.

Caricare l'immagine in Registro Azure Container

Caricare l'immagine compilata nell'istanza del Registro Container creata nell'offerta:

docker tag javaee-cafe:v1 ${LOGIN_SERVER}/javaee-cafe:v1
docker login -u ${USER_NAME} -p ${PASSWORD} ${LOGIN_SERVER}
docker push ${LOGIN_SERVER}/javaee-cafe:v1

Distribuire e testare l'applicazione

Usare la procedura seguente per distribuire e testare l'applicazione:

  1. Connettersi al cluster servizio Azure Kubernetes.

    Incollare il valore di cmdToConnectToCluster in una shell ed eseguire il comando .

  2. Applicare il segreto del database:

    cd $BASE_DIR/java-app/target
kubectl apply -f db-secret.yaml

    L'output è secret/db-secret-sql created.

  3. Applicare il file di distribuzione:

    kubectl apply -f openlibertyapplication-agic.yaml

  4. Attendere il riavvio di tutti i pod usando il comando seguente:

    kubectl get pods --watch

    L'output simile all'esempio seguente indica che tutti i pod sono in esecuzione:

    NAME                                       READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-67cdc95bc-2j2gr   1/1     Running   0          29s
javaee-cafe-cluster-agic-67cdc95bc-fgtt8   1/1     Running   0          29s
javaee-cafe-cluster-agic-67cdc95bc-h47qm   1/1     Running   0          29s

  5. Verificare i risultati:

    1. Ottenere l’indirizzo della risorsa in ingresso distribuita con l'applicazione:

      kubectl get ingress

      Copia il valore di ADDRESS dall'output. Questo valore è l'indirizzo IP pubblico front-end dell'istanza del gateway applicazione distribuita.

    2. Passare a https://<ADDRESS> per testare l'applicazione. Per praticità, questo comando della shell crea una variabile di ambiente il cui valore è possibile incollare direttamente nel browser:

      export APP_URL=https://$(kubectl get ingress | grep javaee-cafe-cluster-agic-ingress | cut -d " " -f14)/
echo $APP_URL

      Se il rendering della pagina Web non viene eseguito correttamente o restituisce un errore 502 Bad Gateway, l'app viene ancora avviata in background. Attendere alcuni minuti e ripetere l'operazione.

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 per rimuovere il gruppo di risorse, il servizio contenitore, il registro contenitori, il database 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, vedere le risorse riportate di seguito:

Per altre informazioni sulla distribuzione della famiglia IBM WebSphere in Azure, vedere Quali sono le soluzioni per eseguire la famiglia di prodotti WebSphere in Azure?