Udostępnij za pośrednictwem

Samouczek: wdrażanie własnych modułów uruchamiających ciągłą integrację/ciągłe wdrażanie za pomocą zadań usługi Azure Container Apps

  • Artykuł

Funkcja GitHub Actions i usługa Azure Pipelines umożliwiają uruchamianie przepływów pracy ciągłej integracji/ciągłego wdrażania za pomocą własnych modułów uruchamiających i agentów. Możesz uruchamiać własne moduły uruchamiające i agentów przy użyciu zadań usługi Azure Container Apps opartych na zdarzeniach.

Samodzielnie hostowane moduły uruchamiające moduły uruchamiające przepływy pracy, które wymagają dostępu do zasobów lokalnych lub narzędzi, które nie są dostępne dla modułu uruchamiającego hostowane w chmurze. Na przykład moduł uruchamiający samodzielnie hostowany w zadaniu usługi Container Apps umożliwia przepływowi pracy uzyskiwanie dostępu do zasobów w sieci wirtualnej zadania, która nie jest dostępna dla modułu uruchamiającego hostowane w chmurze.

Uruchamianie własnych modułów uruchamianych jako zadania sterowane zdarzeniami umożliwia korzystanie z bezserwerowego charakteru 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.

  • Tworzenie środowiska usługi Container Apps w celu wdrożenia własnego modułu uruchamiającego
  • Tworzenie repozytorium GitHub na potrzeby uruchamiania przepływu pracy korzystającego z własnego modułu uruchamiającego moduł uruchamiający
  • Tworzenie obrazu kontenera uruchamiającego moduł uruchamiający funkcję GitHub Actions
  • Wdrażanie modułu uruchamiającego jako zadania w środowisku usługi 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 w własnym module uruchamiającym. Aby uzyskać więcej informacji, zobacz Zabezpieczenia własnego modułu uruchamiającego moduły uruchamiającego.

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

  • 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
  • Wdrażanie agenta jako zadania w środowisku usługi Container Apps
  • Utwórz potok, który używa własnego agenta i sprawdź, czy jest uruchomiony

Ważne

Agenci self-hosted są zalecane 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

Aplikacje kontenerów i zadania nie obsługują uruchamiania platformy Docker w kontenerach. Wszystkie kroki w przepływach pracy używających poleceń platformy Docker kończą się niepowodzeniem po uruchomieniu własnego modułu uruchamiającego lub agenta w zadaniu usługi Container Apps.

Wymagania wstępne

  • Konto platformy Azure: jeśli go nie masz, możesz utworzyć je bezpłatnie.

  • Interfejs wiersza polecenia platformy Azure: zainstaluj interfejs wiersza polecenia platformy Azure.

Zapoznaj się z ograniczeniami zadań, aby zapoznać się z listą 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 az containerapp poleceń w interfejsie wiersza polecenia platformy Azure lub poleceniach cmdlet z modułu Az.App w programie Azure 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, po zainstalowaniu bieżącego rozszerzenia lub modułu Microsoft.App , zarejestruj przestrzenie nazw i 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 wewnętrznym ś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.
    Zainicjuj to repozytorium za pomocą polecenia Wybierz pozycję Dodaj plik README.

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

  3. Kliknij przycisk Create repository (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 jest uruchamiany w module uruchamiającym usługę ubuntu-latest GitHub i wyświetla komunikat w konsoli programu . Później zastąpisz moduł uruchamiający hostowany w usłudze GitHub własnym modułem uruchamiającym.

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 uruchamia się moduł uruchamiający, token jest używany do generowania tokenu w celu zarejestrowania modułu uruchamiającego w usłudze GitHub. Klucz dostępu jest również używany przez regułę skalowania modułu uruchamiającego akcje GitHub Actions do monitorowania kolejki przepływu pracy repozytorium i uruchamiania modułów uruchamianych 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. W obszarze Osobiste tokeny dostępu wybierz pozycję Szczegółowe tokeny.

  4. Wybierz pozycję Generuj nowy token.

  5. Na ekranie Nowy szczegółowe osobiste tokeny 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 pozycję Tylko wybierz repozytoria i wybierz 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>"

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

    Symbol zastępczy Wartość
    <GITHUB_PAT> Wygenerowany identyfikator PAT usługi 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.

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

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

Uwaga

Obraz kompilujący w tym samouczku zawiera podstawowy własny moduł uruchamiający, który jest odpowiedni do uruchamiania jako zadanie usługi 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> ciąg unikatową nazwą tworzenia 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.github" \
    "https://github.com/Azure-Samples/container-apps-ci-cd-runner-tutorial.git"

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

Wdrażanie własnego modułu uruchamiającego jako zadania

Teraz możesz utworzyć zadanie, które używa do używania 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ły skalowania github-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 -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"

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

    Parametr Opis
    --replica-timeout Maksymalny czas trwania repliki może zostać wykonany.
    --replica-retry-limit Liczba ponownych prób ponawiania próby repliki, która zakończyła się niepowodzeniem.
    --replica-completion-count Liczba replik do pomyślnego ukończenia przed pomyślnym wykonaniem zadania zostanie uznana za pomyślną.
    --parallelism Liczba replik do uruchomienia na 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 modułu skalowania modułu uruchamiającego usługę GitHub, zobacz dokumentację usługi 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 Wpisy tajne do użycia w zadaniu.
    --env-vars Zmienne środowiskowe do użycia dla zadania.
    --registry-server Serwer rejestru kontenerów do użycia dla zadania. W przypadku usługi Azure Container Registry polecenie automatycznie konfiguruje uwierzytelnianie.

    Konfiguracja reguły skalowania definiuje źródło zdarzeń do monitorowania. Jest obliczana dla każdego interwału sondowania i określa liczbę wykonań zadań do wyzwolenia. 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 wykonanie zadania zostanie uruchomione, a przepływ pracy zostanie ukończony wkrótce po.

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

  7. Wyświetl listę wykonań zadania w celu potwierdzenia utworzenia i pomyślnego wykonania zadania.

    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

Do wykonania potoku 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 obszarze nawigacji bocznej wybierz pozycję 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ć własny moduł uruchamiający.

  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 Pule agentów usługi Azure DevOps.

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

    Ustawienie Wartość
    Pula do połączenia Wybierz Nowy.
    Typ puli Wybierz pozycję Self-hosted (Self-hosted).
    Nazwa/nazwisko Wprowadź ciąg container-apps.
    Udzielanie uprawnień 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ć własny moduł uruchamiający, należy utworzyć osobisty token dostępu (PAT) w usłudze Azure DevOps. Token dostępu jest używany do uwierzytelniania modułu uruchamiającego za pomocą usługi Azure DevOps. Jest on również używany przez regułę skalowania w celu określenia liczby oczekujących przebiegów potoku i wyzwalania nowych wykonań 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/nazwisko Wprowadź nazwę tokenu.
    Organizacja Wybierz wybraną lub utworzoną wcześniej organizację.
    Zakresy Wybierz pozycję Zdefiniowane niestandardowe.
    Pokaż wszystkie zakresy Wybierz pozycję Pokaż wszystkie zakresy.
    Pule agentów (odczyt i zarządzanie) Wybierz pozycję 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"
REGISTRATION_TOKEN_API_URL="<YOUR_REGISTRATION_TOKEN_API_URL>"

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

    Symbol zastępczy Wartość Komentarze
    <AZP_TOKEN> Wygenerowany identyfikator 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.
    <YOUR_REGISTRATION_TOKEN_API_URL> Adres URL interfejsu API tokenu rejestracji w pliku entrypoint.sh . Na przykład "https://myapi.example.com/get-token"

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 własnego agenta, który jest odpowiedni do uruchamiania jako zadanie usługi Container Apps. Można dostosować go tak, aby zawierał dodatkowe narzędzia lub zależności wymagane przez potoki.

  1. W terminalu 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> ciąg unikatową nazwą tworzenia 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.

Tworzenie zastępczego własnego agenta

Przed uruchomieniem własnego agenta w nowej puli agentów należy utworzyć agenta zastępczego. 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 trwania repliki może zostać wykonany.
    --replica-retry-limit Liczba ponownych prób ponawiania próby repliki, która zakończyła się niepowodzeniem.
    --replica-completion-count Liczba replik do pomyślnego ukończenia przed pomyślnym wykonaniem zadania zostanie uznana za pomyślną.
    --parallelism Liczba replik do uruchomienia na wykonanie zadania.
    --secrets Wpisy tajne do użycia w zadaniu.
    --env-vars Zmienne środowiskowe do użycia dla zadania.
    --registry-server Serwer rejestru kontenerów do użycia dla 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 trybu 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ę wykonań zadania w celu potwierdzenia utworzenia i pomyślnego wykonania zadania.

    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 pozycję Project settings Agent pools>container-apps Agents (Agenci kontenera aplikacji>) w ustawieniach>projektu.
    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"

Tworzenie własnego agenta jako 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 własnego agenta po wyzwoleniu potoku.

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. Jest obliczana dla każdego interwału sondowania i określa liczbę wykonań zadań do wyzwolenia. Aby dowiedzieć się więcej, zobacz Ustawianie reguł skalowania.

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

Uruchamianie potoku i weryfikowanie zadania

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

  1. W obszarze nawigacji po lewej stronie projektu usługi Azure DevOps przejdź do pozycji Potoki.

  2. Wybierz pozycję Utwórz potok.

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

  4. Wybierz utworzone wcześniej repozytorium.

  5. Wybierz pozycję Potok startowy.

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

    pool:
  name: container-apps

  7. Wybierz pozycję Zapisz i uruchom.

    Potok jest uruchamiany i używa zadania własnego agenta utworzonego w środowisku Container Apps.

  8. Wyświetl listę wykonań zadania w celu potwierdzenia utworzenia i pomyślnego wykonania zadania.

    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? Poinformuj nas o usłudze GitHub, otwierając problem w repozytorium usługi 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