ARM テンプレートに条件付きロジックを追加する
場合によっては、特定の条件下で、必要に応じてリソースをデプロイする必要があります。 一般的なケースは、VM にロード バランサーを追加する場合です。 たとえば、eコマース サイトがあり、そのサイトが大規模な販売からのトラフィックの増加に確実に耐えられるようにする場合を考えてみましょう。 ロード バランサーはリソースの一種であり、VM に関連付けることができます。 規則を条件付きで追加することにより、対象の VM に適用されるロード バランサーを "有効" または "無効" にします。
次のような状況を想像してください。
- 既存のリソース。 テンプレートでリソースを指定してデプロイするとき、次の 2 つのいずれかが発生します。 リソースがデプロイされるか、既に存在する場合はデプロイされません。 リソースが存在するかどうかのチェックは、Azure Resource Manager によって自動的に行われます。これは暗黙的です。 問題は、事前に何かが存在することを確認する "方法" を判断する際にこのメカニズムを利用できるかどうかです。
- 分岐ロジック。 テンプレートに渡すパラメーターによっては、デプロイ時に、別のリソースのセットをデプロイすることが必要になる場合があります。 ここで表現するものは、"分岐ロジック" と呼ばれています。 パラメーターに特定の型の値が含まれている場合は、最初の分岐を選択します。 それ以外の場合は、2 番目または 3 番目の分岐を選択してデプロイします。 分岐ロジックはこのように続きます。
上記のいずれの状況も、条件付きロジックが適用されているシナリオを表します。 ロジックは、Resource Manager システム自体にあるか、または明示的に表現する必要があります。
条件付きデプロイ
condition コンストラクトを使用して、何かをデプロイするかどうかを表すことができます。 これは、リソース要素にアタッチする、true または false のいずれかの値を持つプロパティです。 通常、テンプレートでの condition コンストラクトは次の JSON のようになります。
"resources" : [
{
"condition": "[parameters('shouldDeploy')]"
}
]
上記の JSON では、condition プロパティがリソースに追加されています。 プロパティの値は、shouldDeployパラメーターの値として評価されます。
評価
condition コンストラクトを評価するには 2 つの方法があります。 これらの 2 つの方法について理解し、conditional ロジックの表現方法の選択に適用できます。 2 つの方法は次のとおりです。
値が true または false である。 たとえば、次のようなコンストラクトがあるとします。
"condition": "[parameters('deployAccount')]"deployAccountの値は、デプロイ時に値を渡すことができるパラメーターであるか、既定値にフォールバックすることができます。 使用方法に関係なく、値は厳密に false または true になります。 ブール型ではない別の値を割り当てようとすると、エラーが発生します。式が true または false に評価される。 ここでは、true または false の厳密な値を
conditionコンストラクトに割り当てる代わりに、組み込みのテンプレート関数equals(arg1, arg2)を使用します。 関数が true と評価されるためには、arg1がarg2と同じである必要があります。 これで、conditionコンストラクトはこのように表現できるようになりました。"condition": "[equals(parameters('newOrExisting'),'new')]"equals()関数を使用すると、パラメーターに渡す値はtrueやfalseである必要がなくなります。equals()関数の 2 番目の引数と一致する必要があります。 上の JSON の例では、関数がtrueと評価されるためには、newOrExistingパラメーターの値がnewという文字列と一致している必要があります。