Blueprintsが非推奨になるようなので正当後継になりそうな「デプロイスタック」を試す
モチベ
- ある日社内チャットにてBlueprints(プレビュー)がそのまま非推奨になっていくことを知る
- Blueprintsの検証についてはこちら
- 公式ドキュメント上でも案内がされている
2026 年 7 月 11 日に、Blueprints (プレビュー) は非推奨になります。 既存のブループリントの定義と割り当てを Template Specs とデプロイ スタックに移行します。
- ということで、デプロイスタックを触ったことがなかったため、ざっくり確認しておく
デプロイスタック
- BicepとかARMテンプレートからデプロイする際に、特定のスコープで作成したデプロイスタックを指定してデプロイする
- デプロイする際にデプロイスタックの管理下に置くイメージ
- 実際のリソースは、リソースグループにデプロイされる
- 何がうれしいのか
- 適切なスコープでリソースをプロビジョニングし、追跡する(Blueprints的)
- 拒否設定により管理対象リソースに対する不要な変更の防止(Blueprints的)
とりあえず使ってみよう
- 以前紹介しているこのBicepをデプロイする
- (手元にあったから選んだけど、VPNGWを含んでいるのでデプロイに時間がかかった)
デプロイスタックの作成
ドキュメントに記載の手順に従ってデプロイスタックを作成
az stack sub create \
--name <deployment-stack-name> \
--location <location> \
--template-file <bicep-file-name> \
--deployment-resource-group-name <resource-group-name> \
--deny-settings-mode none
- サブスクリプションスコープでデプロイスタックを作成
- この操作はAzure Portal非対応であるため、Azure CLIで実施
- デプロイスタックの作成のタイミングでBicepファイルも渡す
- よって、パラメータが必要な場合には入力が求められる
- デプロイ先のリソースグループは先に作成しておく必要がある
Azure Portal上から確認
-
[サブスクリプション]の画面に影が薄くも存在している[デプロイスタック]を選択する
-
開いてみると、Bicepでデプロイしたリソース一覧が確認できる
- リソースグループを開くことなく追跡できている
- ただし、何の保護もかけていない状態で、例えばリソースが削除された場合にこの画面上でそれを検知できない
- あくまでデプロイスタックを作成したタイミングでの情報が保持されるっぽい
-
[Inputs]をみると、デプロイ時に指定したパラメータを確認できる
-
拒否の割り当ては
none
で作成しているため、リソースグループ側で権限があれば操作はできる状態
デプロイスタックの構成変更
- [Overview]画面の[Edit and redeploy]から構成変更が可能
-
Update behavior
-
Detach
:Incremental Deployのイメージ。今回のデプロイに含まれないリソースは管理下から外す。 -
Delete
:Complete Deployのイメージ。今回のデプロイに含まれないリソースは削除。
-
-
Lock
-
Cannot Delete
:削除ロック -
Read-Only
:更新ロック
-
- Azure CLIだともっと細かい設定が可能
デプロイスタックの削除
デプロイスタックの削除をするタイミングでは、単にデプロイスタック側を削除するのか、リソースも削除するのか選択肢がある
リソースを保護する
特徴の一つでもある[拒否設定]を試してみる
- 以下のようなスクリプトを実行
az stack sub create \
--name <deployment-stack-name> \
--location <location> \
--template-file <bicep-file-name> \
--deny-settings-mode denyWriteAndDelete \
--deny-settings-excluded-actions Microsoft.Compute/virtualMachines/write \
--deny-settings-excluded-principals <object-id> <object-id>
-
--deny-settings-mode
で大枠として、denyDelete
(削除ロック)やdenyWriteAndDelete
(更新ロック)をかける -
一方で、
--deny-settings-excluded-actions
で、拒否設定から除外するアクションを設定するイメージ -
さらに、
--deny-settings-excluded-principles
で、そもそもこの拒否設定の対象外にするプリンシパルも設定できる -
Azure Portal上では下図のようになる
- ここでは、全体に
denyWriteAndDelete
の保護をかけ -
demo
というユーザはその拒否設定の対象から外し -
Microsoft.Compute/virtualMachines/write
アクションを拒否設定から除外している
- ここでは、全体に
保護の確認
-
以下ようなアクセス権を持つユーザで、管理対象のリソースグループ内のリソースの設定をいろいろといじってみる
- 拒否設定が効いていなければ、リソースを自由に変更できる権限を持つ
- 拒否設定が効いていなければ、リソースを自由に変更できる権限を持つ
-
NICの構成変更:想定通り失敗
- エラーメッセージからも拒否設定が効いていることがわかる
- エラーメッセージからも拒否設定が効いていることがわかる
'zukako@msext.net' には、スコープ '20230724-deployment-stack/providers/Microsoft.Network/networkInterfaces/nic-ubuntu-onp'>nic-ubuntu-onp' でアクション 'Microsoft.Network/networkInterfaces/write' を実行するアクセス許可がありますが、スコープ '/subscriptions/subscriptionID/resourceGroups/20230724-deployment-stack/providers/Microsoft.Network/networkInterfaces/nic-ubuntu-onp' での名前 'Deny assignment 'da8f8185-9276-5d67-bc34-408bde5f76b8' created by Deployment Stack '/subscriptions/subscriptionID/providers/Microsoft.Resources/deploymentStacks/depstack-s2svpn-bgp'.'、ID 'da8f818592765d67bc34408bde5f76b8' の拒否の割り当てが原因で、アクセスが拒否されました。
- 接続の構成の編集:想定通り失敗
除外設定の確認
-
仮想マシンの編集権限を除外しているため、VMサイズを変更してみる
- 想定通り、成功
- 想定通り、成功
-
また、セキュリティプリンシパルとして、
demo
というユーザは保護から除外しているためそのユーザでログイン- 当該リソースグループには[共同作成者]権限を持つ
- 先ほどは失敗していた、NICの構成変更が可能になっている
おわり
- Blueprintsが非推奨になっていくというお気持ち表明ののち、テンプレートスペックとデプロイスタックが案内されている
- デプロイスタックは、試した感じBlueprintsの正当後継サービスになるんだろうなーという感じ
- ただ一部怪しい挙動もあったのが気になるところ
- デプロイスタックのプレビューが外れる日が来るのか、果報は寝て待ちましょう
Discussion