Tutorial: Migración de Oracle WebLogic Server a Azure Kubernetes Service (AKS) con el escalador KEDA basado en métricas de Prometheus
En este tutorial se muestra cómo migrar Oracle WebLogic Server (WLS) a Azure Kubernetes Service (AKS) y a configurar el escalado horizontal automático basado en métricas de Prometheus.
En este tutorial, realizará las siguientes tareas:
- Obtener información sobre las métricas de la aplicación WebLogic que puede exportar mediante WebLogic Monitoring Exporter.
- Implementar y ejecutar una aplicación WebLogic en AKS mediante una oferta de Azure Marketplace.
- Habilitar el servicio administrado de Azure Monitor para Prometheus mediante una oferta de Azure Marketplace.
- Proporcionar métricas de WLS a un área de trabajo de Azure Monitor mediante una oferta de Azure Marketplace.
- Integrar el escalado automático controlado por eventos (KEDA) de Kubernetes con un clúster de AKS mediante una oferta de Azure Marketplace.
- Crear un escalador de KEDA basado en métricas de Prometheus.
- Validar la configuración del escalador.
En el diagrama siguiente se muestra la arquitectura que ha creado:
La oferta de Oracle WebLogic Server en AKS ejecuta un operador WLS y un dominio de WLS en AKS. El operador WLS administra un dominio de WLS implementado mediante un tipo de origen de dominio de modelo en imagen. Para obtener más información sobre el operador WLS, consulte Operador de Kubernetes de Oracle WebLogic.
WebLogic Monitoring Exporter extrae las métricas de WebLogic Server y las alimenta en Prometheus. El exportador usa la interfaz de administración RESTful de WebLogic Server 12.2.1.x para acceder al estado y las métricas del entorno de ejecución.
El servicio administrado de Azure Monitor para Prometheus recopila y guarda métricas de WLS a escala mediante una solución de supervisión compatible con Prometheus, basada en el proyecto Prometheus de Cloud Native Compute Foundation. Para más información, vea el servicio administrado de Azure Monitor para Prometheus.
En este artículo se integra KEDA con el clúster de AKS para escalar el clúster de WLS en función de las métricas de Prometheus del área de trabajo de Azure Monitor. KEDA supervisa el servicio administrado de Azure Monitor para Prometheus y alimenta los datos a AKS y al Horizontal Pod Autoscaler (HPA) para impulsar el escalado rápido de la carga de trabajo de WLS.
El siguiente estado y métricas de WLS se exportan de forma predeterminada. Puede configurar el exportador para exportar otras métricas a petición. Para obtener una descripción detallada de la configuración y el uso de WebLogic Monitoring Exporter, consulte WebLogic Monitoring Exporter.
Requisitos previos
- Suscripción a Azure. Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
- Asegúrese de que se le ha asignado el rol
Owner
o los rolesContributor
yUser Access Administrator
en la suscripción. Para comprobar la asignación, siga los pasos descritos en Enumeración de asignaciones de roles de Azure mediante Azure Portal. - Prepare una máquina local con Windows con WSL, GNU/Linux o macOS instalados.
- Instale la versión 2.54.0 o posterior de la CLI de Azure para ejecutar comandos de la CLI de Azure.
- Instale y configure kubectl.
- Instale cURL.
- Tenga las credenciales de una cuenta de inicio de sesión único (SSO) de Oracle. Para crear una, consulte Crear una cuenta de Oracle.
- Siga estos pasos para aceptar los términos de licencia de WLS:
- Visite Oracle Container Registry e inicie sesión.
- Si tiene un derecho de soporte técnico, seleccione Middleware y, a continuación, busque y seleccione weblogic_cpu.
- Si no tiene un derecho de soporte técnico para Oracle, seleccione Middleware y, a continuación, busque y seleccione weblogic.
- Acepta el acuerdo de licencia.
Preparación de la aplicación de ejemplo
En este artículo se usa testwebapp del repositorio weblogic-kubernetes-operator como una aplicación de ejemplo.
Use los comandos siguientes para descargar la aplicación de ejemplo precompilada y expandirla en un directorio. Dado que en este artículo se escriben varios archivos, estos comandos crean un directorio de nivel superior para contener todo.
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
Modificación de la aplicación de ejemplo
En este artículo se usa la métrica openSessionsCurrentCount
para escalar y reducir verticalmente el clúster de WLS. De forma predeterminada, el tiempo de espera de sesión en WebLogic Server es de 60 minutos. Para observar rápidamente la funcionalidad de reducción vertical, siga estos pasos para establecer un breve tiempo de espera:
Use el comando siguiente para especificar un tiempo de espera de sesión de 150 segundos mediante
wls:timeout-secs
. El formatoHEREDOC
se usa para sobrescribir el archivo en testwebapp/WEB-INF/weblogic.xml con el contenido deseado.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
Use el siguiente comando para volver a comprimir la aplicación:
cd testwebapp && zip -r ../testwebapp.war * && cd ..
Creación de una cuenta de Azure Storage y carga de la aplicación
Siga estos pasos para crear una cuenta de almacenamiento y un contenedor. Algunos de estos pasos le dirigen a otras guías. Después de completar los pasos, puede cargar una aplicación de ejemplo para implementarla en WLS.
- Inicie sesión en Azure Portal.
- Cree una cuenta de almacenamiento siguiendo los pasos descritos en Crear una cuenta de almacenamiento. Use las especializaciones siguientes para los valores del artículo:
- Cree un nuevo grupo de recursos para la cuenta de almacenamiento.
- En Región, seleccione Este de EE. UU. .
- En Nombre de cuenta de almacenamiento, use el mismo valor que el nombre del grupo de recursos.
- En Rendimiento, seleccione Estándar.
- Las pestañas restantes no necesitan especializaciones.
- Continúe con la validación y creación de la cuenta, y vuelva a este artículo.
- Cree un contenedor de almacenamiento dentro de la cuenta siguiendo los pasos descritos en la sección Creación de un contenedor de Inicio rápido: Carga, descarga y enumeración de blobs con Azure Portal.
- En el mismo artículo, siga los pasos descritos en la sección Carga de un blob en bloques para cargar el archivo testwebapp.war. Después, regrese a este artículo.
Implementación de WLS en AKS mediante la oferta de Azure Marketplace
En esta sección, creará un clúster de WLS en AKS mediante la oferta Oracle WebLogic Server en AKS. La oferta proporciona un conjunto de características completo para implementar fácilmente WebLogic Server en AKS. Este artículo se centra en las funcionalidades avanzadas de escalado dinámico de la oferta. Para obtener más información sobre la oferta, consulte Implementación de una aplicación Java con WebLogic Server en un clúster de Azure Kubernetes Service (AKS). Para obtener la documentación de referencia completa de la oferta, consulte la documentación de Oracle.
Esta oferta implementa las siguientes opciones para el escalado automático horizontal:
Servidor de métricas de Kubernetes. Esta opción configura todos los ajustes necesarios en el momento de la implementación. Un escalador automático de pods horizontal (HPA) se implementa con una selección de métricas. Puede personalizar aún más HPA después de la implementación.
WebLogic Monitoring Exporter. Esta opción aprovisiona automáticamente WebLogic Monitoring Exporter, el servicio administrado de Azure Monitor para Prometheus y KEDA. Una vez completada la implementación de la oferta, las métricas de WLS se exportan y guardan en el área de trabajo de Azure Monitor. KEDA se instala con la capacidad de recuperar métricas del área de trabajo de Azure Monitor.
Con esta opción, debe realizar más pasos después de la implementación para completar la configuración.
En este artículo se describe la segunda opción. Siga estos pasos para completar la configuración.
Abra la oferta Oracle WebLogic Server en AKS en el explorador y seleccione Crear. Debería ver el panel Aspectos básicos de la oferta.
Siga estos pasos para rellenar el panel Aspectos básicos:
- Asegúrese de que el valor que se muestra para Suscripción es el mismo que tiene los roles enumerados en la sección de requisitos previos.
- Debe implementar la oferta en un grupo de recursos vacío. En el campo Grupo de recursos, seleccione Crear nuevo y rellene un valor único diferente para el grupo de recursos, por ejemplo, wlsaks-eastus-20240109.
- En Detalles de la instancia, en Región, seleccione Este de EE. UU.
- En Credenciales WebLogic, indique una contraseña para el administrador de WebLogic y el cifrado del modelo de WebLogic, respectivamente. Guarde el nombre de usuario y la contraseña del administrador de WebLogic.
- Junto a Configuración básica opcional, seleccione No.
- En Configuración básica opcional, establezca Tamaño máximo de clúster dinámico en 10. Este valor le permite observar el comportamiento de escalado automático.
Seleccione Siguiente y vaya a la pestaña AKS.
En Selección de imágenes, siga estos pasos:
- En Nombre de usuario para la autenticación de inicio de sesión único de Oracle, rellene el nombre de usuario de SSO de Oracle a partir de los requisitos previos.
- En Contraseña para la autenticación de inicio de sesión único de Oracle, rellene las credenciales de SSO de Oracle a partir de los requisitos previos.
En Aplicación, siga estos pasos:
En la sección Aplicación, junto a ¿Implementar una aplicación?, seleccione Sí.
Junto a Paquete de aplicación (.war, .ear, .jar), seleccione Examinar.
Empiece a escribir el nombre de la cuenta de almacenamiento de la sección anterior. Cuando aparezca la cuenta de almacenamiento deseada, selecciónela.
Seleccione el contenedor de almacenamiento de la sección anterior.
Active la casilla situada junto a testwebapp.war, que cargó en la sección anterior. Elija Seleccionar.
Seleccione Siguiente.
Deje los valores predeterminados en el panel Configuración de TLS/SSL. Seleccione Siguiente para ir al panel Equilibrio de carga y, a continuación, siga estos pasos:
- Deje los valores predeterminados para todas las opciones, excepto Crear entrada para la consola de administración. Asegúrese de que ninguna aplicación con la ruta de acceso /console* provocará un conflicto con la ruta de acceso de la consola de administración. Para esta opción, seleccione Sí.
- En los campos restantes, deje los valores predeterminados.
- Seleccione Siguiente.
Deje los valores predeterminados en el panel DNS y seleccione Siguiente para ir al panel Base de datos.
Deje los valores predeterminados en el panel Base de datos, seleccione Siguiente para ir al panel Escalado automático y, a continuación, siga estos pasos:
- Junto a ¿Aprovisionar recursos para el escalado automático horizontal? seleccione Sí.
- En Configuración de escalado automático horizontal, junto a Seleccione una opción de escalado automático., seleccione WebLogic Monitor Exporter (escalado automático avanzado).
- Seleccione Revisar + crear.
Espere hasta que se complete correctamente el proceso Ejecutando validación final... y, a continuación, seleccione Crear. Después de un tiempo, debería ver la página Implementación donde se muestra Implementación en curso.
Si ve algún problema durante el proceso Ejecutando validación final..., corríjalo e inténtelo de nuevo.
Conexión al clúster de AKS
Las secciones siguientes requieren un terminal con kubectl
instalado para administrar el clúster de WLS. Para instalar kubectl
localmente, use el comando az aks install-cli.
Siga los pasos que se indican a continuación para conectarse al clúster de AKS:
- Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
- Seleccione el recurso de tipo Kubernetes Service en la lista de recursos.
- Seleccione Conectar. Aparece una guía para conectarse al clúster de AKS.
- Seleccione la CLI de Azure y siga los pasos para conectarse al clúster de AKS en el terminal local.
Recuperación de métricas del área de trabajo de Azure Monitor
Siga estos pasos para ver las métricas en el área de trabajo de Azure Monitor mediante consultas del lenguaje de consulta Prometheus (PromQL):
En Azure Portal, consulte el grupo de recursos que usó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
Seleccione el recurso de tipo área de trabajo de Azure Monitor.
En Prometheus administrado, seleccione Explorador de Prometheus.
Introduzca
webapp_config_open_sessions_current_count
para consultar la cuenta actual de sesiones abiertas, como se muestra en la captura de pantalla siguiente:
Nota:
Puede usar el siguiente comando para acceder a las métricas mediante la exposición de 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
Espere a que la columna EXTERNAL-IP
de la fila de sample-domain1-cluster-1-exporter
cambie de <pending>
a una dirección IP. A continuación, abra la dirección URL http://<exporter-public-ip>:8080/metrics
en un explorador e inicie sesión con las credenciales que especificó al implementar la oferta. Aquí puede encontrar todas las métricas disponibles. Puede escribir cualquiera de estos elementos en la ventana PromQL para mostrarlos en Azure Monitor. Por ejemplo, heap_free_percent
muestra un gráfico interesante. Para ver la presión de memoria a medida que se aplica la carga a la aplicación, establezca Actualización automática e Intervalo de tiempo con el intervalo más pequeño posible y deje abierta la pestaña.
Creación del escalador KEDA
Los escaladores definen cómo y cuándo KEDA debe escalar una implementación. En este artículo se usa el escalador de Prometheus para recuperar las métricas de Prometheus del área de trabajo de Azure Monitor.
En este artículo se usa openSessionsCurrentCount
como desencadenador. La regla de esta métrica se describe de la manera siguiente. Cuando el recuento medio de sesiones abiertas es superior a 10, escale verticalmente el clúster de WLS hasta que alcance el tamaño máximo de réplica. De lo contrario, reduzca verticalmente el clúster de WLS hasta que alcance su tamaño mínimo de réplica. En la tabla siguiente se enumeran los parámetros importantes:
Nombre del parámetro | Valor |
---|---|
serverAddress |
Punto de conexión de consulta del área de trabajo de Azure Monitor. |
metricName |
webapp_config_open_sessions_current_count |
query |
sum(webapp_config_open_sessions_current_count{app="app1"}) |
threshold |
10 |
minReplicaCount |
1 |
maxReplicaCount |
El valor predeterminado es 5. Si modificó el tamaño máximo del clúster durante la implementación de la oferta, reemplácelo por el tamaño máximo del clúster. |
Dado que seleccionó WebLogic Monitoring Exporter en el momento de la implementación, un escalador KEDA está listo para implementarse. En los pasos siguientes se muestra cómo configurar el escalador KEDA para su uso con el clúster de AKS:
Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
En el panel de navegación, en la sección Configuración, seleccione Implementaciones. Verá una lista ordenada de las implementaciones en este grupo de recursos, con la más reciente primero.
Desplácese hasta la entrada más antigua de esta lista. Esta entrada corresponde a la implementación que inició en la sección anterior. Seleccione la implementación más antigua, cuyo nombre comienza con algo similar a
oracle.20210620-wls-on-aks
.Seleccione Salidas. Esta opción muestra la lista de salidas de la implementación.
El valor kedaScalerServerAddress es la dirección del servidor que guarda las métricas de WLS. KEDA puede acceder a las métricas de la dirección y recuperarlas.
El valor shellCmdtoOutputKedaScalerSample es la cadena
base64
de un ejemplo de escalador. Copie el valor y ejecútelo en el terminal. El comando debería tener un aspecto similar al ejemplo siguiente:echo -e YXBpVm...XV0aAo= | base64 -d > scaler.yaml
Este comando genera un archivo scaler.yaml en el directorio actual.
Modifique las líneas
metric:
yquery:
en scaler.yaml, como se muestra en el ejemplo siguiente:metricName: webapp_config_open_sessions_current_count query: sum(webapp_config_open_sessions_current_count{app="app1"})
Nota:
Al implementar una aplicación con la oferta, se denomina
app1
de forma predeterminada. Puede seguir estos pasos para acceder a la consola de administración de WLS para obtener el nombre de la aplicación:- Siga los pasos anteriores para ver las salidas de implementación.
- El valor adminConsoleExternalUrl es el vínculo completo y visible de Internet público a la consola de administración de WLS. Seleccione el icono para copiar junto al valor de campo para copiar el vínculo en el Portapapeles.
- Pegue el valor en el explorador y abra la consola de administración de WLS.
- Inicie sesión con la cuenta de administrador de WLS, que guardó durante la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
- En Estructura de dominio, seleccione Implementaciones. Encontrará app1 en la lista.
- Seleccione app1 para buscar que el valor de Nombre de la aplicación sea
app1
. Useapp1
como nombre de aplicación en la consulta.
Si lo desea, modifique la línea
maxReplicaCount:
en scaler.yaml como se muestra en el ejemplo siguiente. Es un error establecer este valor superior al especificado en el momento de la implementación en la pestaña AKS.maxReplicaCount: 10
Use el siguiente comando para crear la regla de escalador KEDA aplicando scaler.yaml:
kubectl apply -f scaler.yaml
KEDA tarda varios minutos en recuperar las métricas del área de trabajo de Azure Monitor. Puede ver el estado del escalador mediante el siguiente comando:
kubectl get hpa -n sample-domain1-ns -w
Una vez que el escalador esté listo para funcionar, la salida será similar al siguiente contenido. El valor de la columna
TARGETS
cambia de<unknown>
a0
.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
Prueba del escalado automático
Ahora, está listo para observar la funcionalidad de escalado automático. En este artículo se abren nuevas sesiones con curl
para acceder a la aplicación. Cuando el recuento medio de sesiones sea mayor que 10, se produce la acción de escalado vertical. Las sesiones duran 150 segundos y el recuento de sesiones abiertas disminuye a medida que expiran las sesiones. Cuando el recuento medio de sesiones sea inferior a 10, se produce la acción de reducción vertical. Siga estos pasos para realizar las acciones de escalado y reducción vertical:
Siga estos pasos para obtener la URL de la aplicación:
- Siga los pasos anteriores para ver las salidas de implementación.
- El valor clusterExternalUrl es el vínculo completo y visible de Internet público a la aplicación de ejemplo implementada en WLS en este clúster de AKS. Para copiar el vínculo en el portapapeles, seleccione el icono de copia situado junto al valor del campo.
- La dirección URL para acceder a testwebapp.war es
${clusterExternalUrl}testwebapp
, por ejemplo,http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/testwebapp/
.
Ejecute el comando
curl
para acceder a la aplicación y provocar nuevas sesiones. En el ejemplo siguiente se abren 22 nuevas sesiones. Las sesiones expiran después de 150 segundos. Reemplace el valor de WLS_CLUSTER_EXTERNAL_URL por el suyo.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
En dos shells independientes, use los siguientes comandos:
Utilice el comando siguiente para observar el escalador:
kubectl get hpa -n sample-domain1-ns -w
Esto genera una salida similar a la del siguiente ejemplo:
$ 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
En un shell independiente, use el siguiente comando para observar los pods de WLS:
kubectl get pod -n sample-domain1-ns -w
Esto genera una salida similar a la del siguiente ejemplo:
$ 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
El gráfico del área de trabajo de Azure Monitor es similar a la captura de pantalla siguiente:
Limpieza de recursos
Para evitar los cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Cuando ya no necesite el clúster, use el comando az group delete. Los siguientes comandos quitan el grupo de recursos, el servicio de contenedor, el registro de contenedor y todos los recursos relacionados:
az group delete --name <wls-resource-group-name> --yes --no-wait
az group delete --name <ama-resource-group-name> --yes --no-wait
Pasos siguientes
Continúe explorando las siguientes referencias para conocer más opciones para compilar soluciones de escalado automático y ejecutar WLS en Azure: