同時にデプロイすると失敗するリソースがあるように思う
Bicep で IaC しているときに、徐々にインフラを育てていくとうまくいっていたのですが、改めて下から上まで一発で作ろうと思うとこける 可能性が高いように感じる リソースを備忘録がてら並べておきます。
また、対処策もできれば一応書いておきます。
- 1 つの ExpressRoute Gateway に対する複数の Connection リソース
- Connection リソースと Azure Route Server リソース
1 つの ExpressRoute Gateway に対する複数の Connection リソース
どうもこれはこける可能性が高い気がします。
対応方法の 1 つめとして、Bicep の for 構文と batchSize(int) デコレーターを使います。
for 構文だけでは並列実行になってしまいますが、batchSize(1) としていすることで実質、順次実行に変えてしまいます。
@batchSize(1)
module conn '../lib/connection-ergw.bicep' = [for cct in cct_arr: {
name: 'conn-${cct.name}-${ergw00.name}'
params: {
cctName: cct.name
cctRGName: cct.rgName
ergwName: ergw00.name
}
}]
配列でのデプロイがしづらいケースでは、仕方がないので conn01、conn02 などと定義したうえで、conn02 に対して明示的に conn01 への dependsOn を書いてしまします。
これにより、ARM 的に順次実行となります。
仮に並列実行となってしまい、Connection が failed になった場合、削除 → 作成とやってもあまり時間のロスはありません。
ただ、ExpressRoute Gateway の場合には時間がかかってしまいます。
その場合には、一目では意味がないように見える以下の PowerShell を実行すると直ることがあります。
$ergw = Get-AzVirtualNetworkGateway -ResourceGroupName spoke-hairpin -Name ergw-hub10
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $ergw
Connection リソースと Azure Route Server リソース
ExpressRoute Gateway に対して両方とも影響があるということなのか、これら 2 つも同時にデプロイすると失敗するケースが多いように思います。
こちらに関してはどちらかにもう片方のリソースに対する明示的な dependsOn を指定するほか解消方法はないかと思います。
Discussion