ブログ | NGINX

NGINX チュートリアル: GitHub Actions を使用してマイクロサービスのカナリアデプロイメントを自動化する方法

クリストファー・ハリソン

2023年3月21日公開

この投稿は、 2023 年 3 月の Microservices の概念を実践するのに役立つ 4 つのチュートリアルの 1 つです。マイクロサービスの提供を開始する:

マイクロサービスのデプロイと構成方法
コンテナ内のシークレットを安全に管理する方法
GitHub Actions を使用してマイクロサービスのカナリアリリースを自動化する方法 (この投稿)
OpenTelemetry トレースを使用してマイクロサービスを理解する方法

ほとんどのプロジェクトの成功には、デプロイメントの自動化が不可欠です。ただし、コードをデプロイするだけでは十分ではありません。また、ダウンタイムが制限される（またはなくなる）ようにする必要があり、障害が発生した場合には迅速にロールバックできる機能も必要です。 カナリアデプロイメントとブルーグリーンデプロイメントを組み合わせることは、新しいコードが実行可能であることを確認するための一般的なアプローチです。この戦略には 2 つのステップが含まれます。

ステップ1: 分離してテストするためのカナリアデプロイメント– コードを環境外の分離されたノード、サーバー、またはコンテナーにデプロイし、コードが意図したとおりに動作することを確認するためにテストします。
ステップ2: 運用環境でテストするためのブルーグリーンデプロイメント– コードがカナリアデプロイメントで動作すると仮定して、現在のバージョンのサーバーと並行して、運用環境で新しく作成されたサーバー (またはノードやコンテナー) にコードを移植します。次に、運用トラフィックの一部を新しいバージョンにリダイレクトして、より高い負荷でも引き続き正常に動作するかどうかをテストします。ほとんどの場合、最初は小さな割合 (たとえば 10%) を新しいバージョンに送信し、新しいバージョンがすべてのトラフィックを受信するまで徐々に増やしていきます。増分の大きさは、新しいバージョンがトラフィックを処理できるという確信度に応じて異なります。1 回の手順で完全に新しいバージョンに切り替えることもできます。

アプリやウェブサイトの異なるバージョン間でトラフィックを分散する (トラフィック分割) さまざまなユースケースに詳しくない場合は、ブログの「Kubernetes の高度なトラフィック管理による回復力の向上方法」を読んで、ブルーグリーンデプロイメント、カナリアリリース、A/B テスト、レート制限、サーキットブレーキングなどの概念を理解してください。このブログは Kubernetes に特化していますが、その概念はマイクロサービスアプリに広く適用できます。

チュートリアルの概要

このチュートリアルでは、 GitHub Actions を使用してカナリアブルーグリーンデプロイメントの最初のステップを自動化する方法を示します。チュートリアルの 4 つの課題では、Microsoft Azure Container Apps を使用してアプリケーションの新しいバージョンをデプロイし、 Azure Traffic Manager を使用してトラフィックを古い環境から新しい環境に移行します。

NGINXコンテナアプリを作成してデプロイする
Azure コンテナーアプリのデプロイを自動化するためのアクセス許可を設定する
GitHub Actionsを使用してカナリアブルーグリーンデプロイメントを作成する
GitHub Actionsワークフローをテストする

注記： このチュートリアルでは Azure Container Apps を使用しますが、概念と手法は任意のクラウドベースのホストに適用できます。

前提条件とセットアップ

前提条件

このチュートリアルを独自の環境で実行する場合は、次のものが必要です。

Azure アカウント。組織アカウントを使用すると権限に問題が発生する可能性があるため、組織にリンクされていないアカウントを使用することをお勧めします。
Azure CLI 。
ブラウザベースの GitHub GUI の代わりに（またはブラウザベースの GitHub GUI に加えて）使用する場合、 GitHub CLI を使用します。

設定

必要な基本リソースを作成して構成します。チュートリアルのリポジトリをフォークしてクローンし、Azure CLI にログインして、Azure Container Apps の拡張機能をインストールします。

ホームディレクトリにmicroservices-marchディレクトリを作成します。 (別のディレクトリ名を使用して、それに応じて手順を変更することもできます。)

注記： チュートリアル全体を通して、コマンドをターミナルにコピーして貼り付けやすくするために、Linux コマンドラインのプロンプトは省略されています。
```
mkdir ~/microservices-marchcd ~/microservices-march
```
GitHub CLI または GUI を使用して、 Microservices March プラットフォームリポジトリをフォークし、個人の GitHub アカウントにクローンします。
- GitHub GUI を使用する場合:
  1. ウィンドウの右上隅にある「フォーク」をクリックし、 「所有者」メニューで個人の GitHub アカウントを選択します。
  2. リポジトリをローカルにクローンし、アカウント名を <あなたの GitHub アカウント>:
```
git clone https://github.com/<your_GitHub_account>/platform.gitcd platform
```
- GitHub CLI を使用する場合は、次を実行します。
```
gh repo fork microservices-march/platform -–clone
```

Azure CLI にログインします。ブラウザを使用してログインするには、プロンプトに従います。

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

containerapp拡張機能をインストールします。

az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.

課題1: NGINX コンテナアプリの作成とデプロイ

この最初のチャレンジでは、カナリアブルーグリーンデプロイメントのベースラインとして使用されるアプリケーションの初期バージョンとして、NGINX Azure コンテナーアプリを作成します。 Azure Container Apps は、コンテナーにパッケージ化されたアプリケーションコードを運用対応のコンテナー環境で簡単に実行するために使用する Microsoft Azure サービスです。

コンテナーアプリ用のAzure リソースグループを作成します。

az group create --name my-container-app-rg --location westus{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

コンテナーを Azure Container Apps にデプロイします (この手順には時間がかかる場合があります)。

az containerapp up \    --resource-group my-container-app-rg \
    --name my-container-app \
    --source ./ingress \
    --ingress external \
    --target-port 80 \
    --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

手順 2 の出力で、 Azure Container Registry (ACR) で作成したコンテナーアプリの名前と URL を見つけます。サンプル出力ではオレンジ色で強調表示されています。チュートリアル全体のコマンドで指定された変数を、出力の値 (手順 2 のサンプル出力とは異なります) に置き換えます。
- コンテナーアプリの名前- image.registryキー内の.azurecr.ioの前の文字列。ステップ 2 のサンプル出力では、 cac085021b77acrです。
  
  この文字列を <ACR名> 後続のコマンドで。
- コンテナアプリの URL – Container app createdで始まる行の URL。手順 2 のサンプル出力では、 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/です。
  
  このURLを <ACR_URL> 後続のコマンドで。

ブルーグリーンデプロイメントの必要に応じて、コンテナーアプリのリビジョンを有効にします。

az containerapp revision set-mode \    --name my-container-app \
    --resource-group my-container-app-rg \
    --mode multiple
"Multiple"

(オプション) コンテナ内の/healthエンドポイントをクエリして、デプロイメントが機能していることをテストします。
```
curl <ACR_URL>/healthOK
```

チャレンジ2: Azure コンテナーアプリのデプロイを自動化するためのアクセス許可を設定する

このチャレンジでは、Azure コンテナーアプリのデプロイを自動化できる JSON トークンを取得します。

まず、Azure Container Registry (ACR) の ID を取得し、次に Azureマネージド IDのプリンシパル ID を取得します。次に、ACR の組み込み Azure ロールをマネージド ID に割り当て、マネージド ID を使用するようにコンテナーアプリを構成します。最後に、マネージド ID の JSON 資格情報を取得します。これは、GitHub Actions によって Azure への認証に使用されます。

この一連の手順は面倒に思えるかもしれませんが、新しいアプリケーションを作成するときに一度だけ実行すればよく、プロセスを完全にスクリプト化できます。チュートリアルでは、手順を手動で実行して、手順に慣れていきます。

注記： デプロイ用の資格情報を作成するこのプロセスは、Azure に固有です。

マネージド ID のプリンシパル ID を検索します。これは出力のPrincipalID列に表示されます (読みやすくするために 2 行に分割されています)。この値を <管理対象 ID プリンシパル ID> ステップ3:

az containerapp identity assign \    --name my-container-app \
    --resource-group my-container-app-rg \
    --system-assigned \
    --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

ACRでコンテナアプリのリソースIDを検索し、 <ACR名> ステップ3で記録した名前でチャレンジ 1。この値を <ACR_リソース_ID> 次のステップでは:

az acr show --name <ACR_name> --query id --output tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

ACRの組み込みAzureロールをコンテナーアプリのマネージドIDに割り当て、 <管理対象 ID プリンシパル ID> ステップ1で取得したマネージドIDを使用して、 <ACR_リソース_ID> ステップ2で取得したリソースIDを使用します。

az role assignment create \    --assignee <managed_identity_principal_ID> \
    --role AcrPull \
    --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

ACRからイメージをプルするときにマネージドIDを使用するようにコンテナアプリを構成し、 <ACR名> ステップ3で記録したコンテナアプリ名を入力します。チャレンジ 1 （上記のステップ 2 でも使用されます）：

az containerapp registry set \    --name my-container-app \
    --resource-group my-container-app-rg \
    --server <ACR_name>.azurecr.io \
    --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

Azure サブスクリプション IDを検索します。

az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97c

GitHub Actionが使用する認証情報を含むJSONトークンを作成し、 <サブスクリプションID> AzureサブスクリプションIDを入力します。出力を保存して、シークレットの値として貼り付けます。 AZURE_資格情報 で GitHub リポジトリにシークレットを追加する。 --sdk-authが非推奨であるという警告は無視しても問題ありません。これは既知の問題です。

az ad sp create-for-rbac \    --name my-container-app-rbac \
    --role contributor \
    --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg \
    --sdk-auth \
    --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

課題3: カナリアブルーグリーンデプロイメントGitHubアクションを作成する

このチャレンジでは、GitHub リポジトリにシークレットを追加し(GitHub Action ワークフローで機密データを管理するために使用されます)、 Action ワークフローファイルを作成し、 Action ワークフローを実行します。

シークレット管理の詳細な紹介については、ブログのマイクロサービスに関する 2 番目のチュートリアル「3 月 23 日、コンテナー内のシークレットを安全に管理する方法」を参照してください。

GitHub リポジトリにシークレットを追加する

アプリケーションの新しいバージョンをデプロイするには、セットアップでフォークした GitHub リポジトリに一連のシークレットを作成する必要があります。シークレットは、チャレンジ 2で作成されたマネージド ID の JSON 資格情報と、NGINX イメージの新しいバージョンを Azure にデプロイするために必要な、いくつかの機密性の高いデプロイ固有のパラメーターです。次のセクションでは、GitHub Action でこれらのシークレットを使用して、カナリアブルーグリーンデプロイメントを自動化します。

GitHub GUI を使用する場合:
1. フォークした GitHub リポジトリに移動します。
2. [設定] > [シークレットと変数] > [アクション]を選択します。
3. 新しいリポジトリシークレットをクリックします。
4. 指定されたフィールドに次の値を入力します。
  - 名前– AZURE_CREDENTIALS
  - 秘密–チャレンジ 2のステップ 6 の JSON 認証情報
5. 「シークレットを追加」をクリックします。
6. 手順 3 ～ 5 を 3 回繰り返して、表に記載されているシークレットを作成します。 シークレット名とシークレット値の列の値をそれぞれ GUI の名前とシークレットフィールドに入力します。 3番目の秘密については、 <ACR名> 手順3で記録したコンテナアプリに割り当てられた名前でチャレンジ 1。
  
  秘密の名前秘密の価値
  コンテナアプリ名 私のコンテナアプリ
  リソースグループ 私のコンテナアプリrg
  ACR_NAME <ACR名>
7. 「GitHub Action ワークフローファイルの作成」に進みます。
GitHub CLI を使用する場合:
1. リポジトリのルートに一時ファイルを作成します。
```
touch ~/creds.json
```
2. 好みのテキストエディターを使用して、 creds.jsonを開き、チャレンジ 2の手順 6 で作成した JSON 資格情報をコピーします。
3. シークレットを作成します:
```
gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json
```
4. creds.jsonを削除します:
```
rm ~/creds.json
```
5. このコマンドを繰り返して、さらに 3 つのシークレットを作成します。
```
gh secret set <secret_name> --repo <your_GitHub_account>/platform
```
  繰り返しごとに、 <シークレット名> の1つの値と 秘密の名前 表の列。プロンプトで、シークレット値列から関連する値を貼り付けます。 3番目の秘密については、 <ACR名> 手順3で記録したコンテナアプリに割り当てられた名前でチャレンジ 1。
  
  秘密の名前秘密の価値
  コンテナアプリ名 私のコンテナアプリ
  リソースグループ 私のコンテナアプリrg
  ACR_NAME <ACR名>

秘密の名前	秘密の価値
`コンテナアプリ名`	`私のコンテナアプリ`
`リソースグループ`	`私のコンテナアプリrg`
`ACR_NAME`	`<ACR名>`

秘密の名前	秘密の価値
`コンテナアプリ名`	`私のコンテナアプリ`
`リソースグループ`	`私のコンテナアプリrg`
`ACR_NAME`	`<ACR名>`

GitHub Actionワークフローファイルを作成する

マネージド ID とシークレットを用意したら、カナリアブルーグリーンデプロイメントを自動化する GitHub アクションのワークフローファイルを作成できます。

注記： ワークフローファイルは、空白が重要な YAML 形式で定義されます。以下の手順で示すインデントを必ず維持してください。

アクションワークフロー用のファイルを作成します。
- GitHub GUI を使用する場合:
  1. GitHub リポジトリに移動します。
  2. [アクション] > [新しいワークフロー] > [これをスキップして自分でワークフローを設定する]を選択します。
- GitHub CLI を使用する場合は、 .github/workflowsディレクトリを作成し、 main.ymlという新しいファイルを作成します。
```
mkdir .github/workflowstouch .github/workflows/main.yml
```

好みのテキストエディターを使用して、ワークフローのテキストをmain.ymlに追加します。最も簡単な方法は、完全なワークフローファイルに表示されるテキストをコピーすることです。あるいは、この手順で注釈を付けたスニペットのセットを追加して、ファイルを手動でビルドすることもできます。

注記： ワークフローファイルは、空白が重要な YAML 形式で定義されます。スニペットをコピーする場合は、必ずインデントを保持してください (さらに念のため、ファイルを完全なワークフローファイルと比較してください)。

ワークフローの名前を定義します。
```
name: Deploy to Azure
```
メインブランチにプッシュまたはプルリクエストが行われたときに実行されるワークフローを構成します。
```
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
```

ジョブセクションで、コードをチェックアウトし、Azure にログインして、アプリケーションを Azure Container App にデプロイするビルドデプロイジョブを定義します。

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}\
            -g ${{ secrets.RESOURCE_GROUP }} \
            --source ${{ github.workspace }}/ingress \
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

新しくデプロイされたリビジョンのステージング URL を取得し、GitHub アクションを使用して API エンドポイント/healthに ping を実行し、新しいリビジョンが応答していることを確認するtest-deploymentジョブを定義します。正常性チェックが成功すると、コンテナーアプリ上の Azure Traffic Manager が更新され、すべてのトラフィックが新しくデプロイされたコンテナーに向けられるようになります。

注記： 必ず、前の箇条書きで定義したbuild-deployキーと同じレベルでtest-deploymentキーをインデントしてください。

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

完全なワークフローファイル

これはアクションワークフローファイルの完全なテキストです。

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} \
            -g ${{ secrets.RESOURCE_GROUP }} \
            --source ${{ github.workspace }}/ingress \
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

アクションワークフローを実行する

GitHub GUI を使用する場合:
1. [コミットの開始]をクリックし、必要に応じてコミットメッセージを追加し、ダイアログボックスで[新しいファイルのコミット]を選択します。新しいワークフローファイルがメインブランチにマージされ、実行が開始されます。
2. ワークフローの進行状況を監視するには、 [アクション]をクリックします。
GitHub CLI を使用する場合:
1. main.yml をGit ステージング領域に追加します。
```
git add .github/workflows/main.yml
```
2. ファイルをコミットします:
```
git commit -m "feat: create GitHub Actions workflow"
```
3. 変更を GitHub にプッシュします。
```
git push
```
4. ワークフローの進行状況を監視します。
```
gh workflow view main.yml --repo <your_GitHub_account>/platform
```

課題4: GitHub Actionsワークフローをテストする

このチャレンジでは、ワークフローをテストします。まず、Ingress ロードバランサーへの正常な更新をシミュレートし、アプリケーションが更新されたことを確認します。次に、失敗した更新 (内部サーバーエラーの原因) をシミュレートし、公開されたアプリケーションが変更されていないことを確認します。

アップデートを成功させる

正常な更新を作成し、ワークフローが成功することを確認します。

GitHub GUI を使用する場合:
1. コード > ingress > default.conf.templateを選択します。
2. ツールヒント「このファイルを編集」の付いた鉛筆アイコンを選択して、 default.conf.template を編集用に開きます。
3. ファイルの末尾近くにあるlocation /healthブロックで、 returnディレクティブを次のように変更します。
```
location /health {
    access_log off;
    return 200 "Successful Update!\n";
}
```
4. ダイアログボックスで、 「このコミットの新しいブランチを作成してプルリクエストを開始する」を選択し、 「変更を提案する」を選択します。
5. プルリクエストテンプレートにアクセスするには、 「プルリクエストの作成」をクリックします。
6. プルリクエストを作成するには、もう一度[プルリクエストの作成]をクリックします。
7. ワークフローの進行状況を監視するには、 [アクション]をクリックします。
8. ワークフローが完了したら、コンテナアプリに移動します。 <ACR_URL>/健康エンドポイントでは、 <ACR_URL> のステップ3でメモしたURLです。チャレンジ 1。「更新が成功しました!」というメッセージに注目してください。
9. ターミナルセッションを開始し、アプリにヘルスチェックリクエストを送信することでメッセージを確認できます。 <ACR_URL> ステップ3で記録した値でチャレンジ 1:
```
curl <ACR_URL>/healthSuccessful Update!
```
10. 失敗した更新に進みます。
GitHub CLI を使用する場合:
1. patch-1という新しいブランチを作成します。
```
git checkout -b patch-1
```
2. 好みのテキストエディターでingress/default.conf.templateを開き、ファイルの末尾近くにあるlocation /healthブロックで、 returnディレクティブを次のように変更します。
```
location /health {
    access_log off;
    return 200 "Successful Update!\n";
}
```
3. default.conf.template をGit ステージング領域に追加します。
```
git add ingress/default.conf.template
```
4. ファイルをコミットします:
```
git commit -m "feat: update NGINX ingress"
```
5. 変更を GitHub にプッシュします。
```
git push --set-upstream origin patch-1
```
6. プルリクエスト (PR) を作成します。
```
gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform
```
7. ワークフローの進行状況を監視します。
```
gh workflow view main.yml --repo <your_GitHub_account>/platform
```
8. ワークフローが完了したら、アプリにヘルスチェックリクエストを送信し、 <ACR_URL> ステップ3で記録した値でチャレンジ 1:
```
curl <ACR_URL>/health
Successful Update!
```

更新に失敗する

ここで、失敗した更新を作成し、ワークフローが失敗するのを確認します。これは基本的に、「更新を成功させる」の手順を繰り返しますが、 returnディレクティブの値は異なります。

GitHub GUI を使用する場合:
1. コード > ingress > default.conf.templateを選択します。
2. 左上で、 main を選択し、前のセクションで作成したpatch-1で終わるブランチの名前を選択します。
3. ツールヒント「このファイルを編集」の付いた鉛筆アイコンを選択して、 default.conf.template を編集用に開きます。
4. 次のようにreturnディレクティブを変更します。
```
location /health {
    access_log off;
    return 500 "Unsuccessful Update!\n";
}
```
5. -patch-1 ブランチに直接コミットを選択し、変更をコミットします。
6. ワークフローの進行状況を監視するには、 「アクション」を選択します。 PR 内のファイルが更新されると、ワークフローが再度実行されることに注意してください。
7. ワークフローが完了したら、コンテナアプリに移動します。 <ACR_URL>/健康エンドポイントでは、 <ACR_URL> のステップ3で記録したURLです。チャレンジ 1。
  
  メッセージは「更新が成功しました!」です (前回の更新が成功した後と同じです)。矛盾しているように思えるかもしれませんが、実際にはこの更新が失敗したことが確認されています。更新の試みの結果、ステータスが500(内部サーバーエラーを意味します) が適用されませんでした。
8. ターミナルセッションを開始し、アプリにヘルスチェックリクエストを送信することでメッセージを確認できます。 <ACR_URL> ステップ3で記録した値でチャレンジ 1:
```
curl <ACR_URL>/healthSuccessful Update!
```
GitHub CLI を使用する場合:
1. 前のセクションで作成したpatch-1ブランチを確認します。
```
git checkout patch-1
```
2. 好みのテキストエディターでingress/default.conf.templateを開き、次のようにreturnディレクティブを変更します。
```
location /health {
    access_log off;
    return 500 "Unsuccessful Update!\n";
}
```
3. default.conf.template をGit ステージング領域に追加します。
```
git add ingress/default.conf.template
```
4. ファイルをコミットします:
```
git commit -m "feat: update NGINX ingress again"
```
5. 変更を GitHub にプッシュします。
```
git push
```
6. ワークフローの進行状況を監視します。
```
gh workflow view main.yml --repo <your_GitHub_account>/platform
```
7. ワークフローが完了したら、アプリにヘルスチェックリクエストを送信し、 <ACR_URL> ステップ3で記録した値でチャレンジ 1:
```
curl <ACR_URL>/healthSuccessful Update!
```
  メッセージが「更新が成功しました!」 (前回の更新が成功した後と同じ) であることは矛盾しているように思えるかもしれません。矛盾しているように思えるかもしれませんが、実際にはこの更新が失敗したことが確認されています。更新の試みの結果、ステータス500(内部サーバーエラーを意味します) が適用されませんでした。

リソースのクリーンアップ

将来的に料金が発生する可能性を回避するために、チュートリアルでデプロイした Azure リソースを削除することをお勧めします。

az group delete -n my-container-app-rg -y

必要に応じて、作成したフォークを削除することもできます。

GitHub GUI を使用する場合:
1. [設定]をクリックします。
2. ページの一番下までスクロールします。
3. 「このリポジトリを削除」をクリックします。
4. タイプ <あなたの GitHub アカウント>/プラットフォーム選択して 結果は理解しています。このリポジトリを削除してください。

GitHub CLI を使用する場合:

gh repo delete <your_GitHub_account>/platform -yes

次のステップ

おめでとう！ GitHub Actions を使用してマイクロサービスアプリのカナリアブルーグリーンデプロイメントを実行する方法を学びました。DevOps の知識をさらに深めるには、GitHub ドキュメントの次の記事を参照してください。

カナリアデプロイメントの 2 番目のステップ (本番環境でのテスト) を試す準備ができたら、ブログの Microservices March 2022 のチュートリアル「カナリアデプロイメントによる稼働時間と回復力の向上」をご覧ください。 NGINX Service Mesh を使用して、段階的に新しいアプリバージョンに移行します。デプロイメントがまだサービスメッシュを必要とするほど複雑でない場合や、Kubernetes を使用していない場合でも、Ingress コントローラーまたはロードバランサーのみを使用するより単純なデプロイメントには原則が適用されます。

マイクロサービスに関する学習を継続するには、「Microservices March 2023」をご覧ください。ユニット 3「自動化によるマイクロサービスデプロイメントの加速」では、デプロイメントの自動化について詳しく学習します。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"

検索結果の提案

NGINX チュートリアル: GitHub Actions を使用してマイクロサービスのカナリアデプロイメントを自動化する方法

チュートリアルの概要

前提条件とセットアップ

前提条件

設定

課題1: NGINX コンテナアプリの作成とデプロイ

チャレンジ2: Azure コンテナーアプリのデプロイを自動化するためのアクセス許可を設定する

課題3: カナリアブルーグリーンデプロイメントGitHubアクションを作成する

GitHub リポジトリにシークレットを追加する

GitHub Actionワークフローファイルを作成する

完全なワークフローファイル

アクションワークフローを実行する

課題4: GitHub Actionsワークフローをテストする

アップデートを成功させる

更新に失敗する

リソースのクリーンアップ

次のステップ

あらゆるアプリを安全に配信しましょう

NGINX チュートリアル: GitHub Actions を使用してマイクロサービスのカナリア デプロイメントを自動化する方法

チュートリアルの概要

前提条件とセットアップ

前提条件

設定

課題1: NGINX コンテナ アプリの作成とデプロイ

チャレンジ2: Azure コンテナー アプリのデプロイを自動化するためのアクセス許可を設定する

課題3: カナリアブルーグリーンデプロイメントGitHubアクションを作成する

GitHub リポジトリにシークレットを追加する

GitHub Actionワークフローファイルを作成する

完全なワークフローファイル

アクションワークフローを実行する

課題4: GitHub Actionsワークフローをテストする

アップデートを成功させる

更新に失敗する

リソースのクリーンアップ

次のステップ

あらゆるアプリを安全に配信しましょう

F5の情報を入手

NGINX チュートリアル: GitHub Actions を使用してマイクロサービスのカナリアデプロイメントを自動化する方法

課題1: NGINX コンテナアプリの作成とデプロイ

チャレンジ2: Azure コンテナーアプリのデプロイを自動化するためのアクセス許可を設定する