Udostępnij za pośrednictwem

Konfigurowanie potoku i aktualizacji wypychanych

  • Artykuł

W tym artykule dowiesz się, jak za pomocą interfejsu wiersza polecenia dla deweloperów platformy Azure (azd) wypychać zmiany szablonu za pośrednictwem potoku ciągłej integracji/ciągłego wdrażania, takiego jak GitHub Actions lub Azure DevOps. W tym przykładzie użyjesz aplikacji internetowej React z interfejsem API Node.js i bazą danych MongoDB na platformie Azure , ale możesz zastosować zasady, które poznasz w tym artykule, do dowolnego z szablonów interfejsu wiersza polecenia dla deweloperów platformy Azure.

Uwaga

Polecenie azd pipeline config jest nadal w wersji beta. Przeczytaj więcej na temat obsługi funkcji alfa i beta na stronie strategii obsługi wersji funkcji i wydania.

Wymagania wstępne

azd szablony mogą lub nie mogą zawierać domyślnej funkcji GitHub Actions i/lub pliku konfiguracji potoku usługi Azure DevOps o nazwie azure-dev.yml, który jest wymagany do skonfigurowania ciągłej integracji/ciągłego wdrażania. Ten plik konfiguracji aprowizuje zasoby platformy Azure i wdróż kod w gałęzi głównej. Możesz znaleźć następujące informacje azure-dev.yml:

  • W przypadku funkcji GitHub Actions: w .github/workflows katalogu.
  • W przypadku .azdo/pipelines usługi Azure DevOps: w katalogu .

Możesz użyć pliku konfiguracji zgodnie z potrzebami lub zmodyfikować go zgodnie z potrzebami.

Uwaga

Przed wywołaniem azd pipeline configszablonu upewnij się, że szablon ma definicję potoku (azure-dev.yaml). azd program nie tworzy automatycznie tego pliku. Zobacz Tworzenie definicji potoku dla azd poniżej.

azd pipeline config Użyj polecenia , aby skonfigurować potok ciągłej integracji/ciągłego wdrażania, który obsługuje następujące zadania:

  • Tworzy i konfiguruje jednostkę usługi dla aplikacji w subskrypcji platformy Azure. Użytkownik musi mieć Owner rolę lub Contributor + User Access Administrator role w ramach subskrypcji platformy Azure, aby umożliwić azd tworzenie i przypisywanie ról do jednostki usługi.
  • Procedura tworzenia i konfigurowania repozytorium GitHub lub Azure DevOps oraz zatwierdzania do niego kodu projektu. Możesz również użyć istniejącego repozytorium.
  • Tworzy bezpieczne połączenie między platformą Azure i repozytorium.
  • Uruchamia akcję Usługi GitHub po zaewidencjonowyniu pliku przepływu pracy.

Aby uzyskać bardziej szczegółową kontrolę nad tym procesem lub jeśli użytkownik nie ma wymaganych ról, możesz ręcznie skonfigurować potok.

Wybierz preferowanego dostawcę potoku, aby kontynuować:

Autoryzowanie usługi GitHub do wdrażania na platformie Azure

Aby skonfigurować przepływ pracy, musisz autoryzować jednostkę usługi do wdrożenia na platformie Azure w Twoim imieniu z akcji usługi GitHub. azd Tworzy jednostkę usługi i poświadczenia federacyjne.

  1. Uruchom następujące polecenie, aby utworzyć jednostkę usługi platformy Azure i skonfigurować potok:

    azd pipeline config

    To polecenie opcjonalnie tworzy repozytorium GitHub i wypycha kod do nowego repozytorium.

    Uwaga

    Domyślnie azd pipeline config używa protokołu OpenID Connect (OIDC), nazywanego poświadczeniami federacyjnymi . Jeśli nie chcesz używać protokołu OIDC, uruchom polecenie azd pipeline config --auth-type client-credentials.

    Poświadczenia OIDC/federacyjne nie są obsługiwane w przypadku programu Terraform.

    Dowiedz się więcej o obsłudze funkcji OIDC w systemie azd.

  2. Podaj żądane informacje w witrynie GitHub.

  3. Po wyświetleniu monitu o zatwierdzenie i wypchnięcie lokalnych zmian w celu uruchomienia nowego uruchomienia funkcji GitHub Actions określ wartość y.

  4. W oknie terminalu wyświetl wyniki azd pipeline config polecenia. Polecenie azd pipeline config wyświetli nazwę repozytorium GitHub dla projektu.

  5. Za pomocą przeglądarki otwórz repozytorium GitHub dla projektu.

  6. Wybierz pozycję Akcje , aby wyświetlić uruchomiony przepływ pracy.

    Zrzut ekranu przedstawiający uruchomiony przepływ pracy usługi GitHub.

Wprowadzanie i wypychanie zmiany kodu

  1. W katalogu projektu /src/web/src/layout otwórz plik header.tsx.

  2. Znajdź wiersz <Text variant="xLarge">ToDo</Text>.

  3. Zmień literał ToDo na myTodo.

  4. Zapisz plik.

  5. Zatwierdź wprowadzone zmiany. Zatwierdzenie zmiany powoduje uruchomienie potoku akcji usługi GitHub w celu wdrożenia aktualizacji.

    Zrzut ekranu przedstawiający kroki wymagane do wprowadzenia i zatwierdzenia zmiany w pliku testowym.

  6. Za pomocą przeglądarki otwórz repozytorium GitHub projektu, aby wyświetlić oba te elementy:

    • Zatwierdzenie
    • Zatwierdzanie z konfigurowanych funkcji GitHub Actions.

    Zrzut ekranu przedstawiający zatwierdzoną zmianę w usłudze GitHub.

  7. Wybierz pozycję Akcje , aby wyświetlić aktualizację testu odzwierciedlona w przepływie pracy.

    Zrzut ekranu przedstawiający przepływ pracy usługi GitHub uruchomiony po aktualizacji testowej.

  8. Odwiedź adres URL frontonu internetowego, aby sprawdzić aktualizację.

azd jako akcja usługi GitHub

Dodaj azd jako akcję usługi GitHub. Ta akcja spowoduje zainstalowanie azdelementu . Aby go użyć, możesz dodać następujące elementy do :.github\workflows\azure-dev.yml

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - name: Install azd
         uses: Azure/setup-azd@v0.1.0

Czyszczenie zasobów

Jeśli nie potrzebujesz już zasobów platformy Azure utworzonych w tym artykule, uruchom następujące polecenie:

azd down

Funkcje zaawansowane

Możesz rozszerzyć azd pipeline config polecenie dla określonych scenariuszy lub wymagań szablonu, zgodnie z opisem w poniższych sekcjach.

Dodatkowe wpisy tajne lub zmienne

Domyślnie azd ustawia zmienne i wpisy tajne dla potoku. Na przykład azd pipeline config polecenie tworzy zmienną subscription id, environment name i region jako zmienne potoku za każdym razem, gdy jest wykonywany. Następnie definicja potoku odwołuje się do tych zmiennych:

env:
   AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
   AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
   AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
   AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
   AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}

Po uruchomieniu azd potoku pobiera wartości ze środowiska, które są mapowane na zmienne i wpisy tajne. W zależności od szablonu mogą istnieć ustawienia, które można kontrolować przy użyciu zmiennych środowiskowych. Na przykład zmienna środowiskowa o nazwie KEY_VAULT_NAME może zostać ustawiona tak, aby zdefiniować nazwę zasobu usługi Key Vault w ramach infrastruktury szablonu. W takich przypadkach można zdefiniować listę zmiennych i wpisów tajnych przy użyciu szablonu azure.yaml. Rozważmy na przykład następującą azure.yaml konfigurację:

pipeline:
  variables:
    - KEY_VAULT_NAME
    - STORAGE_NAME
  secrets:
    - CONNECTION_STRING

W przypadku tej konfiguracji sprawdza, azd czy którakolwiek ze zmiennych lub wpisów tajnych ma wartość niepustą w środowisku. azd Następnie tworzy zmienną lub wpis tajny dla potoku przy użyciu nazwy klucza w konfiguracji jako nazwy zmiennej lub wpisu tajnego, a wartość nieciągniowa ze środowiska dla wartości.

Definicja azure-dev.yaml potoku może następnie odwoływać się do zmiennych lub wpisów tajnych:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      KEY_VAULT_NAME: ${{ variables.KEY_VAULT_NAME }}
      STORAGE_NAME: ${{ variables.STORAGE_NAME }}
      CONNECTION_STRING: ${{ secrets.CONNECTION_STRING }}

Uwaga

Aby zresetować wartości potoku, należy uruchomić polecenie azd pipeline config po zaktualizowaniu listy wpisów tajnych lub zmiennych w azure.yaml pliku azd.

Parametry infrastruktury

Rozważmy następujący przykład bicepu:

@secure()
param BlobStorageConnection string

Parametr BlobStorageConnection nie ma ustawionej wartości domyślnej, dlatego azd monituje użytkownika o wprowadzenie wartości. Nie ma jednak interakcyjnego monitu podczas ciągłej integracji/ciągłego wdrażania. azd Musi zażądać wartości parametru podczas uruchamiania azd pipeline configpolecenia , zapisać wartość w potoku, a następnie pobrać wartość ponownie po uruchomieniu potoku.

azd używa wpisu tajnego potoku wywoływanego AZD_INITIAL_ENVIRONMENT_CONFIG do automatycznego zapisywania i ustawiania wartości wszystkich wymaganych parametrów w potoku. W potoku musisz odwoływać się tylko do tego wpisu tajnego:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}

Po uruchomieniu azd potoku przyjmuje wartości parametrów z wpisu tajnego, co eliminuje konieczność wyświetlenia interakcyjnego monitu.

Uwaga

W przypadku dodania nowego parametru należy ponownie uruchomić azd pipeline config polecenie .

Tworzenie definicji potoku

azd Jeśli szablon nie ma jeszcze pliku definicji potoku ciągłej integracji/ciągłego wdrażania, możesz go utworzyć samodzielnie. Definicja potoku ciągłej integracji/ciągłego wdrażania zawiera zazwyczaj 4 główne sekcje:

  • wyzwalacz
  • uprawnienia
  • system operacyjny lub pula
  • kroki do uruchomienia

W poniższych przykładach pokazano, jak utworzyć plik definicji i powiązane konfiguracje dla funkcji GitHub Actions i usługi Azure Pipelines.

Uruchomienie azd funkcji GitHub Actions wymaga następujących konfiguracji:

  • Udzielanie id-token: write zakresów dostępu i contents: read uzyskiwanie do tego dostępu.
  • Zainstaluj akcję azd, chyba że używasz obrazu platformy Docker, w którym azd jest już zainstalowany.

Możesz użyć następującego szablonu jako punktu wyjścia dla własnej definicji potoku:

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

# Set this permission if you are using a Federated Credential.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # azd build-in variables.
    # This variables are always set by `azd pipeline config`
    # You can set them as global env (apply to all steps) or you can add them to individual steps' environment
    env:
      AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
      AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
      ## Define the additional variables or secrets that are required globally (provision and deploy)
      # ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
      # ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}      
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # using the install-azd action
      - name: Install azd
        uses: Azure/setup-azd@v1.0.0

      # # If you want to use azd-daily build, or install it from a PR, you can remove previous step and
      # # use the next one:
      # - name: Install azd - daily or from PR
      #  # Update this scrip based on the OS - pool of your pipeline. This example is for a linux pipeline installing daily build
      #  run: curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --version daily
      #  shell: pwsh

      # azd set up Federated Credential by default. You can remove this step if you are using Client Credentials
      - name: Log in with Azure (Federated Credentials)
        if: ${{ env.AZURE_CLIENT_ID != '' }}
        run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"
        shell: pwsh

      ## If you set up your pipeline with Client Credentials, remove previous step and uncomment this one
      # - name: Log in with Azure (Client Credentials)
      #   if: ${{ env.AZURE_CREDENTIALS != '' }}
      #   run: |
      #     $info = $Env:AZURE_CREDENTIALS | ConvertFrom-Json -AsHashtable;
      #     Write-Host "::add-mask::$($info.clientSecret)"

      #     azd auth login `
      #       --client-id "$($info.clientId)" `
      #       --client-secret "$($info.clientSecret)" `
      #       --tenant-id "$($info.tenantId)"
      #   shell: pwsh
      #   env:
      #     AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Provision Infrastructure
        run: azd provision --no-prompt
        env:
         #  # uncomment this if you are using infrastructure parameters
         #  AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}
         ## Define the additional variables or secrets that are required only for provision 
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}

      - name: Deploy Application
        run: azd deploy --no-prompt
        env:
         ## Define the additional variables or secrets that are required only for deploy
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}