0

私は、templatesの使用とtroubleshootの展開の失敗を含め、Azureのautomatically deploying resources groupsに関するさまざまな記事を読んでいます。自動化されたAzureリソースグループの配備でエラー/障害はどのように処理されますか?

これらの記事で明らかにされていない点は、展開の途中でエラーが発生した場合にロールバック機能が構築されているかどうか、および/またはリソースインフラストラクチャを最後の正常な状態に戻す最善の方法です。

たとえば、Octopus Deployには、障害が発生した場合にのみトリガされる特定のビルドステップの概念があり、基本的にはすべてが展開が開始される前の状態に戻されます。

コマンドレットを実行して実際に展開を実行する前に潜在的なエラーを減らすことができ、展開後のプロビジョニング状態を表示することが可能であることがわかりますGet-AzureRmResourceGroupDeployment

enter image description here

そこから私はfailedの状態をチェックし、条件付きで失敗した後にクリーンアップするためのスクリプトを実行することができます。

しかし、このシナリオに対応するために何かが組み込まれていますか?

答えて

1

既存の環境の上に配置をロールオーバーすることは可能ですが、テンプレートの主な目的は、新しい環境を展開することです(またはそうであるように見えます)。

これは途中で何かが失敗した場合は、すべてを削除してからやり直すことを意味します。または、自分のロジックを作成して、その理由を理解してください。 Azureが失敗した場合に唯一行うのは、それをあなたに報告することです。あなたがそれにどのように反応するかを決めるのはあなた次第です。

私の個人的なアプローチは、テンプレート(VM、ストレージなど)を介して基本ビルディングブロックを展開し、構成管理エンジンにソフトウェアの展開と構成のより複雑なタスクを引き継ぐことです。物事を転がして修復するインテリジェンスを持っているものがあります。

+0

ARMテンプレートを使用すると、初期導入後すぐに同じスクリプトを再配備することができますし、同じ結果(変更なし)を取得することを意味し、冪等です。テンプレートに別のVMを追加して再展開する場合は、既存のVMはそのまま残り、新しいVMが追加されます。 – Lewis

+0

@Lewis問題は、既存のインフラストラクチャ全体に変更されたテンプレートをローリングした結果が矛盾していることです。何が修正されるのか、何が無視されるのかは必ずしも明確ではありません。 Azureは、トップレベルのリソース(VMなど)の存在を確認するようですが、追加のディスクなどのプロパティ設定は無視されますので、VMを追加することはできますが、それ以上の微妙なものはありません。問題にぶつかる –

0

これは私がまとめたものです。それは助けるかもしれませんが、Test-AzureRmResourceGroupDeploymentからの結果が成功するとnullですが、失敗したときにオブジェクトを持つため、基本的には独自のエラーを投げる必要があります。

Do{ 
    Try{ 
     Write-Output "Testing Deployment..." 
     If ($TestResult = Test-AzureRmResourceGroupDeployment -ResourceGroupName $ResourceGroupName -TemplateFile $VMTemplatePath -TemplateParameterObject $VMDeploymentParameters) { 
      Throw "Testing failed.`r`n$($TestResult.Message)`r`n" 
     } 
     Write-Output "Testing complete." 
     $TestResponse = "N" 
    } 
    Catch{ 
     Write-Output $_ 
     If ($TestResponse = (Read-Host "Would you like to try again? Y/N.") -ne "Y") { Exit } 
    } 
} 
While($TestResponse -eq "Y") 

乾杯

ルイス

関連する問題