NGINX チュートリアル: GitHub Actions を使用してマイクロサービスのカナリア デプロイメントを自動化する方法
この投稿は、 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-marchGitHub CLI または GUI を使用して、 Microservices March プラットフォームリポジトリをフォークし、個人の GitHub アカウントにクローンします。
GitHub GUI を使用する場合:
ウィンドウの右上隅にある「フォーク」をクリックし、 「所有者」メニューで個人の GitHub アカウントを選択します。
リポジトリをローカルにクローンし、アカウント名を
<あなたの GitHub アカウント>:gitクローン https://github.com/<あなたの GitHub アカウント>/platform.gitcd プラットフォーム
GitHub CLI を使用する場合は、次を実行します。
gh リポジトリ フォーク microservices-march/platform -–clone
Azure CLI にログインします。ブラウザを使用してログインするには、プロンプトに従います。
az ログイン[ { "クラウド名": "AzureCloud", "ホームテナントID": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e", "ID": "60efapl2-38ad-41w8-g49a-0ecc6723l97c", "isDefault": true, "managedByTenants": [], "名前": 「Azure サブスクリプション 1」、「状態」: "有効", "テナントID": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "ユーザー": { "名前": "user@example.com", "タイプ": "user" } } ]containerapp拡張機能をインストールします。az extension add --name containerapp -upgradeインストールされた拡張機能 'containerapp' はプレビュー段階です。
課題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": "成功しました" }, "タグ": null, "タイプ": "Microsoft.Resources/リソースグループ" }コンテナーを 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 ... - イメージ: レジストリ: cac085021b77acr .azurecr.io リポジトリ: my-container-app タグ: "20230315212413756768" ダイジェスト: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... ランタイム依存関係: レジストリ: registry.hub.docker.com リポジトリ: library/nginx タグ: "1.23" ダイジェスト: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} 実行 ID: cf1 は 27 秒後に成功しました。リソース グループ my-container-app-rg にコンテナー アプリ my-container-app を作成しています。レジストリ パスワードを "ca2ffbce7810acrazurecrio-cac085021b77acr" という名前のシークレットとして追加しています。コンテナー アプリが作成されました。 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/でアプリにアクセスします...手順 2 の出力で、 Azure Container Registry (ACR) で作成したコンテナー アプリの名前と URL を見つけます。 サンプル出力ではオレンジ色で強調表示されています。 チュートリアル全体のコマンドで指定された変数を、出力の値 (手順 2 のサンプル出力とは異なります) に置き換えます。
コンテナー アプリの名前-
image.registryキー内の.azurecr.ioの前の文字列。 ステップ 2 のサンプル出力では、cac085021b77acrです。この文字列を
<ACR名>後続のコマンドで。コンテナ アプリの URL –
Containerappcreatedで始まる行の URL。 手順 2 のサンプル出力では、https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/です。このURLを
<ACR_URL>後続のコマンドで。
ブルーグリーン デプロイメントの必要に応じて、コンテナー アプリのリビジョンを有効にします。
az containerapp リビジョン set-mode \ --name my-container-app \ --resource-group my-container-app-rg \ --mode multiple "複数"(オプション) コンテナ内の/healthエンドポイントをクエリして、デプロイメントが機能していることをテストします。
カール <ACR_URL>/健康わかりました
チャレンジ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 assignment \ --name my-container-app \ --resource-group my-container-app-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ ... 39f8434b-12d6-4735-81d8-ba0apo14579f ... ... テナント ID ... ------------------------------------ ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsdeACRでコンテナアプリのリソースIDを検索し、
<ACR名>ステップ3で記録した名前で チャレンジ 1。 この値を<ACR_リソース_ID>次のステップでは:az acr show --name <ACR名> --クエリID --出力tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acrACRの組み込みAzureロールをコンテナーアプリのマネージドIDに割り当て、
<管理対象 ID プリンシパル ID>ステップ1で取得したマネージドIDを使用して、<ACR_リソース_ID>ステップ2で取得したリソースIDを使用します。az ロール割り当て作成 \ --assignee <管理対象 ID プリンシパル ID> \ --role AcrPull \ --scope <ACR_リソース_ID> { "条件": null、 "条件バージョン": null、 "作成者": null、 "作成日": "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"、"プリンシパルタイプ": "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", "更新者": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d", "更新日": "2023-03-15T20:28:41.127243+00:00" }ACRからイメージをプルするときにマネージドIDを使用するようにコンテナアプリを構成し、
<ACR名>ステップ3で記録したコンテナアプリ名を入力します。 チャレンジ 1 （上記のステップ 2 でも使用されます）：az containerapp レジストリ セット \ --name my-container-app \ --resource-group my-container-app-rg \ --server <ACR名>.azurecr.io \ --アイデンティティ システム [ { "identity": "system", "passwordSecretRef": "", "server": "cac085021b77acr.azurecr.io", "username": "" } ]Azure サブスクリプション IDを検索します。
az アカウント ショー --クエリ ID --出力 tsv 0efafl2-38ad-41w8-g49a-0ecc6723l97cGitHub Actionが使用する認証情報を含むJSONトークンを作成し、
<サブスクリプションID>AzureサブスクリプションIDを入力します。出力を保存して、シークレットの値として貼り付けます。AZURE_資格情報で GitHub リポジトリにシークレットを追加する。--sdk-authが非推奨であるという警告は無視しても問題ありません。これは既知の問題です。az ad sp create-for-rbac \ --name my-container-app-rbac \ --role contributor \ --scopes /subscriptions/<サブスクリプションID>/resourceGroups/my-container-app-rg \ --sdk-auth \ --output json オプション '--sdk-auth' は非推奨となり、将来のリリースで削除される予定です。 ... { "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er"、"クライアントシークレット": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe"、"サブスクリプションID": "0efafl2-38ad-41w8-g49a-0ecc6723l97c", "テナント ID": "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 を使用する場合:
- フォークした GitHub リポジトリに移動します。
- [設定] > [シークレットと変数] > [アクション]を選択します。
- 新しいリポジトリシークレットをクリックします。
指定されたフィールドに次の値を入力します。
- 名前–
AZURE_CREDENTIALS - 秘密–チャレンジ 2のステップ 6 の JSON 認証情報
- 名前–
- 「シークレットを追加」をクリックします。
手順 3 ～ 5 を 3 回繰り返して、表に記載されているシークレットを作成します。 シークレット名とシークレット値の列の値をそれぞれ GUI の名前とシークレットフィールドに入力します。 3番目の秘密については、
<ACR名>手順3で記録したコンテナアプリに割り当てられた名前で チャレンジ 1。秘密の名前 秘密の価値 コンテナアプリ名私のコンテナアプリリソースグループ私のコンテナアプリrgACR_NAME<ACR名>- 「GitHub Action ワークフロー ファイルの作成」に進みます。
GitHub CLI を使用する場合:
リポジトリのルートに一時ファイルを作成します。
~/creds.json をタッチします- 好みのテキスト エディターを使用して、 creds.jsonを開き、チャレンジ 2の手順 6 で作成した JSON 資格情報をコピーします。
シークレットを作成します:
gh シークレット セット AZURE_CREDENTIALS --repo <あなたの GitHub アカウント>/プラットフォーム < ~/creds.jsoncreds.jsonを削除します:
rm ~/creds.jsonこのコマンドを繰り返して、さらに 3 つのシークレットを作成します。
ghシークレットセット <シークレット名> --レポ <あなたの GitHub アカウント>/プラットフォーム繰り返しごとに、
<シークレット名>の1つの値と 秘密の名前 表の列。 プロンプトで、シークレット値列から関連する値を貼り付けます。 3番目の秘密については、<ACR名>手順3で記録したコンテナアプリに割り当てられた名前で チャレンジ 1。秘密の名前 秘密の価値 コンテナアプリ名私のコンテナアプリリソースグループ私のコンテナアプリrgACR_NAME<ACR名>
GitHub Actionワークフローファイルを作成する
マネージド ID とシークレットを用意したら、カナリア ブルーグリーン デプロイメントを自動化する GitHub アクションのワークフロー ファイルを作成できます。
注記： ワークフロー ファイルは、空白が重要な YAML 形式で定義されます。 以下の手順で示すインデントを必ず維持してください。
アクション ワークフロー用のファイルを作成します。
GitHub GUI を使用する場合:
- GitHub リポジトリに移動します。
- [アクション] > [新しいワークフロー] > [これをスキップして自分でワークフローを設定する]を選択します。
GitHub CLI を使用する場合は、 .github/workflowsディレクトリを作成し、 main.ymlという新しいファイルを作成します。
.github/workflowstouch を .github/workflows/main.yml にコピーします。
好みのテキスト エディターを使用して、ワークフローのテキストをmain.ymlに追加します。 最も簡単な方法は、完全なワークフロー ファイルに表示されるテキストをコピーすることです。 あるいは、この手順で注釈を付けたスニペットのセットを追加して、ファイルを手動でビルドすることもできます。
注記： ワークフロー ファイルは、空白が重要な YAML 形式で定義されます。 スニペットをコピーする場合は、必ずインデントを保持してください (さらに念のため、ファイルを完全なワークフロー ファイルと比較してください)。
ワークフローの名前を定義します。
名前： Azure にデプロイメイン ブランチにプッシュまたはプル リクエストが行われたときに実行されるワークフローを構成します。
on: push: ブランチ: - main pull_request: ブランチ: - mainジョブセクションで、コードをチェックアウトし、Azure にログインして、アプリケーションを Azure Container App にデプロイするビルド デプロイジョブを定義します。ジョブ: ビルド-デプロイ: 実行先: ubuntu-22.04 ステップ: - 名前: コードベースの使用を確認してください: actions/checkout@v3 - name: Azure へのログインには、次の認証情報を使用します: azure/login@v1: creds:${{ secrets.AZURE_CREDENTIALS } } - 名前： コンテナー アプリをビルドしてデプロイします。実行: | # コンテナー アプリ拡張機能を手動で追加します。az extension add --name containerapp --upgrade # Azure CLI を使用して更新をデプロイします。az containerapp up -n${{ secrets.CONTAINER_APP_NAME } }\ -g${{ secrets.RESOURCE_GROUP } } \ - ソース${{ github.workspace }}/ingress \ --registry-server${{ secrets.ACR_NAME } }.azurecr.io新しくデプロイされたリビジョンのステージング URL を取得し、GitHub アクションを使用して API エンドポイント/healthに ping を実行し、新しいリビジョンが応答していることを確認する
test-deploymentジョブを定義します。 正常性チェックが成功すると、コンテナー アプリ上の Azure Traffic Manager が更新され、すべてのトラフィックが新しくデプロイされたコンテナーに向けられるようになります。注記： 必ず、前の箇条書きで定義した
build-deployキーと同じレベルでtest-deploymentキーをインデントしてください。テストデプロイメント: 必要: build-deploy 実行環境: ubuntu-22.04 手順: - 名前: Azure へのログインには、次の認証情報を使用します: azure/login@v1: creds:${{ secrets.AZURE_CREDENTIALS } } - 名前： 新しいコンテナー名を取得します。実行: | # コンテナー アプリ拡張機能を手動で追加します。az extension add --name containerapp --upgrade # 最後にデプロイされたリビジョン名を取得します。REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # 最後にデプロイされたリビジョンの FQDN を取得します REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # env vars に値を保存します echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: テストデプロイメント ID: test-deployment 使用: jtalk/url-health-check-action@v3 # エンドポイントにアクセスする Marketplace アクション: url: "https://${{ env.REVISION_FQDN } }/health" # ステージングエンドポイント - 名前: デプロイが成功しました run: | echo "デプロイが成功しました! 新しいリビジョンを有効にする" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --リビジョン重み "${{ env.REVISION_NAME } }=100"
完全なワークフローファイル
これはアクション ワークフロー ファイルの完全なテキストです。
名前： Azure にデプロイ: push: ブランチ: - main pull_request: ブランチ: - main ジョブ: build-deploy: 実行先: ubuntu-22.04 ステップ: - 名前: コードベースの使用を確認してください: actions/checkout@v3 - name: Azure へのログインには、次の認証情報を使用します: azure/login@v1: creds:${{ secrets.AZURE_CREDENTIALS } } - 名前： コンテナーをビルドしてデプロイします。実行: | # containerapp 拡張機能を手動で追加します。az extension add --name containerapp -upgrade # Azure CLI を使用して更新をデプロイします。az containerapp up -n${{ secrets.CONTAINER_APP_NAME } } \ -g${{ secrets.RESOURCE_GROUP } } \ - ソース${{ github.workspace }}/ingress \ --registry-server${{ secrets.ACR_NAME } }.azurecr.io テスト デプロイメント: ニーズ: ビルド デプロイメント 実行環境: ubuntu-22.04 ステップ: - 名前: Azure へのログインには、次の認証情報を使用します: azure/login@v1: creds:${{ secrets.AZURE_CREDENTIALS } } - 名前： 新しいコンテナー名を取得します。実行: | # Azure CLI の containerapp 拡張機能をインストールします。az extension add --name containerapp --upgrade # 最後にデプロイされたリビジョン名を取得します。REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # 最後にデプロイされたリビジョンの FQDN を取得します REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # env vars に値を保存します echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: テストデプロイメント ID: test-deployment 使用: jtalk/url-health-check-action@v3 # エンドポイントにアクセスする Marketplace アクション: url: "https://${{ env.REVISION_FQDN } }/health" # ステージングエンドポイント - 名前: デプロイが成功しました run: | echo "デプロイが成功しました! 新しいリビジョンを有効にする" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --リビジョン重み "${{ env.REVISION_NAME } }=100"
アクションワークフローを実行する
GitHub GUI を使用する場合:
- [コミットの開始]をクリックし、必要に応じてコミット メッセージを追加し、ダイアログ ボックスで[新しいファイルのコミット]を選択します。 新しいワークフロー ファイルがメイン ブランチにマージされ、実行が開始されます。
- ワークフローの進行状況を監視するには、 [アクション]をクリックします。
GitHub CLI を使用する場合:
main.yml をGit ステージング領域に追加します。
git で .github/workflows/main.yml を追加します。ファイルをコミットします:
git commit -m "feat: GitHub Actions ワークフローを作成する"変更を GitHub にプッシュします。
gitプッシュワークフローの進行状況を監視します。
gh ワークフロービュー main.yml --repo <あなたの GitHub アカウント>/プラットフォーム
課題4: GitHub Actionsワークフローをテストする
このチャレンジでは、ワークフローをテストします。 まず、Ingress ロードバランサーへの正常な更新をシミュレートし、アプリケーションが更新されたことを確認します。 次に、失敗した更新 (内部サーバー エラーの原因) をシミュレートし、公開されたアプリケーションが変更されていないことを確認します。
アップデートを成功させる
正常な更新を作成し、ワークフローが成功することを確認します。
GitHub GUI を使用する場合:
- コード > ingress > default.conf.templateを選択します。
- ツールヒント「このファイルを編集」の付いた鉛筆アイコンを選択して、 default.conf.template を編集用に開きます。
ファイルの末尾近くにある
location/healthブロックで、returnディレクティブを次のように変更します。location /health { access_log off; return 200 "更新に成功しました!\n"; }- ダイアログボックスで、 「このコミットの新しいブランチを作成してプルリクエストを開始する」を選択し、 「変更を提案する」を選択します。
- プル リクエスト テンプレートにアクセスするには、 「プル リクエストの作成」をクリックします。
- プル リクエストを作成するには、もう一度[プル リクエストの作成]をクリックします。
- ワークフローの進行状況を監視するには、 [アクション]をクリックします。
- ワークフローが完了したら、コンテナアプリに移動します。 <ACR_URL>/健康 エンドポイントでは、 <ACR_URL> のステップ3でメモしたURLです。 チャレンジ 1。 「更新
が成功しました!」というメッセージに注目してください。 ターミナルセッションを開始し、アプリにヘルスチェックリクエストを送信することでメッセージを確認できます。
<ACR_URL>ステップ3で記録した値で チャレンジ 1:カール <ACR_URL>/健康アップデート成功！- 失敗した更新に進みます。
GitHub CLI を使用する場合:
patch-1という新しいブランチを作成します。
git チェックアウト -b パッチ 1好みのテキスト エディターでingress/default.conf.templateを開き、ファイルの末尾近くにある
location/healthブロックで、returnディレクティブを次のように変更します。location /health { access_log off; return 200 "更新に成功しました!\n"; }default.conf.template をGit ステージング領域に追加します。
git で ingress/default.conf.template を追加します。ファイルをコミットします:
git commit -m "feat: NGINX ingress を更新"変更を GitHub にプッシュします。
git プッシュ --set-upstream origin patch-1プルリクエスト (PR) を作成します。
gh pr create --head patch-1 --fill --repo <あなたのGitHubアカウント> /プラットフォームワークフローの進行状況を監視します。
gh ワークフロービュー main.yml --repo <あなたの GitHub アカウント>/プラットフォームワークフローが完了したら、アプリにヘルスチェックリクエストを送信し、
<ACR_URL>ステップ3で記録した値で チャレンジ 1:カール <ACR_URL>/健康 アップデート成功！
更新に失敗する
ここで、失敗した更新を作成し、ワークフローが失敗するのを確認します。 これは基本的に、 「更新を成功させる」の手順を繰り返しますが、 returnディレクティブの値は異なります。
GitHub GUI を使用する場合:
- コード > ingress > default.conf.templateを選択します。
- 左上で、 main を選択し、前のセクションで作成したpatch-1で終わるブランチの名前を選択します。
- ツールヒント「このファイルを編集」の付いた鉛筆アイコンを選択して、 default.conf.template を編集用に開きます。
次のように
returnディレクティブを変更します。location /health { access_log off; return 500 "更新に失敗しました!\n"; }- -patch-1 ブランチに直接コミットを選択し、変更をコミットします。
- ワークフローの進行状況を監視するには、 「アクション」を選択します。 PR 内のファイルが更新されると、ワークフローが再度実行されることに注意してください。
ワークフローが完了したら、コンテナアプリに移動します。 <ACR_URL>/健康 エンドポイントでは、 <ACR_URL> のステップ3で記録したURLです。 チャレンジ 1。
メッセージは
「更新が成功しました!」です (前回の更新が成功した後と同じです)。 矛盾しているように思えるかもしれませんが、実際にはこの更新が失敗したことが確認されています。更新の試みの結果、ステータスが500(内部サーバーエラーを意味します) が適用されませんでした。ターミナルセッションを開始し、アプリにヘルスチェックリクエストを送信することでメッセージを確認できます。
<ACR_URL>ステップ3で記録した値で チャレンジ 1:カール <ACR_URL>/健康アップデート成功！
GitHub CLI を使用する場合:
前のセクションで作成したpatch-1ブランチを確認します。
git チェックアウト パッチ 1好みのテキスト エディターでingress/default.conf.templateを開き、次のように
returnディレクティブを変更します。location /health { access_log off; return 500 "更新に失敗しました!\n"; }default.conf.template をGit ステージング領域に追加します。
git で ingress/default.conf.template を追加します。ファイルをコミットします:
git commit -m "feat: NGINX ingress を再度更新"変更を GitHub にプッシュします。
gitプッシュワークフローの進行状況を監視します。
gh ワークフロービュー main.yml --repo <あなたの GitHub アカウント>/プラットフォームワークフローが完了したら、アプリにヘルスチェックリクエストを送信し、
<ACR_URL>ステップ3で記録した値で チャレンジ 1:カール <ACR_URL>/健康アップデート成功！メッセージが
「更新が成功しました!」 (前回の更新が成功した後と同じ) であることは矛盾しているように思えるかもしれません。 矛盾しているように思えるかもしれませんが、実際にはこの更新が失敗したことが確認されています。更新の試みの結果、ステータス500(内部サーバーエラーを意味します) が適用されませんでした。
リソースのクリーンアップ
将来的に料金が発生する可能性を回避するために、チュートリアルでデプロイした Azure リソースを削除することをお勧めします。
az グループ削除 -n コンテナー アプリ rg -y
必要に応じて、作成したフォークを削除することもできます。
GitHub GUI を使用する場合:
- [設定]をクリックします。
- ページの一番下までスクロールします。
- 「このリポジトリを削除」をクリックします。
- タイプ <あなたの GitHub アカウント>/プラットフォーム 選択して 結果は理解しています。このリポジトリを削除してください。
GitHub CLI を使用する場合:
gh repo delete <あなたのGitHubアカウント> /platform -yes
次のステップ
おめでとう！ GitHub Actions を使用してマイクロサービス アプリのカナリア ブルーグリーン デプロイメントを実行する方法を学びました。DevOps の知識をさらに深めるには、GitHub ドキュメントの次の記事を参照してください。
カナリア デプロイメントの 2 番目のステップ (本番環境でのテスト) を試す準備ができたら、ブログの Microservices March 2022 のチュートリアル「カナリア デプロイメントによる稼働時間と回復力の向上」をご覧ください。 NGINX Service Mesh を使用して、段階的に新しいアプリ バージョンに移行します。 デプロイメントがまだサービス メッシュを必要とするほど複雑でない場合や、Kubernetes を使用していない場合でも、Ingress コントローラーまたはロード バランサーのみを使用するより単純なデプロイメントには原則が適用されます。
マイクロサービスに関する学習を継続するには、「Microservices March 2023」をご覧ください。 ユニット 3「自動化によるマイクロサービス デプロイメントの加速」では、デプロイメントの自動化について詳しく学習します。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"