Azure Spring Apps CI/CD gebruiken met GitHub Actions

  • Artikel

Notitie

Azure Spring Apps is de nieuwe naam voor de Azure Spring Cloud-service. Hoewel de service een nieuwe naam heeft, ziet u de oude naam op sommige plaatsen terwijl we werken aan het bijwerken van assets, zoals schermopnamen, video's en diagrammen.

Dit artikel is van toepassing op: ✔️ Basic/Standard ✔️ Enterprise

In dit artikel leest u hoe u een CI/CD-werkstroom bouwt voor Azure Spring Apps met GitHub Actions.

GitHub Actions ondersteunt een geautomatiseerde werkstroom voor de levenscyclus van softwareontwikkeling. Met GitHub Actions voor Azure Spring Apps kunt u werkstromen maken in uw opslagplaats om te bouwen, testen, verpakken, vrijgeven en implementeren in Azure.

Vereisten

Voor dit voorbeeld is de Azure CLI vereist.

GitHub-opslagplaats instellen en verifiëren

U hebt een azure-service-principalreferentie nodig om de aanmeldingsactie van Azure te autoriseren. Als u een Azure-referentie wilt ophalen, voert u de volgende opdrachten uit op uw lokale computer:

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

Als u toegang wilt krijgen tot een specifieke resourcegroep, kunt u het bereik beperken:

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

De opdracht moet een JSON-object uitvoeren:

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

In dit voorbeeld wordt het steeltoe-voorbeeld op GitHub gebruikt. Maak een fork van de opslagplaats, open de gitHub-opslagplaatspagina voor de fork en selecteer het tabblad Instellingen. Open het menu Geheimen en selecteer Nieuw geheim:

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

Stel de geheime naam AZURE_CREDENTIALS in op en de waarde ervan op de JSON-tekenreeks die u hebt gevonden onder de kop Uw GitHub-opslagplaats instellen en verifiëren.

Screenshot of the GitHub Actions secrets / New secret page.

U kunt ook de Azure-aanmeldingsreferentie ophalen uit Key Vault in GitHub Actions, zoals wordt uitgelegd in Verificatie van Azure Spring met Key Vault in GitHub Actions.

Service-exemplaar inrichten

Voer de volgende opdrachten uit met behulp van de Azure CLI om uw Azure Spring Apps-service-exemplaar in te richten.

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

De werkstroom bouwen

De werkstroom wordt gedefinieerd met behulp van de volgende opties.

Implementatie voorbereiden met Azure CLI

De opdracht az spring app create is momenteel niet idempotent. Nadat u deze eenmaal hebt uitgevoerd, krijgt u een foutmelding als u dezelfde opdracht opnieuw uitvoert. We raden deze werkstroom aan voor bestaande Azure Spring Apps-apps en -exemplaren.

Gebruik de volgende Azure CLI-opdrachten voor voorbereiding:

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

Rechtstreeks implementeren met Azure CLI

Maak het .github/workflows/main.yml-bestand in de opslagplaats met de volgende inhoud. Vervang <de naam> van uw resourcegroep en< uw servicenaam> door de juiste waarden.

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 }}

GitHub-opslagplaats instellen en verifiëren

U hebt een azure-service-principalreferentie nodig om de aanmeldingsactie van Azure te autoriseren. Als u een Azure-referentie wilt ophalen, voert u de volgende opdrachten uit op uw lokale computer:

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

Als u toegang wilt krijgen tot een specifieke resourcegroep, kunt u het bereik beperken:

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

De opdracht moet een JSON-object uitvoeren:

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

In dit voorbeeld wordt het PiggyMetrics-voorbeeld op GitHub gebruikt. Maak een fork van het voorbeeld, schakel het selectievakje Alleen de Azure-vertakking kopiëren uit, open de pagina van de GitHub-opslagplaats en selecteer het tabblad Instellingen. Open het menu Geheimen en selecteer Een nieuw geheim toevoegen:

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

Stel de geheime naam AZURE_CREDENTIALS in op en de waarde ervan op de JSON-tekenreeks die u hebt gevonden onder de kop Uw GitHub-opslagplaats instellen en verifiëren.

Screenshot of the GitHub Actions secrets / New secret page.

U kunt ook de Azure-aanmeldingsreferentie ophalen uit Key Vault in GitHub Actions, zoals wordt uitgelegd in Verificatie van Azure Spring met Key Vault in GitHub Actions.

Service-exemplaar inrichten

Voer de volgende opdrachten uit met behulp van de Azure CLI om uw Azure Spring Apps-service-exemplaar in te richten.

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

End-to-end voorbeeldwerkstromen

In de volgende voorbeelden ziet u veelvoorkomende gebruiksscenario's.

Implementeren

In de volgende secties ziet u verschillende opties voor het implementeren van uw app.

Naar productie

Azure Spring Apps biedt ondersteuning voor implementaties met ingebouwde artefacten (bijvoorbeeld JAR of .NET Core ZIP) of broncodearchief.

In het volgende voorbeeld wordt geïmplementeerd in de standaardproductie-implementatie in Azure Spring Apps met behulp van een JAR-bestand dat is gebouwd door Maven. Dit voorbeeld is het enige mogelijke implementatiescenario wanneer u de Basic-SKU gebruikt:

Notitie

Het pakketzoekpatroon mag slechts precies één pakket retourneren. Als de buildtaak meerdere JAR-pakketten produceert, zoals sources.jar en javadoc.jar, moet u het zoekpatroon verfijnen zodat het alleen overeenkomt met het binaire artefact van de toepassing.

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

In het volgende voorbeeld wordt geïmplementeerd in de standaardproductie-implementatie in Azure Spring Apps met behulp van broncode.

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 }}

In het volgende voorbeeld wordt geïmplementeerd in de standaardproductie-implementatie in Azure Spring Apps met behulp van broncode in het Enterprise-abonnement. U kunt opgeven welke opbouwfunctie moet worden gebruikt voor het implementeren van acties met behulp van de builder optie.

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>

In het volgende voorbeeld wordt geïmplementeerd in de standaardproductie-implementatie in Azure Spring Apps met een bestaande containerinstallatiekopieën.

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>

Tijdens de implementatie kunt u meer functionaliteit bereiken met behulp van meer argumenten. Zie de sectie Argumenten van GitHub Action voor implementatie in Azure Spring Apps voor meer informatie.

Blauw-groen

De volgende voorbeelden worden geïmplementeerd in een bestaande faseringsimplementatie. Deze implementatie ontvangt geen productieverkeer totdat deze is ingesteld als een productie-implementatie. U kunt use-staging-deployment true instellen om de faseringsimplementatie automatisch te vinden of om een specifieke implementatienaam toe te wijzen. We richten ons alleen op de spring-apps-deploy actie en laten de voorbereidende taken in de rest van het artikel achter.

# 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

Zie Blauwgroene implementatiestrategieën voor meer informatie over blauwgroene implementaties, waaronder een alternatieve aanpak.

Productie-implementatie instellen

In het volgende voorbeeld wordt de huidige faseringsimplementatie ingesteld als productie, waarbij effectief wordt gewisseld welke implementatie productieverkeer ontvangt.

# 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

Een faseringsimplementatie verwijderen

Met Delete Staging Deployment de actie kunt u de implementatie verwijderen die geen productieverkeer ontvangt. Met deze verwijdering worden resources vrijgemaakt die door die implementatie worden gebruikt en is ruimte voor een nieuwe faseringsimplementatie:

# 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>

Build maken of bijwerken (alleen Enterprise-abonnement)

In het volgende voorbeeld wordt een buildresource gemaakt of bijgewerkt in het Enterprise-abonnement:

# 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>

Build verwijderen (alleen Enterprise-abonnement)

In het volgende voorbeeld wordt een buildresource in het Enterprise-abonnement verwijderd:

# 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>

Implementeren met Maven-invoegtoepassing

Een andere optie is om de Maven-invoegtoepassing te gebruiken voor het implementeren van de Jar en het bijwerken van app-instellingen. De opdracht mvn azure-spring-apps:deploy is idempotent en maakt indien nodig automatisch apps. U hoeft vooraf geen bijbehorende apps te maken.

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

De werkstroom uitvoeren

GitHub Actions moet automatisch worden ingeschakeld nadat u .github/workflow/main.yml naar GitHub hebt gepusht. De actie wordt geactiveerd wanneer u een nieuwe doorvoering pusht. Als u dit bestand in de browser maakt, moet uw actie al zijn uitgevoerd.

Als u wilt controleren of de actie is ingeschakeld, selecteert u het tabblad Acties op de gitHub-opslagplaatspagina:

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

Als uw actie bijvoorbeeld wordt uitgevoerd als u de Azure-referentie niet hebt ingesteld, kunt u controles opnieuw uitvoeren nadat de fout is opgelost. Selecteer op de pagina gitHub-opslagplaats acties, selecteer de specifieke werkstroomtaak en selecteer vervolgens de knop Controles opnieuw uitvoeren om controles opnieuw uit te voeren:

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

Volgende stappen