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

  • Artikel

Mit GitHub-Aktionen und Azure-Pipelines können Sie CI/CD-Workflows mit selbst gehosteten Läufern und Agents ausführen. Sie können selbst gehostete Läufer und Agents mit ereignisgesteuerten Azure-Container-Apps-Aufträgen ausführen.

Selbst gehostete Läufer sind nützlich, wenn Sie Workflows ausführen müssen, die Zugriff auf lokale Ressourcen oder Tools erfordern, die für einen in der Cloud gehosteten Läufer nicht verfügbar sind. Beispielsweise ermöglicht ein selbst gehosteter Läufer in einem Container-Apps-Auftrag Ihrem Workflow den Zugriff auf Ressourcen innerhalb des virtuellen Netzwerks des Auftrags, auf das für einen in der Cloud gehosteten Läufer nicht zugegriffen werden kann.

Wenn Sie selbst gehostete Läufer als ereignisgesteuerte Aufträge ausführen, können Sie die serverlose Art von Azure-Container-Apps nutzen. Aufträge werden automatisch ausgeführt, wenn ein Workflow ausgelöst und beendet wird, wenn der Auftrag abgeschlossen ist.

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

In diesem Lernprogramm erfahren Sie, wie Sie GitHub Actions-Läufer als ereignisgesteuerten Container-Apps-Auftrag ausführen.

  • Erstellen einer Container-Apps-Umgebung zum Bereitstellen Ihres selbst gehosteten Runners
  • Erstellen eines GitHub-Repositorys zum Ausführen eines Workflows, der einen selbst gehosteten Runner verwendet
  • Erstellen eines Containerimages, das einen GitHub Actions runner ausführt
  • Bereitstellen des Runners als Auftrag in der Container-Apps-Umgebung
  • Erstellen sie einen Workflow, der den selbst gehosteten Runner verwendet, und überprüfen Sie, ob er ausgeführt wird.

Wichtig

Selbst gehostete Läufer werden nur für private Repositorys empfohlen. Die Verwendung mit öffentlichen Repositorys kann es gefährlichen Code ermöglichen, auf Ihrem selbst gehosteten Läufer auszuführen. Weitere Informationen finden Sie unter Self-hosted runner security.

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

  • Erstellen einer Container-Apps-Umgebung zum Bereitstellen Ihres selbst gehosteten 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 sie eine Pipeline, die den selbst gehosteten Agent verwendet, und überprüfen Sie, ob sie ausgeführt wird.

Wichtig

Selbst gehostete Agents werden nur für private Projekte empfohlen. Die Verwendung mit öffentlichen Projekten kann es gefährlichen Code ermöglichen, auf Ihrem selbst gehosteten Agent auszuführen. Weitere Informationen finden Sie unter Self-Hosted Agent Security.

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 selbst gehosteten Runner oder Agent in einem Container-Apps-Auftrag ausgeführt werden.

Voraussetzungen

  • Azure-Konto: Wenn Sie kein Konto haben, können Sie ein kostenloses Konto erstellen.

  • Azure CLI: Installieren Sie die Azure CLI.

  • Azure DevOps-Organisation: Wenn Sie keine DevOps-Organisation mit einem aktiven Abonnement haben, können Sie eine kostenlos erstellen.

Verweisen Sie auf Auftragseinschränkungen für eine Liste der Einschränkungen.

Setup

  1. 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

  2. Stellen Sie mithilfe des Befehls upgrade sicher, dass Sie die neueste Version der CLI ausführen.

    az upgrade

  3. Installieren Sie die neueste Version der Azure Container Apps-CLI-Erweiterung.

    az extension add --name containerapp --upgrade

  4. Registrieren Sie die Namespaces Microsoft.App und Microsoft.OperationalInsights, wenn Sie sie noch nicht in Ihrem Azure-Abonnement registriert haben.

    az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights

  5. Definieren Sie die Umgebungsvariablen, 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 zum Ausführen 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.
    Initialisieren Sie dieses Repository mit Wähle README-Datei hinzufügen aus.

    Behalten Sie die restlichen Werte als Standardauswahl bei.

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

  4. Wählen Sie in Ihrem neuen Repository "Aktionen" aus.

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

  6. Wählen Sie "Commit für Änderungen übernehmen", um den Workflow zu Ihrem Repository hinzuzufügen.

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

Abrufen eines persönlichen GitHub-Zugriffstokens

Um einen selbst gehosteten Runner auszuführen, müssen Sie in GitHub ein persönliches Zugriffstoken (PERSONAL Access Token, PAT) erstellen. Jedes Mal, wenn ein Läufer gestartet wird, wird der PAT verwendet, um ein Token zu generieren, um den Läufer bei GitHub zu registrieren. Der PAT wird auch von der GitHub Actions-Skalierungsregel verwendet, um die Workflowwarteschlange des Repositorys zu überwachen und Läufer nach Bedarf zu starten.

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

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

  3. Wählen Sie unter "Persönliche Zugriffstoken" feinkörnige Token aus.

  4. Wählen Sie Generate new token.

  5. Geben Sie im Bildschirm "Neues fein abgestimmtes 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 Repositorys aus, und wählen Sie das von Ihnen erstellte Repository aus.

    Geben Sie die folgenden Werte für Repositoryberechtigungen ein.

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

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

  7. Kopieren Sie den Tokenwert.

  8. Definieren Sie Variablen, die verwendet werden, um die Läufer- und Skalierungsregel später zu konfigurieren.

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

    Ersetzen Sie die Platzhalter durch die folgenden Werte:

    Platzhalter Wert
    <GITHUB_PAT> Der von Ihnen generierte GitHub-PAT.
    <REPO_OWNER> Der Besitzer des Zuvor erstellten Repositorys. Dieser Wert ist normalerweise Ihr GitHub-Benutzername.
    <REPO_NAME> Der Name des Zuvor erstellten Repositorys. Dieser Wert ist derselbe Name, den Sie im Feld "Repositoryname " eingegeben haben.

Erstellen des GitHub Actions runner-Containerimages

Um einen selbst gehosteten Läufer zu erstellen, müssen Sie ein Containerimage erstellen, das den Läufer ausführt. In diesem Abschnitt erstellen Sie das Containerimage und übertragen es an eine Containerregistrierung.

Hinweis

Das Image, das Sie in diesem Lernprogramm erstellen, enthält einen einfachen selbst gehosteten Läufer, der für die Ausführung als Container-Apps-Auftrag geeignet ist. Sie können sie 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 den <CONTAINER_REGISTRY_NAME> Namen durch einen eindeutigen Namen zum Erstellen einer Containerregistrierung. Containerregistrierungsnamen müssen in Azure eindeutig sein und von 5 bis 50 Zeichen länge sein, die 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. Die Dockerfile-Datei zum Erstellen des Runner-Images ist auf GitHub verfügbar. Führen Sie den folgenden Befehl aus, um das Repository zu klonen und das Containerimage mithilfe des az acr build Befehls 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.

Bereitstellen eines selbst gehosteten Läufers als Auftrag

Sie können jetzt einen Auftrag erstellen, der zum Verwenden des Containerimages verwendet wird. In diesem Abschnitt erstellen Sie einen Auftrag, der den selbst gehosteten Runner ausführt und sich mit GitHub mithilfe des zuvor generierten PAT 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 -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"

    In der folgenden Tabelle werden die schlüsselparameter beschrieben, die im Befehl verwendet werden.

    Parameter Beschreibung
    --replica-timeout Die maximale Dauer, die ein Replikat ausführen kann.
    --replica-retry-limit Die Anzahl der Wiederholungen eines fehlgeschlagenen Replikats.
    --replica-completion-count Die Anzahl der Replikate, die erfolgreich abgeschlossen werden sollen, bevor eine Auftragsausführung als erfolgreich angesehen wird.
    --parallelism Die Anzahl der Replikate, die pro Auftragsausführung gestartet werden sollen.
    --min-executions Die Mindestanzahl von Auftragsausführungen pro Abrufintervall.
    --max-executions Die maximale Anzahl von Auftragsausführungen pro Abrufintervall.
    --polling-interval Das Abrufintervall, in 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 githubAPIURL Sie es mit der API-URL.
    --scale-rule-auth Die Authentifizierung für die Skalierungsregel.
    --secrets Die geheimen Schlüssel, 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-Containerregistrierung konfiguriert der Befehl automatisch die Authentifizierung.

    Die Skalierungsregelkonfiguration definiert die zu überwachende Ereignisquelle. Es wird für jedes Abrufintervall ausgewertet und bestimmt, wie viele Auftragsausführungen ausgelöst werden sollen. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln.

Der ereignisgesteuerte Auftrag wird jetzt 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 überprüft sie die Anzahl der ausstehenden Workflowausführungen, die einen selbst gehosteten Läufer erfordern, und startet eine neue Auftragsausführung für ausstehende Workflows, 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 selbst gehosteten Läufer 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 ist eine YAML-Datei im .github/workflows Verzeichnis.

  2. Wählen Sie "Bearbeiten" aus.

  3. Aktualisieren Sie die runs-on Eigenschaft 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 ist jetzt in die Warteschlange eingereiht. Innerhalb von 30 Sekunden wird die Auftragsausführung gestartet, und der Workflow wird in Kürze abgeschlossen.

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

  7. Listet die Ausführungen des Auftrags auf, um zu bestätigen, dass 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 Organisation.

  3. Wählen Sie auf der Seite "Organisationsübersicht" die Option "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 in der seitlichen Navigation "Neu verfassen" aus.

  6. Wählen Sie unter "Initialize Standard branch with a README" oder ".gitignore" die Option "README hinzufügen" aus.

  7. Behalten Sie die restlichen Werte als Standardwerte bei, und wählen Sie " Initialisieren" aus.

Erstellen eines neuen Agentpools

Erstellen Sie einen neuen Agentpool, um den selbst gehosteten Läufer auszuführen.

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

    Screenshot of the Azure DevOps project settings button.

  2. Wählen Sie unter dem Abschnitt "Pipelines" im Navigationsmenü "Project-Einstellungen" die Option "Agentpools" aus.

    Screenshot of Azure DevOps agent pools button.

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

    Einstellung Wert
    Pool, der verknüpft werden soll Wählen Sie Neu aus.
    Pooltyp Wählen Sie selbst gehostet 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 Azure DevOps-Zugriffstokens

Um einen selbst gehosteten Läufer auszuführen, müssen Sie ein persönliches Zugriffstoken (PAT) in Azure DevOps erstellen. Der PAT wird verwendet, um den Läufer 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.

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

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

  3. Wählen Sie auf der Seite "Persönliche Zugriffstoken" "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 Bereiche anzeigen" aus.
    Agentpools (Lesen und Verwalten) Wählen Sie Agentpools (Lesen und Verwalten) aus.

    Lassen Sie alle anderen Bereiche nicht ausgewählt.

  4. Klicken Sie auf Erstellen.

  5. Kopieren Sie den Tokenwert an einen sicheren Speicherort.

    Sie können das Token nicht abrufen, nachdem Sie die Seite verlassen haben.

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

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

    Ersetzen Sie die Platzhalter durch die folgenden Werte:

    Platzhalter Wert Kommentare
    <AZP_TOKEN> Der von Ihnen generierte Azure DevOps PAT.
    <ORGANIZATION_URL> Die URL Ihrer Azure DevOps-Organisation. Stellen Sie sicher, dass am Ende der URL kein nachgestellter / Code vorhanden ist. Zum Beispiel: https://dev.azure.com/myorg oder https://myorg.visualstudio.com.

Erstellen des Containerimages des Azure Pipelines-Agents

Um einen selbst gehosteten Agent zu erstellen, müssen Sie ein Containerimage erstellen, das den Agent ausführt. In diesem Abschnitt erstellen Sie das Containerimage und übertragen es an eine Containerregistrierung.

Hinweis

Das Image, das Sie in diesem Lernprogramm erstellen, enthält einen einfachen selbst gehosteten Agent, der für die Ausführung als Container-Apps-Auftrag geeignet ist. Sie können sie anpassen, um zusätzliche Tools oder Abhängigkeiten einzuschließen, die Ihre Pipelines benötigen.

  1. Definieren Sie in Ihrem Terminal 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 den <CONTAINER_REGISTRY_NAME> Namen durch einen eindeutigen Namen zum Erstellen einer Containerregistrierung.

    Containerregistrierungsnamen müssen in Azure eindeutig sein und von 5 bis 50 Zeichen länge sein, die 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. Die Dockerfile-Datei zum Erstellen des Runner-Images ist auf GitHub verfügbar. Führen Sie den folgenden Befehl aus, um das Repository zu klonen und das Containerimage mithilfe des az acr build Befehls 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 selbst gehosteten Platzhalter-Agents

Bevor Sie einen selbst gehosteten 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 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, in der der Platzhalter-Agent erstellt wird.

    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 schlüsselparameter beschrieben, die im Befehl verwendet werden.

    Parameter Beschreibung
    --replica-timeout Die maximale Dauer, die ein Replikat ausführen kann.
    --replica-retry-limit Die Anzahl der Wiederholungen eines fehlgeschlagenen Replikats.
    --replica-completion-count Die Anzahl der Replikate, die erfolgreich abgeschlossen werden sollen, bevor eine Auftragsausführung als erfolgreich angesehen wird.
    --parallelism Die Anzahl der Replikate, die pro Auftragsausführung gestartet werden sollen.
    --secrets Die geheimen Schlüssel, 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-Containerregistrierung konfiguriert der Befehl automatisch die Authentifizierung.

    Wenn Sie die AZP_PLACEHOLDER Umgebungsvariable festlegen, wird der Agentcontainer 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. Listet die Ausführungen des Auftrags auf, um zu bestätigen, dass 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 "Agent-Pools für>Project-Einstellungen>"-Container-Apps-Agents> aus.
    3. Vergewissern Sie sich, dass ein benannter placeholder-agent Platzhalter-Agent aufgelistet ist und sein Status offline ist.

  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 selbst gehosteten Agents als ereignisgesteuerter Auftrag

Nachdem Sie nun über einen Platzhalter-Agent verfügen, können Sie einen selbst gehosteten Agent erstellen. In diesem Abschnitt erstellen Sie einen ereignisgesteuerten Auftrag, der einen selbst gehosteten 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 werden die skalierungsregelparameter beschrieben, die im Befehl verwendet werden.

Parameter Beschreibung
--min-executions Die Mindestanzahl von Auftragsausführungen pro Abrufintervall.
--max-executions Die maximale Anzahl von Auftragsausführungen pro Abrufintervall.
--polling-interval Das Abrufintervall, in 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 Skalierungsregelkonfiguration definiert die zu überwachende Ereignisquelle. Es wird für jedes Abrufintervall ausgewertet und bestimmt, wie viele Auftragsausführungen ausgelöst werden sollen. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln.

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

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

Nachdem Sie nun einen selbst gehosteten Agent-Auftrag konfiguriert haben, können Sie eine Pipeline ausführen und überprüfen, ob er ordnungsgemäß funktioniert.

  1. Navigieren Sie in der linken Navigation 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 in der Pipeline YAML von poolvmImage: ubuntu-latest zu name: container-apps.

    pool:
  name: container-apps

  7. Klicken Sie auf Speichern und ausführen.

    Die Pipeline wird ausgeführt und verwendet den selbst gehosteten Agentauftrag, den Sie in der Container-Apps-Umgebung erstellt haben.

  8. Listet die Ausführungen des Auftrags auf, um zu bestätigen, dass 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