Freigeben über

Tutorial: Bereitstellen von selbstgehosteten CI/CD-Runnern und -Agents mit Azure Container Apps-Aufträgen

  • Artikel

Mit GitHub Actions und Azure-Pipelines können Sie CI/CD-Workflows mit selbstgehosteten Runnern und Agents ausführen. Sie können selbstgehostete Runner und Agents mit ereignisgesteuerten Azure Container Apps-Aufträgen ausführen.

Selbstgehostete Runner sind beim Ausführen von Workflows nützlich, die Zugriff auf lokale Ressourcen oder Tools erfordern, die für einen in der Cloud gehosteten Runner nicht verfügbar sind. Beispielsweise ermöglicht ein selbstgehosteter Runner in einem Container Apps-Auftrag Ihrem Workflow den Zugriff auf Ressourcen innerhalb des virtuellen Netzwerks des Auftrags, auf das von einem in der Cloud gehosteten Runner nicht zugegriffen werden kann.

Wenn Sie selbstgehostete Runner als ereignisgesteuerte Aufträge ausführen, können Sie die Serverlosigkeit von Azure Container Apps nutzen. Aufträge werden automatisch ausgeführt, wenn ein Workflow ausgelöst wird, und wird beendet, wenn der Auftrag abgeschlossen ist.

Sie zahlen nur für die Zeit, die der Auftrag ausgeführt wird.

In diesem Tutorial erfahren Sie, wie Sie GitHub Actions-Runner als ereignisgesteuerten Container Apps-Auftrag ausführen.

  • Erstellen einer Container Apps-Umgebung für die Bereitstellung Ihres selbstgehosteten Runners
  • Erstellen eines GitHub-Repositorys zum Ausführen eines Workflows, der einen selbstgehosteten Runner verwendet
  • Erstellen eines Containerimages, das einen GitHub Actions-Runner ausführt
  • Bereitstellen des Runners als Auftrag in der Container Apps-Umgebung
  • Erstellen eines Workflows, der den selbstgehosteten Runner verwendet, und Überprüfen, ob er ausgeführt wird

Wichtig

Selbstgehostete Runner werden nur für private Repositorys empfohlen. Die Verwendung mit öffentlichen Repositorys kann die Ausführung von gefährlichem Code auf Ihrem selbstgehosteten Runner ermöglichen. Weitere Informationen finden Sie unter Sicherheit von selbstgehosteten Runnern.

In diesem Tutorial erfahren Sie, wie Sie Azure Pipelines-Agents als ereignisgesteuerten Container Apps-Auftrag ausführen.

  • Erstellen einer Container Apps-Umgebung für die Bereitstellung Ihres selbstgehosteten Agents
  • Erstellen einer Azure DevOps-Organisation und eines Projekts
  • Erstellen eines Containerimages, das einen Azure Pipelines-Agent ausführt
  • Verwenden eines manuellen Auftrags zum Erstellen eines Platzhalter-Agents in der Container Apps-Umgebung
  • Bereitstellen des Agents als Auftrag in der Container Apps-Umgebung
  • Erstellen einer Pipeline, die den selbstgehosteten Agent verwendet, und Überprüfen, ob sie ausgeführt wird

Wichtig

Selbstgehostete Agents werden nur für private Projekte empfohlen. Die Verwendung mit öffentlichen Projekten kann die Ausführung von gefährlichem Code auf Ihrem selbstgehosteten Agent ermöglichen. Weitere Informationen finden Sie unter Sicherheit von selbstgehosteten Agents.

Hinweis

Container-Apps und -Aufträge unterstützen die Ausführung von Docker in Containern nicht. Alle Schritte in Ihren Workflows, die Docker-Befehle verwenden, schlagen fehl, wenn sie auf einem selbstgehosteten Runner oder Agent in einem Container Apps-Auftrag ausgeführt werden.

Voraussetzungen

Eine Liste der Einschränkungen finden Sie unter Einschränkungen für Aufträge.

Setup

Um sich ausgehend von der CLI bei Azure anzumelden, führen Sie den folgenden Befehl aus und befolgen Sie die Anweisungen, um den Authentifizierungsprozess abzuschließen.

az login

Verwenden Sie den Upgradebefehl, um sicherzustellen, dass Sie die neueste Version der CLI ausführen.

az upgrade

Installieren oder aktualisieren Sie als Nächstes die Azure Container Apps-Erweiterung für die CLI.

Falls Sie Fehler aufgrund fehlender Parameter erhalten, wenn Sie az containerapp-Befehle in der Azure CLI oder Cmdlets aus dem Az.App-Modul in Azure PowerShell ausführen, stellen Sie sicher, dass die aktuelle Version der Azure Container Apps-Erweiterung installiert ist.

az extension add --name containerapp --upgrade

Hinweis

Ab Mai 2024 aktivieren Azure CLI-Erweiterungen standardmäßig keine Previewfunktionen mehr. Um auf Previewfunktionen von Container Apps zuzugreifen, installieren Sie die Container Apps-Erweiterung mit --allow-preview true.

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

Nachdem die aktuelle Erweiterung oder das aktuelle Modul installiert ist, registrieren Sie nun die Namespaces Microsoft.App und Microsoft.OperationalInsights.

az provider register --namespace Microsoft.App

az provider register --namespace Microsoft.OperationalInsights

Erstellen von Umgebungsvariablen

Nachdem die Einrichtung Ihrer Azure CLI abgeschlossen ist, können Sie die Umgebungsvariablen definieren, die in diesem Artikel verwendet werden.

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"

Erstellen einer Container-Apps-Umgebung

Die Azure Container Apps-Umgebung fungiert als sichere Grenze um Container-Apps und -Aufträge, sodass sie das gleiche Netzwerk nutzen und miteinander kommunizieren können.

Hinweis

Informationen zum Erstellen einer Container Apps-Umgebung, die in ein vorhandenes virtuelles Netzwerk integriert ist, finden Sie unter Bereitstellen eines virtuellen Netzwerks für eine interne Azure Container Apps-Umgebung.

  1. Erstellen Sie mithilfe des folgenden Befehls eine Ressourcengruppe.

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

  2. Erstellen Sie die Container-Apps-Umgebung mit dem folgenden Befehl.

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

Erstellen eines GitHub-Repositorys für die Ausführung eines Workflows

Zum Ausführen eines Workflows müssen Sie ein GitHub-Repository erstellen, das die Workflowdefinition enthält.

  1. Navigieren Sie zu GitHub, und melden Sie sich an.

  2. Erstellen Sie ein neues Repository, indem Sie die folgenden Werte eingeben:

    Einstellung Wert
    Besitzer Wählen Sie Ihren GitHub-Benutzernamen aus.
    Name des Repositorys Geben Sie einen Namen für Ihr Repository ein.
    Sichtbarkeit Wählen Sie Privat.
    Dieses Repository initialisieren mit Wähle README-Datei hinzufügen aus.

    Übernehmen Sie bei den verbleibenden Werten die Standardauswahl.

  3. Klicken Sie auf Create repository (Repository erstellen).

  4. Wählen Sie in dem neuen Repository Aktionen aus.

  5. Suchen Sie nach der Vorlage Einfacher Workflow, und wählen Sie Konfigurieren aus.

  6. Wählen Sie Änderungen committen aus, um den Workflow Ihrem Repository hinzuzufügen.

Der Workflow wird auf dem von GitHub gehosteten Runner ubuntu-latest ausgeführt und gibt eine Nachricht in der Konsole aus. Später ersetzen Sie den von GitHub gehosteten Runner durch einen selbstgehosteten Runner.

Abrufen eines persönlichen GitHub-Zugriffstokens

Um einen selbstgehosteten Runner auszuführen, müssen Sie in GitHub ein persönliches Zugriffstoken (Personal Access Token, PAT) erstellen. Jedes Mal, wenn ein Runner gestartet wird, wird mithilfe des PAT ein Token generiert, um den Runner bei GitHub zu registrieren. Das PAT wird auch von der Skalierungsregel des GitHub Actions-Runners verwendet, um die Workflowwarteschlange des Repositorys zu überwachen und Runner nach Bedarf zu starten.

Hinweis

Persönliche Zugriffstoken (Personal Access Tokens, PATs) weisen ein Ablaufdatum auf. Drehen Sie Ihre Token regelmäßig, um sicherzustellen, dass sie gültig (nicht abgelaufen) bleiben, um unterbrechungsfreie Dienste aufrechtzuerhalten.

  1. Wählen Sie in GitHub Ihr Profilbild in der oberen rechten Ecke und dann Einstellungen aus.

  2. Wählen Sie Developer Settings (Entwicklereinstellungen) aus.

  3. Wählen Sie unter Persönliches Zugriffstoken die Option Differenzierte Token aus.

  4. Wählen Sie Generate new token.

  5. Geben Sie auf dem Bildschirm Neues differenziertes persönliches Zugriffstoken die folgenden Werte ein:

    Einstellung Wert
    Token name Geben Sie einen Namen für Ihr Token ein.
    Ablauf Wählen Sie 30 Tage aus.
    Repositoryzugriff Wählen Sie Nur ausgewählte Repositorys und dann das von Ihnen erstellte Repository aus.

    Geben Sie die folgenden Werte für Repositoryberechtigungen ein:

    Einstellung Wert
    Aktionen Wählen Sie für Schreibgeschützt aus.
    Verwaltung Wählen Sie Lesen und Schreiben aus.
    Metadaten Wählen Sie für Schreibgeschützt aus.

  6. Wählen Sie Generate token (Token generieren) aus.

  7. Kopieren Sie den Tokenwert.

  8. Definieren Sie Variablen, die später zum Konfigurieren des Runners und der Skalierungsregel verwendet werden.

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

    Ersetzen Sie die Platzhalter durch die folgenden Werte:

    Platzhalter Wert
    <GITHUB_PAT> Das von Ihnen generierte GitHub-PAT
    <REPO_OWNER> Der Besitzer des zuvor erstellten Repositorys. Dieser Wert ist in der Regel der GitHub-Benutzername.
    <REPO_NAME> Der Name des zuvor erstellten Repositorys. Dieser Wert ist derselbe Name, den Sie im Feld Repositoryname eingegeben haben.

Erstellen des Containerimages für den GitHub Actions-Runner

Zum Erstellen eines selbstgehosteten Runners müssen Sie ein Containerimage erstellen, das den Runner ausführt. In diesem Abschnitt erstellen Sie das Containerimage und pushen es an eine Containerregistrierung.

Hinweis

Das in diesem Tutorial erstellte Image enthält einen einfachen selbstgehosteten Runner, der für die Ausführung als Container Apps-Auftrag geeignet ist. Sie können es anpassen, um zusätzliche Tools oder Abhängigkeiten einzuschließen, die Ihre Workflows erfordern.

  1. Definieren Sie einen Namen für Ihr Containerimage und die Registrierung.

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

    Ersetzen Sie <CONTAINER_REGISTRY_NAME> durch einen eindeutigen Namen für die Erstellung einer Containerregistrierung. Containerregistrierungsnamen müssen innerhalb von Azure eindeutig und zwischen fünf und 50 Zeichen lang sein. Außerdem dürfen sie nur Zahlen und Kleinbuchstaben enthalten.

  2. Erstellen Sie eine Containerregistrierung.

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

  3. Ihre Containerregistrierung muss ARM-Zielgruppentoken (Azure Resource Manager) für die Authentifizierung zulassen, um eine verwaltete Identität zum Pullen von Images zu verwenden.

    Verwenden Sie den folgenden Befehl, um zu überprüfen, ob ARM-Token auf Ihre ACR-Instanz (Azure Container Registry) zugreifen dürfen:

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

    Wenn ARM-Token zulässig sind, gibt der Befehl Folgendes aus:

    {
  "status": "enabled"
}

    Wenn disabled für status angegeben ist, lassen Sie ARM-Token mit dem folgenden Befehl zu:

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

  4. Das Dockerfile zum Erstellen des Runnerimages ist auf GitHub verfügbar. Führen Sie den folgenden Befehl aus, um das Repository zu klonen und das Containerimage mithilfe des Befehls az acr build in der Cloud zu erstellen.

    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"

    Das Image ist jetzt in der Containerregistrierung verfügbar.

Erstellen einer benutzerseitig zugewiesenen verwalteten Identität

Um die Verwendung von Administratoranmeldeinformationen zu vermeiden, pullen Sie Images aus privaten Repositorys in Microsoft Azure Container Registry unter Verwendung von verwalteten Identitäten für die Authentifizierung. Verwenden Sie nach Möglichkeit eine benutzerseitig zugewiesene verwaltete Identität zum Pullen von Images.

  1. Erstellen einer benutzerseitig zugewiesenen verwalteten Identität. Wählen Sie vor dem Ausführen der folgenden Befehle einen Namen für die verwaltete Identität aus, und ersetzen Sie \<PLACEHOLDER\> durch den Namen.

    IDENTITY="<YOUR_IDENTITY_NAME>"

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

  2. Rufen Sie die Ressourcen-ID der Identität ab.

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

Bereitstellen eines selbstgehosteten Runners als Auftrag

Sie können jetzt einen Auftrag erstellen, der das Containerimage verwendet. In diesem Abschnitt erstellen Sie einen Auftrag, der den selbstgehosteten Runner ausführt und sich mithilfe des zuvor generierten PAT bei GitHub authentifiziert. Der Auftrag verwendet die github-runner-Skalierungsregel, um Auftragsausführungen basierend auf der Anzahl der ausstehenden Workflowausführungen zu erstellen.

  1. Erstellen Sie einen Auftrag in der Container Apps-Umgebung.

    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"

    In der folgenden Tabelle werden die wichtigsten Parameter des Befehls beschrieben:

    Parameter Beschreibung
    --replica-timeout Die maximale Dauer, für die ein Replikat ausgeführt werden kann.
    --replica-retry-limit Die Anzahl von Wiederholungsversuchen für ein fehlerhaftes Replikat.
    --replica-completion-count Die Anzahl von Replikaten, die erfolgreich abgeschlossen werden müssen, damit eine Auftragsausführung als erfolgreich betrachtet wird.
    --parallelism Die Anzahl von Replikaten, die pro Auftragsausführung gestartet werden sollen.
    --min-executions Die Mindestanzahl von Auftragsausführungen, die pro Abrufintervall ausgeführt werden sollen.
    --max-executions Die maximale Anzahl von Auftragsausführungen, die pro Abrufintervall ausgeführt werden sollen.
    --polling-interval Das Abrufintervall, mit dem die Skalierungsregel ausgewertet werden soll.
    --scale-rule-name Der Name der Skalierungsregel.
    --scale-rule-type Der Typ der zu verwendenden Skalierungsregel. Weitere Informationen zum GitHub-Runner-Scaler finden Sie in der KEDA-Dokumentation.
    --scale-rule-metadata Die Metadaten für die Skalierungsregel. Wenn Sie GitHub Enterprise verwenden, aktualisieren Sie githubAPIURL mit der API-URL.
    --scale-rule-auth Die Authentifizierung für die Skalierungsregel.
    --secrets Die Geheimnisse, die für den Auftrag verwendet werden sollen.
    --env-vars Die Umgebungsvariablen, die für den Auftrag verwendet werden sollen.
    --registry-server Der Containerregistrierungsserver, der für den Auftrag verwendet werden soll. Bei einer Azure Container Registry-Instanz wird die Authentifizierung automatisch durch den Befehl konfiguriert.
    --mi-user-assigned Die Ressourcen-ID der benutzerseitig zugewiesenen verwalteten Identität zum Zuweisen des Auftrags
    --registry-identity Die Ressourcen-ID einer verwalteten Identität zum Authentifizieren beim Registrierungsserver anstelle eines Benutzernamens und eines Kennworts. Sofern möglich, wird automatisch die Rollenzuweisung „acrpull“ für die Identität erstellt.

    Die Konfiguration der Skalierungsregel definiert die zu überwachende Ereignisquelle. Regeln werden in jedem Abrufintervall ausgewertet, um zu bestimmen, wie viele Auftragsausführungen ausgelöst werden. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln.

Der ereignisgesteuerte Auftrag wird nun in der Container Apps-Umgebung erstellt.

Ausführen eines Workflows und Überprüfen des Auftrags

Der Auftrag ist so konfiguriert, dass die Skalierungsregel alle 30 Sekunden ausgewertet wird. Während jeder Auswertung wird die Anzahl der ausstehenden Workflowausführungen, die einen selbstgehosteten Runner erfordern, überprüft und eine neue Auftragsausführung für ausstehende Workflows gestartet, und zwar bis zu einem konfigurierten Maximum von 10 Ausführungen.

Um zu überprüfen, ob der Auftrag ordnungsgemäß konfiguriert wurde, ändern Sie den Workflow so, dass er einen selbstgehosteten Runner verwendet und eine Workflowausführung auslöst. Anschließend können Sie die Auftragsausführungsprotokolle anzeigen, um die Workflowausführung anzuzeigen.

  1. Navigieren Sie im GitHub-Repository zu dem Workflow, den Sie zuvor generiert haben. Es handelt sich um eine YAML-Datei im Verzeichnis .github/workflows.

  2. Wählen Sie Direkt bearbeiten aus.

  3. Aktualisieren Sie die Eigenschaft runs-on auf self-hosted:

    runs-on: self-hosted

  4. Wählen Sie Änderungen committen aus.

  5. Wählen Sie Commit changes (Änderungen committen) aus.

  6. Navigieren Sie zur Registerkarte Aktionen.

    Ein neuer Workflow wird jetzt in die Warteschlange eingereiht. Innerhalb von 30 Sekunden wird die Auftragsausführung gestartet, und der Workflow wird kurz darauf abgeschlossen.

    Warten Sie, bis die Aktion abgeschlossen ist, bevor Sie mit dem nächsten Schritt fortfahren.

  7. Listen Sie die Ausführungen des Auftrags auf, um zu überprüfen, ob eine Auftragsausführung erstellt und erfolgreich abgeschlossen wurde.

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

Erstellen eines Azure DevOps-Projekts und -Repositorys

Zum Ausführen einer Pipeline benötigen Sie ein Azure DevOps-Projekt und ein Repository.

  1. Navigieren Sie zu Azure DevOps, und melden Sie sich bei Ihrem Konto an.

  2. Wählen Sie eine vorhandene Organisation aus, oder erstellen Sie eine neue.

  3. Wählen Sie auf der Übersichtsseite der Organisation Neues Projekt aus, und geben Sie die folgenden Werte ein.

    Einstellung Wert
    Projektname Geben Sie einen Namen für das Projekt ein.
    Sichtbarkeit Wählen Sie Privat.

  4. Klicken Sie auf Erstellen.

  5. Wählen Sie auf der Seitennavigationsleiste die Option Repositorys aus.

  6. Wählen Sie unter Mainbranch mit einer INFODATEI oder mit „.gitignore“ initialisieren die Option INFODATEI hinzufügen aus.

  7. Übernehmen Sie die übrigen Standardwerte, und wählen Sie Initialisieren aus.

Erstellen eines neuen Agentpools

Erstellen Sie einen neuen Agentpool, um den selbstgehosteten Runner auszuführen.

  1. Erweitern Sie in Ihrem Azure DevOps-Projekt die linke Navigationsleiste, und wählen Sie Projekteinstellungen aus.

    Screenshot: Azure DevOps-Schaltfläche „Projekteinstellungen“

  2. Wählen Sie im Abschnitt Pipelines im Navigationsmenü Projekteinstellungen die Option Agentpools aus.

    Screenshot: Azure DevOps-Schaltfläche „Agentpools“

  3. Wählen Sie Pool hinzufügen aus, und geben Sie die folgenden Werte ein:

    Einstellung Wert
    Zu verknüpfender Pool Wählen Sie Neu aus.
    Pooltyp Wählen Sie Selbstgehostet aus.
    Name Geben Sie container-apps ein.
    Gewähren der Zugriffsberechtigung für alle Pipelines Aktiviere dieses Kontrollkästchen.

  4. Klicken Sie auf Erstellen.

Abrufen eines persönlichen Zugriffstokens für Azure DevOps

Um einen selbstgehosteten Runner auszuführen, müssen Sie in Azure DevOps ein persönliches Zugriffstoken (Personal Access Token, PAT) erstellen. Das PAT wird verwendet, um den Runner bei Azure DevOps zu authentifizieren. Es wird auch von der Skalierungsregel verwendet, um die Anzahl der ausstehenden Pipelineausführungen zu ermitteln und neue Auftragsausführungen auszulösen.

[!NOTE]

Persönliche Zugriffstoken (Personal Access Tokens, PATs) weisen ein Ablaufdatum auf. Drehen Sie Ihre Token regelmäßig, um sicherzustellen, dass sie gültig (nicht abgelaufen) bleiben, um unterbrechungsfreie Dienste aufrechtzuerhalten.

  1. Wählen Sie in Azure DevOps neben Ihrem Profilbild in der oberen rechten Ecke die Option Benutzereinstellungen aus.

  2. Wählen Sie Personal Access Tokens (Persönliche Zugriffstoken) aus.

  3. Wählen Sie auf der Seite Persönliche Zugriffstoken die Option Neues Token aus, und geben Sie die folgenden Werte ein:

    Einstellung Wert
    Name Geben Sie einen Namen für Ihr Token ein.
    Organisation Wählen Sie die Organisation aus, die Sie zuvor ausgewählt oder erstellt haben.
    Bereiche Wählen Sie Benutzerdefiniert aus.
    Alle Bereiche anzeigen Wählen Sie Alle Bereich anzeigen aus.
    Agent-Pools (Lesen und verwalten) Wählen Sie Agent-Pools (Lesen und verwalten) aus.

    Wählen Sie keine weiteren Bereich aus.

  4. Klicken Sie auf Erstellen.

  5. Kopieren Sie den Tokenwert an einen sicheren Speicherort.

    Sie können das Token nach Verlassen der Seite nicht mehr abrufen.

  6. Definieren Sie Variablen, die später zum Konfigurieren der Container Apps-Aufträge verwendet werden.

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

    Ersetzen Sie die Platzhalter durch die folgenden Werte:

    Platzhalter Wert Kommentare
    <AZP_TOKEN> Das von Ihnen generierte Azure DevOps-PAT
    <ORGANIZATION_URL> Die URL Ihrer Azure DevOps-Organisation. Achten Sie darauf, dass am Ende der URL kein / steht. Zum Beispiel: https://dev.azure.com/myorg oder https://myorg.visualstudio.com.
    <YOUR_REGISTRATION_TOKEN_API_URL> Die URL der Registrierungstoken-API in der Datei entrypoint.sh. Zum Beispiel, „https://myapi.example.com/get-token“

Erstellen des Containerimages für den Azure Pipelines-Agent

Zum Erstellen eines selbstgehosteten Agents müssen Sie ein Containerimage erstellen, das den Agent ausführt. In diesem Abschnitt erstellen Sie das Containerimage und pushen es an eine Containerregistrierung.

Hinweis

Das in diesem Tutorial erstellte Image enthält einen einfachen selbstgehosteten Agent, der für die Ausführung als Container Apps-Auftrag geeignet ist. Sie können es anpassen, um zusätzliche Tools oder Abhängigkeiten einzuschließen, die Ihre Pipelines erfordern.

  1. Navigieren Sie zurück zum Terminal, und definieren Sie einen Namen für Ihr Containerimage und die Registrierung.

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

    Ersetzen Sie <CONTAINER_REGISTRY_NAME> durch einen eindeutigen Namen für die Erstellung einer Containerregistrierung.

    Containerregistrierungsnamen müssen innerhalb von Azure eindeutig und zwischen fünf und 50 Zeichen lang sein. Außerdem dürfen sie nur Zahlen und Kleinbuchstaben enthalten.

  2. Erstellen Sie eine Containerregistrierung.

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

  3. Das Dockerfile zum Erstellen des Runnerimages ist auf GitHub verfügbar. Führen Sie den folgenden Befehl aus, um das Repository zu klonen und das Containerimage mithilfe des Befehls az acr build in der Cloud zu erstellen.

    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"

    Das Image ist jetzt in der Containerregistrierung verfügbar.

Erstellen eines selbstgehosteten Platzhalter-Agents

Bevor Sie einen selbstgehosteten Agent in Ihrem neuen Agentpool ausführen können, müssen Sie einen Platzhalter-Agent erstellen. Der Platzhalter-Agent stellt sicher, dass der Agentpool verfügbar ist. Pipelines, die den Agentpool verwenden, schlagen fehl, wenn kein Platzhalter-Agent vorhanden ist.

Sie können einen manuellen Auftrag ausführen, um einen Offlineplatzhalter-Agent zu registrieren. Der Auftrag wird einmal ausgeführt und kann dann gelöscht werden. Der Platzhalter-Agent verbraucht keine Ressourcen in Azure Container Apps oder Azure DevOps.

  1. Erstellen Sie einen manuellen Auftrag in der Container Apps-Umgebung, der den Platzhalter-Agent erstellt.

    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"

    In der folgenden Tabelle werden die wichtigsten Parameter des Befehls beschrieben:

    Parameter Beschreibung
    --replica-timeout Die maximale Dauer, für die ein Replikat ausgeführt werden kann.
    --replica-retry-limit Die Anzahl von Wiederholungsversuchen für ein fehlerhaftes Replikat.
    --replica-completion-count Die Anzahl von Replikaten, die erfolgreich abgeschlossen werden müssen, damit eine Auftragsausführung als erfolgreich betrachtet wird.
    --parallelism Die Anzahl von Replikaten, die pro Auftragsausführung gestartet werden sollen.
    --secrets Die Geheimnisse, die für den Auftrag verwendet werden sollen.
    --env-vars Die Umgebungsvariablen, die für den Auftrag verwendet werden sollen.
    --registry-server Der Containerregistrierungsserver, der für den Auftrag verwendet werden soll. Bei einer Azure Container Registry-Instanz wird die Authentifizierung automatisch durch den Befehl konfiguriert.

    Wenn Sie die Umgebungsvariable AZP_PLACEHOLDER festlegen, wird der Agent-Container so konfiguriert, dass er als Offlineplatzhalter-Agent registriert wird, ohne einen Auftrag auszuführen.

  2. Führen Sie den manuellen Auftrag aus, um den Platzhalter-Agent zu erstellen.

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

  3. Listen Sie die Ausführungen des Auftrags auf, um zu überprüfen, ob eine Auftragsausführung erstellt und erfolgreich abgeschlossen wurde.

    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. Überprüfen Sie, ob der Platzhalter-Agent in Azure DevOps erstellt wurde.

    1. Navigieren Sie in Azure DevOps zu Ihrem Projekt.
    2. Wählen Sie Projekteinstellungen>Agentpools>container-apps>Agents aus.
    3. Vergewissern Sie sich, dass ein Platzhalter-Agent mit dem Namen placeholder-agent aufgeführt wird und sein Status „offline“ lautet.

  5. Der Auftrag wird nicht mehr benötigt. Sie können es löschen.

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

Erstellen eines selbstgehosteten Agents als ereignisgesteuerter Auftrag

Nachdem Sie nun über einen Platzhalter-Agent verfügen, können Sie einen selbstgehosteten Agent erstellen. In diesem Abschnitt erstellen Sie einen ereignisgesteuerten Auftrag, der einen selbstgehosteten Agent ausführt, wenn eine Pipeline ausgelöst wird.

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"

In der folgenden Tabelle sind die Skalierungsregelparameter beschrieben, die im Befehl verwendet werden.

Parameter Beschreibung
--min-executions Die Mindestanzahl von Auftragsausführungen, die pro Abrufintervall ausgeführt werden sollen.
--max-executions Die maximale Anzahl von Auftragsausführungen, die pro Abrufintervall ausgeführt werden sollen.
--polling-interval Das Abrufintervall, mit dem die Skalierungsregel ausgewertet werden soll.
--scale-rule-name Der Name der Skalierungsregel.
--scale-rule-type Der Typ der zu verwendenden Skalierungsregel. Weitere Informationen zum Azure Pipelines-Scaler finden Sie in der KEDA-Dokumentation.
--scale-rule-metadata Die Metadaten für die Skalierungsregel.
--scale-rule-auth Die Authentifizierung für die Skalierungsregel.

Die Konfiguration der Skalierungsregel definiert die zu überwachende Ereignisquelle. Regeln werden in jedem Abrufintervall ausgewertet, um zu bestimmen, wie viele Auftragsausführungen ausgelöst werden. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln.

Der ereignisgesteuerte Auftrag wird nun in der Container Apps-Umgebung erstellt.

Ausführen einer Pipeline und Überprüfen des Auftrags

Nachdem ein Auftrag eines selbstgehosteten Agents konfiguriert wurde, können Sie eine Pipeline ausführen und überprüfen, ob er ordnungsgemäß funktioniert.

  1. Navigieren Sie im linken Navigationsbereich Ihres Azure DevOps-Projekts zu Pipelines.

  2. Wählen Sie Pipeline erstellen aus.

  3. Wählen Sie Azure Repos Git als Speicherort Ihres Codes aus.

  4. Wählen Sie das zuvor erstellte Repository aus.

  5. Wählen Sie Starterpipeline aus.

  6. Ändern Sie im YAML-Code der Pipeline den Wert für pool von vmImage: ubuntu-latest in name: container-apps.

    pool:
  name: container-apps

  7. Klicken Sie auf Speichern und ausführen.

    Die Pipeline wird ausgeführt und verwendet den Auftrag des selbstgehosteten Agents, den Sie in der Container Apps-Umgebung erstellt haben.

  8. Listen Sie die Ausführungen des Auftrags auf, um zu überprüfen, ob eine Auftragsausführung erstellt und erfolgreich abgeschlossen wurde.

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

Tipp

Treten Probleme auf? Informieren Sie uns über GitHub, indem Sie ein Problem im Azure Container Apps-Repository öffnen.

Bereinigen von Ressourcen

Führen Sie anschließend den folgenden Befehl aus, um die Ressourcengruppe zu löschen, die Ihre Container Apps-Ressourcen enthält.

Achtung

Mit dem folgenden Befehl werden die angegebene Ressourcengruppe und alle darin enthaltenen Ressourcen gelöscht. Falls in der angegebenen Ressourcengruppe Ressourcen enthalten sind, die nicht zum Umfang dieses Tutorials gehören, werden sie ebenfalls gelöscht.

az group delete \
    --resource-group $RESOURCE_GROUP

Informationen zum Löschen Ihres GitHub-Repositorys finden Sie unter Löschen eines Repositorys.

Nächste Schritte

Container Apps-Aufträge