Azureリソースの設定変更を行って、ミスった場合に、設定変更前の状態に戻したい場合があると思います。
Azure Portalの場合だと、設定した内容の逆の設定を実施して、戻せばよいのですが、戻す作業自体をミスる可能性があり、機械的に戻せる方法があるとベターです。
方法について確認してみました。
- 結論
- ARM テンプレートによるAzure リソースデプロイの基礎（前提知識）
- Q＆A
- Azure Portalでの設定変更前に、バックアップファイルとしてArmテンプレートをダウンロードする運用にすればいいんじゃないの？
- （リソースグループXに、リソースA,B,Cが存在している前提で、）増分モードでリソースグループをスコープとしてデプロイした場合、リソースAは、サービス停止が発生するか。リソースＢ/Ｃはサービス停止も発生するか
- 増分モードでデプロイできるAzureリソースの種類はどれか
- Azure上の既存リソースは、一つのNSGリソースのみです。そのNSGリソースにはルールが３つあるとします。次に、そのうちの２つのルールを含むARMテンプレートを増分モードでデプロイしたとします。その場合、増分モードなので、最終的には元の３つのルールを含むNSGリソースが存在しますか
- 増分モードでのデプロイで、ちゃんと元に戻るのか
- 過去にデプロイ成功したテンプレートは必ずしも再利用できるとは限らない？
- デプロイの最小単位は？
- Azure Portalから、Azure リソースの状態をある時点の状態に戻すことってできない？
- Azure Portal での運用と、ARMテンプレートでの運用の併用は可能か
- データを含むAzureリソース（Azure Storageなど）を、ARMテンプレートから再デプロイした場合、データは残るか（それとも、消えてしまうのか）
- 参考
結論
設定変更を、ARMテンプレートのデプロイで行う運用に切り替えれば可能（設定変更を、Azure Portalから行う場合、手動で設定を戻す以外の方法はない）
ARM テンプレートによるAzure リソースデプロイの基礎（前提知識）
- ARM テンプレートの適用は、リソース単位ではなくリソースグループ単位（一部、リソースグループよりも大きな単位でしか適用できないAzureリソースあり）
- 増分モードと完全モードのデプロイがある（詳細はこちらの記事で記載しています）
- リソースグループ内の特定のリソースのみ設定変更したい（設定を元に戻したい）場合は、「増分モード」を使う必要がある（「完全モード」の場合、対象のリソース以外をARMテンプレートで指定しなかった場合は削除されてしまう。）
Q＆A
勉強会を行った際に、参加者からいただいた質問に対しての回答を記載させていただきます（具体的なイメージが湧くと思います）
Azure Portalでの設定変更前に、バックアップファイルとしてArmテンプレートをダウンロードする運用にすればいいんじゃないの？
Azure Portal 上のテンプレートのエクスポートでは、一部情報が含まれていない場合があり、そのままデプロイした場合に失敗する可能性あります。
以下、一部情報が含まれないケースです（例） ★そもそも、ARMテンプレートは管理プレーンと分類されるような、構成に関する情報をJSON形式で記載したものです。
１．秘密鍵、シークレット等、各サービスが意図してARMテンプレートにエクスポートしないもの
例えばApplication Gatewayにアップロードした証明書の秘密鍵などはARMテンプレートに記載されません。
２．Blobストレージに格納されるBlobデータの様な、データプレーンに該当するため、ARMにエクスポートされないもの
例えばBlobストレージのBlobデータや、SQL DBに格納されるデータなどはARMテンプレートに記載されません。
３．ARMテンプレートと各サービスの互換性がないため、エクスポートされないもの
端的に言えば、ARM テンプレートと各サービスの互換性がないため、エクスポート時に警告が表示されることがあります。
（リソースグループXに、リソースA,B,Cが存在している前提で、）増分モードでリソースグループをスコープとしてデプロイした場合、リソースAは、サービス停止が発生するか。リソースＢ/Ｃはサービス停止も発生するか
回答
対象の ARM テンプレートのデプロイがリソース A のみの場合、リソース B、リソース C は影響を受けません。
一方で、リソース A については、ARM テンプレートのデプロイ時、サービス停止が発生するか否かは、対象のサービス、およびデプロイで更新する内容に依存するため一概には言えません。
停止しない例ですが、ストレージ アカウントの「安全な転送設定」のパラメーターが変更するように、管理プレーンのパラメーター値の設定変更するくらいであれば、ダウンタイムは発生せず、サービス停止も発生しません。
停止する例ですが、Azure API Management というサービスで SKU を Developer から他のレベルに変更するスケーリングの変更をARM テンプレートのデプロイにて実施するような場合は、API Management のサービス側の仕様によりダウンタイムが発生します。
■補足
ARM テンプレートの増分モードでのデプロイでのサービス停止が発生する場合は、Azure Portal から変更を実施してもサービスの停止が発生します（ARMテンプレートからのデプロイだから、停止が発生するというわけではない）
言い換えると、サービスが停止するか否かについては、変更するサービスやその変更内容に依存し、変更のリクエストを実施するツール (Azure Portal から実施するか、ARM テンプレートで実施するか) には依存しません。
■ 参考 : Azure API Management インスタンスのアップグレードとスケーリングを行う # スケールアップおよびスケールダウンの際のダウンタイム | Microsoft Learn
増分モードでデプロイできるAzureリソースの種類はどれか
増分モードでのデプロイに関しては、リソース グループのスコープでのデプロイとなるため、リソース グループでのデプロイに対応している ARM テンプレートのリソースか否か、が判別できる情報となります（「リソースグループのスコープでデプロイ可能」＝「増分モードでデプロイ可能」）。
リソースグループでのデプロイに対応しているかは、（参考画像）のように個々のリソースごとにデプロイ スコープについての記載を確認することで判別可能です。
■ 参考 : Azure リソース リファレンス – Bicep, ARM template & Terraform AzAPI reference | Microsoft Learn
（参考画像）
Azure上の既存リソースは、一つのNSGリソースのみです。そのNSGリソースにはルールが３つあるとします。次に、そのうちの２つのルールを含むARMテンプレートを増分モードでデプロイしたとします。その場合、増分モードなので、最終的には元の３つのルールを含むNSGリソースが存在しますか
いいえ。増分モードの認識が間違っています。最終的には、最後にデプロイしたARMテンプレートに含まれる２つのルールのみを含むNSGリソースが存在します。
増分モードは、あくまでリソース単位の話です。リソース内部の設定項目単位（今回の場合はルール）については、完全モードであろうと、増分モードであろうと、ARMテンプレートの内容が反映されます（冪等性の考えです）。
増分モードでのデプロイで、ちゃんと元に戻るのか
質問
増分モードでリソースAをデプロイした場合で、以下の２つのテンプレートがあったとします。
テンプレートX ・・・現在のAZUREリソースのテンプレート
テンプレートY ・・・一つ前のテンプレート（ロールバックするために使おうとしているテンプレート）
テンプレートXに、テンプレートYには含まれていない設定（たとえばNSGリソースでいうところのNSGルール）が存在した場合、テンプレートYを増分モードでデプロイした場合（ロールバックした場合）、テンプレートYには含まれていなかった設定項目は削除されるのでしょうか。（間違って設定追加をしてしまった場合でも、ちゃんと設定が削除されるのか。設定項目に対して、「有効」「無効」のようがある場合は、設定項目自体が存在するので元に戻りそうな気がするが、テンプレートX,Yの間に設定自体の有無の差異があった場合にどうなるのか）
こちらは、一つの例ですが、現状のAzureリソースの状態と、テンプレートＹの状態にいかなる差異があった場合でも、テンプレートＹの状態に完全に戻るのか。
回答
はい、テンプレート Y を増分モードでデプロイした場合、(以前までのテンプレートの状態との差分ではなく) テンプレート Y に完全に合致する内容でデプロイが実施されます。
そのため、現在の ARM リソースの状況として、テンプレート Y に含まれない項目 (NSG リソースの ARM テンプレート内の NSG ルール) があったとしても、テンプレート Y のデプロイが完了した時点で、このテンプレート Y に含まれていなかった項目は削除されます。
言い換えると、現在の ARM リソースに存在する設定項目の中で、テンプレート Y に含まれない項目があった場合、その内容は既定値に戻ってしまいます。
この点については、ドキュメントでも以下のように記載されており注意が必要です。
■ ご参考 : 展開モード – Azure Resource Manager # 増分モード | Microsoft Learn
過去にデプロイ成功したテンプレートは必ずしも再利用できるとは限らない？
質問
テンプレートＹが過去にデプロイ成功の実績がある場合でも、改めてテンプレートＹをデプロイした場合に失敗するケースがあるか。
例えば、テンプレートYに含まれるリソースＡが、テンプレートYとは全く関係のないリソースＤと何かしらの依存関係があり、過去にテンプレートＹをデプロイした際は、リソースＤが存在していたのでデプロイ成功したが、リソースＤの状態の変化している（たとえば、リソースＤ自体が存在しなくなっている）場合など、テンプレートＹのデプロイに失敗する可能性がある気がするが、どうか。
回答
はい、失敗するケースはあります。
過去にデプロイが成功した際と、対象の ARM テンプレートの関連項目などの状況に変化がないかについては、再デプロイ実施前に整合性チェックをして、必要に応じてARM点テンプレートを修正した上でデプロイを実施する必要があります。
デプロイの最小単位は？
質問
増分モード、完全モードによらずデプロイの最小単位は、リソースグループ単位になるという理解であっているか。（リソースを指定しての、デプロイはできないという認識であっているか）
回答
「リソース」をデプロイするためには「スコープ」の指定が必要であり、この最小単位が「リソース グループ」となります。以下参考ですが、「リソースグループ」より大きな単位（「サブスクリプション」「管理グループ」など）でのデプロイも可能です。
■ 参考 : REST API とテンプレートを使用してリソースをデプロイする – Azure Resource Manager # デプロイのスコープ | Microsoft Learn
■補足
デプロイのスコープとして Azure 全体で用意されている単位としてはリソース グループが最小の単位ですが、一部リソースでは、個々のリソース グループにデプロイされるのではなく、サブスクリプション全体や管理グループなどがデプロイの最小単位となるようなサービスもあります。
サブスクリプション・管理グループ・テナント単位でデプロイ可能なリソースについて、下記デプロイ スコープの公開情報内で記載があります。(ただ、これらに記載のリソースがすべて最小単位がサブスクリプション・管理グループ・テナントとなるものではなく、サブスクリプション単位・管理グループ単位・テナント単位でもデプロイが可能であり、リソース グループが最小単位となるリソースも含まれる点は注意ください)
（参考 URL)
サブスクリプションにリソースをデプロイする – Azure Resource Manager | Microsoft Learn
管理グループにリソースをデプロイする – Azure Resource Manager | Microsoft Learn
リソースをテナントにデプロイする – Azure Resource Manager | Microsoft Learn
デプロイ スコープがリソース グループより上位の場合、デプロイ モードの指定はできませんが、増分モードと同等の動き (以前までのテンプレートの状態との差分ではなく、 適用したテンプレート に完全に合致する内容でデプロイが実施) でのデプロイとなります。
Azure Portalから、Azure リソースの状態をある時点の状態に戻すことってできない？
質問
Azure Portalから設定変更を行う運用を想定した場合、Azure Portalで設定変更前の状態に戻す機能はないか。
直前の操作した設定を元に戻すような機能はない場合、定期的にAzure上でAzureリソースの設定情報をバックアップをとってくれていて、ある時点（たとえば、1日前の0時など）に戻すようなことは、Azure Portalからできないか
回答
Azure Portalにおいて「変更前の Azure リソースの設定情報をスナップショットなどような形で取得しており、そのスナップショットを利用して特定の時点に戻す」といった機能はありません。
Azure Portalから設定変更を行う運用を想定した場合、Azureリソースを設定変更前の状態に戻すには、設定変更前のパラメーターに明示的に指定しなおす、などの形で Azure Portal で設定変更前の値に再度変更するしかなさそうです。
Azure Portal での運用と、ARMテンプレートでの運用の併用は可能か
質問
「Azure Portalで設定変更した際に、設定が間違っていた場合に、変更前の状態に戻せるようにしたい」が実現したいことです。 Azure リソースを、設定前の状態に戻したい場合、増分モードのデプロイが現実解だと感じていますが、その場合、設定変更などの運用は、すべてARM temprateに一元化する必要があるのでしょうか（Azure Portalからの設定変更はしない運用にする必要があるのでしょうか）
Azure Portalから設定変更をした後に、ARMテンプレートをエクスポートすることも可能かと思いますが、エクスポートしたテンプレートは情報が欠落している可能性あると、以前MSサポートの方から伺ったことがあり、エクスポートしたテンプレートをそのまま、デプロイしてもデプロイ失敗する可能性があると認識しています。そうなると、「設定変更などの運用は、すべてARM temprateに一元化する」しか選択肢がないような気がしていますが、認識あっておりますでしょうか（ARM temprateによる設定変更の運用は一定のスキルが必要なので、できればAzure Portalでの運用が望ましいです）
回答
はい、認識合っています。
Azure Portal 上のテンプレートのエクスポートでは、一部情報が含まれていない場合があり、そのままデプロイした場合に失敗する可能性あります。
Azure Portal やそのほか対象サービスの REST API で直接リソースの update の PUT リクエストなどで設定変更をした場合、この設定変更内容を ARM テンプレートに正確に反映させることは難しいと思います（労力面、品質面）。
そのため、すべての設定変更を網羅するためには、設定変更の運用は ARM テンプレートにて一元管理するのが望ましいと思います。
もちろん、運用のハードルやコストなどの要件を勘案の結果、設定変更するパラメーター値について変更前の内容をスクリーンショットやAzure PowerShell などのコマンドの Get リクエストの結果などから取得した上で、変更を実施、もしも変更後問題があった際は変更前に取得していた情報をもとに再度変更前の値への変更操作を実施、といった運用を選択するケースも多いです。
データを含むAzureリソース（Azure Storageなど）を、ARMテンプレートから再デプロイした場合、データは残るか（それとも、消えてしまうのか）
基本的には、増分デプロイであれば管理プレーンの更新となるので、ユーザー データはそのまま残ります。しかしながら ARM テンプレートでの増分デプロイに限らず、リソースの構成を変更する操作においては、各Azureサービスで固有の注意点や前提条件等がある場合が多いです。詳細については、各Azureサービス観点で詳細を確認した方がよいと思います。
参考
「デプロイ履歴」機能について
リソース管理を、Azure PortalではなくARMテンプレートで行うこと前提ですが、元に戻す作業については、「デプロイ履歴」機能を使うことができます（設定変更は、ARMテンプレートの「増分デプロイ」で行い、戻す作業は「デプロイ履歴」機能で行うイメージです）。
デプロイ履歴からのロールバック方法（例）
1.以下チュートリアル ページの内容をもとに、デプロイするストレージ アカウントの ARM テンプレートの内容を用意
■ ご参考 : チュートリアル – テンプレートにリソースを追加する – Azure Resource Manager # リソースの追加 | Microsoft Learn
2.下記コマンドにて “rollback-test” リソース グループ上で上記ストレージ アカウントのデプロイを実施
3.対象のストレージ アカウントがデプロイされ、”supportsHttpsTrafficOnly”: true が指定された設定になっていることを確認
4.設定変更として、”supportsHttpsTrafficOnly”: false への変更を実施すると仮定し、変更後の ARM テンプレートを用意して設定変更のデプロイを実施。
設定が変更されていることを対象のリソースで確認。
5.対象リソース グループのデプロイ履歴から、上記 2 回分のデプロイ履歴を確認。ロールバックのため、初回のデプロイ名を選択し、再デプロイをクリック。
([テンプレートの表示] をクリックするとでテンプレートを手元にダウンロードできるため、テンプレートのデプロイを手元の PowerShell などのコマンドで実行することも可能です。
また、デプロイ履歴からの確認ではなく、ロールバックしたい時点の対象リソースの ARM テンプレート ファイルが手元にある場合、そのテンプレートを使用して再度デプロイする方法でももちろん問題ありません)
6.初回のデプロイに使用された ARM テンプレートを使用したデプロイの画面に遷移するので、そのまま [確認と作成] から作成を実行して、デプロイを実施。
7.デプロイ完了後、対象リソースが初回の設定内容に戻っていることを確認。
デプロイ履歴の履歴数
デプロイ履歴の上限はリソース グループごとに 600件となります。
— (引用ここから) —
デプロイが 700 件を超えると、履歴からデプロイが削除されます。 履歴が 600 件に減るまで、Azure Resource Manager によってデプロイが削除されます。 常に、最も古いデプロイが先に削除されます。
— (引用ここまで) —
コメント