Partager via

Tutoriel : Migrer Oracle WebLogic Server vers Azure Kubernetes Service (AKS) avec un scaler KEDA basé sur les métriques Prometheus

  • Article

Ce tutoriel vous montre comment migrer Oracle WebLogic Server (WLS) vers Azure Kubernetes Service (AKS) et configurer un scaling horizontal automatique basé sur les métriques Prometheus.

Dans ce tutoriel, vous accomplissez les tâches suivantes :

  • Découvrez quelles métriques d’application WebLogic vous pouvez exporter en utilisant WebLogic Monitoring Exporter.
  • Déployez et exécutez une application WebLogic sur AKS en utilisant une offre du marketplace Azure.
  • Activez le service géré Azure Monitor pour Prometheus en utilisant une offre du marketplace Azure.
  • Alimentez les métriques WLS dans un workspace Azure Monitor en utilisant une offre du marketplace Azure.
  • Intégrez Kubernetes Event-driven Autoscaling (KEDA) avec un cluster AKS en utilisant une offre du marketplace Azure.
  • Créez un scaler KEDA basé sur les métriques Prometheus.
  • Validez la configuration du scaler.

Le schéma suivant illustre l’architecture que vous construisez :

Diagramme de l’architecture de la solution de WLS sur AKS avec un scaler KEDA basé sur les métriques Prometheus.

L’offre Oracle WebLogic Server sur AKS exécute un opérateur WLS et un domaine WLS sur AKS. L’opérateur WLS gère un domaine WLS déployé en utilisant un type de source de domaine modèle dans une image. Pour en savoir plus sur l’opérateur WLS, veuillez consulter la section Opérateur Oracle WebLogic Kubernetes.

WebLogic Monitoring Exporter collecte les métriques de WebLogic Server et les envoie à Prometheus. L’exporteur utilise l’interface de gestion RESTful de WebLogic Server 12.2.1.x pour accéder à l’état d’exécution et aux métriques.

Le service géré Azure Monitor pour Prometheus collecte et enregistre les métriques de WLS à grande échelle en utilisant une solution de monitoring compatible avec Prometheus, basée sur le projet Prometheus de la Cloud Native Computing Foundation. Pour plus d'informations, consultez le service de gestion Azure Monitor pour Prometheus.

Cet article intègre KEDA à votre cluster AKS pour mettre à l’échelle le cluster WLS en fonction des métriques Prometheus du workspace Azure Monitor. KEDA surveille le service géré Azure Monitor pour Prometheus et transmet ces données à AKS et au Horizontal Pod Autoscaler (HPA) pour déclencher une mise à l’échelle rapide de la charge de travail WLS.

Les états et métriques WLS suivants sont exportés par défaut. Vous pouvez configurer l’exporteur pour exporter d’autres métriques à la demande. Pour une description détaillée de la configuration et de l’utilisation de WebLogic Monitoring Exporter, veuillez consulter la section WebLogic Monitoring Exporter.

Métriques WebLogic.

Prérequis

  • Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
  • Assurez-vous d’avoir soit le rôle Owner, soit les rôles Contributor et User Access Administrator dans l’abonnement. Vous pouvez vérifier l’affectation en suivant les étapes de la section Liste des affectations de rôles Azure en utilisant le portail Azure.
  • Préparez une machine locale avec Windows avec WSL, GNU/Linux, ou macOS installé.
  • Installez Azure CLI version 2.54.0 ou supérieure pour exécuter les commandes Azure CLI.
  • Installez et configurez kubectl.
  • Installez cURL.
  • Disposez des informations d’identification d’un compte d’authentification unique (SSO) Oracle. Pour en créer un, consultez la rubrique Créer votre compte Oracle.
  • Suivez la procédure suivante pour accepter les conditions de licence pour WLS :
    1. Accédez à Oracle Container Registry et connectez-vous.
    2. Si vous disposez d’un droit d’assistance, sélectionnez Intergiciel, puis recherchez et sélectionnez weblogic_cpu.
    3. Si vous disposez d’un droit d’utilisation support, sélectionnez Intergiciel, puis recherchez et sélectionnez weblogic_cpu.
    4. Acceptent le contrat de licence.

Préparez l’application d’exemple

Cet article utilise testwebapp du référentiel weblogic-kubernetes-operator comme application d’exemple.

Utilisez les commandes suivantes pour télécharger l’application d’exemple prédéfinie et l’extraire dans un répertoire. Comme cet article écrit plusieurs fichiers, ces commandes créent un répertoire de niveau supérieur pour tout contenir.

export BASE_DIR=$PWD/wlsaks
mkdir $BASE_DIR && cd $BASE_DIR
curl -L -o testwebapp.war https://aka.ms/wls-aks-testwebapp
unzip -d testwebapp testwebapp.war

Modifiez l’application d’exemple

Cet article utilise la métrique openSessionsCurrentCount pour augmenter et diminuer la taille du cluster WLS. Par défaut, le délai d’expiration de session sur WebLogic Server est de 60 minutes. Pour observer rapidement la capacité de diminution, procédez comme suit pour définir un délai d’expiration court :

  1. Utilisez la commande suivante pour spécifier un délai d’expiration de session de 150 secondes en utilisant wls:timeout-secs. Le format HEREDOC est utilisé pour écraser le fichier à testwebapp/WEB-INF/weblogic.xml avec le contenu souhaité.

    cat <<EOF > testwebapp/WEB-INF/weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>

<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
    <wls:weblogic-version>12.2.1</wls:weblogic-version>
    <wls:jsp-descriptor>
    <wls:keepgenerated>false</wls:keepgenerated>
    <wls:debug>false</wls:debug>
  </wls:jsp-descriptor>
  <wls:context-root>testwebapp</wls:context-root>
  <wls:session-descriptor>
    <wls:timeout-secs>150</wls:timeout-secs>
 </wls:session-descriptor>
</wls:weblogic-web-app>
EOF

  2. Utilisez la commande suivante pour recomprimer l’application d’exemple :

    cd testwebapp && zip -r ../testwebapp.war * && cd ..

Créez un compte de stockage Azure et téléchargez l’application

Utilisez les étapes suivantes pour créer un compte et un conteneur de stockage. Certaines de ces étapes vous renvoient à d’autres guides. Une fois les étapes terminées, vous pouvez télécharger un exemple d’application à déployer sur WLS.

  1. Connectez-vous au portail Azure.
  2. Créez un compte de stockage en suivant les étapes décrites dans la section Créer un compte de stockage. Utilisez les spécialisations suivantes pour les valeurs de cet article :
    • Créez un nouveau groupe de ressources pour le compte de stockage.
    • Pour Région, sélectionnez USA Est.
    • Pour Nom du compte de stockage, utilisez la même valeur que le nom du groupe de ressources.
    • Pour Performances, sélectionnez Standard.
    • Les autres onglets n’ont pas besoin de spécialisations.
  3. Passez à la validation et à la création du compte, puis revenez à cet article.
  4. Créez un conteneur de stockage dans le compte en suivant les étapes de la section Créer un conteneur de la rubrique Prise en main rapide : rapide : Charger, télécharger et répertorier des objets blob avec le Portail Azure.
  5. Dans le même article, suivez les étapes de la section Télécharger un blob de bloc pour télécharger le fichier testwebapp.war. Ensuite, revenez à cet article.

Déployez WLS sur AKS en utilisant l’offre du Marketplace Azure

Dans cette section, vous créez un cluster WLS sur AKS en utilisant l’offre Oracle WebLogic Server sur AKS. L’offre fournit un ensemble de fonctionnalités complet pour déployer facilement WebLogic Server sur AKS. Cet article se concentre sur les capacités avancées de scaling dynamique de l’offre. Pour plus d’informations sur l’offre, veuillez consulter la section Déployer une application Java avec WebLogic Server sur un cluster Azure Kubernetes Service (AKS). Pour la documentation de référence complète de l’offre, veuillez consulter la documentation Oracle.

Cette offre met en œuvre les choix suivants pour l’autoscaling horizontal :

  • Kubernetes Metrics Server. Ce choix configure toute la configuration nécessaire au moment du déploiement. Un horizontal pod autoscaler (HPA) est déployé avec un choix de métriques. Vous pouvez personnaliser davantage le HPA après le déploiement.

  • WebLogic Monitoring Exporter. Ce choix approvisionne automatiquement WebLogic Monitoring Exporter, le service géré Azure Monitor pour Prometheus, et KEDA. Après le déploiement de l’offre, les métriques WLS sont exportées et enregistrées dans le workspace Azure Monitor. KEDA est installé avec la capacité de récupérer les métriques du workspace Azure Monitor.

    Avec cette option, vous devez effectuer d’autres étapes après le déploiement pour compléter la configuration.

Cet article décrit la deuxième option. Procédez comme suit pour compléter la configuration :

  1. Ouvrez l’offre Oracle WebLogic Server sur AKS dans votre navigateur et sélectionnez Créer. Vous devriez voir le volet Informations de base de l’offre.

  2. Utilisez les étapes suivantes pour remplir le volet Informations de base :

    1. Assurez-vous que la valeur affichée pour Abonnement est la même que celle qui contient les rôles listés dans la section des prérequis.
    2. Vous devez déployer l’offre dans un groupe de ressources vide. Dans le champ Groupe de ressources, sélectionnez Créer nouveau et remplissez une valeur unique pour le groupe de ressources, par exemple wlsaks-eastus-20240109.
    3. Sous Détails de l’instance, pour Région, sélectionnez USA Est.
    4. Sous Credentials WebLogic, fournissez respectivement un mot de passe pour WebLogic Administrator et WebLogic Model encryption. Sauvegardez le nom d’utilisateur et le mot de passe pour WebLogic Administrator.
    5. À côté de Configuration de base facultative, sélectionnez Non.
    6. Sous Configuration de base facultative, paramétrez Taille maximale du cluster dynamique sur 10. Cette valeur vous permet d’observer le comportement de l’autoscaling.

    Capture d’écran du portail Azure montrant le volet Principes de l’offre Oracle WebLogic Server sur AKS.

  3. Sélectionnez Suivant et allez sur l’onglet AKS.

  4. Sous Sélection d’images, procédez comme suit :

    1. Pour Authentification par nom d’utilisateur pour l’authentification unique Oracle, renseignez votre nom d’utilisateur Oracle SSO à partir des prérequis.
    2. Pour Mot de passe pour le nom d’utilisateur pour l’authentification unique Oracle, renseignez vos identifiants Oracle SSO à partir des prérequis.

    Capture d’écran du portail Azure montrant le volet Sélection de l’image de l’offre Oracle WebLogic Server sur AKS.

  5. Sous Application, utilisez les étapes suivantes :

    1. Dans la section Application, en regard de Déployer une application ?, sélectionnez Oui.

    2. À côté de Package d’application (.war, .ear, .jar), sélectionnez Parcourir.

    3. Commencez à taper le nom du compte de stockage de la section précédente. Lorsque le compte de stockage souhaité s’affiche, sélectionnez-le.

    4. Sélectionnez le conteneur de stockage de la section précédente.

    5. Cochez la case à côté de testwebapp.war, que vous avez téléchargé dans la section précédente. Cliquez sur Sélectionner.

    6. Cliquez sur Suivant.

      Capture d’écran du portail Azure montrant le volet Sélection de l’application de l’offre Oracle WebLogic Server sur AKS.

  6. Laissez les valeurs par défaut dans le volet Configuration TLS/SSL. Sélectionnez Suivant pour passer au volet Load Balancing, puis procédez comme suit :

    1. Laissez les valeurs par défaut pour toutes les options, sauf pour Créer un ingress pour la console d’administration. Assurez-vous qu’aucune application avec le chemin /console* ne cause de conflit avec le chemin de la console d’administration. Pour cette option, sélectionnez Yes.
    2. Laissez les valeurs par défaut dans les champs restants.
    3. Cliquez sur Suivant.

    Capture d’écran du portail Azure montrant le volet Load Balancing du cluster Oracle WebLogic Server sur AKS.

  7. Laissez les valeurs par défaut dans le volet DNS puis sélectionnez Suivant pour passer au volet Base de données.

  8. Gardez les valeurs par défaut pour le volet Base de données, sélectionnez Suivant pour passer au volet Autoscaling, puis procédez comme suit :

    1. À côté de Approvisionner des ressources pour l’autoscaling horizontal ?, sélectionnez Oui.
    2. Sous Paramètres d’autoscaling horizontal, à côté de Sélectionner l’option d’autoscaling, sélectionnez WebLogic Monitor Exporter (autoscaling avancé).
    3. Sélectionnez Revoir + créer.

    Capture d’écran du portail Azure montrant le volet Autoscaling horizontal du cluster Oracle WebLogic Server sur AKS.

  9. Attendez que Exécution de la validation finale... soit terminée avec succès, puis sélectionnez Créer. Après un moment, vous devriez voir la page Déploiement où Le déploiement est en cours est affiché.

Si vous rencontrez des problèmes lors de l’exécution de la validation finale..., corrigez-les et essayez à nouveau.

Se connecter au cluster AKS

Les sections suivantes nécessitent un terminal avec kubectl installé pour gérer le cluster WLS. Pour installer kubectl en local, utilisez la commande az aks install-cli.

Procédez comme suit pour vous connecter au cluster AKS :

  1. Ouvrez le portail Azure et allez dans le groupe de ressources que vous avez approvisionné dans la section Déployer WLS sur AKS en utilisant l’offre du Marketplace Azure.
  2. Sélectionnez la ressource de type service Kubernetes dans la liste des ressources.
  3. Sélectionnez Connecter. Des instructions pour se connecter au cluster AKS apparaissent.
  4. Sélectionnez Azure CLI et suivez les étapes pour vous connecter au cluster AKS dans votre terminal local.

Récupérez les métriques du workspace Azure Monitor

Procédez comme suit pour voir les métriques dans le workspace Azure Monitor en utilisant des requêtes Prometheus Query Language (PromQL) :

  1. Dans le portail Azure, consultez le groupe de ressources que vous avez utilisé dans la section Déployer WLS sur AKS en utilisant l’offre du Marketplace Azure.

  2. Sélectionnez la ressource de type workspace Azure Monitor.

  3. Sous Prometheus managé, sélectionnez Prometheus explorer.

  4. Saisissez webapp_config_open_sessions_current_count pour interroger le compte actuel des sessions ouvertes, comme illustré dans la capture d’écran suivante :

    Capture d’écran du portail Azure montrant l’explorateur Prometheus.

Remarque

Vous pouvez utiliser la commande suivante pour accéder aux métriques en exposant le WebLogic Monitoring Exporter :

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: sample-domain1-cluster-1-exporter
  namespace: sample-domain1-ns
spec:
  ports:
  - name: default
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    weblogic.domainUID: sample-domain1
    weblogic.clusterName: cluster-1
  sessionAffinity: None
  type: LoadBalancer
EOF

kubectl get svc -n sample-domain1-ns -w

Attendez que la colonne EXTERNAL-IP dans la ligne pour sample-domain1-cluster-1-exporter passe de <pending> à une adresse IP. Ensuite, ouvrez l’URL http://<exporter-public-ip>:8080/metrics dans un navigateur et connectez-vous avec les identifiants que vous avez spécifiés lors du déploiement de l’offre. Ici, vous pouvez trouver toutes les métriques disponibles. Vous pouvez saisir l’une d’elles dans la fenêtre PromQL pour les afficher dans Azure Monitor. Par exemple, heap_free_percent montre un graphique intéressant. Pour surveiller la pression sur la mémoire à mesure que la charge est appliquée à l’application, réglez Actualisation automatique et Plage de temps sur l’intervalle le plus court possible et laissez l’onglet ouvert.

Créez le scaler KEDA

Les outils de mise à l'échelle définissent comment et quand KEDA doit mettre à l’échelle un déploiement. Cet article utilise le Prometheus scaler pour récupérer les métriques Prometheus du workspace Azure Monitor.

Cet article utilise openSessionsCurrentCount comme déclencheur. La règle pour cette métrique est décrite comme suit. Lorsque le nombre moyen de sessions ouvertes est supérieur à 10, augmentez la taille du cluster WLS jusqu’à ce qu’il atteigne la taille maximale des réplicas. Sinon, réduisez la taille du cluster WLS jusqu’à ce qu’il atteigne sa taille minimale de réplicas. Le tableau suivant répertorie les paramètres importants :

Nom du paramètre Valeur
serverAddress Le point de terminaison de la requête de votre workspace Azure Monitor.
metricName webapp_config_open_sessions_current_count
query sum(webapp_config_open_sessions_current_count{app="app1"})
threshold 10
minReplicaCount 1
maxReplicaCount La valeur par défaut est 5. Si vous avez modifié la taille maximale du cluster lors du déploiement de l’offre, remplacez par votre taille maximale de cluster.

Comme vous avez sélectionné WebLogic Monitoring Exporter au moment du déploiement, un scaler KEDA est prêt à être déployé. Les étapes suivantes vous montrent comment configurer le scaler KEDA pour l’utiliser avec votre cluster AKS :

  1. Ouvrez le portail Azure et allez dans le groupe de ressources que vous avez approvisionné dans la section Déployer WLS sur AKS en utilisant l’offre du Marketplace Azure.

  2. Dans le volet de navigation de gauche, section Paramètres, sélectionnez Déploiements. Une liste triée des déploiements effectués dans ce groupe de ressources s’affiche, avec le plus récent en premier.

  3. Faites défiler la liste jusqu’à l’entrée la plus ancienne. Cette entrée correspond au déploiement que vous avez lancé dans la section précédente. Sélectionnez le déploiement le plus ancien, dont le nom commence par quelque chose de similaire à oracle.20210620-wls-on-aks.

  4. Sélectionnez Sorties. Cette option affiche la liste des sorties du déploiement.

  5. La valeur kedaScalerServerAddress est l’adresse du serveur qui enregistre les métriques WLS. KEDA est capable d’accéder et de récupérer des métriques depuis cette adresse.

  6. La valeur shellCmdtoOutputKedaScalerSample est la chaîne base64 d’un échantillon de scaler. Copiez la valeur et exécutez-la dans votre terminal. La commande doit être similaire à l’exemple suivant :

    echo -e YXBpVm...XV0aAo= | base64 -d > scaler.yaml

    Cette commande produit un fichier scaler.yaml dans le répertoire actuel.

  7. Modifiez les lignes metric: et query: dans scaler.yaml comme indiqué dans l’exemple suivant :

    metricName: webapp_config_open_sessions_current_count
query: sum(webapp_config_open_sessions_current_count{app="app1"})

    Remarque

    Lorsque vous déployez une application avec l’offre, elle est nommée app1 par défaut. Vous pouvez utiliser les étapes suivantes pour accéder à la console d’administration WLS pour obtenir le nom de l’application :

    1. Utilisez les étapes précédentes pour consulter les sorties du déploiement.
    2. La valeur adminConsoleExternalUrl est le lien internet public complet visible vers la console d’administration WLS. Sélectionnez l’icône de copie en regard de la valeur du champ pour copier le lien dans le presse-papiers.
    3. Collez la valeur dans votre navigateur et ouvrez la console d’administration WLS.
    4. Connectez-vous avec le compte d’administration WLS, que vous avez mis de côté lors de la section Déployer WLS sur AKS en utilisant l’offre du Marketplace Azure.
    5. Sous Structure de domaine, sélectionnez Déploiements. Vous trouverez app1 listé.
    6. Sélectionnez app1 pour constater que la valeur Nom de l’application est app1. Utilisez app1 comme nom de l’application dans la requête.

  8. Si vous le souhaitez, modifiez la ligne maxReplicaCount: dans scaler.yaml comme indiqué dans l’exemple suivant. Il est incorrect de définir cette valeur plus haut que ce que vous avez spécifié lors du déploiement dans l’onglet AKS.

    maxReplicaCount: 10

  9. Utilisez la commande suivante pour créer la règle du scaler KEDA en appliquant scaler.yaml :

    kubectl apply -f scaler.yaml

    Il faut plusieurs minutes pour que KEDA récupère les métriques du workspace Azure Monitor. Vous pouvez surveiller le statut du scaler en utilisant la commande suivante :

    kubectl get hpa -n sample-domain1-ns -w

    Une fois que le scaler est prêt à fonctionner, la sortie ressemble au contenu suivant. La valeur dans la colonne TARGETS passe de <unknown> à 0.

    NAME                                       REFERENCE                          TARGETS              MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)           1         5         2          15s

Testez l’autoscaling

Vous êtes maintenant prêt à observer la capacité d’autoscaling. Cet article ouvre de nouvelles sessions en utilisant curl pour accéder à l’application. Après que le nombre moyen de sessions est supérieur à 10, l’action de scaling-up se produit. Les sessions durent 150 secondes, et le nombre de sessions ouvertes diminue à mesure que les sessions expirent. Après que le nombre moyen de sessions est inférieur à 10, l’action de scaling-down se produit. Procédez comme suit pour provoquer les actions de scaling-up et de scaling-down :

  1. Procédez comme suit pour obtenir l’URL de l’application :

    1. Utilisez les étapes précédentes pour consulter les sorties du déploiement.
    2. La valeur clusterExternalUrl est le lien, visible publiquement sur Internet, complet et qualifié, vers l’application d’exemple déployée dans WLS sur ce cluster AKS. Pour copier le lien dans votre presse-papiers, sélectionnez l’icône de copie à côté de la valeur du champ.
    3. L’URL pour accéder à testwebapp.war est ${clusterExternalUrl}testwebapp, par exemple http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/testwebapp/.

  2. Exécutez la commande curl pour accéder à l’application et provoquer de nouvelles sessions. L’exemple suivant ouvre 22 nouvelles sessions. Les sessions expirent après 150 secondes. Remplacez la valeur WLS_CLUSTER_EXTERNAL_URL par la vôtre.

    COUNTER=0
MAXCURL=22
WLS_CLUSTER_EXTERNAL_URL="http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/"
APP_URL="${WLS_CLUSTER_EXTERNAL_URL}testwebapp/"

while [ $COUNTER -lt $MAXCURL ]; do curl ${APP_URL}; let COUNTER=COUNTER+1; sleep 1;done

  3. Dans deux shells distincts, utilisez les commandes suivantes :

    • Utilisez la commande suivante pour observer le scaler :

      kubectl get hpa -n sample-domain1-ns -w

      Cette commande produit une sortie qui ressemble à l’exemple suivant :

      $ kubectl get hpa -n sample-domain1-ns -w
NAME                                       REFERENCE                          TARGETS          MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         24m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         24m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   5/10 (avg)       1         10         1         26m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   22/10 (avg)      1         10         1         27m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   7334m/10 (avg)   1         10         3         29m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   14667m/10 (avg)  1         10         3         48m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         3         30m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         3         35m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         35m
keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         5         53m

    • Dans un shell séparé, utilisez la commande suivante pour observer les pods WLS :

      kubectl get pod -n sample-domain1-ns -w

      Cette commande produit une sortie qui ressemble à l’exemple suivant :

      $ kubectl get pod -n sample-domain1-ns -w
NAME                             READY   STATUS              RESTARTS   AGE
sample-domain1-admin-server      2/2     Running             0          28h
sample-domain1-managed-server1   2/2     Running             0          28h
sample-domain1-managed-server1   2/2     Running             0          28h
sample-domain1-managed-server2   0/2     Pending             0          0s
sample-domain1-managed-server2   0/2     Pending             0          0s
sample-domain1-managed-server2   0/2     ContainerCreating   0          0s
sample-domain1-managed-server3   0/2     Pending             0          0s
sample-domain1-managed-server3   0/2     Pending             0          0s
sample-domain1-managed-server3   0/2     ContainerCreating   0          0s
sample-domain1-managed-server3   1/2     Running             0          1s
sample-domain1-admin-server      2/2     Running             0          95m
sample-domain1-managed-server1   2/2     Running             0          94m
sample-domain1-managed-server2   2/2     Running             0          56s
sample-domain1-managed-server3   2/2     Running             0          55s
sample-domain1-managed-server4   1/2     Running             0          9s
sample-domain1-managed-server5   1/2     Running             0          9s
sample-domain1-managed-server5   2/2     Running             0          37s
sample-domain1-managed-server4   2/2     Running             0          42s
sample-domain1-managed-server5   1/2     Terminating         0          6m46s
sample-domain1-managed-server5   1/2     Terminating         0          6m46s
sample-domain1-managed-server4   1/2     Running             0          6m51s
sample-domain1-managed-server4   1/2     Terminating         0          6m53s
sample-domain1-managed-server4   1/2     Terminating         0          6m53s
sample-domain1-managed-server3   1/2     Running             0          7m40s
sample-domain1-managed-server3   1/2     Terminating         0          7m45s
sample-domain1-managed-server3   1/2     Terminating         0          7m45s

Le graphique dans le workspace Azure Monitor ressemble à la capture d’écran suivante :

Capture d’écran du portail Azure montrant le graphique de l’explorateur Prometheus.

Nettoyer les ressources

Pour éviter des frais Azure, vous devez nettoyer les ressources non nécessaires. Lorsque vous n’avez plus besoin du cluster, utilisez la commande az group delete. Les commandes suivantes suppriment le groupe de ressources, le service de conteneur, le registre de conteneur, et toutes les ressources associées :

az group delete --name <wls-resource-group-name> --yes --no-wait
az group delete --name <ama-resource-group-name> --yes --no-wait

Étapes suivantes

Continuez à explorer les références suivantes pour plus d’options afin de construire des solutions d’autoscaling et exécuter WLS sur Azure :

Options de mise à l’échelle des applications dans AKS (Azure Kubernetes Service)

Quelles sont les solutions permettant d’exécuter Oracle WebLogic Server sur l’environnement Azure Kubernetes Service ?

Scaling de l’opérateur Kubernetes WebLogic

Utiliser Prometheus et Grafana pour surveiller WebLogic Server sur Kubernetes

Opérateur WebLogic Kubernetes

Quelles sont les solutions permettant d’exécuter Oracle WebLogic Server sur Machines Virtuelles Azure ?