Condividi tramite

Esercitazione: Distribuire strumenti di esecuzione e agenti CI/CD self-hosted con processi di App Azure Container

  • Articolo

GitHub Actions e Azure Pipelines consentono di eseguire flussi di lavoro CI/CD con strumenti di esecuzione e agenti self-hosted. È possibile eseguire strumenti di esecuzione e agenti self-hosted usando processi basati su eventi di App Azure Container.

Gli strumenti di esecuzione self-hosted sono utili quando è necessario eseguire flussi di lavoro che richiedono l'accesso a risorse o strumenti locali non disponibili per uno strumento di esecuzione ospitato nel cloud. Ad esempio, uno strumento di esecuzione self-hosted in un processo di App contenitore consente al flusso di lavoro di accedere alle risorse all'interno della rete virtuale del processo che non è accessibile a uno strumento di esecuzione ospitato nel cloud.

L'esecuzione di strumenti di esecuzione self-hosted come processi basati su eventi consente di sfruttare la natura serverless di App Contenitore di Azure. I processi vengono eseguiti automaticamente quando viene attivato un flusso di lavoro e terminano al termine del processo.

Si paga solo per il tempo in cui il processo è in esecuzione.

In questa esercitazione si apprenderà come eseguire gli strumenti di esecuzione di GitHub Actions come processo di app contenitore basate su eventi.

  • Creare un ambiente app contenitore per distribuire lo strumento di esecuzione self-hosted
  • Creare un repository GitHub per l'esecuzione di un flusso di lavoro che usa uno strumento di esecuzione self-hosted
  • Creare un'immagine del contenitore che esegue uno strumento di esecuzione di GitHub Actions
  • Distribuire lo strumento di esecuzione come processo nell'ambiente App contenitore
  • Creare un flusso di lavoro che usa lo strumento di esecuzione self-hosted e verificare che venga eseguito

Importante

Gli strumenti di esecuzione self-hosted sono consigliati solo per i repository privati . L'uso con repository pubblici può consentire l'esecuzione di codice pericoloso nel runner self-hosted. Per altre informazioni, vedere Sicurezza dello strumento di esecuzione self-hosted.

Questa esercitazione illustra come eseguire gli agenti di Azure Pipelines come processo di app contenitore basate su eventi.

  • Creare un ambiente app contenitore per distribuire l'agente self-hosted
  • Creare un'organizzazione e un progetto di Azure DevOps
  • Creare un'immagine del contenitore che esegue un agente di Azure Pipelines
  • Usare un processo manuale per creare un agente segnaposto nell'ambiente App contenitore
  • Distribuire l'agente come processo nell'ambiente App contenitore
  • Creare una pipeline che usa l'agente self-hosted e verificare che venga eseguita

Importante

Gli agenti self-hosted sono consigliati solo per i progetti privati . L'uso con progetti pubblici può consentire l'esecuzione di codice pericoloso nell'agente self-hosted. Per altre informazioni, vedere Sicurezza dell'agente self-hosted.

Nota

Le app e i processi del contenitore non supportano l'esecuzione di Docker nei contenitori. Tutti i passaggi nei flussi di lavoro che usano i comandi Docker avranno esito negativo quando vengono eseguiti in uno strumento di esecuzione o un agente self-hosted in un processo di App contenitore.

Prerequisiti

Per un elenco delle limitazioni, vedere Restrizioni dei processi.

Attrezzaggio

Per accedere ad Azure dall'interfaccia della riga di comando, eseguire il comando seguente e seguire le istruzioni per completare il processo di autenticazione.

az login

Per assicurarsi di eseguire la versione più recente dell'interfaccia della riga di comando, eseguire il comando di aggiornamento.

az upgrade

Installare o aggiornare quindi l'estensione App Azure Container per l'interfaccia della riga di comando.

Se si ricevono errori relativi ai parametri mancanti quando si eseguono az containerapp comandi nell'interfaccia della riga di comando di Azure o nei cmdlet del Az.App modulo in Azure PowerShell, assicurarsi di avere installato la versione più recente dell'estensione App Azure Container.

az extension add --name containerapp --upgrade

Nota

A partire da maggio 2024, le estensioni dell'interfaccia della riga di comando di Azure non abilitano più le funzionalità di anteprima per impostazione predefinita. Per accedere alle funzionalità di anteprima di App contenitore, installare l'estensione App contenitore con --allow-preview true.

az extension add --name containerapp --upgrade --allow-preview true

Ora che l'estensione o il modulo corrente è installato, registrare gli Microsoft.App spazi dei nomi e Microsoft.OperationalInsights .

Nota

Le risorse di App Azure Container sono state migrate dallo Microsoft.Web spazio dei nomi allo Microsoft.App spazio dei nomi . Per altri dettagli, vedere Migrazione dello spazio dei nomi da Microsoft.Web a Microsoft.App nel mese di marzo 2022.

az provider register --namespace Microsoft.App

az provider register --namespace Microsoft.OperationalInsights

Creare variabili di ambiente

Dopo aver completato la configurazione dell'interfaccia della riga di comando di Azure, è possibile definire le variabili di ambiente usate in questo articolo.

RESOURCE_GROUP="jobs-sample"
LOCATION="northcentralus"
ENVIRONMENT="env-jobs-sample"
JOB_NAME="github-actions-runner-job"

RESOURCE_GROUP="jobs-sample"
LOCATION="northcentralus"
ENVIRONMENT="env-jobs-sample"
JOB_NAME="azure-pipelines-agent-job"
PLACEHOLDER_JOB_NAME="placeholder-agent-job"

Creare un ambiente app contenitore

L'ambiente app Azure Container funge da limite sicuro per le app e i processi del contenitore, in modo che possano condividere la stessa rete e comunicare tra loro.

Nota

Per creare un ambiente app contenitore integrato con una rete virtuale esistente, vedere Fornire una rete virtuale a un ambiente interno di App Contenitore di Azure.

  1. Creare un gruppo di risorse usando il comando seguente.

    az group create \
    --name "$RESOURCE_GROUP" \
    --location "$LOCATION"

  2. Creare l'ambiente App contenitore usando il comando seguente.

    az containerapp env create \
    --name "$ENVIRONMENT" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION"

Creare un repository GitHub per l'esecuzione di un flusso di lavoro

Per eseguire un flusso di lavoro, è necessario creare un repository GitHub contenente la definizione del flusso di lavoro.

  1. Passare a GitHub e accedere.

  2. Creare un nuovo repository immettendo i valori seguenti.

    Impostazione Valore
    Proprietario Selezionare il nome utente di GitHub.
    Nome del repository Immettere un nome per il repository.
    Visibilità Selezionare Private (Privato).
    Inizializzare questo repository con Selezionare Aggiungi un file README.

    Lasciare il resto dei valori come selezione predefinita.

  3. Selezionare Create repository.

  4. Nel nuovo repository selezionare Azioni.

  5. Cercare il modello Flusso di lavoro semplice e selezionare Configura.

  6. Selezionare Commit changes (Commit changes ) per aggiungere il flusso di lavoro al repository.

Il flusso di lavoro viene eseguito nello ubuntu-latest strumento di esecuzione ospitato in GitHub e stampa un messaggio nella console. Successivamente, si sostituisce lo strumento di esecuzione ospitato in GitHub con uno strumento di esecuzione self-hosted.

Ottenere un token di accesso personale gitHub

Per eseguire uno strumento di esecuzione self-hosted, è necessario creare un token di accesso personale in GitHub. Ogni volta che viene avviato uno strumento di esecuzione, il pat viene usato per generare un token per registrare lo strumento di esecuzione con GitHub. Il pat viene usato anche dalla regola di scala dello strumento di esecuzione di GitHub Actions per monitorare la coda del flusso di lavoro del repository e avviare gli strumenti di esecuzione in base alle esigenze.

  1. In GitHub selezionare l'immagine del profilo nell'angolo superiore destro e selezionare Impostazioni.

  2. Selezionare Developer settings.

  3. In Token di accesso personali selezionare Token con granularità fine.

  4. Selezionare Genera nuovo token.

  5. Nella schermata Nuovo token di accesso personale con granularità fine immettere i valori seguenti.

    Impostazione Valore
    Nome token Immettere un nome per il token.
    Scadenza Selezionare 30 giorni.
    Accesso al repository Selezionare Solo repository e selezionare il repository creato.

    Immettere i valori seguenti per Autorizzazioni repository.

    Impostazione Valore
    Azioni Selezionare Sola lettura.
    Amministrazione Selezionare Lettura e scrittura.
    Metadati UFX Selezionare Sola lettura.

  6. Selezionare Genera token.

  7. Copiare il valore del token.

  8. Definire le variabili usate per configurare lo strumento di esecuzione e la regola di scalabilità in un secondo momento.

    GITHUB_PAT="<GITHUB_PAT>"
REPO_OWNER="<REPO_OWNER>"
REPO_NAME="<REPO_NAME>"

    Sostituire i segnaposto con i valori seguenti:

    Segnaposto Valore
    <GITHUB_PAT> GitHub PAT generato.
    <REPO_OWNER> Proprietario del repository creato in precedenza. Questo valore è in genere il nome utente di GitHub.
    <REPO_NAME> Nome del repository creato in precedenza. Questo valore è lo stesso nome immesso nel campo Nome repository.

Compilare l'immagine del contenitore dello strumento di esecuzione di GitHub Actions

Per creare uno strumento di esecuzione self-hosted, è necessario creare un'immagine del contenitore che esegue lo strumento di esecuzione. In questa sezione si compila l'immagine del contenitore ed eseguirne il push in un registro contenitori.

Nota

L'immagine compilata in questa esercitazione contiene uno strumento di esecuzione self-hosted di base adatto per l'esecuzione come processo di App contenitore. È possibile personalizzarla in modo da includere strumenti o dipendenze aggiuntivi richiesti dai flussi di lavoro.

  1. Definire un nome per l'immagine del contenitore e il registro.

    CONTAINER_IMAGE_NAME="github-actions-runner:1.0"
CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"

    Sostituire <CONTAINER_REGISTRY_NAME> con un nome univoco per la creazione di un registro contenitori. I nomi del registro contenitori devono essere univoci in Azure e avere una lunghezza compresa tra 5 e 50 caratteri contenenti solo numeri e lettere minuscole.

  2. Creare un registro contenitori.

    az acr create \
    --name "$CONTAINER_REGISTRY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION" \
    --sku Basic \
    --admin-enabled true

  3. Il Dockerfile per la creazione dell'immagine dello strumento di esecuzione è disponibile in GitHub. Eseguire il comando seguente per clonare il repository e compilare l'immagine del contenitore nel cloud usando il az acr build comando .

    az acr build \
    --registry "$CONTAINER_REGISTRY_NAME" \
    --image "$CONTAINER_IMAGE_NAME" \
    --file "Dockerfile.github" \
    "https://github.com/Azure-Samples/container-apps-ci-cd-runner-tutorial.git"

    L'immagine è ora disponibile nel registro contenitori.

Distribuire uno strumento di esecuzione self-hosted come processo

È ora possibile creare un processo che usa per usare l'immagine del contenitore. In questa sezione viene creato un processo che esegue lo strumento di esecuzione self-hosted ed esegue l'autenticazione con GitHub usando il token di accesso personale generato in precedenza. Il processo usa la github-runner regola di scalabilità per creare esecuzioni di processi in base al numero di esecuzioni del flusso di lavoro in sospeso.

  1. Creare un processo nell'ambiente App contenitore.

    az containerapp job create -n "$JOB_NAME" -g "$RESOURCE_GROUP" --environment "$ENVIRONMENT" \
    --trigger-type Event \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \
    --replica-completion-count 1 \
    --parallelism 1 \
    --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \
    --min-executions 0 \
    --max-executions 10 \
    --polling-interval 30 \
    --scale-rule-name "github-runner" \
    --scale-rule-type "github-runner" \
    --scale-rule-metadata "githubAPIURL=https://api.github.com" "owner=$REPO_OWNER" "runnerScope=repo" "repos=$REPO_NAME" "targetWorkflowQueueLength=1" \
    --scale-rule-auth "personalAccessToken=personal-access-token" \
    --cpu "2.0" \
    --memory "4Gi" \
    --secrets "personal-access-token=$GITHUB_PAT" \
    --env-vars "GITHUB_PAT=secretref:personal-access-token" "GH_URL=https://github.com/$REPO_OWNER/$REPO_NAME" "REGISTRATION_TOKEN_API_URL=https://api.github.com/repos/$REPO_OWNER/$REPO_NAME/actions/runners/registration-token" \
    --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"

    Nella tabella seguente vengono descritti i parametri chiave usati nel comando .

    Parametro Descrizione
    --replica-timeout Durata massima di esecuzione di una replica.
    --replica-retry-limit Numero di tentativi di replica non riuscita.
    --replica-completion-count Numero di repliche da completare correttamente prima che un'esecuzione del processo venga considerata riuscita.
    --parallelism Numero di repliche da avviare per ogni esecuzione del processo.
    --min-executions Numero minimo di esecuzioni di processi da eseguire per intervallo di polling.
    --max-executions Numero massimo di esecuzioni di processi da eseguire per intervallo di polling.
    --polling-interval Intervallo di polling in corrispondenza del quale valutare la regola di scalabilità.
    --scale-rule-name Nome della regola di scalabilità.
    --scale-rule-type Tipo di regola di scalabilità da usare. Per altre informazioni sul scaler dello strumento di esecuzione di GitHub, vedere la documentazione di KEDA.
    --scale-rule-metadata Metadati per la regola di scalabilità. Se si usa GitHub Enterprise, aggiornare githubAPIURL con il relativo URL DELL'API.
    --scale-rule-auth Autenticazione per la regola di scalabilità.
    --secrets Segreti da usare per il processo.
    --env-vars Variabili di ambiente da usare per il processo.
    --registry-server Server del registro contenitori da usare per il processo. Per un Registro Azure Container, il comando configura automaticamente l'autenticazione.

    La configurazione della regola di scalabilità definisce l'origine evento da monitorare. Viene valutato in ogni intervallo di polling e determina il numero di esecuzioni di processi da attivare. Per altre informazioni, vedere Impostare le regole di ridimensionamento.

Il processo basato su eventi viene ora creato nell'ambiente App contenitore.

Eseguire un flusso di lavoro e verificare il processo

Il processo è configurato per valutare la regola di scalabilità ogni 30 secondi. Durante ogni valutazione, controlla il numero di esecuzioni del flusso di lavoro in sospeso che richiedono uno strumento di esecuzione self-hosted e avvia una nuova esecuzione del processo per il flusso di lavoro in sospeso, fino a un massimo di 10 esecuzioni configurate.

Per verificare che il processo sia stato configurato correttamente, modificare il flusso di lavoro per usare uno strumento di esecuzione self-hosted e attivare un'esecuzione del flusso di lavoro. È quindi possibile visualizzare i log di esecuzione del processo per visualizzare l'esecuzione del flusso di lavoro.

  1. Nel repository GitHub passare al flusso di lavoro generato in precedenza. Si tratta di un file YAML nella .github/workflows directory.

  2. Selezionare Modifica sul posto.

  3. Aggiornare la runs-on proprietà in self-hosted:

    runs-on: self-hosted

  4. Selezionare Commit changes (Esegui commit modifiche).

  5. Selezionare Eseguire il commit delle modifiche.

  6. Passare alla scheda Azioni .

    Viene ora accodato un nuovo flusso di lavoro. Entro 30 secondi, l'esecuzione del processo verrà avviata e il flusso di lavoro verrà completato subito dopo.

    Attendere il completamento dell'azione prima di procedere con il passaggio successivo.

  7. Elencare le esecuzioni del processo per verificare che sia stata creata e completata correttamente un'esecuzione del processo.

    az containerapp job execution list \
    --name "$JOB_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --output table \
    --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'

Creare un progetto e un repository Di Azure DevOps

Per eseguire una pipeline, è necessario un progetto e un repository Di Azure DevOps.

  1. Passare ad Azure DevOps e accedere al proprio account.

  2. Selezionare un'organizzazione esistente o crearne una nuova.

  3. Nella pagina di panoramica dell'organizzazione selezionare Nuovo progetto e immettere i valori seguenti.

    Impostazione Valore
    Nome progetto Immettere un nome per il progetto.
    Visibilità Selezionare Private (Privato).

  4. Seleziona Crea.

  5. Nel riquadro di spostamento laterale selezionare Repository.

  6. In Inizializzare il ramo main con un file README o .gitignore selezionare Aggiungi un FILE LEGGIMI.

  7. Lasciare i valori predefiniti rimanenti e selezionare Inizializza.

Creare un nuovo pool di agenti

Creare un nuovo pool di agenti per eseguire lo strumento di esecuzione self-hosted.

  1. Nel progetto Azure DevOps espandere la barra di spostamento a sinistra e selezionare Impostazioni progetto.

    Screenshot del pulsante delle impostazioni del progetto Azure DevOps.

  2. Nella sezione Pipeline del menu di spostamento Impostazioni progetto selezionare Pool di agenti.

    Screenshot del pulsante Pool di agenti di Azure DevOps.

  3. Selezionare Aggiungi pool e immettere i valori seguenti.

    Impostazione Valore
    Pool da collegare Selezionare Nuovo.
    Tipo di pool Selezionare Self-hosted.
    Nome Immettere container-apps.
    Concedere l'autorizzazione di accesso a tutte le pipeline Selezionare questa casella di controllo.

  4. Seleziona Crea.

Ottenere un token di accesso personale di Azure DevOps

Per eseguire uno strumento di esecuzione self-hosted, è necessario creare un token di accesso personale in Azure DevOps. Il token di accesso personale viene usato per autenticare lo strumento di esecuzione con Azure DevOps. Viene usato anche dalla regola di scalabilità per determinare il numero di esecuzioni di pipeline in sospeso e attivare nuove esecuzioni di processi.

  1. In Azure DevOps selezionare Impostazioni utente accanto all'immagine del profilo nell'angolo in alto a destra.

  2. Selezionare Personal access tokens.

  3. Nella pagina Token di accesso personali selezionare Nuovo token e immettere i valori seguenti.

    Impostazione valore
    Nome Immettere un nome per il token.
    Azienda Selezionare l'organizzazione scelta o creata in precedenza.
    Ambiti Selezionare Personalizzato definito.
    Mostra tutti gli ambiti Selezionare Mostra tutti gli ambiti.
    Pool di agenti (lettura e gestione) Selezionare Pool di agenti (Lettura e gestione).

    Lasciare deselezionati tutti gli altri ambiti.

  4. Seleziona Crea.

  5. Copiare il valore del token in una posizione sicura.

    Non è possibile recuperare il token dopo aver lasciato la pagina.

  6. Definire le variabili usate per configurare i processi di App contenitore in un secondo momento.

    AZP_TOKEN="<AZP_TOKEN>"
ORGANIZATION_URL="<ORGANIZATION_URL>"
AZP_POOL="container-apps"

    Sostituire i segnaposto con i valori seguenti:

    Segnaposto Valore Commenti
    <AZP_TOKEN> Pat di Azure DevOps generato.
    <ORGANIZATION_URL> URL dell'organizzazione di Azure DevOps. Assicurarsi che non sia presente alcun risultato / finale alla fine dell'URL. Ad esempio, https://dev.azure.com/myorg o https://myorg.visualstudio.com.

Creare l'immagine del contenitore dell'agente di Azure Pipelines

Per creare un agente self-hosted, è necessario creare un'immagine del contenitore che esegue l'agente. In questa sezione si compila l'immagine del contenitore ed eseguirne il push in un registro contenitori.

Nota

L'immagine compilata in questa esercitazione contiene un agente self-hosted di base adatto per l'esecuzione come processo di App contenitore. È possibile personalizzarla in modo da includere strumenti o dipendenze aggiuntivi richiesti dalle pipeline.

  1. Tornare al terminale, definire un nome per l'immagine del contenitore e il registro.

    CONTAINER_IMAGE_NAME="azure-pipelines-agent:1.0"
CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"

    Sostituire <CONTAINER_REGISTRY_NAME> con un nome univoco per la creazione di un registro contenitori.

    I nomi del registro contenitori devono essere univoci in Azure e avere una lunghezza compresa tra 5 e 50 caratteri contenenti solo numeri e lettere minuscole.

  2. Creare un registro contenitori.

    az acr create \
    --name "$CONTAINER_REGISTRY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION" \
    --sku Basic \
    --admin-enabled true

  3. Il Dockerfile per la creazione dell'immagine dello strumento di esecuzione è disponibile in GitHub. Eseguire il comando seguente per clonare il repository e compilare l'immagine del contenitore nel cloud usando il az acr build comando .

    az acr build \
    --registry "$CONTAINER_REGISTRY_NAME" \
    --image "$CONTAINER_IMAGE_NAME" \
    --file "Dockerfile.azure-pipelines" \
    "https://github.com/Azure-Samples/container-apps-ci-cd-runner-tutorial.git"

    L'immagine è ora disponibile nel registro contenitori.

Creare un agente self-hosted segnaposto

Prima di poter eseguire un agente self-hosted nel nuovo pool di agenti, è necessario creare un agente segnaposto. L'agente segnaposto garantisce che il pool di agenti sia disponibile. Le pipeline che usano il pool di agenti hanno esito negativo quando non è presente alcun agente segnaposto.

È possibile eseguire un processo manuale per registrare un agente segnaposto offline. Il processo viene eseguito una sola volta e può essere eliminato. L'agente segnaposto non usa alcuna risorsa nelle app contenitore di Azure o in Azure DevOps.

  1. Creare un processo manuale nell'ambiente App contenitore che crea l'agente segnaposto.

    az containerapp job create -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP" --environment "$ENVIRONMENT" \
    --trigger-type Manual \
    --replica-timeout 300 \
    --replica-retry-limit 0 \
    --replica-completion-count 1 \
    --parallelism 1 \
    --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \
    --cpu "2.0" \
    --memory "4Gi" \
    --secrets "personal-access-token=$AZP_TOKEN" "organization-url=$ORGANIZATION_URL" \
    --env-vars "AZP_TOKEN=secretref:personal-access-token" "AZP_URL=secretref:organization-url" "AZP_POOL=$AZP_POOL" "AZP_PLACEHOLDER=1" "AZP_AGENT_NAME=placeholder-agent" \
    --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"

    Nella tabella seguente vengono descritti i parametri chiave usati nel comando .

    Parametro Descrizione
    --replica-timeout Durata massima di esecuzione di una replica.
    --replica-retry-limit Numero di tentativi di replica non riuscita.
    --replica-completion-count Numero di repliche da completare correttamente prima che un'esecuzione del processo venga considerata riuscita.
    --parallelism Numero di repliche da avviare per ogni esecuzione del processo.
    --secrets Segreti da usare per il processo.
    --env-vars Variabili di ambiente da usare per il processo.
    --registry-server Server del registro contenitori da usare per il processo. Per un Registro Azure Container, il comando configura automaticamente l'autenticazione.

    L'impostazione della AZP_PLACEHOLDER variabile di ambiente configura il contenitore dell'agente per la registrazione come agente segnaposto offline senza eseguire un processo.

  2. Eseguire il processo manuale per creare l'agente segnaposto.

    az containerapp job start -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP"

  3. Elencare le esecuzioni del processo per verificare che sia stata creata e completata correttamente un'esecuzione del processo.

    az containerapp job execution list \
    --name "$PLACEHOLDER_JOB_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --output table \
    --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'

  4. Verificare che l'agente segnaposto sia stato creato in Azure DevOps.

    1. Passare al proprio progetto in Azure DevOps.
    2. Selezionare Project settings>Agent pools>container-apps Agents (Pool di agenti container-apps).>
    3. Verificare che sia elencato un agente segnaposto denominato placeholder-agent e che lo stato sia offline.

  5. Il processo non è più necessario. È possibile eliminarlo.

    az containerapp job delete -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP"

Creare un agente self-hosted come processo basato su eventi

Ora che si dispone di un agente segnaposto, è possibile creare un agente self-hosted. In questa sezione viene creato un processo basato su eventi che esegue un agente self-hosted quando viene attivata una pipeline.

az containerapp job create -n "$JOB_NAME" -g "$RESOURCE_GROUP" --environment "$ENVIRONMENT" \
    --trigger-type Event \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \
    --replica-completion-count 1 \
    --parallelism 1 \
    --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \
    --min-executions 0 \
    --max-executions 10 \
    --polling-interval 30 \
    --scale-rule-name "azure-pipelines" \
    --scale-rule-type "azure-pipelines" \
    --scale-rule-metadata "poolName=$AZP_POOL" "targetPipelinesQueueLength=1" \
    --scale-rule-auth "personalAccessToken=personal-access-token" "organizationURL=organization-url" \
    --cpu "2.0" \
    --memory "4Gi" \
    --secrets "personal-access-token=$AZP_TOKEN" "organization-url=$ORGANIZATION_URL" \
    --env-vars "AZP_TOKEN=secretref:personal-access-token" "AZP_URL=secretref:organization-url" "AZP_POOL=$AZP_POOL" \
    --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"

Nella tabella seguente vengono descritti i parametri delle regole di scala usati nel comando .

Parametro Descrizione
--min-executions Numero minimo di esecuzioni di processi da eseguire per intervallo di polling.
--max-executions Numero massimo di esecuzioni di processi da eseguire per intervallo di polling.
--polling-interval Intervallo di polling in corrispondenza del quale valutare la regola di scalabilità.
--scale-rule-name Nome della regola di scalabilità.
--scale-rule-type Tipo di regola di scalabilità da usare. Per altre informazioni sul ridimensionatore di Azure Pipelines, vedere la documentazione di KEDA.
--scale-rule-metadata Metadati per la regola di scalabilità.
--scale-rule-auth Autenticazione per la regola di scalabilità.

La configurazione della regola di scalabilità definisce l'origine evento da monitorare. Viene valutato in ogni intervallo di polling e determina il numero di esecuzioni di processi da attivare. Per altre informazioni, vedere Impostare le regole di ridimensionamento.

Il processo basato su eventi viene ora creato nell'ambiente App contenitore.

Eseguire una pipeline e verificare il processo

Dopo aver configurato un processo dell'agente self-hosted, è possibile eseguire una pipeline e verificare che funzioni correttamente.

  1. Nel riquadro di spostamento sinistro del progetto Azure DevOps passare a Pipeline.

  2. Selezionare Crea pipeline.

  3. Selezionare GIT Azure Repos come percorso del codice.

  4. Selezionare il repository creato in precedenza.

  5. Selezionare Pipeline starter.

  6. Nella pipeline YAML modificare da poolvmImage: ubuntu-latest a name: container-apps.

    pool:
  name: container-apps

  7. Seleziona Salva ed Esegui.

    La pipeline viene eseguita e usa il processo dell'agente self-hosted creato nell'ambiente App contenitore.

  8. Elencare le esecuzioni del processo per verificare che sia stata creata e completata correttamente un'esecuzione del processo.

    az containerapp job execution list \
    --name "$JOB_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --output table \
    --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'

Suggerimento

Problemi? Segnalare il problema in GitHub aprendo un problema nel repository di App contenitore di Azure.

Pulire le risorse

Al termine, eseguire il comando seguente per eliminare il gruppo di risorse che contiene le risorse di App contenitore.

Attenzione

Il comando seguente elimina il gruppo di risorse specificato e tutte le risorse contenute al suo interno. Se nel gruppo di risorse specificato sono presenti anche risorse diverse da quelle usate in questa esercitazione, verranno eliminate.

az group delete \
    --resource-group $RESOURCE_GROUP

Per eliminare il repository GitHub, vedere Eliminazione di un repository.

Passaggi successivi

Processi di App contenitore