Использование непрерывной поставки и непрерывной интеграции Azure Spring Apps с помощью GitHub Actions

Статья
11/05/2024

Примечание.

Планы "Базовый", "Стандартный" и "Корпоративный" будут устарели начиная с середины марта 2025 г. с 3-летнего периода выхода на пенсию. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в объявлении о выходе на пенсию в Azure Spring Apps.

Стандартный план потребления и выделенного плана будет устарел с 30 сентября 2024 г. с полным завершением работы после шести месяцев. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в статье "Миграция потребления Azure Spring Apps Standard" и выделенного плана в приложения контейнеров Azure.

Эта статья относится к: ✔️ Basic/Standard ✔️ Enterprise

В этой статье показано, как создать рабочий процесс CI/CD для Azure Spring Apps с помощью GitHub Actions.

Компонент GitHub Actions поддерживает создание автоматизированных рабочих процессов жизненного цикла разработки программного обеспечения. С помощью GitHub Actions для Azure Spring Apps вы можете создавать рабочие процессы в своем репозитории для сборки, тестирования, упаковки, выпуска и развертывания в Azure.

Необходимые компоненты

Для выполнения инструкций из этого примера требуется Azure CLI.

Настройка репозитория GitHub и проверка подлинности

Для авторизации действия входа в Azure требуются учетные данные субъекта-службы Azure. Чтобы получить учетные данные Azure, выполните следующие команды на локальном компьютере:

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

Для доступа к определенной группе ресурсов можно ограничить область:

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

Команда должна выводить объект JSON:

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

В этом примере используется пример Steeltoe из GitHub. Создайте вилку репозитория, откройте страницу репозитория GitHub для вилки и перейдите на вкладку Параметры. Откройте меню Секреты и выберите Новый секрет:

Задайте для имени секрета AZURE_CREDENTIALS, а для его значения — строку JSON, которая расположена под заголовком Настройка репозитория GitHub и проверка подлинности.

Кроме того, можно получить учетные данные для входа в Azure из Key Vault с помощью GitHub Actions, как описано в статье Проверка подлинности Azure Spring с помощью Key Vault в GitHub Actions.

Подготовка экземпляра службы к работе

Чтобы подготовить к работе экземпляр службы Azure Spring Apps, выполните указанные ниже команды с помощью Azure CLI.

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

Создание рабочего процесса

Рабочий процесс определяется с помощью указанных ниже возможностей.

Подготовка к развертыванию с помощью Azure CLI

Сейчас команда az spring app create не является идемпотентной. После его запуска вы получите ошибку при повторном выполнении той же команды. Мы рекомендуем этот рабочий процесс для существующих приложений и экземпляров Azure Spring Apps.

Используйте следующие команды Azure CLI для подготовки:

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

Развертывание с помощью Azure CLI напрямую

Создайте файл .github/workflows/main.yml в репозитории со следующим содержимым. Замените <имя вашей группы ресурсов> и <название вашей службы> правильными значениями.

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 и проверка подлинности

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

Для доступа к определенной группе ресурсов можно ограничить область:

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

Команда должна выводить объект JSON:

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

В этом примере используется пример PiggyMetrics из GitHub. Вилку примера снимите флажок "Копировать только ветвь Azure", откройте страницу репозитория GitHub и откройте вкладку "Параметры". Откройте меню "Секреты" и выберите "Добавить новый секрет".

Подготовка экземпляра службы к работе

Чтобы подготовить к работе экземпляр службы Azure Spring Apps, выполните указанные ниже команды с помощью Azure CLI.

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

Сквозные примеры рабочих процессов

Следующие примеры демонстрируют распространенные сценарии использования.

Развертывание

В следующих разделах показаны различные варианты развертывания вашего приложения.

В рабочей среде

Azure Spring Apps поддерживает развертывание в развертываниях со встроенными артефактами (например, JAR или ZIP-файл .NET Core) или архивом исходного кода.

В следующем примере выполняется развертывание в рабочее развертывание по умолчанию в Azure Spring Apps с использованием JAR-файла, созданного Maven. Этот пример является единственным возможным сценарием развертывания при использовании номера SKU уровня "Базовый".

Примечание.

Шаблон поиска пакетов должен возвращать только один пакет. Если задача сборки создает несколько пакетов JAR, таких как sources.jar и javadoc.jar, необходимо уточнить шаблон поиска, чтобы он соответствовал только двоичному артефакту приложения.

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

В следующем примере выполняется развертывание в рабочее развертывание по умолчанию в Azure Spring Apps с использованием исходного кода.

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

Следующий пример развертывается в рабочей среде по умолчанию в Azure Spring Apps с помощью исходного кода в плане Enterprise. Можно указать, какой построитель будет использоваться для развертывания действий с помощью builder параметра.

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>

В следующем примере выполняется развертывание рабочей среды по умолчанию в Azure Spring Apps с существующим образом контейнера.

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>

Во время развертывания можно добиться большей функциональности с помощью дополнительных аргументов. Дополнительные сведения см. в разделе "Аргументы" действия GitHub для развертывания в Azure Spring Apps.

Сине-зеленый

Следующие примеры развертываются в существующее промежуточное развертывание. Это развертывание не получает рабочий трафик, пока он не будет установлен в качестве рабочего развертывания. Вы можете установить для use-staging-deployment значение true, чтобы автоматически найти промежуточное развертывание, или просто выделить конкретное имя развертывания. Мы сосредоточимся только на spring-apps-deploy действии и оставим подготовительные задания в остальной части статьи.

# 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

Дополнительные сведения о сине-зеленых развертываниях, включая альтернативный подход, см. в статье Стратегии сине-зеленых развертываний.

Настройка рабочего развертывания

Следующий пример задает текущее промежуточное развертывание в качестве рабочей среды, эффективно переключяя, какое развертывание получает рабочий трафик.

# 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

Удаление промежуточного развертывания

Это Delete Staging Deployment действие позволяет удалить развертывание, не получающее рабочий трафик. Это удаление освобождает ресурсы, используемые этим развертыванием, и делает местом для нового промежуточного развертывания:

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

Создание или обновление сборки (только для корпоративного плана)

В следующем примере создается или обновляется ресурс сборки в плане 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>

Удаление сборки (только для корпоративного плана)

В следующем примере удаляется ресурс сборки в плане 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>

Развертывание с помощью подключаемого модуля Maven

Другой вариант — использовать подключаемый модуль Maven для развертывания JAR-файла и обновления параметров приложения. mvn azure-spring-apps:deploy Команда идемпотентна и автоматически создает приложения при необходимости. Создавать соответствующие приложения заранее не требуется.

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

Запуск рабочего процесса

GitHub Actions должны быть включены автоматически после отправки файла .github/workflow/main.yml в GitHub. Действие активируется при отправке новой фиксации. При создании этого файла в браузере действие должно быть уже запущено.

Чтобы убедиться, что действие включено, щелкните вкладку Действия на странице репозитория GitHub:

Если действие завершается ошибкой, например, если вы не задали учетные данные Azure, вы можете повторно выполнить проверку после исправления ошибки. На странице репозитория GitHub выберите Actions (Действия), выберите конкретную задачу рабочего процесса, а затем нажмите кнопку Rerun checks (Повторное выполнение проверок), чтобы повторно запустить проверки:

Поделиться через

Использование непрерывной поставки и непрерывной интеграции Azure Spring Apps с помощью GitHub Actions

Необходимые компоненты

Настройка репозитория GitHub и проверка подлинности

Подготовка экземпляра службы к работе

Создание рабочего процесса

Подготовка к развертыванию с помощью Azure CLI

Развертывание с помощью Azure CLI напрямую

Настройка репозитория GitHub и проверка подлинности

Подготовка экземпляра службы к работе

Сквозные примеры рабочих процессов

Развертывание

В рабочей среде

Сине-зеленый

Настройка рабочего развертывания

Удаление промежуточного развертывания

Создание или обновление сборки (только для корпоративного плана)

Удаление сборки (только для корпоративного плана)

Развертывание с помощью подключаемого модуля Maven

Запуск рабочего процесса

Следующие шаги

Обратная связь

Дополнительные ресурсы