デプロイスタックの使い方を考えてミタ

デプロイスタックの使い方を考えてミタ ～StaticWebAppsから始めるコード管理～

Whoami  今年で30歳  クラウド大好き4年目 （ふれっしゅめん）  最近はAzure触る機会がな くなって悲しい Twitter：ryuuu_ch

きっかけ：RBACでリソース管理めんどい

デプロイスタックとは  Azure デプロイ スタックは、Azure リソースのグループをアトミック単位として管理できるよう にする Azure リソースの一種です。

何が嬉しいのか？  コードから生成したリソース群を追跡、管理できる  BicepやARMテンプレートからデプロイスタックを通じてリソースデプロイするとコードとリソースが常に 一致する  デプロイスタックによりできたリソース群に対してまとめて削除拒否モード、削除変更拒否モードをか けることができる  リソース名など元々のリソースと異なる扱いになる変更だと再作成を伴う  デプロイスタック自体のリソースは管理グループ、サブスクリプション、リソースグループの各スコープに 配置できる 利用者に変更させたくないのであれば権限のない上位スコープに配置すればよい   （e.g.）利用者はリソースグループで所有者を持っていてもそこにあるデプロイスタックで管理されたリソース の変更はできず、デプロイスタック自体の設定変更もできない。 設定変更をしたいのであればプルリクエストを発行し承認されなければならない、、みたいな デプロイスタックの削除でデプロイスタックと関連づいたリソースをマルっと消せるためクリーンアップが 楽！！

検証コマンド az stack sub create \ --name demoStack \ --location ‘japaneast’ \ --deployment-resource-group ‘rg-webapp-test-jpe-01’ \ --template-file './staticwebapps.bicep’ \ --parameters './staticwebapps_parameters.json’ \ --action-on-unmanage deleteAll \ --deny-settings-mode denyWriteAndDelete --yes

設定値をコードで管理しよう  設定値の変更をポータルからできないようにすることで徹底したコード管理が可能  Bicepのテストとデプロイスタックのエラーハンドリングでパイプラインを構築してみる ＜Bicep コードをリントして検証する＞ ＜az bicep lint＞ ＜az stack sub＞ ＜クイックスタート: Bicep を使用してデプロイ スタックを作成してデプロイする＞

• https://learn.microsoft.com/ja-jp/training/modules/test-bicep-code-using-azure-pipelines/3-lint-validate-bicep-code?pivots=powershell
• https://learn.microsoft.com/ja-jp/cli/azure/bicep?view=azure-cli-latest
• https://learn.microsoft.com/ja-jp/cli/azure/stack/sub?view=azure-cli-latest
• https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/quickstart-create-deployment-stacks?tabs=azure-cli,CLI

DeployStack：設定値をコードで管理しよう  即時に設定が変わり、URLに変更もない ＜https://github.com/ryusuke06/deploystack＞※今Privateなので後で公開します

• https://github.com/ryusuke06/deploystack

StaticWebApps：アプリケーションを変更しよう １．devブランチでコンテンツをいじってPR発行 ２．CIが動く ３．StaticWebAppsで環境のプレビューが作成 ４．PRをMergeする ５．本番環境が切り替わる ＜認証されたパスのキャッシュを無効にする＞ ※即時反映させたいためキャッシュは無効

• https://learn.microsoft.com/ja-jp/azure/static-web-apps/configuration

StaticWebApps：アプリケーションを変更しよう ＜https://github.com/ryusuke06/deploystack-app＞

• https://github.com/ryusuke06/deploystack-app

StaticWebApps：アプリケーションを変更しよう

StaticWebApps：アプリケーションを変更しよう

無停止でしたか？  1secで外形監視していたが問題なさそう

DeployStack：エラーを見てみよう  テンプレートスペックとデプロイスタックのエラーの違い  デプロイスタックはエラーが出たタイミングで止まりエラー理由も表示される   エラー検証として選択肢にないリージョンを指定する（e.g. japaneast） Bicepのlintと併せてARMテンプレートよりも十分テストができそう

DeployStack：エラーを見てみよう  既存環境が（計測ミスって恐らくほぼ）止まらずエラー理由も出力される

DeployStack：設定値をコードで管理しよう  リソース名のように別リソース扱いになるような変更の場合は再作成の動作になるみたい ＝＝＝ 以前にテンプレートに含まれていたリソースが削除された場合、デプロイ スタックの指定された actionOnUnmanage 動作に基づいて、そのリソースはデタッチまたは削除されます。 ＝＝＝ ＜デプロイ スタック (プレビュー)＞

• https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/deployment-stacks?tabs=azure-cli

DeployStack：設定値をコードで管理しよう   過去のリソースは削除され疎通が取れなくなった。  何でもかんでもPRをApproveするのではなく、なくなってよいリソースなのか慎重になると吉  自動生成されるWorkflowのYamlファイルもふえちゃった どうしても仕組みとして欲しいならスタック名・デプロイ先リソースグループを変えれば既存リ ソース群が上書きされず、スコープも被らないのでブルーグリーンデプロイみたくできる

注意事項：再作成

BicepのLintをジョブに追加する  せっかくなのでBicepのLint機能も使ってみる

DeployStackのお片付け

まとめ  取っても夢のあるDeployStackのGA待ってるぞ！！！  コストの様子を見つつ自分のサイトを移し替えたいなと検討中