Condividi tramite


Esercitazione: Distribuire un'app WordPress nel servizio Azure Kubernetes con Database di Azure per MySQL - Server flessibile

In questa esercitazione si distribuisce un'applicazione WordPress scalabile protetta tramite HTTPS in un cluster servizio Azure Kubernetes (AKS) con Database di Azure per MySQL server flessibile usando l'interfaccia della riga di comando di Azure. Il servizio Azure Kubernetes è un servizio Kubernetes gestito che consente di distribuire e gestire rapidamente i cluster. Che cos'è Database di Azure per MySQL - Server flessibile? è un servizio di database completamente gestito progettato per offrire un controllo e una flessibilità più granulari rispetto alle funzioni di gestione del database e alle impostazioni di configurazione.

Nota

Questa esercitazione presuppone una comprensione di base dei concetti relativi a Kubernetes, WordPress e MySQL.

Se non si ha una sottoscrizione di Azure, creare un account Azure gratuito prima di iniziare. Attualmente, con un account gratuito di Azure, è possibile provare il server flessibile di Database MySQL di Azure gratuitamente per 12 mesi. Per altre informazioni, vedere Usare un account gratuito di Azure per provare gratuitamente Database di Azure per MySQL - Server flessibile.

Prerequisiti

Prima di iniziare, assicurarsi di aver eseguito l'accesso all'interfaccia della riga di comando di Azure e di aver selezionato una sottoscrizione da usare con l'interfaccia della riga di comando. Assicurarsi di aver installato Helm.

Nota

Se si eseguono i comandi in questa esercitazione in locale (anziché con Azure Cloud Shell), eseguire i comandi come amministratore.

Definire le variabili di ambiente

Il primo passaggio di questa esercitazione consiste nel definire le variabili di ambiente.

export SSL_EMAIL_ADDRESS="$(az account show --query user.name --output tsv)"
export NETWORK_PREFIX="$(($RANDOM % 253 + 1))"
export RANDOM_ID="$(openssl rand -hex 3)"
export MY_RESOURCE_GROUP_NAME="myWordPressAKSResourceGroup$RANDOM_ID"
export REGION="westeurope"
export MY_AKS_CLUSTER_NAME="myAKSCluster$RANDOM_ID"
export MY_PUBLIC_IP_NAME="myPublicIP$RANDOM_ID"
export MY_DNS_LABEL="mydnslabel$RANDOM_ID"
export MY_VNET_NAME="myVNet$RANDOM_ID"
export MY_VNET_PREFIX="10.$NETWORK_PREFIX.0.0/16"
export MY_SN_NAME="mySN$RANDOM_ID"
export MY_SN_PREFIX="10.$NETWORK_PREFIX.0.0/22"
export MY_MYSQL_DB_NAME="mydb$RANDOM_ID"
export MY_MYSQL_ADMIN_USERNAME="dbadmin$RANDOM_ID"
export MY_MYSQL_ADMIN_PW="$(openssl rand -base64 32)"
export MY_MYSQL_SN_NAME="myMySQLSN$RANDOM_ID"
export MY_MYSQL_HOSTNAME="$MY_MYSQL_DB_NAME.mysql.database.azure.com"
export MY_WP_ADMIN_PW="$(openssl rand -base64 32)"
export MY_WP_ADMIN_USER="wpcliadmin"
export FQDN="${MY_DNS_LABEL}.${REGION}.cloudapp.azure.com"

Creare un gruppo di risorse

Un gruppo di risorse di Azure è un gruppo logico in cui le risorse di Azure vengono distribuite e gestite. Tutte le risorse devono essere posizionate in un gruppo di risorse. Il comando seguente crea un gruppo di risorse con i parametri $MY_RESOURCE_GROUP_NAME e $REGION definiti in precedenza.

az group create \
    --name $MY_RESOURCE_GROUP_NAME \
    --location $REGION

Risultati:

{
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myWordPressAKSResourceGroupXXX",
  "location": "eastus",
  "managedBy": null,
  "name": "testResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

Nota

La località del gruppo di risorse è quella in cui vengono archiviati i relativi metadati. È anche quella in cui viene eseguita la risorsa in Azure se non si specifica un'area diversa durante la creazione.

Creare una rete virtuale e una subnet

Una rete virtuale rappresenta il blocco costitutivo fondamentale per le reti private di Azure. Il servizio Rete virtuale di Microsoft Azure consente alle risorse di Azure, come le VM, di comunicare in modo sicuro tra loro e con Internet.

az network vnet create \
    --resource-group $MY_RESOURCE_GROUP_NAME \
    --location $REGION \
    --name $MY_VNET_NAME \
    --address-prefix $MY_VNET_PREFIX \
    --subnet-name $MY_SN_NAME \
    --subnet-prefixes $MY_SN_PREFIX

Risultati:

{
  "newVNet": {
    "addressSpace": {
      "addressPrefixes": [
        "10.210.0.0/16"
      ]
    },
    "enableDdosProtection": false,
    "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/myWordPressAKSResourceGroupXXX/providers/Microsoft.Network/virtualNetworks/myVNetXXX",
    "location": "eastus",
    "name": "myVNet210",
    "provisioningState": "Succeeded",
    "resourceGroup": "myWordPressAKSResourceGroupXXX",
    "subnets": [
      {
        "addressPrefix": "10.210.0.0/22",
        "delegations": [],
        "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/myWordPressAKSResourceGroupXXX/providers/Microsoft.Network/virtualNetworks/myVNetXXX/subnets/mySNXXX",
        "name": "mySN210",
        "privateEndpointNetworkPolicies": "Disabled",
        "privateLinkServiceNetworkPolicies": "Enabled",
        "provisioningState": "Succeeded",
        "resourceGroup": "myWordPressAKSResourceGroupXXX",
        "type": "Microsoft.Network/virtualNetworks/subnets"
      }
    ],
    "type": "Microsoft.Network/virtualNetworks",
    "virtualNetworkPeerings": []
  }
}

Creare un'istanza del server flessibile di Database di Azure per MySQL

Il server flessibile di Database di Azure per MySQL è un servizio gestito che consente di eseguire, gestire e dimensionare server MySQL a disponibilità elevata nel cloud. Creare un'istanza del server flessibile Database di Azure per MySQL con il comando az mysql flexible-server create. Un server può contenere più database. Il comando seguente crea un server usando le impostazioni predefinite del servizio e i valori variabili del contesto locale dell'interfaccia della riga di comando di Azure:

az mysql flexible-server create \
    --admin-password $MY_MYSQL_ADMIN_PW \
    --admin-user $MY_MYSQL_ADMIN_USERNAME \
    --auto-scale-iops Disabled \
    --high-availability Disabled \
    --iops 500 \
    --location $REGION \
    --name $MY_MYSQL_DB_NAME \
    --database-name wordpress \
    --resource-group $MY_RESOURCE_GROUP_NAME \
    --sku-name Standard_B2s \
    --storage-auto-grow Disabled \
    --storage-size 20 \
    --subnet $MY_MYSQL_SN_NAME \
    --private-dns-zone $MY_DNS_LABEL.private.mysql.database.azure.com \
    --tier Burstable \
    --version 8.0.21 \
    --vnet $MY_VNET_NAME \
    --yes -o JSON

Risultati:

{
  "databaseName": "wordpress",
  "host": "mydbxxx.mysql.database.azure.com",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myWordPressAKSResourceGroupXXX/providers/Microsoft.DBforMySQL/flexibleServers/mydbXXX",
  "location": "East US",
  "resourceGroup": "myWordPressAKSResourceGroupXXX",
  "skuname": "Standard_B2s",
  "subnetId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myWordPressAKSResourceGroupXXX/providers/Microsoft.Network/virtualNetworks/myVNetXXX/subnets/myMySQLSNXXX",
  "username": "dbadminxxx",
  "version": "8.0.21"
}

Il server creato ha gli attributi seguenti:

  • La prima volta che si effettua il provisioning del server, viene creato un nuovo database vuoto.
  • Il nome del server, il nome utente amministratore, la password amministratore, il nome del gruppo di risorse e la posizione sono già specificati nell'ambiente di contesto locale di Cloud Shell e si trovano nella stessa posizione del gruppo di risorse e di altri componenti di Azure.
  • Le impostazioni predefinite del servizio per le configurazioni server rimanenti sono: livello di calcolo (con possibilità di burst), dimensioni/SKU di calcolo (Standard_B2s), periodo di conservazione dei backup (sette giorni) e versione di MySQL (8.0.21).
  • Il metodo di connettività predefinito è l'accesso privato (integrazione rete virtuale) con una rete virtuale collegata e una subnet generata automaticamente.

Nota

Il metodo di connettività non può essere modificato dopo la creazione del server. Ad esempio, se è stato selezionato Private access (VNet Integration) durante la creazione, non è possibile passare a Public access (allowed IP addresses) dopo la creazione. È consigliabile creare un server con accesso privato per accedere in modo sicuro al server tramite l'integrazione rete virtuale. Altre informazioni sull'accesso privato sono disponibili nell'articolo sui concetti.

Per modificare le impostazioni predefinite, vedere la documentazione di riferimento dell'interfaccia della riga di comando di Azure per l'elenco completo dei parametri dell'interfaccia della riga di comando configurabili.

Controllare lo stato del Database di Azure per MySQL - Server flessibile

Sono necessari alcuni minuti per creare il server flessibile di Database di Azure per MySQL e le risorse di supporto.

runtime="10 minute"; endtime=$(date -ud "$runtime" +%s); while [[ $(date -u +%s) -le $endtime ]]; do STATUS=$(az mysql flexible-server show -g $MY_RESOURCE_GROUP_NAME -n $MY_MYSQL_DB_NAME --query state -o tsv); echo $STATUS; if [ "$STATUS" = 'Ready' ]; then break; else sleep 10; fi; done

Configurare i parametri del server nel server flessibile di Database di Azure per MySQL

È possibile gestire la configurazione del server flessibile di Database di Azure per MySQL mediante i parametri del server. I parametri del server vengono configurati con il valore predefinito e consigliato in fase di creazione del server.

Per visualizzare i dettagli di un determinato parametro per un server, eseguire il comando az mysql flexible-server parameter show.

Disabilitare il parametro di connessione SSL del server flessibile per Database di Azure per MySQL per l'integrazione di WordPress

È anche possibile modificare il valore di determinati parametri del server per aggiornare i valori di configurazione sottostanti del motore del server MySQL. Per aggiornare il parametro del server, usare il comando az mysql flexible-server parameter set.

az mysql flexible-server parameter set \
    -g $MY_RESOURCE_GROUP_NAME \
    -s $MY_MYSQL_DB_NAME \
    -n require_secure_transport -v "OFF" -o JSON

Risultati:

{
  "allowedValues": "ON,OFF",
  "currentValue": "OFF",
  "dataType": "Enumeration",
  "defaultValue": "ON",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myWordPressAKSResourceGroupXXX/providers/Microsoft.DBforMySQL/flexibleServers/mydbXXX/configurations/require_secure_transport",
  "isConfigPendingRestart": "False",
  "isDynamicConfig": "True",
  "isReadOnly": "False",
  "name": "require_secure_transport",
  "resourceGroup": "myWordPressAKSResourceGroupXXX",
  "source": "user-override",
  "systemData": null,
  "type": "Microsoft.DBforMySQL/flexibleServers/configurations",
  "value": "OFF"
}

Creare un cluster del servizio Azure Container

Per creare un cluster del servizio Azure Kubernetes con Container Insights, usare il comando az aks create con il parametro di monitoraggio -enable-addons . L'esempio seguente crea un cluster abilitato per la zona di disponibilità, denominato myAKSCluster:

Questa azione richiede alcuni minuti.

export MY_SN_ID=$(az network vnet subnet list --resource-group $MY_RESOURCE_GROUP_NAME --vnet-name $MY_VNET_NAME --query "[0].id" --output tsv)

az aks create \
    --resource-group $MY_RESOURCE_GROUP_NAME \
    --name $MY_AKS_CLUSTER_NAME \
    --auto-upgrade-channel stable \
    --enable-cluster-autoscaler \
    --enable-addons monitoring \
    --location $REGION \
    --node-count 1 \
    --min-count 1 \
    --max-count 3 \
    --network-plugin azure \
    --network-policy azure \
    --vnet-subnet-id $MY_SN_ID \
    --no-ssh-key \
    --node-vm-size Standard_DS2_v2 \
    --service-cidr 10.255.0.0/24 \
    --dns-service-ip 10.255.0.10 \
    --zones 1 2 3

Nota

Quando si crea un cluster del servizio Azure Kubernetes, viene creato automaticamente un secondo gruppo di risorse per archiviare le risorse del servizio Azure Kubernetes. Vedere Perché vengono creati due gruppi di risorse con il servizio Azure Kubernetes?

Stabilire la connessione al cluster

Per gestire un cluster Kubernetes, usare kubectl, il client da riga di comando di Kubernetes. Se si usa Azure Cloud Shell, kubectl è già installato. È anche possibile installare kubectl in locale usando il comando az aks install-cli.

    if ! [ -x "$(command -v kubectl)" ]; then az aks install-cli; fi

Quindi, configurare kubectl per connettersi al cluster Kubernetes usando il comando az aks get-credentials. Questo comando scarica le credenziali e configura l'interfaccia della riga di comando di Kubernetes per usarli. Il comando usa ~/.kube/config, la posizione predefinita per il file di configurazione Kubernetes. È possibile specificare un percorso diverso per il file di configurazione di Kubernetes usando l'argomento -file .

Avviso

Questo comando sovrascriverà le credenziali esistenti con la stessa voce.

az aks get-credentials --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_AKS_CLUSTER_NAME --overwrite-existing

Per verificare la connessione al cluster, usare il comando kubectl get per restituire un elenco di nodi del cluster.

kubectl get nodes

Installare il controller in ingresso NGINX

È possibile configurare il controller in ingresso con un indirizzo IP pubblico statico. L'indirizzo IP pubblico statico viene mantenuto dopo l’eliminazione del controller in ingresso. L'indirizzo IP non viene mantenuto se si elimina il cluster del servizio Azure Kubernetes. Quando si aggiorna il controller in ingresso, è necessario passare un parametro alla versione Helm per assicurarsi che il servizio del controller in ingresso sia informato del servizio di bilanciamento del carico che verrà allocato. Per un uso corretto dei certificati HTTPS, usare un'etichetta DNS per configurare un nome di dominio completo (FQDN) per l'indirizzo IP del controller in ingresso. Il nome di dominio completo deve seguire questo formato: $MY_DNS_LABEL.AZURE_REGION_NAME.cloudapp.azure.com.

export MY_STATIC_IP=$(az network public-ip create --resource-group MC_${MY_RESOURCE_GROUP_NAME}_${MY_AKS_CLUSTER_NAME}_${REGION} --location ${REGION} --name ${MY_PUBLIC_IP_NAME} --dns-name ${MY_DNS_LABEL} --sku Standard --allocation-method static --version IPv4 --zone 1 2 3 --query publicIp.ipAddress -o tsv)

Aggiungere quindi il repository Helm ingress-nginx, aggiornare la cache locale del repository dei grafici Helm e installare il componente aggiuntivo ingress-nginx tramite Helm. È possibile impostare l'etichetta DNS con - set controller.service.annotations". service.beta.kubernetes.io/azure-dns-label-name"="<DNS_LABEL>" parametro quando si distribuisce per la prima volta il controller di ingresso o versione successiva. In questo esempio si specifica il proprio indirizzo IP pubblico creato nel passaggio precedente con il parametro -set controller.service.loadBalancerIP="<STATIC_IP>".

    helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
    helm repo update
    helm upgrade --install --cleanup-on-fail --atomic ingress-nginx ingress-nginx/ingress-nginx \
        --namespace ingress-nginx \
        --create-namespace \
        --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=$MY_DNS_LABEL \
        --set controller.service.loadBalancerIP=$MY_STATIC_IP \
        --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
        --wait --timeout 10m0s

Aggiungere la terminazione HTTPS al dominio personalizzato

A questo punto dell'esercitazione è disponibile un'app Web del servizio Azure Kubernetes con NGINX come controller in ingresso e un dominio personalizzato che è possibile usare per accedere all'applicazione. Il passaggio successivo consiste nell'aggiungere un certificato SSL al dominio in modo che gli utenti possano raggiungere l'applicazione in modo sicuro tramite https.

Installare Gestore certificati

Per aggiungere HTTPS, usare Cert Manager. Cert Manager è uno strumento open source per ottenere e gestire i certificati SSL per le distribuzioni Kubernetes. Cert Manager ottiene i certificati dalle autorità emittenti pubbliche e private più diffuse, garantisce che i certificati siano validi e aggiornati e tenta di rinnovare i certificati in un momento configurato prima della scadenza.

  1. Per installare cert-manager, è prima necessario creare uno spazio dei nomi in cui eseguirlo. Questa esercitazione installa cert-manager nello spazio dei nomi cert-manager. È possibile eseguire cert-manager in uno spazio dei nomi diverso, ma è necessario apportare modifiche ai manifesti della distribuzione.

    kubectl create namespace cert-manager
    
  2. Ora è possibile installare cert-manager. Tutte le risorse sono incluse in un singolo file manifesto YAML. Installare il file manifesto con il comando seguente:

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.0/cert-manager.crds.yaml
    
  3. Aggiungere l'etichetta certmanager.k8s.io/disable-validation: "true" allo spazio dei nomi cert-manager eseguendo quanto segue. In questo modo le risorse di sistema che cert-manager richiede per avviare la creazione TLS nel proprio spazio dei nomi.

    kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
    

Ottenere un certificato tramite grafici Helm

Helm è uno strumento di distribuzione Kubernetes per automatizzare la creazione, la creazione di pacchetti, la configurazione e la distribuzione di applicazioni e servizi nei cluster Kubernetes.

Cert-manager fornisce grafici Helm come metodo di installazione di prima classe in Kubernetes.

  1. Aggiungere il repository Helm di Jetstack. Questo repository è l'unica origine supportata dei grafici cert-manager. Ci sono altri mirror e copie su Internet, ma non sono ufficiali e potrebbero presentare un rischio per la sicurezza.

    helm repo add jetstack https://charts.jetstack.io
    
  2. Aggiornare la cache del repository locale di grafici Helm.

    helm repo update
    
  3. Installare il componente aggiuntivo Cert-Manager tramite Helm.

    helm upgrade --install --cleanup-on-fail --atomic \
        --namespace cert-manager \
        --version v1.7.0 \
        --wait --timeout 10m0s \
        cert-manager jetstack/cert-manager
    
  4. Applicare il file YAML dell'autorità di certificazione. Per ClusterIssuers si intendono le risorse Kubernetes che rappresentano le autorità di certificazione (CA) che possono generare certificati firmati rispettando le richieste di firma dei certificati. Tutti i certificati cert-manager richiedono un'autorità di certificazione di riferimento pronte per tentare di rispettare la richiesta. È possibile trovare l'autorità di certificazione individuare cluster-issuer-prod.yml file.

    cluster_issuer_variables=$(<cluster-issuer-prod.yaml)
    echo "${cluster_issuer_variables//\$SSL_EMAIL_ADDRESS/$SSL_EMAIL_ADDRESS}" | kubectl apply -f -
    

Creare una classe di archiviazione personalizzata

Le classi di archiviazione predefinite soddisfano gli scenari più comuni, ma non tutti. Per alcuni casi, potrebbe essere necessario personalizzare la propria classe di archiviazione con i propri parametri. Ad esempio, usare il manifesto seguente per configurare mountOptions della condivisione file. Il valore predefinito per fileMode e dirMode è 0755 per le condivisioni file montate in Kubernetes. È possibile specificare le diverse opzioni di montaggio nell'oggetto classe di archiviazione.

kubectl apply -f wp-azurefiles-sc.yaml

Distribuire WordPress nel cluster del servizio Azure Kubernetes

Per questa esercitazione viene usato un grafico Helm esistente per WordPress compilato da Bitnami. Il grafico Helm di Bitnami usa un database MariaDB locale, quindi è necessario eseguire l'override di questi valori per usare l'app con Database di Azure per MySQL. È possibile eseguire l'override dei valori e delle impostazioni personalizzate del file helm-wp-aks-values.yaml.

  1. Aggiungere il repository Helm di Wordpress Bitnami.

    helm repo add bitnami https://charts.bitnami.com/bitnami
    
  2. Aggiornare la cache del repository locale di grafici Helm.

    helm repo update
    
  3. Installare il carico di lavoro Wordpress tramite Helm.

    helm upgrade --install --cleanup-on-fail \
        --wait --timeout 10m0s \
        --namespace wordpress \
        --create-namespace \
        --set wordpressUsername="$MY_WP_ADMIN_USER" \
        --set wordpressPassword="$MY_WP_ADMIN_PW" \
        --set wordpressEmail="$SSL_EMAIL_ADDRESS" \
        --set externalDatabase.host="$MY_MYSQL_HOSTNAME" \
        --set externalDatabase.user="$MY_MYSQL_ADMIN_USERNAME" \
        --set externalDatabase.password="$MY_MYSQL_ADMIN_PW" \
        --set ingress.hostname="$FQDN" \
        --values helm-wp-aks-values.yaml \
        wordpress bitnami/wordpress
    

Risultati:

Release "wordpress" does not exist. Installing it now.
NAME: wordpress
LAST DEPLOYED: Tue Oct 24 16:19:35 2023
NAMESPACE: wordpress
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: wordpress
CHART VERSION: 18.0.8
APP VERSION: 6.3.2

** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    wordpress.wordpress.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL and associate WordPress hostname to your cluster external IP:

   export CLUSTER_IP=$(minikube ip) # On Minikube. Use: `kubectl cluster-info` on others K8s clusters
   echo "WordPress URL: https://mydnslabelxxx.eastus.cloudapp.azure.com/"
   echo "$CLUSTER_IP  mydnslabelxxx.eastus.cloudapp.azure.com" | sudo tee -a /etc/hosts
    export CLUSTER_IP=$(minikube ip) # On Minikube. Use: `kubectl cluster-info` on others K8s clusters
    echo "WordPress URL: https://mydnslabelxxx.eastus.cloudapp.azure.com/"
    echo "$CLUSTER_IP  mydnslabelxxx.eastus.cloudapp.azure.com" | sudo tee -a /etc/hosts

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

    echo Username: wpcliadmin
    echo Password: $(kubectl get secret --namespace wordpress wordpress -o jsonpath="{.data.wordpress-password}" | base64 -d)

Esplorare la distribuzione del servizio Azure Kubernetes protetta tramite HTTPS

Eseguire il comando seguente per ottenere l'endpoint HTTPS per l'applicazione:

Nota

La propagazione del certificato SSL richiede spesso 2-3 minuti e circa 5 minuti affinché tutte le repliche POD WordPress siano pronte e il sito sia completamente raggiungibile tramite https.

runtime="5 minute"
endtime=$(date -ud "$runtime" +%s)
while [[ $(date -u +%s) -le $endtime ]]; do
    export DEPLOYMENT_REPLICAS=$(kubectl -n wordpress get deployment wordpress -o=jsonpath='{.status.availableReplicas}');
    echo Current number of replicas "$DEPLOYMENT_REPLICAS/3";
    if [ "$DEPLOYMENT_REPLICAS" = "3" ]; then
        break;
    else
        sleep 10;
    fi;
done

Verificare che il contenuto WordPress venga recapitato correttamente usando il comando seguente:

if curl -I -s -f https://$FQDN > /dev/null ; then
    curl -L -s -f https://$FQDN 2> /dev/null | head -n 9
else
    exit 1
fi;

Risultati:

{
<!DOCTYPE html>
<html lang="en-US">
<head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name='robots' content='max-image-preview:large' />
<title>WordPress on AKS</title>
<link rel="alternate" type="application/rss+xml" title="WordPress on AKS &raquo; Feed" href="https://mydnslabelxxx.eastus.cloudapp.azure.com/feed/" />
<link rel="alternate" type="application/rss+xml" title="WordPress on AKS &raquo; Comments Feed" href="https://mydnslabelxxx.eastus.cloudapp.azure.com/comments/feed/" />
}

Visitare il sito Web tramite l'URL seguente:

echo "You can now visit your web server at https://$FQDN"

Pulire le risorse (facoltativo)

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 e tutte le risorse correlate.

Nota

Quando si elimina il cluster, l'entità servizio Microsoft Entra usata dal cluster del servizio Azure Kubernetes non viene rimossa. Per istruzioni su come rimuovere l'entità servizio, vedere le considerazioni sull'entità servizio servizio Azure Kubernetes e la sua eliminazione. Se è stata usata un'identità gestita, l'identità viene gestita dalla piattaforma e non richiede la rimozione.