Udostępnij za pośrednictwem

Poradnik: wdrażanie własnych agentów CI/CD przy użyciu zadań w Azure Container Apps

GitHub Actions i Azure Pipelines umożliwiają uruchamianie przepływów pracy CI/CD za pomocą hostowanych samodzielnie runnerów i agentów. Możesz uruchamiać hostowane lokalnie agenty i agentów przy użyciu zadań opartych na zdarzeniach usługi Azure Container Apps .

Samodzielnie hostowane moduły uruchamiające są przydatne, gdy trzeba uruchamiać przepływy pracy wymagające dostępu do zasobów lokalnych lub narzędzi, które nie są dostępne dla modułów uruchamiających hostowanych w chmurze. Na przykład własny agent w zadaniu usługi Container Apps umożliwia przepływowi pracy dostęp do zasobów w sieci wirtualnej zadania, które nie są dostępne dla agenta hostowanego w chmurze.

Uruchamianie samodzielnie hostowanych interpreterów jako zadań uruchamianych w odpowiedzi na zdarzenia umożliwia korzystanie z natury bezserwerowej usługi Azure Container Apps. Zadania są wykonywane automatycznie, gdy przepływ pracy jest wyzwalany i zamykany po zakończeniu zadania.

Płacisz tylko za czas działania zadania.

Z tego samouczka dowiesz się, jak uruchamiać moduły uruchamiane w usłudze GitHub Actions jako zadanie aplikacji kontenera sterowane zdarzeniami.

  • Utwórz środowisko aplikacji kontenerowych, aby wdrożyć samohostowanego agenta.
  • Utwórz repozytorium GitHub do uruchamiania przepływu pracy korzystającego z własnego agenta
  • Utwórz obraz kontenera uruchamiający runnera dla GitHub Actions
  • Wdróż runner jako zadanie w środowisku Container Apps.
  • Utwórz przepływ pracy, który używa własnego modułu uruchamiającego i sprawdź, czy działa

Ważne

Moduły uruchamiane samodzielnie są zalecane tylko w przypadku repozytoriów prywatnych . Używanie ich z repozytoriami publicznymi może umożliwić wykonywanie niebezpiecznego kodu na własnoręcznie zarządzanym uruchamiaczu. Aby uzyskać więcej informacji, zobacz Zabezpieczenia własnego biegacza.

Uwaga

Każdy osobisty token dostępu ma datę wygaśnięcia. Należy upewnić się, że PAT są regularnie wymieniane przed datą wygaśnięcia. Aby uzyskać więcej informacji na temat zarządzania tokenem pat, zobacz Use personal access tokens (Używanie osobistych tokenów dostępu).

Z tego samouczka dowiesz się, jak uruchamiać agentów usługi Azure Pipelines jako zadanie usługi Container Apps sterowane zdarzeniami.

  • Tworzenie środowiska usługi Container Apps w celu wdrożenia własnego agenta
  • Tworzenie organizacji i projektu usługi Azure DevOps
  • Tworzenie obrazu kontenera, który uruchamia agenta usługi Azure Pipelines
  • Używanie zadania ręcznego do tworzenia agenta zastępczego w środowisku usługi Container Apps
  • Wdróż agenta jako zadanie w środowisku Container Apps
  • Utwórz potok, który używa własnego agenta i sprawdź, czy jest uruchomiony

Ważne

Agenci typu self-hosted są zalecani tylko w przypadku projektów prywatnych. Używanie ich z publicznymi projektami umożliwia wykonywanie niebezpiecznego kodu na własnym agencie. Aby uzyskać więcej informacji, zobacz Zabezpieczenia własnego agenta.

Uwaga

Każdy osobisty token dostępu ma datę wygaśnięcia. Należy upewnić się, że PAT są regularnie wymieniane przed datą wygaśnięcia. Aby uzyskać więcej informacji na temat zarządzania tokenem pat, zobacz Use personal access tokens (Używanie osobistych tokenów dostępu).

Uwaga

Aplikacje kontenerowe i zadania nie obsługują działania Dockera w kontenerach. Wszystkie kroki w przepływach roboczych używających poleceń Docker kończą się niepowodzeniem podczas uruchamiania na lokalnie hostowanym narzędziu uruchamiającym lub agencie w zadaniu Container Apps.

Wymagania wstępne

Zapoznaj się z ograniczeniami zadań w celu uzyskania listy ograniczeń.

Ustawienia

Aby zalogować się do platformy Azure z poziomu interfejsu wiersza polecenia, uruchom następujące polecenie i postępuj zgodnie z monitami, aby ukończyć proces uwierzytelniania.

az login

Aby upewnić się, że używasz najnowszej wersji interfejsu wiersza polecenia, uruchom polecenie uaktualniania.

az upgrade

Następnie zainstaluj lub zaktualizuj rozszerzenie usługi Azure Container Apps dla interfejsu wiersza polecenia.

Jeśli podczas uruchamiania polecenia az containerapp w Azure CLI lub polecenia cmdlet z modułu Az.App w PowerShell wystąpią błędy dotyczące brakujących parametrów, upewnij się, że masz zainstalowaną najnowszą wersję rozszerzenia Azure Container Apps.

az extension add --name containerapp --upgrade

Uwaga

Począwszy od maja 2024 r., rozszerzenia interfejsu wiersza polecenia platformy Azure domyślnie nie włączają funkcji w wersji zapoznawczej. Aby uzyskać dostęp do funkcji usługi Container Apps w wersji zapoznawczej, zainstaluj rozszerzenie Container Apps za pomocą polecenia --allow-preview true.

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

Teraz, gdy bieżące rozszerzenie lub moduł jest zainstalowane, zarejestruj przestrzenie nazw Microsoft.App oraz Microsoft.OperationalInsights.

az provider register --namespace Microsoft.App

az provider register --namespace Microsoft.OperationalInsights

Tworzenie zmiennych środowiskowych

Teraz, gdy konfiguracja interfejsu wiersza polecenia platformy Azure została ukończona, możesz zdefiniować zmienne środowiskowe używane w tym artykule.

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"

Tworzenie środowiska usługi Container Apps

Środowisko usługi Azure Container Apps działa jako bezpieczna granica wokół aplikacji i zadań kontenerów, dzięki czemu mogą współużytkować tę samą sieć i komunikować się ze sobą.

Uwaga

Aby utworzyć środowisko usługi Container Apps zintegrowane z istniejącą siecią wirtualną, zobacz Zapewnianie sieci wirtualnej w środowisku usługi Azure Container Apps.

  1. Utwórz grupę zasobów przy użyciu poniższego polecenia.

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

  2. Utwórz środowisko Container Apps przy użyciu następującego polecenia.

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

Tworzenie repozytorium GitHub na potrzeby uruchamiania przepływu pracy

Aby wykonać przepływ pracy, należy utworzyć repozytorium GitHub zawierające definicję przepływu pracy.

  1. Przejdź do usługi GitHub i zaloguj się.

  2. Utwórz nowe repozytorium, wprowadzając następujące wartości.

    Ustawienie Wartość
    Właściciel Wybierz swoją nazwę użytkownika usługi GitHub.
    Nazwa repozytorium Wprowadź nazwę repozytorium.
    Widoczność Wybierz pozycję Prywatny.
    Aby zainicjować to repozytorium, użyj komendy Wybierz pozycję Dodaj plik README.

    Pozostaw pozostałe wartości jako domyślne zaznaczenie.

  3. Wybierz pozycję Utwórz repozytorium.

  4. W nowym repozytorium wybierz pozycję Akcje.

  5. Wyszukaj szablon Prosty przepływ pracy i wybierz pozycję Konfiguruj.

  6. Wybierz pozycję Zatwierdź zmiany , aby dodać przepływ pracy do repozytorium.

Przepływ pracy działa na hostowanym przez GitHub module uruchamiającym i wyświetla komunikat w konsoli. Później zastąpisz agenta hostowanego w usłudze GitHub własnym agentem.

Uzyskiwanie osobistego tokenu dostępu w usłudze GitHub

Aby uruchomić własny moduł uruchamiający, należy utworzyć osobisty token dostępu (PAT) w usłudze GitHub. Za każdym razem, gdy uruchamiany jest runner, PAT jest używany do zarejestrowania runnera w GitHub. Token dostępu osobistego jest również używany przez regułę skalowania runnera w GitHub Actions do monitorowania kolejki zadań repozytorium i uruchamiania runnerów zgodnie z potrzebami.

Uwaga

Osobiste tokeny dostępu (PAT) mają datę wygaśnięcia. Regularnie wymieniaj tokeny, aby upewnić się, że pozostają prawidłowe (nie wygasły), aby zachować nieprzerwaną obsługę.

  1. W usłudze GitHub wybierz swój obraz profilu w prawym górnym rogu i wybierz pozycję Ustawienia.

  2. Wybierz pozycję Ustawienia dewelopera.

  3. Pod Osobiste tokeny dostępu wybierz Drobnoziarniste tokeny.

  4. Wybierz pozycję Generuj nowy token.

  5. Na ekranie Nowy szczegółowy osobisty token dostępu wprowadź następujące wartości.

    Ustawienie Wartość
    Nazwa tokenu Wprowadź nazwę tokenu.
    Wygaśnięcie Wybierz 30 dni.
    Dostęp do repozytorium Wybierz Tylko wybrane repozytoria i zaznacz utworzone repozytorium.

    Wprowadź następujące wartości dla uprawnień repozytorium.

    Ustawienie Wartość
    Akcje Wybierz pozycję Tylko do odczytu.
    Administracja Wybierz pozycję Odczyt i zapis.
    Metadane Wybierz pozycję Tylko do odczytu.

  6. Wybierz pozycję Generuj token.

  7. Skopiuj wartość tokenu.

  8. Zdefiniuj zmienne używane do późniejszego konfigurowania modułu uruchamiającego i reguły skalowania.

    GITHUB_PAT="<GITHUB_PAT>"
REPO_OWNER="<REPO_OWNER>"
REPO_NAME="<REPO_NAME>"
REGISTRATION_TOKEN_API_URL="<YOUR_REGISTRATION_TOKEN_API_URL>"

    Zastąp symbole zastępcze następującymi wartościami:

    Symbol zastępczy Wartość
    <GITHUB_PAT> Wygenerowany przez ciebie PAT GitHub.
    <REPO_OWNER> Właściciel utworzonego wcześniej repozytorium. Ta wartość jest zwykle twoją nazwą użytkownika usługi GitHub.
    <REPO_NAME> Nazwa utworzonego wcześniej repozytorium. Ta wartość jest tą samą nazwą wprowadzoną w polu Nazwa repozytorium .
    <YOUR_REGISTRATION_TOKEN_API_URL> Adres URL interfejsu API tokenu rejestracji w pliku entrypoint.sh. Na przykład "https://myapi.example.com/get-token"

Kompilowanie obrazu kontenera modułu uruchamiającego akcje GitHub Actions

Aby utworzyć samodzielnie hostowany moduł uruchamiający, musisz zbudować obraz kontenera, który go uruchamia. W tej sekcji skompilujesz obraz kontenera i wypchniesz go do rejestru kontenerów.

Uwaga

Obraz, który tworzysz w tym samouczku, zawiera podstawowy samodzielnie hostowany agent, który jest odpowiedni do uruchamiania jako zadanie aplikacji Container Apps. Można dostosować go tak, aby zawierał dodatkowe narzędzia lub zależności wymagane przez przepływy pracy.

  1. Zdefiniuj nazwę obrazu kontenera i rejestru.

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

    Zastąp <CONTAINER_REGISTRY_NAME> unikatową nazwą przy tworzeniu rejestru kontenerów. Nazwy rejestru kontenerów muszą być unikatowe na platformie Azure i mieć długość od 5 do 50 znaków zawierających tylko cyfry i małe litery.

  2. Utwórz rejestr kontenerów.

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

  3. Rejestr kontenerów musi zezwalać na tokeny odbiorców usługi Azure Resource Manager (ARM) na potrzeby uwierzytelniania w celu użycia tożsamości zarządzanej do ściągania obrazów.

    Użyj następującego polecenia, aby sprawdzić, czy tokeny usługi ARM mogą uzyskiwać dostęp do usługi Azure Container Registry (ACR).

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

    Jeśli tokeny usługi ARM są dozwolone, polecenie zwraca następujący wynik.

    {
  "status": "enabled"
}

    Jeśli status jest disabled, zezwól na tokeny ARM za pomocą następującego polecenia.

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

  4. Plik Dockerfile do tworzenia obrazu modułu uruchamiającego jest dostępny w witrynie GitHub. Uruchom następujące polecenie, aby sklonować repozytorium i skompilować obraz kontenera w chmurze przy użyciu az acr build polecenia .

    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"

    Obraz jest teraz dostępny w rejestrze kontenerów.

Tworzenie tożsamości zarządzanej przypisanej przez użytkownika

Aby uniknąć używania poświadczeń administracyjnych, pobieraj obrazy z prywatnych repozytoriów w usłudze Microsoft Azure Container Registry, używając tożsamości zarządzanych do uwierzytelniania. Jeśli to możliwe, użyj tożsamości zarządzanej przypisanej przez użytkownika do ściągania obrazów.

  1. Utwórz tożsamość zarządzaną przypisaną przez użytkownika. Przed uruchomieniem następujących poleceń wybierz nazwę tożsamości zarządzanej i zastąp ciąg \<PLACEHOLDER\> nazwą .

    IDENTITY="<YOUR_IDENTITY_NAME>"

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

  2. Pobierz identyfikator zasobu tożsamości.

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

Uruchom własnego runnera jako zadanie

Teraz możesz utworzyć zadanie, które używa obrazu kontenera. W tej sekcji utworzysz zadanie, które wykonuje własny moduł uruchamiający i uwierzytelnia się w usłudze GitHub przy użyciu wygenerowanego wcześniej identyfikatora PAT. Zadanie używa regułygithub-runner do tworzenia wykonań zadań na podstawie liczby oczekujących przebiegów przepływu pracy.

  1. Utwórz zadanie w środowisku Container Apps.

    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"

    W poniższej tabeli opisano kluczowe parametry używane w poleceniu .

    Parametr Opis
    --replica-timeout Maksymalny czas, przez jaki replika może działać.
    --replica-retry-limit Liczba ponownych prób ponawiania próby repliki, która zakończyła się niepowodzeniem.
    --replica-completion-count Liczba replik, które muszą zostać pomyślnie ukończone, aby wykonanie zadania mogło być uznane za pomyślne.
    --parallelism Liczba replik do uruchomienia na każde wykonanie zadania.
    --min-executions Minimalna liczba wykonań zadań do uruchomienia na interwał sondowania.
    --max-executions Maksymalna liczba wykonań zadań do uruchomienia w interwale sondowania.
    --polling-interval Interwał sondowania, w którym ma być oceniana reguła skalowania.
    --scale-rule-name Nazwa reguły skalowania.
    --scale-rule-type Typ reguły skalowania do użycia. Aby dowiedzieć się więcej na temat skalera runnerów GitHub, zobacz dokumentację KEDA.
    --scale-rule-metadata Metadane reguły skalowania. Jeśli używasz usługi GitHub Enterprise, zaktualizuj githubAPIURL adres URL interfejsu API.
    --scale-rule-auth Uwierzytelnianie dla reguły skalowania.
    --secrets Tajemnice do wykorzystania w pracy.
    --env-vars Zmienne środowiskowe do użycia dla zadania.
    --registry-server Serwer rejestracji kontenerów, który ma być użyty do zadania. W przypadku usługi Azure Container Registry polecenie automatycznie konfiguruje uwierzytelnianie.
    --mi-user-assigned Identyfikator zasobu tożsamości zarządzanej przypisanej przez użytkownika do przypisania do zadania.
    --registry-identity Identyfikator zasobu tożsamości zarządzanej do uwierzytelniania na serwerze rejestru zamiast przy użyciu nazwy użytkownika i hasła. Jeśli to możliwe, dla tożsamości zostanie automatycznie utworzone przypisanie roli „acrpull”.

    Konfiguracja reguły skalowania definiuje źródło zdarzeń do monitorowania. Reguły są oceniane w każdym interwale sondowania, aby określić, ile wykonań zadań należy uruchomić. Aby dowiedzieć się więcej, zobacz Ustawianie reguł skalowania.

Zadanie sterowane zdarzeniami jest teraz tworzone w środowisku usługi Container Apps.

Uruchamianie przepływu pracy i weryfikowanie zadania

Zadanie jest skonfigurowane do oceny reguły skalowania co 30 sekund. Podczas każdej oceny sprawdza liczbę oczekujących przebiegów przepływu pracy, które wymagają własnego modułu uruchamiającego i uruchamia nowe wykonanie zadania dla oczekującego przepływu pracy, maksymalnie do skonfigurowanego maksymalnie 10 wykonań.

Aby sprawdzić, czy zadanie zostało poprawnie skonfigurowane, zmodyfikuj przepływ pracy tak, aby używał własnego modułu uruchamiającego i wyzwalał przebieg przepływu pracy. Następnie możesz wyświetlić dzienniki wykonywania zadania, aby wyświetlić przebieg przepływu pracy.

  1. W repozytorium GitHub przejdź do wygenerowanego wcześniej przepływu pracy. Jest to plik YAML w .github/workflows katalogu.

  2. Wybierz pozycję Edytuj w miejscu.

  3. runs-on Zaktualizuj właściwość na self-hosted:

    runs-on: self-hosted

  4. Wybierz pozycję Zatwierdź zmiany....

  5. Wybierz pozycję Zatwierdź zmiany.

  6. Przejdź do karty Akcje .

    Nowy przepływ pracy jest teraz w kolejce. W ciągu 30 sekund uruchomienie zadania zostanie rozpoczęte, a przepływ pracy zostanie ukończony niedługo potem.

    Poczekaj na ukończenie akcji, zanim przejdziesz do następnego kroku.

  7. Wyświetl listę realizacji zadania, aby potwierdzić, że wykonanie zadania zostało utworzone i zakończone pomyślnie.

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

Tworzenie projektu i repozytorium usługi Azure DevOps

Aby uruchomić pipeline, potrzebny jest projekt i repozytorium usługi Azure DevOps.

  1. Przejdź do usługi Azure DevOps i zaloguj się do swojego konta.

  2. Wybierz istniejącą organizację lub utwórz nową.

  3. Na stronie przeglądu organizacji wybierz pozycję Nowy projekt i wprowadź następujące wartości.

    Ustawienie Wartość
    Nazwa projektu Wprowadź nazwę projektu.
    Widoczność Wybierz pozycję Prywatny.

  4. Wybierz pozycję Utwórz.

  5. W nawigacji bocznej wybierz Repozytoria.

  6. W obszarze Inicjowanie gałęzi głównej przy użyciu pliku README lub .gitignore wybierz pozycję Dodaj plik README.

  7. Pozostaw pozostałe wartości jako wartości domyślne i wybierz pozycję Inicjuj.

Tworzenie nowej puli agentów

Utwórz nową pulę agentów, aby uruchomić samodzielnie hostowany runner.

  1. W projekcie usługi Azure DevOps rozwiń lewy pasek nawigacyjny i wybierz pozycję Ustawienia projektu.

    Zrzut ekranu przedstawiający przycisk ustawień projektu usługi Azure DevOps.

  2. W sekcji Potoki w menu nawigacji Ustawienia projektu wybierz pozycję Pule agentów.

    Zrzut ekranu przedstawiający przycisk puli agentów w Azure DevOps.

  3. Wybierz pozycję Dodaj pulę i wprowadź następujące wartości.

    Ustawienie Wartość
    Zasoby do połączenia Wybierz pozycję Nowy.
    Typ puli Wybierz pozycję Self-hosted.
    Nazwa Wprowadź container-apps.
    Nadaj uprawnienia dostępu do wszystkich potoków Zaznacz to pole wyboru.

  4. Wybierz pozycję Utwórz.

Uzyskiwanie osobistego tokenu dostępu usługi Azure DevOps

Aby uruchomić samodzielnie hostowanego runnera, należy utworzyć osobisty token dostępu (PAT) w Azure DevOps. Token dostępu osobistego (PAT) jest używany do uwierzytelniania agenta w Azure DevOps. Jest on także używany przez regułę skalowania do określenia liczby oczekujących uruchomień potoku oraz inicjowania nowych zadań.

Uwaga

Osobiste tokeny dostępu (PAT) mają datę wygaśnięcia. Regularnie wymieniaj tokeny, aby upewnić się, że pozostają prawidłowe (nie wygasły), aby zachować nieprzerwaną obsługę.

  1. W usłudze Azure DevOps wybierz pozycję Ustawienia użytkownika obok obrazu profilu w prawym górnym rogu.

  2. Wybierz pozycję Osobiste tokeny dostępu.

  3. Na stronie Osobiste tokeny dostępu wybierz pozycję Nowy token i wprowadź następujące wartości.

    Ustawienie Wartość
    Nazwa Wprowadź nazwę tokenu.
    Organizacja Wybierz wybraną lub utworzoną wcześniej organizację.
    Zakresy Wybierz Niestandardowe.
    Pokaż wszystkie zakresy Wybierz pozycję Pokaż wszystkie zakresy.
    Pule Agentów (odczyt i zarządzanie) Wybierz Pule agentów (odczyt i zarządzanie).

    Pozostaw wszystkie inne zakresy niezaznaczone.

  4. Wybierz pozycję Utwórz.

  5. Skopiuj wartość tokenu do bezpiecznej lokalizacji.

    Nie można pobrać tokenu po opuszczeniu strony.

  6. Zdefiniuj zmienne, które są używane do późniejszego konfigurowania zadań usługi Container Apps.

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

    Zastąp symbole zastępcze następującymi wartościami:

    Symbol zastępczy Wartość Komentarze
    <AZP_TOKEN> Wygenerowany token PAT usługi Azure DevOps.
    <ORGANIZATION_URL> Adres URL organizacji usługi Azure DevOps. Upewnij się, że na końcu adresu URL nie ma żadnych końcowych / elementów. Na przykład: https://dev.azure.com/myorg lub https://myorg.visualstudio.com.

Tworzenie obrazu kontenera agenta usługi Azure Pipelines

Aby utworzyć własnego agenta, należy utworzyć obraz kontenera, który uruchamia agenta. W tej sekcji skompilujesz obraz kontenera i wypchniesz go do rejestru kontenerów.

Uwaga

Obraz, który tworzysz w tym samouczku, zawiera podstawowego agenta samodzielnie hostowanego, który jest odpowiedni do uruchomienia jako zadanie Container Apps. Można dostosować tak, aby umieścić dodatkowe narzędzia lub zależności potrzebne do działania potoków.

  1. Wracając do swojego terminala, zdefiniuj nazwę obrazu kontenera i rejestru.

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

    Zastąp <CONTAINER_REGISTRY_NAME> unikatową nazwą przy tworzeniu rejestru kontenerów.

    Nazwy rejestru kontenerów muszą być unikatowe na platformie Azure i mieć długość od 5 do 50 znaków zawierających tylko cyfry i małe litery.

  2. Utwórz rejestr kontenerów.

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

  3. Plik Dockerfile do tworzenia obrazu modułu uruchamiającego jest dostępny w witrynie GitHub. Uruchom następujące polecenie, aby sklonować repozytorium i skompilować obraz kontenera w chmurze przy użyciu az acr build polecenia .

    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"

    Obraz jest teraz dostępny w rejestrze kontenerów.

Utwórz tymczasowego agenta hostowanego samodzielnie

Przed uruchomieniem własnego agenta w nowej puli agentów należy utworzyć tymczasowego agenta. Agent zastępczy zapewnia dostępność puli agentów. Potoki korzystające z puli agentów kończą się niepowodzeniem, gdy nie ma agenta zastępczego.

Możesz uruchomić zadanie ręczne, aby zarejestrować agenta zastępczego w trybie offline. Zadanie jest uruchamiane raz i można je usunąć. Agent zastępczy nie używa żadnych zasobów w usłudze Azure Container Apps ani Azure DevOps.

  1. Utwórz zadanie ręczne w środowisku Container Apps, które tworzy agenta zastępczego.

    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"

    W poniższej tabeli opisano kluczowe parametry używane w poleceniu .

    Parametr Opis
    --replica-timeout Maksymalny czas, przez jaki replika może działać.
    --replica-retry-limit Liczba ponownych prób ponawiania próby repliki, która zakończyła się niepowodzeniem.
    --replica-completion-count Liczba replik, które muszą zostać pomyślnie ukończone, aby wykonanie zadania mogło być uznane za pomyślne.
    --parallelism Liczba replik do uruchomienia na każde wykonanie zadania.
    --secrets Tajemnice do wykorzystania w pracy.
    --env-vars Zmienne środowiskowe do użycia dla zadania.
    --registry-server Serwer rejestracji kontenerów, który ma być użyty do zadania. W przypadku usługi Azure Container Registry polecenie automatycznie konfiguruje uwierzytelnianie.

    Ustawienie zmiennej środowiskowej AZP_PLACEHOLDER powoduje skonfigurowanie kontenera agenta do zarejestrowania jako agenta zastępczego w trybie offline bez uruchamiania zadania.

  2. Wykonaj zadanie ręczne, aby utworzyć agenta zastępczego.

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

  3. Wyświetl listę realizacji zadania, aby potwierdzić, że wykonanie zadania zostało utworzone i zakończone pomyślnie.

    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. Sprawdź, czy agent zastępczy został utworzony w usłudze Azure DevOps.

    1. W usłudze Azure DevOps przejdź do projektu.
    2. Wybierz ustawienia projektu>pul agenckich>container-apps>agentów.
    3. Upewnij się, że agent zastępczy o nazwie placeholder-agent jest wymieniony, a jego stan jest w trybie offline.

  5. Zadanie nie jest ponownie potrzebne. Można je usunąć.

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

Utwórz agenta samodzielnego w formie zadania sterowanego zdarzeniami

Teraz, gdy masz agenta zastępczego, możesz utworzyć własnego agenta. W tej sekcji utworzysz zadanie sterowane zdarzeniami, które uruchamia samodzielnego agenta, gdy potok zostanie wyzwolony.

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"

W poniższej tabeli opisano parametry reguły skalowania używane w poleceniu .

Parametr Opis
--min-executions Minimalna liczba wykonań zadań do uruchomienia na interwał sondowania.
--max-executions Maksymalna liczba wykonań zadań do uruchomienia w interwale sondowania.
--polling-interval Interwał sondowania, w którym ma być oceniana reguła skalowania.
--scale-rule-name Nazwa reguły skalowania.
--scale-rule-type Typ reguły skalowania do użycia. Aby dowiedzieć się więcej na temat usługi Azure Pipelines Scaler, zobacz dokumentację usługi KEDA.
--scale-rule-metadata Metadane reguły skalowania.
--scale-rule-auth Uwierzytelnianie dla reguły skalowania.

Konfiguracja reguły skalowania definiuje źródło zdarzeń do monitorowania. Reguły są oceniane w każdym interwale sondowania, aby określić, ile wykonań zadań należy uruchomić. Aby dowiedzieć się więcej, zobacz Ustawianie reguł skalowania.

Zadanie sterowane zdarzeniami jest teraz tworzone w środowisku usługi Container Apps.

Uruchom potok i zweryfikuj zadanie

Po skonfigurowaniu własnego zadania agenta można uruchomić potok i sprawdzić, czy działa prawidłowo.

  1. Na pasku nawigacyjnym po lewej stronie projektu Azure DevOps przejdź do sekcji Potoki.

  2. Wybierz Utwórz pipeline.

  3. Wybierz pozycję Azure Repos Git jako lokalizację kodu.

  4. Wybierz utworzone wcześniej repozytorium.

  5. Wybierz Potok startowy.

  6. W potoku YAML zmień pool z vmImage: ubuntu-latest na name: container-apps.

    pool:
  name: container-apps

  7. Wybierz pozycję Zapisz i uruchom.

    Pipeline działa i korzysta z zadania samodzielnie hostowanego agenta utworzonego w środowisku Container Apps.

  8. Wyświetl listę realizacji zadania, aby potwierdzić, że wykonanie zadania zostało utworzone i zakończone pomyślnie.

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

Napiwek

Masz problemy? Daj nam znać na GitHubie, tworząc zgłoszenie w repozytorium Azure Container Apps.

Czyszczenie zasobów

Po zakończeniu uruchom następujące polecenie, aby usunąć grupę zasobów zawierającą zasoby usługi Container Apps.

Uwaga

Następujące polecenie usuwa określoną grupę zasobów i wszystkie zawarte w niej zasoby. Jeśli zasoby spoza zakresu tego samouczka istnieją w określonej grupie zasobów, zostaną również usunięte.

az group delete \
    --resource-group $RESOURCE_GROUP

Aby usunąć repozytorium GitHub, zobacz Usuwanie repozytorium.

Następne kroki

Zadania usługi Container Apps