Używanie ciągłej integracji/ciągłego wdrażania usługi Azure Spring Apps z funkcją GitHub Actions

  • Artykuł

Uwaga

Azure Spring Apps to nowa nazwa usługi Azure Spring Cloud. Mimo że usługa ma nową nazwę, stara nazwa będzie widoczna w niektórych miejscach przez pewien czas, ponieważ pracujemy nad aktualizowaniem zasobów, takich jak zrzuty ekranu, filmy wideo i diagramy.

Ten artykuł dotyczy: ✔️ Podstawowa/Standardowa ✔️ Enterprise

W tym artykule pokazano, jak utworzyć przepływ pracy ciągłej integracji/ciągłego wdrażania dla usługi Azure Spring Apps za pomocą funkcji GitHub Actions.

Funkcja GitHub Actions obsługuje zautomatyzowany przepływ pracy cyklu życia tworzenia oprogramowania. Za pomocą funkcji GitHub Actions dla usługi Azure Spring Apps można tworzyć przepływy pracy w repozytorium w celu kompilowania, testowania, tworzenia pakietów, wydawania i wdrażania na platformie Azure.

Wymagania wstępne

Ten przykład wymaga interfejsu wiersza polecenia platformy Azure.

Konfigurowanie repozytorium GitHub i uwierzytelnianie

Aby autoryzować akcję logowania platformy Azure, potrzebujesz poświadczeń jednostki usługi platformy Azure. Aby uzyskać poświadczenia platformy Azure, wykonaj następujące polecenia na komputerze lokalnym:

az login
az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID> \
    --json-auth

Aby uzyskać dostęp do określonej grupy zasobów, możesz zmniejszyć zakres:

az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
    --json-auth

Polecenie powinno zwrócić obiekt JSON:

{
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
}

W tym przykładzie użyto przykładu steeltoe w usłudze GitHub. Utwórz rozwidlenie repozytorium, otwórz stronę repozytorium GitHub rozwidlenia i wybierz kartę Ustawienia. Otwórz menu Wpisy tajne i wybierz pozycję Nowy wpis tajny:

Screenshot of the GitHub Actions secrets and variables page with the New repository secret button highlighted.

Ustaw nazwę wpisu tajnego na AZURE_CREDENTIALS i jego wartość na ciąg JSON znaleziony pod nagłówkiem Konfigurowanie repozytorium GitHub i uwierzytelnianie.

Screenshot of the GitHub Actions secrets / New secret page.

Możesz również uzyskać poświadczenia logowania platformy Azure z usługi Key Vault w funkcji GitHub Actions, jak wyjaśniono w artykule Uwierzytelnianie platformy Azure Spring za pomocą usługi Key Vault w funkcji GitHub Actions.

Aprowizuj wystąpienie usługi

Aby aprowizować wystąpienie usługi Azure Spring Apps, uruchom następujące polecenia przy użyciu interfejsu wiersza polecenia platformy Azure.

az extension add --name spring
az group create \
    --name <resource-group-name> \
    --location eastus 
az spring create \
    --resource-group <resource-group-name> \
    --name <service-instance-name> 
az spring config-server git set \
    --name <service-instance-name> \
    --uri https://github.com/Azure-Samples/azure-spring-apps-samples \
    --label main \
    --search-paths steeltoe-sample/config

Tworzenie przepływu pracy

Przepływ pracy jest definiowany przy użyciu następujących opcji.

Przygotowywanie do wdrożenia przy użyciu interfejsu wiersza polecenia platformy Azure

Polecenie az spring app create nie jest obecnie idempotentne. Po uruchomieniu go raz zostanie wyświetlony błąd, jeśli ponownie uruchomisz to samo polecenie. Zalecamy ten przepływ pracy w istniejących aplikacjach i wystąpieniach usługi Azure Spring Apps.

Do przygotowania użyj następujących poleceń interfejsu wiersza polecenia platformy Azure:

az config set defaults.group=<service-group-name>
az config set defaults.spring=<service-instance-name>
az spring app create --name planet-weather-provider
az spring app create --name solar-system-weather

Wdrażanie za pomocą interfejsu wiersza polecenia platformy Azure bezpośrednio

Utwórz plik .github/workflows/main.yml w repozytorium z następującą zawartością. Zastąp <nazwę> grupy zasobów i <nazwę> usługi poprawnymi wartościami.

name: Steeltoe-CD

# Controls when the action runs. Triggers the workflow on push or pull request
# events but only for the main branch
on:
  push:
    branches: [ main]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job runs on
    runs-on: ubuntu-latest
    env:
      working-directory: ./steeltoe-sample
      resource-group-name: <your resource group name>
      service-name: <your service name>

    # Supported .NET Core version matrix.
    strategy:
      matrix:
        dotnet: [ '3.1.x' ]

    # Steps represent a sequence of tasks that is executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Set up .NET Core 3.1 SDK
      - uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ matrix.dotnet }}

      # Set credential for az login
      - uses: azure/login@v1.1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: install Azure CLI extension
        run: |
          az extension add --name spring --yes

      - name: Build and package planet-weather-provider app
        working-directory: ${{env.working-directory}}/src/planet-weather-provider
        run: |
          dotnet publish
          az spring app deploy -n planet-weather-provider --runtime-version NetCore_31 --main-entry Microsoft.Azure.SpringCloud.Sample.PlanetWeatherProvider.dll --artifact-path ./publish-deploy-planet.zip -s ${{ env.service-name }} -g ${{ env.resource-group-name }}
      - name: Build solar-system-weather app
        working-directory: ${{env.working-directory}}/src/solar-system-weather
        run: |
          dotnet publish
          az spring app deploy -n solar-system-weather --runtime-version NetCore_31 --main-entry Microsoft.Azure.SpringCloud.Sample.SolarSystemWeather.dll --artifact-path ./publish-deploy-solar.zip -s ${{ env.service-name }} -g ${{ env.resource-group-name }}

Konfigurowanie repozytorium GitHub i uwierzytelnianie

Aby autoryzować akcję logowania platformy Azure, potrzebujesz poświadczeń jednostki usługi platformy Azure. Aby uzyskać poświadczenia platformy Azure, wykonaj następujące polecenia na komputerze lokalnym:

az login
az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID> \
    --json-auth

Aby uzyskać dostęp do określonej grupy zasobów, możesz zmniejszyć zakres:

az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
    --json-auth

Polecenie powinno zwrócić obiekt JSON:

{
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
}

W tym przykładzie użyto przykładu PiggyMetrics w usłudze GitHub. Utwórz rozwidlenie przykładu, usuń zaznaczenie pola wyboru Kopiuj tylko gałąź platformy Azure, otwórz stronę repozytorium GitHub i wybierz kartę Ustawienia. Otwórz menu Wpisy tajne i wybierz pozycję Dodaj nowy wpis tajny:

Screenshot of the GitHub Actions secrets and variables page with the New repository secret button highlighted.

Ustaw nazwę wpisu tajnego na AZURE_CREDENTIALS i jego wartość na ciąg JSON znaleziony pod nagłówkiem Konfigurowanie repozytorium GitHub i uwierzytelnianie.

Screenshot of the GitHub Actions secrets / New secret page.

Możesz również uzyskać poświadczenia logowania platformy Azure z usługi Key Vault w funkcji GitHub Actions, jak wyjaśniono w artykule Uwierzytelnianie platformy Azure Spring za pomocą usługi Key Vault w funkcji GitHub Actions.

Aprowizuj wystąpienie usługi

Aby aprowizować wystąpienie usługi Azure Spring Apps, uruchom następujące polecenia przy użyciu interfejsu wiersza polecenia platformy Azure.

az extension add --name spring
az group create --location eastus --name <resource group name>
az spring create -n <service instance name> -g <resource group name>
az spring config-server git set -n <service instance name> --uri https://github.com/xxx/piggymetrics --label config

Kompleksowe przykładowe przepływy pracy

W poniższych przykładach przedstawiono typowe scenariusze użycia.

Wdrażanie

W poniższych sekcjach przedstawiono różne opcje wdrażania aplikacji.

Do środowiska produkcyjnego

Usługa Azure Spring Apps obsługuje wdrażanie we wdrożeniach z utworzonymi artefaktami (na przykład PLIK JAR lub PLIK ZIP platformy .NET Core) lub archiwum kodu źródłowego.

Poniższy przykład jest wdrażany w domyślnym wdrożeniu produkcyjnym w usłudze Azure Spring Apps przy użyciu pliku JAR skompilowanego przez narzędzie Maven. Ten przykład jest jedynym możliwym scenariuszem wdrażania w przypadku korzystania z jednostki SKU w warstwie Podstawowa:

Uwaga

Wzorzec wyszukiwania pakietów powinien zwracać tylko dokładnie jeden pakiet. Jeśli zadanie kompilacji generuje wiele pakietów JAR, takich jak sources.jar i javadoc.jar, należy uściślić wzorzec wyszukiwania, aby był zgodny tylko z artefaktem binarnym aplikacji.

name: AzureSpringApps
on: push
env:
  ASC_PACKAGE_PATH: ${{ github.workspace }}
  AZURE_SUBSCRIPTION: <azure subscription name>

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    name: deploy to production with artifact
    steps:
      - name: Checkout GitHub Action
        uses: actions/checkout@v2

      - name: Set up Java 11
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '11'

      - name: maven build, clean
        run: |
          mvn clean package

      - name: Login via Azure CLI
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: deploy to production with artifact
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: Deploy
          service-name: <service instance name>
          app-name: <app name>
          use-staging-deployment: false
          package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar

Poniższy przykład jest wdrażany w domyślnym wdrożeniu produkcyjnym w usłudze Azure Spring Apps przy użyciu kodu źródłowego.

name: AzureSpringApps
on: push
env:
  ASC_PACKAGE_PATH: ${{ github.workspace }}
  AZURE_SUBSCRIPTION: <azure subscription name>

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    name: deploy to production with source code
    steps:
      - name: Checkout GitHub Action
        uses: actions/checkout@v2

      - name: Login via Azure CLI
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: deploy to production step with source code
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: deploy
          service-name: <service instance name>
          app-name: <app name>
          use-staging-deployment: false
          package: ${{ env.ASC_PACKAGE_PATH }}

Poniższy przykład jest wdrażany w domyślnym wdrożeniu produkcyjnym w usłudze Azure Spring Apps przy użyciu kodu źródłowego w planie Enterprise. Możesz określić, który konstruktor ma być używany do wdrażania akcji przy użyciu builder opcji .

name: AzureSpringApps
on: push
env:
  ASC_PACKAGE_PATH: ${{ github.workspace }}
  AZURE_SUBSCRIPTION: <azure subscription name>

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    name: deploy to production with source code
    steps:
      - name: Checkout GitHub Action
        uses: actions/checkout@v2

      - name: Login via Azure CLI
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: deploy to production step with source code in the Enterprise plan
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: deploy
          service-name: <service instance name>
          app-name: <app name>
          use-staging-deployment: false
          package: ${{ env.ASC_PACKAGE_PATH }}
          builder: <builder>

Poniższy przykład jest wdrażany w domyślnym wdrożeniu produkcyjnym w usłudze Azure Spring Apps przy użyciu istniejącego obrazu kontenera.

name: AzureSpringApps
on: push
env:
  ASC_PACKAGE_PATH: ${{ github.workspace }}
  AZURE_SUBSCRIPTION: <azure subscription name>

jobs:
  deploy_to_production:
    runs-on: ubuntu-latest
    name: deploy to production with source code
    steps:
      - name: Checkout GitHub Action
        uses: actions/checkout@v2

      - name: Login via Azure CLI
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy Custom Image
        uses: Azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: deploy
          service-name: <service instance name>
          app-name: <app name>
          deployment-name: <deployment name>
          container-registry: <your container image registry>
          registry-username: ${{ env.REGISTRY_USERNAME }}
          registry-password: ${{ secrets.REGISTRY_PASSWORD }}
          container-image: <your image tag>

Podczas wdrażania można osiągnąć większą funkcjonalność przy użyciu większej liczby argumentów. Aby uzyskać więcej informacji, zobacz sekcję Argumenty akcji usługi GitHub na potrzeby wdrażania w usłudze Azure Spring Apps.

Niebieski-zielony

Poniższe przykłady są wdrażane w istniejącym wdrożeniu przejściowym. To wdrożenie nie odbiera ruchu produkcyjnego, dopóki nie zostanie ustawione jako wdrożenie produkcyjne. Możesz ustawić wartość use-staging-deployment true, aby znaleźć wdrożenie przejściowe automatycznie lub po prostu przydzielić określoną nazwę wdrożenia. Skupiamy się tylko na spring-apps-deploy akcji i pozostawiamy prace przygotowawcze w pozostałej części artykułu.

# environment preparation configurations omitted
    steps:
      - name: blue green deploy step use-staging-deployment
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: deploy
          service-name: <service instance name>
          app-name: <app name>
          use-staging-deployment: true
          package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar

# environment preparation configurations omitted
    steps:
      - name: blue green deploy step with deployment-name
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: deploy
          service-name: <service instance name>
          app-name: <app name>
          deployment-name: staging
          package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar

Aby uzyskać więcej informacji na temat wdrożeń niebiesko-zielonych, w tym alternatywnego podejścia, zobacz Blue-green deployment strategies (Strategie wdrażania blue-green).

Ustawianie wdrożenia produkcyjnego

W poniższym przykładzie ustawiono bieżące wdrożenie przejściowe jako produkcyjne, co skutecznie zamienia, które wdrożenie odbiera ruch produkcyjny.

# environment preparation configurations omitted
    steps:
      - name: set production deployment step
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: set-production
          service-name: <service instance name>
          app-name: <app name>
          use-staging-deployment: true

Usuwanie wdrożenia przejściowego

Akcja Delete Staging Deployment umożliwia usunięcie wdrożenia, które nie odbiera ruchu produkcyjnego. To usunięcie zwalnia zasoby używane przez to wdrożenie i sprawia, że miejsce na nowe wdrożenie przejściowe:

# environment preparation configurations omitted
    steps:
      - name: Delete staging deployment step
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: delete-staging-deployment
          service-name: <service instance name>
          app-name: <app name>

Tworzenie lub aktualizowanie kompilacji (tylko plan enterprise)

Poniższy przykład tworzy lub aktualizuje zasób kompilacji w planie Enterprise:

# environment preparation configurations omitted
    steps:
      - name: Create or update build
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: build
          service-name: <service instance name>
          build-name: <build name>
          package: ${{ env.ASC_PACKAGE_PATH }}
          builder: <builder>

Usuwanie kompilacji (tylko plan przedsiębiorstwa)

Poniższy przykład usuwa zasób kompilacji w planie Enterprise:

# environment preparation configurations omitted
    steps:
      - name: Delete build
        uses: azure/spring-apps-deploy@v1
        with:
          azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
          action: delete-build
          service-name: <service instance name>
          build-name: <build name>

Wdrażanie za pomocą wtyczki Maven

Inną opcją jest użycie wtyczki Maven do wdrażania pliku Jar i aktualizowania ustawień aplikacji. Polecenie mvn azure-spring-apps:deploy jest idempotentne i automatycznie tworzy aplikacje w razie potrzeby. Nie musisz wcześniej tworzyć odpowiednich aplikacji.

name: AzureSpringApps
on: push

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

    - uses: actions/checkout@main

    - name: Set up Java 11
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '11'

    - name: maven build, clean
      run: |
        mvn clean package -DskipTests

    # Maven plugin can cosume this authentication method automatically
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    # Maven deploy, make sure you have correct configurations in your pom.xml
    - name: deploy to Azure Spring Apps using Maven
      run: |
        mvn azure-spring-apps:deploy

Uruchom przepływ pracy

Funkcja GitHub Actions powinna być włączana automatycznie po wypchnięciu pliku .github/workflow/main.yml do usługi GitHub. Akcja jest wyzwalana po wypchnięciu nowego zatwierdzenia. Jeśli utworzysz ten plik w przeglądarce, akcja powinna być już uruchomiona.

Aby sprawdzić, czy akcja została włączona, wybierz kartę Akcje na stronie repozytorium GitHub:

Screenshot of the GitHub Actions tab showing the All workflows section.

Jeśli akcja jest uruchamiana w błędzie, na przykład jeśli nie ustawiono poświadczeń platformy Azure, możesz ponownie uruchomić testy po naprawieniu błędu. Na stronie repozytorium GitHub wybierz pozycję Akcje, wybierz określone zadanie przepływu pracy, a następnie wybierz przycisk Uruchom ponownie kontrole , aby ponownie uruchomić testy:

Screenshot of the GitHub Actions tab with the Re-run checks button highlighted.

Następne kroki