0

Ich habe verschiedene Artikel auf automatically deploying resources groups in Azure gelesen, einschließlich der Verwendung von templates und wie zu troubleshoot fehlgeschlagenen Bereitstellungen. In diesen Artikeln ist nicht klar, welche Rollback-Funktionen ggf. erstellt werden und/oder die beste Möglichkeit, die Ressourceninfrastruktur bei Fehlern während der Bereitstellung zurück in den letzten erfolgreichen Zustand zu versetzen.Wie werden Fehler/Fehler in automatisierten Azure Resource Group-Bereitstellungen behandelt?

Zum Beispiel gibt es in Octopus Deploy die Vorstellung von bestimmten Build-Schritten, die nur im Falle eines Fehlers ausgelöst werden und im Wesentlichen alles so zurückbringen, wie es vor der Bereitstellung war.

Ich kann sehen, dass es möglich ist, Ihre Vorlagen und Infrastruktur „Validierung“ durch das Test-AzureRmResourceGroupDeployment Cmdlets läuft tatsächlich mögliche Fehler zu reduzieren, bevor die Bereitstellung ausgeführt wird, und auch, dass es möglich ist, die Bereitstellung Zustand nach Bereitstellung anzuzeigen Get-AzureRmResourceGroupDeployment, indem Sie :

enter image description here

von denen konnte ich für den failed Status überprüfen und bedingt ein Skript zu bereinigen nach dem Scheitern führen.

Ist jedoch etwas eingebaut, um dieses Szenario zu berücksichtigen?

Antwort

1

Es ist zwar möglich, eine Bereitstellung über den Anfang einer vorhandenen Umgebung hinaus zu rollen. Der Hauptzweck von Vorlagen ist (oder scheint zu sein) die Bereitstellung einer neuen Umgebung.

Was bedeutet, dass, wenn etwas auf dem Weg scheitert, Sie das Ganze löschen und neu beginnen. Oder erstellen Sie Ihre eigene Logik, um hineinzugehen und herauszufinden, warum. Das einzige, was Azure im Falle eines Fehlers tun wird, ist es Ihnen zu melden. Es liegt dann an Ihnen, die Entscheidung zu treffen, wie Sie darauf reagieren werden.

Mein persönlicher Ansatz besteht darin, die grundlegenden Bausteine ​​über Vorlagen (also VMs, Speicher usw.) zu implementieren und dann eine Konfigurationsmanagement-Engine für die komplexeren Aufgaben der Bereitstellung von Software und der Konfiguration zu übernehmen. Etwas, das die Intelligenz hat, Dinge zurückzurollen und zu reparieren.

+0

ARM-Vorlagen ist idempotent, was bedeutet, dass Sie das gleiche Skript unmittelbar nach einer anfänglichen Bereitstellung erneut bereitstellen können, und Sie werden das gleiche Ergebnis (keine Änderungen) erhalten. Wenn Sie sich dazu entschließen, Ihrer Vorlage eine weitere VM hinzuzufügen und sie erneut zu implementieren, verbleiben die vorhandenen VMs, und die neue VM wird hinzugefügt. – Lewis

+0

@Lewis Das Problem besteht darin, dass die Ergebnisse einer geänderten Vorlage in einer vorhandenen Infrastruktur nicht konsistent sind. Es ist nicht immer klar, was geändert wird und was ignoriert wird. Azure scheint eine Überprüfung der Existenz der Ressource der obersten Ebene durchzuführen (dh der VM, ignoriert jedoch alle Eigenschaftseinstellungen wie zusätzliche Festplatten usw.). Sie können also eine VM hinzufügen, aber alles, was subtiler ist als das und Sie sind werde auf Probleme stoßen –

0

Das habe ich zusammengestellt. Es kann helfen, aber im Grunde müssen Sie Ihren eigenen Fehler werfen, da das Ergebnis von Test-AzureRmResourceGroupDeployment für Erfolg NULL ist, aber ein Objekt hat, wenn es fehlschlägt.

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") 

Prost

Lewis

Verwandte Themen