Infrastructure ProvisionersやARMテンプレートを活用する（その２）

最終回となる今回は、ARMテンプレートのテンプレート化にHarnessの変数を使用する方法と、AzureにはないHarnessのロールバック機能を紹介します。

このシリーズの最初のパートでは、Harness Provisionersを使用してARMテンプレートをデプロイする方法について学びました。また、Azure ARMの基本を学び、ARMテンプレートをデプロイする際にHarnessサービスが互いにどのように通信するのかを説明しました。最初のブログを読んで、この情報を再確認しておくことをお勧めします。

シリーズ後半となる今回は、ARMテンプレートのテンプレート化にHarnessの変数を使用する方法と、AzureにはないHarnessのロールバック機能を紹介します。

ARMテンプレートのHarness変数

例えば、Order Service、Payment Service、User Serviceなど、異なるマイクロサービスに対して異なるAzure Webアプリを作成したいとします。同じARMテンプレートを使い、各Webアプリの名前はパラメーターとして定義することができます。

ARMテンプレートのWebアプリ作成セクション

{
      "apiVersion": "2016-08-01",
      "type": "Microsoft.Web/sites",
      "name": "[parameters('siteName')]",
      "location": "[resourceGroup().location]",
      "properties": {
        "siteConfig": {
          "name": "[parameters('siteName')]",
          "appSettings": [
            {
              "name": "WEBSITES_ENABLE_APP_SERVICE_STORAGE",
              "value": "false"
            }
          ],
          "linuxFxVersion": "DOCKER|nginx:alpine"
        },
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('servicePlanName'))]"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('servicePlanName'))]"
      ]
    }

ご覧の通り、名前は"name": "[parameters('siteName')]"と定義されています。

パラメーターファイルは次のようなものになります。

さて、各マイクロサービスには、これらのパラメーターファイルが必要です。

30～50のマイクロサービスを持つことを想像してみてください。これらのファイルを全て維持する必要があるので、保守の問題が起きやすいでしょう。これは全くスケーラブルではありません。

Harnessの変数を使うことで、この負担をたった１つのパラメーターファイルに減らすことができます。ユーザーは、Service、Environment、Secret、WorkflowなどのHarness組み込み変数をARMテンプレートで活用できます。詳しくは、組み込み変数に関する公式ドキュメントをご覧ください。

HarnessはARMデプロイメントのリクエストをデリゲートに送る前に、これらの変数を全て解決します。これはHarnessが提供する強力なツールで、ARMパラメーターの上にARMテンプレートをテンプレート化することができます。

また、パラメーターファイル内のパラメーターをワークフロー変数として定義し、デプロイ時にその値をOrderServiceやPaymentServiceなどとして提供することもできます。

デプロイ時に、これらの変数の値を提供することができます。デプロイするマイクロサービスの数だけステージを持つパイプラインを作成し、同じワークフローを使用して、異なる実行時の値を提供することができます。

ステージ１　PaymentService-webapp

ステージ２　OrderService-webapp

Azureポータルでは、同じARMテンプレートとパラメーターファイルを使用して、異なるウェブアプリが作られていることを確認できます。

HarnessはARMデプロイメントのロールバックサポートをどのように提供するか

ARMのデプロイ時に、以下のようなシナリオで障害処理を行う必要があります。

• GitからのARMテンプレートのダウンロード中に不具合が起きた。
• ARMテンプレートの処理に不具合が起きた。
• ARM のデプロイ開始後、Azure側で障害が発生した。

１番目と２番目については、まだデプロイが開始されていないので、何もする必要はありません。３番目では、Harnessはロールバックを実行します。その方法を説明します。

R1とR2という２つのリソースを持つリソースグループ（RG1）があるとします。RG1のARMテンプレートを使って、追加のリソース（R3、R4）をインクリメンタルモードでデプロイしようとしました。R3は正常に作成されましたが、R4を作成する際に何か問題が発生しました。理想的には、以前の状態（この場合、R1とR2の２つのリソースのみ）に戻れるはずです。しかし、Azureはロールバックせずにデプロイメントをそのままにします。RG1にR1、R2、および R3がある状態になってしまいます。これは、Azure がロールバックをネイティブにサポートしていないためです。

Harnessは、既存のインフラに変更を加える前に、リソースグループの現在の状態を保存することで、Azureの制限を克服しました。ロールバックの際、既存のテンプレートはCOMPLETEモードでデプロイされ、テンプレートに記載されたリソースのみがデプロイされるようになります。たとえば、新たにデプロイされたものは全て削除されます。

以下は、ARM デプロイメントを開始する前に発生することの図です。

• マネージャーサービスがARM展開を開始するためのリクエストを送信します。
• デリゲートがAzureにリクエストを送信し、既存のリソースグループ用のテンプレートを生成します。
• AzureがARMテンプレートをデリゲートに送信します。
• デリゲートはJSON応答をマネージャーに転送します。
• マネージャーはARMテンプレートをMongoDBに保存します。

ARMデプロイメント中に何か障害が発生した場合

• マネージャーは実行開始前に保存したJSONテンプレートを取得するためにクエリーを送信します。
• マネージャーは、現在の実行IDを使用して既存のテンプレートを取得します。
• マネージャーがデリゲートに新しい ARMデプロイメントタスクを送信します。
• デリゲートは、既存のARMテンプレートを使用してCOMPLETEモードで新しいデプロイメントを実行します。
• デリゲートはデプロイメントステータスをポーリングします。
• 定期的にデプロイメントステータスがデリゲートから受信され、UIに表示されます。

まとめ

今回で、Harness Infrastructure ProvisionersとARMテンプレートに関するブログシリーズを終了します。

今回は、ARMテンプレート内でのHarness変数の使用と、Harnessのロールバックサポートについて学びました。

基本的なことを学ぶには、シリーズの最初のブログをお気軽に参照してください。もっと詳しく知りたい方は 今すぐデモをご予約ください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。