Condividi tramite

Esercitazione: Distribuire runner 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 runner e agenti self-hosted. È possibile eseguire runner e agenti self-hosted usando processi basati su eventi di App contenitore di Azure.

I runner self-hosted sono utili quando è necessario eseguire flussi di lavoro che richiedono l'accesso a risorse o strumenti locali che non sono disponibili per un runner ospitato nel cloud. Ad esempio, un runner 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 un runner ospitato nel cloud.

L'esecuzione di runner 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 completamento del processo.

Si paga solo per il tempo durante il quale il processo è in esecuzione.

In questa esercitazione si apprenderà come eseguire i runner di GitHub Actions come processo di App contenitore basato su eventi.

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

Importante

I runner 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 del runner 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 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 contenitore non supportano l'esecuzione di Docker nei contenitori. Tutti i passaggi dei flussi di lavoro che usano i comandi Docker avranno esito negativo quando vengono eseguiti in un runner o in un agente self-hosted in un processo di App contenitore.

Prerequisiti

  • Organizzazione di Azure DevOps: se non si ha un'organizzazione DevOps con una sottoscrizione attiva, è possibile crearne una gratuitamente.

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

Assicurarsi di eseguire l'ultima versione dell'interfaccia della riga di comando eseguire il comando di aggiornamento.

az upgrade

Installare o aggiornare quindi l'estensione App contenitore di Azure 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 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 spazi dei nomi Microsoft.App e Microsoft.OperationalInsights.

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 contenitore di Azure funge da limite sicuro per le app contenitore e i processi, in modo che possano condividere la stessa rete e comunicare tra loro.

Nota

Per creare un ambiente di App contenitore integrato con una rete virtuale esistente, vedere Fornire una rete virtuale a un ambiente 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 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 da 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 delle modifiche per aggiungere il flusso di lavoro al repository.

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

Ottenere un token di accesso personale GitHub

Per eseguire un runner self-hosted, è necessario creare un token di accesso personale in GitHub. Ogni volta che viene avviato un runner, il token di accesso personale viene usato per generare un token per registrare il runner con GitHub. Il token di accesso personale viene usato anche dalla regola di ridimensionamento del runner di GitHub Actions per monitorare la coda del flusso di lavoro del repository e avviare i runner in base alle esigenze.

Nota

I token di accesso personale hanno una data di scadenza. Ruotare regolarmente i token per assicurarsi che rimangano validi (non scaduti) per mantenere un servizio ininterrotto.

  1. In GitHub selezionare l'immagine del profilo nell'angolo in alto a destra e selezionare Impostazioni.

  2. Selezionare Developer settings.

  3. In Token di accesso personali selezionare Token dettagliato.

  4. Selezionare Genera nuovo token.

  5. Nella schermata Nuovo token di accesso personale dettagliato immettere i valori seguenti.

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

    Immettere i valori seguenti in 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 il runner e la regola di ridimensionamento 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> Token di accesso personale GitHub 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 del runner di GitHub Actions

Per creare un runner self-hosted, è necessario compilare un'immagine del contenitore che esegue il runner. In questa sezione si compila l'immagine del contenitore e se ne esegue il push in un registro contenitori.

Nota

L'immagine compilata in questa esercitazione contiene un runner self-hosted di base adatto per l'esecuzione come processo di App contenitore. È possibile personalizzarlo 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

  3. Il registro contenitori deve consentire token di destinatari di Azure Resource Manager (ARM) per l'autenticazione per usare l'identità gestita per eseguire il pull delle immagini.

    Usare il comando seguente per verificare se i token ARM sono autorizzati ad accedere al Registro Azure Container (ACR).

    az acr config authentication-as-arm show --registry "$CONTAINER_REGISTRY_NAME"

    Se sono consentiti token ARM, il comando restituisce quanto segue.

    {
  "status": "enabled"
}

    status Se è disabled, consentire i token ARM con il comando seguente.

    az acr config authentication-as-arm update --registry "$CONTAINER_REGISTRY_NAME" --status enabled

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

    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.

Creare un'identità gestita assegnata dall'utente

Per evitare di usare credenziali amministrative, eseguire il pull delle immagini dai repository privati in Microsoft Registro Azure Container usando le identità gestite per l'autenticazione. Quando possibile, usare un'identità gestita assegnata dall'utente per eseguire il pull delle immagini.

  1. Creare un'identità gestita assegnata dall'utente. Prima di eseguire i comandi seguenti, scegliere un nome per l'identità gestita e sostituire con \<PLACEHOLDER\> il nome .

    IDENTITY="<YOUR_IDENTITY_NAME>"

    az identity create \
    --name $IDENTITY \
    --resource-group $RESOURCE_GROUP

  2. Ottenere l'ID risorsa dell'identità.

    IDENTITY_ID=$(az identity show \
    --name $IDENTITY \
    --resource-group $RESOURCE_GROUP \
    --query id \
    --output tsv)

Distribuire un runner self-hosted come processo

È ora possibile creare un processo che usi l'immagine del contenitore. In questa sezione viene creato un processo che esegue il runner self-hosted ed esegue l'autenticazione con GitHub usando il token di accesso personale generato in precedenza. Il processo usa la regola di scalabilità github-runner 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 \
    --name "$JOB_NAME" \
    --resource-group "$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" \
    --mi-user-assigned "$IDENTITY_ID" \
    --registry-identity "$IDENTITY_ID"

    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 sullo scaler del runner di GitHub, vedere la documentazione KEDA.
    --scale-rule-metadata Metadati della 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.
    --mi-user-assigned ID risorsa dell'identità gestita assegnata dall'utente da assegnare al processo.
    --registry-identity ID risorsa di un'identità gestita da autenticare con il server del Registro di sistema anziché usare un nome utente e una password. Se possibile, viene creata automaticamente un'assegnazione di ruolo "acrpull" per l'identità.

    La configurazione della regola di scalabilità definisce l'origine evento da monitorare. Le regole vengono valutate in ogni intervallo di polling per determinare il numero di esecuzioni di processi da attivare. Per altre informazioni, vedere Impostare le regole di ridimensionamento.

Il processo guidato dagli eventi viene così 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 un runner 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 un runner 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 directory .github/workflows.

  2. Selezionare Modifica sul posto.

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

    runs-on: self-hosted

  4. Selezionare 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 Azure DevOps

Per eseguire una pipeline, sono necessari un progetto e un repository 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 principale con un file README o .gitignore, selezionare Aggiungi un file README.

  7. Lasciare i valori predefiniti rimanenti e selezionare Inizializza.

Creare un nuovo pool di agenti

Creare un nuovo pool di agenti per eseguire il runner 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-app.
    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 un runner self-hosted, è necessario creare un token di accesso personale in Azure DevOps. Il token di accesso personale viene usato per autenticare il runner 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.

[!NOTE]

I token di accesso personale hanno una data di scadenza. Ruotare regolarmente i token per assicurarsi che rimangano validi (non scaduti) per mantenere un servizio ininterrotto.

  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"
REGISTRATION_TOKEN_API_URL="<YOUR_REGISTRATION_TOKEN_API_URL>"

    Sostituire i segnaposto con i valori seguenti:

    Segnaposto Valore Commenti
    <AZP_TOKEN> Token di accesso personale di Azure DevOps generato.
    <ORGANIZATION_URL> URL dell'organizzazione di Azure DevOps. Assicurarsi che non sia presente alcun / finale alla fine dell'URL. Ad esempio, https://dev.azure.com/myorg o https://myorg.visualstudio.com.
    <YOUR_REGISTRATION_TOKEN_API_URL> URL dell'API del token di registrazione nel file entrypoint.sh . Ad esempio, 'https://myapi.example.com/get-token'

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 e se ne esegue 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 personalizzarlo 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 del runner è disponibile in GitHub. Eseguire il comando seguente per clonare il repository e compilare l'immagine del contenitore nel cloud usando il comando az acr build.

    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 in 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 variabile di ambiente AZP_PLACEHOLDER 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 Impostazioni progetto>Pool agenti>container-apps>Agenti.
    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 della regola di ridimensionamento 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 sullo scaler di Azure Pipelines, vedere la documentazione KEDA.
--scale-rule-metadata Metadati della regola di scalabilità.
--scale-rule-auth Autenticazione per la regola di scalabilità.

La configurazione della regola di scalabilità definisce l'origine evento da monitorare. Le regole vengono valutate in ogni intervallo di polling per determinare il numero di esecuzioni di processi da attivare. Per altre informazioni, vedere Impostare le regole di ridimensionamento.

Il processo guidato dagli eventi viene così 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 a sinistra 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 pool da vmImage: 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 i problemi su GitHub aprendo un ticket nel repository App contenitore di Azure.

Pulire le risorse

Una volta terminato, eseguire il comando seguente per eliminare il gruppo di risorse che contiene le risorse di App contenitore.

Attenzione

Nell'esempio seguente, il gruppo di risorse specificato e tutte le risorse al suo interno vengono eliminati. 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