Infrastructure ProvisionersやARMテンプレートを活用する

ARMテンプレートの基本を学び、Harnessワークフローエンジンを使ってデプロイする方法をご紹介します。このチュートリアルに沿って進んでください。

Harness Infrastructure Provisionersは、TerraformやAWS CloudFormationなどの既知のInfrastructure as Code（IaC）テクノロジーからデプロイインフラのブループリントを定義し、その出力設定をマッピングしてインフラを割り当てます。Infrastructure Provisionersを利用することで、Harnessワークフローはサービスのデプロイ時にインフラを臨機応変に割り当てることができます。このブログでは、Harness ARMプロビジョナーについて学びます。その前に、Azure ARMの基本的なコンセプトを理解しておきましょう。

ARMテンプレートとは？

Azure Resource Manager（ARM）は、AzureにおけるIaCのためのネイティブプラットフォームです。ARMテンプレートは、IaCの一種であり、デプロイに必要なインフラをそこで定義しようという概念です。ポータルのあちこちをクリックして仮想マシンを作成したり、ストレージアカウントをデプロイするためのスクリプトを書いたりする必要はもうありません。代わりに、テンプレートがリソースを定義し、ARM管理レイヤーがインフラを作成します。

ARMテンプレート活用のメリット

Azure環境を管理する際にARMテンプレートを使うと、多くの利点があります。例えば、宣言的な構文を使うことで、複数のデプロイシナリオを処理するための複雑なデプロイスクリプトを記述する必要がなくなります。

さらに、これらのテンプレートは再現性のある結果を提供します。同じテンプレートを書いてデプロイして同じ結果を何度でも得ることができます。逆に、開発インフラに使ったのと同じテンプレートを、本番環境のデプロイに使うこともできます。同じテンプレートを使うことで、リソースや設定の同一性を担保します。

ARMは、デプロイの操作順序も処理します。その結果、ARMは依存するリソースを正しい順序で、可能であれば並行してデプロイして、より高速化します。さらに、PowerShellまたはBashで記述されたデプロイスクリプトでテンプレートを拡張し、完全なエンドツーエンド環境を構築することができます。

ARMテンプレートの基本

テンプレートはJSON（JavaScript Object Notation）構文を使用し、高度な機能も備えています。

テンプレートは宣言的な構文を使用します。これにより、長々とコマンドを書かなくても何をデプロイするかを指定することができます。具体的には、テンプレートはデプロイされるリソースとそのプロパティを指定します。

Resource Managerでテンプレートを検証した後、デプロイへと進められます。このため、デプロイが途中で失敗することはまずありません。

このテンプレートには、以下のパーツが含まれています。

• パラメーター - デプロイ中に異なる環境で同じテンプレートを使用できるようにするための値です。
• 変数 - 異なるテンプレートで再利用するための値です。変数は、パラメーターから値を使うことができます。
• ユーザー定義関数 - カスタマイズされた要素を定義して、テンプレートを簡素化することができます。
• リソース - デプロイするAzureリソースを指定します。
• アウトプット - デプロイされたリソースの返り値です。

以下は、ストレージアカウントを作成するためのARMテンプレートです。

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storagename": {
"type": "string",
"defaultValue": "temp"
}
},
"functions": [],
"variables": {},
"resources": [{
"name": "[parameters('storagename')]",
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2019-06-01",
"location": "[resourceGroup().location]",
"kind": "StorageV2",
"sku": {
"name": "Standard_LRS"
}
}],
"outputs": {}
}

パラメーター

パラメーターを使用すると、デプロイ時に使用するさまざまな値をARMテンプレートに渡すことができます。一般的な例としては、リソースの名前や、リソースをホストするAzureリージョンがあります。パラメーターを使用すると、テンプレートをよりダイナミックに、異なる環境間で使うことができます。

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storagename": {
"value": "anilstorage"
}
}
} 

ARMのデプロイは、以下のモードで行うことができます。

• インクリメンタル
  • このモードでは、デプロイはARMテンプレートに存在する新しいリソースを作成します。ただし、テンプレートに明示されていない限り、Resource Group内の既存のリソースの状態は変更されません。
• コンプリート
  • このモードでは、テンプレートに記載されたリソースのみが作成されます。それ以外の既存のリソースは削除されます。

インクリメンタルモードとコンプリートモードの違いを理解するために、次のシナリオを考えてみましょう。

リソースグループには、以下のリソースがあります。

Resource A

Resource B

Resource C

テンプレートには、以下のリソースがあります。

Resource A

Resource B

Resource D

インクリメンタルモードでデプロイされた場合、リソースグループには以下が残ります。

Resource A

Resource B

Resource C

Resource D

コンプリートモードでデプロイすると、Resource Cは削除されます。リソースグループには以下が残ります。

Resource A

Resource B

Resource D

HarnessがARMテンプレートを展開する方法

まず、ユーザーはARMプロビジョナーを定義します。これは本質的にARMテンプレートの定義を提供することです。
 

ステップ1：ARMプロビジョナーの定義

次のように定義できます。

• インライン
  • Harnessは、テンプレートをローカルストレージに保存します。
  • デプロイ時には、ローカルストレージから取得し、ARMデプロイを実行します。
• リモート
  • テンプレートがGitリポジトリーに存在する場合、ARMプロビジョナーをリモートとして定義することができます。HarnessはユーザーのGitリポジトリーからARMテンプレートを取得し、デプロイを実行します。

注）Harnessは、Azure Blueprintのデプロイにも対応しています。ユーザーは、ARMをARMリソースタイプに選択する必要があります。HarnessがAzure Blueprintをどのようにサポートしているかについては、別の記事で説明する予定です。

ステップ2：ARMのワークフローを定義する

• ユーザーはARMワークフローを作成し、ステップ1で作成したプロビジョナーにマッピングする必要があります。
• ここで、パラメーターファイルを提供できます。前述の通り、インラインまたはGitリポジトリーへのパスを指定できます。

ワークフローの実行中、Harnessはテンプレートとパラメーターファイルをダウンロードします。これらのファイルは、デリゲートの作業ディレクトリーにダウンロードされます。そして、Harness Delegateは、これらのファイルを使用してAzureにデプロイのリクエストを送信します。

インラインの場合

リモートの場合
 

ワークフローを作成し、上記のARMプロビジョナーを選択する必要があります。

ワークフローの実行が終了すると、テンプレートに記載された全てのリソースがAzureに割り当てられます。

以下の手順で行います。

• Download Files → GitリポジトリーからARMテンプレートをダウンロードします。
• Execute ARM Deployment → ユーザーが指定したARMテンプレートを使ってAzureにデプロイ要求を送信します。
• ARM Deployment Steady state →進行中のデプロイの状態をリアルタイムに表示します。

インラインテンプレートの配置の流れ
 

 インラインARMプロビジョナーを作成すると、テンプレートがHarness Mongoに保存されます。

• UIはワークフローの実行を開始するようマネージャーにリクエストを送ります。
• マネージャーはMongoコレクションからテンプレートを取得するリクエストを送信します。
• マネージャーは全てのテンプレート（arm/params）ファイルを受信します。
• マネージャーは全てのテンプレートとその他のメタデータをバンドルして、Taskリクエストをデリゲートに送信します。
• デリゲートは、テンプレート付きのARMデプロイを開始するようAzureにリクエストを送ります。
• デリゲートは、デプロイが成功または失敗するまで、デプロイの状態を取得するために一定間隔でポーリングを続けます。
• ポーリング要求のステータスは、一定時間ごとにマネージャーに送信されます。
• UIは、マネージャーからデプロイの状況について定期的にポーリングし、実行ログに表示します。

リモートテンプレートの展開フロー

デリゲートサービスのインスタンスが複数起動することになります。

• UIはマネージャーにワークフローの実行を開始するようリクエストを送ります。
• マネージャーは、Gitリポジトリーの詳細を含むGit Fetch Taskリクエストをデリゲートに送ります。複数のデリゲートの中から、実行するデリゲートを１つ選びます。
• デリゲートはGitのパスをチェックアウトします。
• デリゲートはGitリポジトリーからテンプレートをダウンロードします。
• デリゲートはテンプレートの詳細をマネージャーに応答として送信します。
• マネージャーはテンプレートに存在するHarness変数をレンダリングし、ARMデプロイの新しいリクエストを送信します。
• デリゲートはAzureにリクエストを送信し、レンダリングされたテンプレートを使用してARMデプロイを開始します。
• デリゲートは定期的にデプロイの状態を確認します。
• デプロイのステータスは、定期的にマネージャーに報告されます。
• UIは、定期的にマネージャーからデプロイステータスをポーリングし、実行ログに表示します。

デリゲートがステップ４の後にデプロイのリクエストを送信しなかったことを不思議に思われたかもしれません。既にARMテンプレートを持っているのに、なぜテンプレートをマネージャーに送信するのでしょうか。それは、テンプレートにHarnessの変数が組み込まれているからです（このブログシリーズの第２回で取り上げます）。デリゲートはステートレスです。つまり、変数については何も知りません。タスクを実行する方法だけを知っています。マネージャーはこれらの変数を解決するために必要な、関連詳細情報を全て持っています。したがって、テンプレートをダウンロードした後、テンプレートをマネージャーに送信し、テンプレートが参照するHarness変数を解決できるようにします。そして、レンダリングされたテンプレートは、別のタスクとして実行するためにデリゲートに送られます。

まとめ

この記事では、ARMテンプレートの基礎と、Harnessワークフローエンジンを使ったデプロイ方法について学びました。さらに、Harnessのデプロイプロセスと、UI、マネージャー、デリゲートの間でどのように通信が行われるかを学びました。次回は、ARMテンプレート内でHarness変数を使用する方法と、Harnessのロールバックサポートについて学びます。

今後もご期待ください。Harness社内でのHarness CD活用事例もお読みになっていただければ幸いです。

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