Condividi tramite


Pianificare le risorse prima della distribuzione

La gestione temporanea è un passaggio di pre-distribuzione che consente di convalidare e scaricare le risorse prima che vengano distribuite nel cluster perimetrale. Questo processo garantisce che tutte le configurazioni, le immagini e le dipendenze siano configurate correttamente, garantendo distribuzioni affidabili all'interno di finestre di manutenzione limitate.

Alcuni scenari comuni in cui la gestione temporanea è utile sono:

  • Gli utenti con fabbriche situate in aree remote in cui la latenza di rete può aumentare il rischio di fallimenti di distribuzione.
  • Gli utenti gestiscono distribuzioni su larga scala e il download di immagini di container di grandi dimensioni dall'Azure Container Registry durante finestre di manutenzione limitate può risultare difficile.

Prerequisiti

Configurare il Azure Container Registry

Per preparare le risorse, è necessario configurare un Registro Azure Container per archiviare le immagini del contenitore e altri artefatti necessari per le distribuzioni.

  1. Creare un ACR nel portale di Azure con SKU Premium.

    acrName="<acr_name>"
    rg="<resource_group>"
    
    az acr create --resource-group "$rg" --name "$acrName" --sku Premium
    az acr update --name "$acrName" --data-endpoint-enabled
    
  2. Inserire qualsiasi repository nell'Azure Container Registry. Il registro connesso richiede che almeno un repository sia presente nel Registry Azure Container.

    # Login to the ACR for pulling operations
    az acr login --name "$acrName"
    docker pull hello-world
    docker tag hello-world:latest "$acrName.azurecr.io/hello-world:latest"
    docker push "$acrName.azurecr.io/hello-world:latest"
    
  3. Creare un registro connesso per il Registro dei Container di Azure.

    connectedRegistryName="<any connected registry name>"
    # leave "staging-temp" as default value, connected registry doesn't need this repo to be existing but it needs at least one repo.
    az acr connected-registry create --registry "$acrName" --name "$connectedRegistryName" --repository "staging-temp" --mode ReadOnly --log-level Debug --yes
    az acr connected-registry list --registry "$acrName" --output table # shows offline
    
  4. Controllare l'intervallo IP disponibile nel cluster da usare per il servizio registro connesso.

    resourceGroup="<resource_group>"
    arcCluster="<arc_cluster>"
    
    az aks show --resource-group "$resourceGroup" --name "$arcCluster" --query "networkProfile.serviceCidr"
    # check IPs which are in use
    kubectl get services -A
    
    # Pick an IP which is within the available IP range and is not in use to host the connected registry service
    available_ip="<valid_IP>"
    
  5. Configurare una stringa di connessione per il Registro di sistema connesso e archiviarla in un file JSON. Questa stringa di connessione viene usata per autenticare il Registro di sistema connesso locale nel cloud.

    subId="<subscription_id>"
    
    connectionString=$(az acr connected-registry get-settings \
      --name "$connectedRegistryName" \
      --registry "$acrName" \
      --parent-protocol https \
      --generate-password 1 \
      --query ACR_REGISTRY_CONNECTION_STRING \
      --subscription "$subId" \
      --output tsv \
      --yes)
    # Remove carriage return characters (Linux/Mac)
    connectionString=$(echo "$connectionString" | tr -d '\r')
    # Create valid JSON and write it to the file
    echo "{\"connectionString\": \"$connectionString\"}" > protected-settings-extension.json
    
  6. Aprire protected-settings-extension.json file nell'editor. Se il file è codificato con "UTF-8 con BOM", modificarlo in "UTF-8" e salvare il file.

  7. Installare l'estensione CLI del registro connesso sul cluster ARC per abilitare la gestione temporanea.

    resourceGroup="<resource_group>"
    arcCluster="<arc_cluster>"
    
    az k8s-extension create --cluster-name "$arcCluster" --cluster-type connectedClusters --extension-type Microsoft.ContainerRegistry.ConnectedRegistry --name "$connectedRegistryName" --resource-group "$resourceGroup" --config service.clusterIP="$available_ip" --config pvc.storageRequest=20Gi --config cert-manager.install=false --config-protected-file protected-settings-extension.json
    # if you want to use a storage class other than the default one, add below flag: #--config pvc.storageClassName=<storage class name>
    
    # confirm installation successful: (you should see 3 pods running, one for connected-registry and others for containerd on each node)
    kubectl get pods -n connected-registry
    
    # check connected-registry state on ACR:
    az acr connected-registry list --registry "$acrName" --output table # shows online
    

    Annotazioni

    Se si usano cluster Tanzu Kubernetes Grid (TKG), è necessario seguire i passaggi aggiuntivi per installare l'estensione dell'interfaccia della riga di comando del Registro di sistema connessa. Vedere la sezione Installare il registro connesso per i cluster Kubernetes Tanzu.

  8. (Facoltativo) È possibile verificare lo stato di installazione del Registro di sistema connesso nel portale di Azure. Passare alla risorsa Registro Azure Container , selezionare Registri connessi e controllare lo stato del registro connesso. Dovrebbe essere visualizzato come Online.

  9. Creare un nuovo token client o aggiungerne uno esistente al Registro di sistema connesso.

    az acr scope-map create --name "all-repos-read" --registry "$acrName" --repository "staging-temp" content/read metadata/read --description "Scope map for pulling from ACR"
    
    az acr token create --name "all-repos-pull-token" --registry "$acrName" --scope-map "all-repos-read"
    
    az acr connected-registry update --name "$connectedRegistryName" --registry "$acrName" --add-client-token "all-repos-pull-token"
    
  10. Salvare il token del client in un secret di k8s per usarlo in un secondo momento nel file secret.yaml. È possibile scegliere una delle due password generate dal comando precedente.

    apiVersion: v1
    data:
        password: <base64-encoded-password>
        username: <base64-encoded-username>
    kind: Secret
    metadata:
        name: my-acr-secret
        namespace: default
    type: Opaque
    

    È possibile codificare la password in formato Base64 usando il comando seguente:

    echo -n "<tokenname/value>" | base64
    
  11. Salva il segreto nel cluster.

    kubectl apply -f secret.yaml
    

Installare il registro collegato per i cluster Kubernetes Tanzu (solo per i cluster TKG)

Se si usano cluster TKG (Tanzu Kubernetes Grid), è necessario seguire questi passaggi aggiuntivi per installare l'estensione dell'interfaccia della riga di comando del Registro di sistema connessa. Dopo aver installato il Registro di sistema connesso, è possibile procedere con la procedura descritta nella sezione Configurare Registro Azure Container.

  1. Aggiungere l'etichetta dei privilegi allo spazio dei nomi del Registro di sistema connesso.

    kubectl label --overwrite ns connected-registry pod-security.kubernetes.io/enforce=privileged
    
  2. Installare l'estensione CLI del registro connesso con trustDistribution disabilitata. È necessario specificare un indirizzo IP all'interno dell'intervallo IP valido in Tanzu.

    az k8s-extension create --cluster-name "$cluster" --cluster-type connectedClusters --extension-type Microsoft.ContainerRegistry.ConnectedRegistry --name connectedext --resource-group "$rg" --config trustDistribution.enabled=false --config service.clusterIP=<serviceIP> --config pvc.storageClassName=<storage_class_name> --config pvc.storageRequest=20Gi --config cert-manager.install=false --config-protected-file protected-settings-extension.json
    
  3. Controllare il file ca.crt creato per il Registro di sistema connesso.

    kubectl get secret connectedext-ca-cert -n connected-registry -o yaml
    
  4. Copiare il file ca.crt e archiviarlo in una $certification variabile.

    $certification="<ca.crt content>"
    echo "$certification" | base64 --decode > ca.crt
    

Configurare manualmente config.toml nei singoli pod di debug

Seguire questa procedura per aggiornare manualmente la configurazione in contenitori in ogni pod di debug:

  1. Aprire una sessione della shell nel pod di destinazione.

    # Replace with the actual pod name
    kubectl exec -it debug-xxxxx -- bash
    root [ / ]# chroot /host
    sh-5.1# ls etc/containerd/
    
  2. Creare la directory richiesta e aggiungere il ca.crt file.

    sh-5.1# sudo mkdir -p /etc/containerd/certs.d/<serviceIP>:443/
    sh-5.1# cd /etc/containerd/certs.d/<serviceIP>:443/
    sh-5.1# vi ca.crt
    (copy and paste the content of ca.crt into the file)
    
  3. Modificare il file config.toml.

    sh-5.1# cd /etc/containerd/
    sh-5.1# vi config.toml 
    
  4. Nel file config.toml, commentare le voci del registro di sistema esistenti e aggiungere la nuova configurazione per l'indirizzo IP del servizio.

    1. Commentare la sezione esistente:

      
      #    [plugins."io.containerd.grpc.v1.cri".registry]
      #      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
      #        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      #          endpoint = ["https://registry-1.docker.io"]
      #        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
      #          endpoint = ["http://localhost:5000"]
      
    2. Aggiungere la configurazione seguente:

        [plugins."io.containerd.grpc.v1.cri".registry]
          [plugins."io.containerd.grpc.v1.cri".registry.configs."<serviceIP>:443".tls]
            ca_file   = "/etc/containerd/certs.d/<serviceIP>:443/ca.crt"
      
  5. Riavviare il servizio containerd e verificare lo stato del servizio kubelet.

    sh-5.1# sudo systemctl restart containerd
    sh-5.1# sudo systemctl status kubelet
    

Abilitare lo staging a livello di soluzione

Per abilitare lo staging per una soluzione, è necessario aggiungere il campo staged al campo properties nel file del modello di soluzione specs.json associato a una versione della soluzione. Questo campo indica che la soluzione deve essere temporanea prima della distribuzione. È necessario specificare l'ID risorsa del registro Azure Container e i percorsi dei file delle immagini.

    properties: {
      "staged": {
        "acrResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerRegistry/registries/<acr-name>",
        "images": [
            "demo-image:latest"
        ]
      }
    }

La preparazione viene attivata automaticamente una volta che la soluzione è configurata.

Annotazioni

Se si verificano problemi durante la gestione temporanea di una soluzione, vedere la guida alla risoluzione dei problemi.

Preparare la versione del modello di soluzione per la gestione temporanea

Caricare un'immagine

  1. Caricare un'immagine del contenitore nel Registro Azure Container creato nel passaggio precedente.

    image="<image_name>"
    
    # Copy your existing file into the build context (optional, if not already there)
    cp /path/to/your/file ./bigfile
    # Build the Docker image
    docker build -t "$image" .
    # Tag the image for Azure Container Registry
    docker tag "$image" "$acrName.azurecr.io/$image:latest"
    # Push the image to ACR
    docker push "$acrName.azurecr.io/$image:latest"
    
  2. È possibile verificare che l'immagine sia stata caricata correttamente.

    az acr repository list --name "$acrName" --output table
    

Creare un target

scopename="staging"
targetName="Line01"

az workload-orchestration target create \
    --resource-group "$rg" \
    --location "$l" \
    --name "$targetName" \
    --display-name "$targetName" \
    --hierarchy-level line \
    --capabilities "This is the capability" \
    --description "This is Line01 Site" \
    --solution-scope "$scopename" \
    --target-specification "@targetspecs.json" \
    --extended-location "@custom-location.json"

Creare un modello di soluzione

  1. Creare il file dello schema della soluzione.

    az workload-orchestration schema create --resource-group "$rg" --version "1.0.0" --schema-name "${resourcePrefix}-SS" --schema-file ./demo-app-schema.yaml -l "$l"
    
  2. Assicurarsi di impostare il nome dello schema corretto e immettere l'immagine compilata nel repository demo-app-config-template.yaml:

    configs:
      image:
        repository: ${{$val(LocalConnectedRegistryIP)}}+/<image_name>
    
  3. In spec.json, cambia l'immagine dello stage con la tua immagine:

    "staged": {
        "acrResourceId": "<your_acr_resource_ID>",
        "images": [
            "<your-image-name>:<tag>"
        ]
    }
    
  4. Creare un file modello di soluzione.

    solutionTemplateName="Line01-Solution"
    
    az workload-orchestration solution-template create \
        --solution-template-name "$solutionTemplateName" \
        -g "$rg" \
        -l "$l" \
        --capabilities "This is the capability" \
        --description "This is Staging Solution" \
        --configuration-template-file "./demo-app-config-template.yaml" \
        --specification "@demo-app-spec.json" \
        --version "1.0.0"
    

Impostare la configurazione a livello di destinazione

Specificare l'indirizzo IP del servizio assegnato al servizio registro connesso. Questo passaggio di configurazione è necessario una sola volta e non deve essere ripetuto per le distribuzioni successive.

az workload-orchestration configuration set -g "$rg" --solution-template-name "$solutionTemplateName" --target-name "$targetName"

Risolvere ed esaminare la versione del modello

  1. Determinare la versione del template di soluzione.

    az workload-orchestration target resolve --solution-template-name "$solutionTemplateName" --solution-template-version "1.0.0" --resource-group "$rg" --target-name "$targetName"
    
  2. Esaminare la versione del modello.

    az workload-orchestration target review --solution-template-name "$solutionTemplateName" --solution-template-version "1.0.0" --resource-group "$rg" --target-name "$targetName"
    

Pubblicare e installare la soluzione

  1. Pubblicare la versione del modello.

    reviewId="<input the ID from previous step>"
    az workload-orchestration target publish --solution-name "$solutionName" --solution-version "1.0.0" --review-id "$reviewId" --resource-group "$rg" --target-name "$targetName"
    
  2. Controllare lo stato della soluzione. Deve passare da "inReview" a "staging".

    subscriptionId="<your subscription id>"
    curl -H "Authorization: Bearer <access_token>" \
      "https://eastus2euap.management.azure.com/subscriptions/$subscriptionId/resourceGroups/$rg/providers/Microsoft.Edge/targets/$targetName/solutions/$solutionName/versions?api-version=2025-01-01-preview"
    
  3. Al termine della pubblicazione, eseguire i comandi seguenti per verificare che le immagini vengano gestite in locale:

    kubectl exec -it <connected_registry_pod> -n $cr -- bash
    # (inside the pod)
    # cd maestro-tmp
    # ./check-acr-images.sh "demo-image-0x:latest"
    
  4. Installazione della soluzione.

    az workload-orchestration target install --solution-name "$solutionName" --solution-version "1.0.0" --resource-group "$rg" --target-name "$targetName"
    
  5. Dopo l'installazione, verificare che l'immagine venga usata nella distribuzione.

    kubectl describe pod -n "$scopename"
    

Visualizzare le risorse a fasi

È possibile visualizzare i dettagli di gestione temporanea nella scheda Soluzioni pubblicate del portale di orchestrazione del carico di lavoro.

  1. Accedere al portale di orchestrazione del carico di lavoro e passare alla scheda Configura sul lato sinistro della pagina.

  2. Selezionare la scheda Soluzioni pubblicate .

  3. Scegliere una soluzione con stato Pubblicazione in corso e fare clic sull'icona dell'avviso per visualizzare i dettagli del processo di gestione temporanea.

    Screenshot della scheda Soluzioni pubblicate nel portale di orchestrazione del carico di lavoro.

  4. Viene visualizzato lo stato del processo di staging. Se la preparazione ha esito positivo, viene visualizzato un messaggio che conferma che le immagini vengono scaricate nel cluster perimetrale.

    Screenshot dello stato riuscito di fase di staging nel portale per l'orchestrazione dei carichi di lavoro.

  5. Se la messa in scena ha esito negativo, compare un messaggio di errore che descrive il problema. Per altre informazioni, contattare l'amministratore IT.

    Screenshot dello stato di staging non riuscito nel portale di orchestrazione del carico di lavoro.