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

2.1K Views

April 21, 24

スライド概要

Jazug 2024 のショートセッション
https://jazug.connpass.com/event/311408/

profile-image

クラウドメインの一兵卒 インフラ全般が好きな人

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

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

2.

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

3.

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

4.

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

5.

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

6.

検証コマンド 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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

注意事項:再作成

19.

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

20.

DeployStackのお片付け

21.

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