Empfehlungen für sichere Bereitstellungsmethoden

  • Artikel

Gilt für diese Empfehlung der Prüfliste "Operational Excellence" für Azure Well-Architected Framework:

OE:11 Definieren Sie klar die Sicheren Bereitstellungsmethoden Ihrer Workload. Heben Sie die Ideale kleiner, inkrementeller, qualitätsorientierter Releasemethoden hervor. Verwenden Sie moderne Bereitstellungsmuster und progressive Expositionstechniken, um Risiken zu kontrollieren. Berücksichtigen Sie Routinebereitstellungen und Notfall- oder Hotfixbereitstellungen.

In diesem Leitfaden werden die Empfehlungen für die Verwendung von Methoden für die sichere Bereitstellung (Safe Deployment Practices, SDP) beschrieben. Sichere Bereitstellungsprozesse und -verfahren definieren, wie Änderungen an Ihrer Workload sicher vorgenommen und bereitgestellt werden. Die Implementierung von SDP erfordert, dass Sie über Bereitstellungen im Hinblick auf das Risikomanagement nachdenken. Sie können das Risiko menschlicher Fehler in Ihren Bereitstellungen minimieren und die Auswirkungen problematischer Bereitstellungen auf Ihre Benutzer begrenzen, indem Sie SDP implementieren.

Wichtige Entwurfsstrategien

Es gibt vier wichtige Richtlinien, die Sie bei der Implementierung sicherer Bereitstellungsmethoden beachten sollten:

  • Sicherheit und Konsistenz: Alle Änderungen an der Produktionsworkload sind grundsätzlich riskant und müssen mit schwerpunktmäßiger Sicherheit und Konsistenz vorgenommen werden.

  • Progressive Exposition: Sie können den potenziellen Explosionsradius von bereitstellungsbedingten Problemen minimieren, indem Sie ein progressives Bereitstellungsmodell für die Belichtung verwenden.

  • Integritätsmodelle: Bereitstellungen müssen Integritätsprüfungen bestehen, bevor jede Phase der progressiven Exposition beginnen kann.

  • Problemerkennung: Wenn Probleme erkannt werden, sollte die Bereitstellung sofort angehalten und die Wiederherstellung initiiert werden.

Die folgenden Abschnitte enthalten detaillierte Empfehlungen zu jedem dieser Punkte.

Sicherheit und Konsistenz

Unabhängig davon, ob Sie ein Update für Ihren Anwendungscode, Infrastructure-as-Code (IaC), Featureflag oder ein Konfigurationsupdate bereitstellen, führen Sie Risiken in die Workload ein. Es gibt keine Bereitstellungen mit geringem Risiko für die Produktion. Jede Bereitstellung muss einem Standardmuster folgen und automatisiert werden, um Konsistenz zu erzwingen und das Risiko menschlicher Fehler zu minimieren. Es ist wichtig, dass Ihre Workloadlieferkette und Bereitstellungspipelines zuverlässig und sicher sind und klar definierte Bereitstellungsstandards aufweisen. Behandeln Sie jede Bereitstellung als mögliches Risiko, und unterwerfen Sie jede Bereitstellung dem gleichen Risikomanagement. Trotz der Risiken sollten Sie weiterhin regelmäßige Änderungen an Ihrer Workload bereitstellen. Wenn sie keine regelmäßigen Updates bereitstellen, führt das zu anderen Risiken, z. B. Sicherheitsrisiken, die durch Bereitstellungen behoben werden müssen. Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen einer Workloadentwicklungs-Lieferkette.

Häufige kleine Bereitstellungen sind seltenen großen Bereitstellungen vorzuziehen. Kleine Änderungen sind einfacher zu beheben, wenn Probleme auftreten und häufige Bereitstellungen Ihrem Team helfen, Vertrauen in den Bereitstellungsprozess zu schaffen. Es ist auch wichtig, dass Sie aus der Produktion lernen, indem Sie Ihre Workloadprozesse überprüfen, wenn während der Bereitstellung eine Anomalie auftritt. Möglicherweise finden Sie Schwächen beim Entwurf Ihrer Infrastruktur oder beim Rollout. Wenn Probleme während der Bereitstellung auftreten, stellen Sie sicher, dass schuldlose Postmortems Teil Ihres SDP-Prozesses sind, um Lektionen über den Vorfall zu erfassen.

Bereitstellung der progressiven Exposition

Wenn Bereitstellungsprobleme auftreten, besteht das Ziel darin, diese so früh wie möglich abzufangen, um die Auswirkungen auf Endbenutzer zu minimieren. Implementieren Sie ein Schrittweises Rollout-Bereitstellungsmodell, das auch als progressives Expositionsmodell bezeichnet wird, um dieses Ziel zu erreichen. Canary-Bereitstellungen sind ein häufiges Beispiel für eine progressive Offenlegung. In diesem Bereitstellungsmodell erhält zuerst eine kleine Gruppe interner oder externer Benutzer das neue Feature. Nachdem die erste Gruppe die neue Version ohne Probleme ausgeführt hat, wird das Feature nacheinander für größere Gruppen bereitgestellt, bis die gesamte Benutzerpopulation die neue Version ausführt. Featureflags werden in der Regel verwendet, um die neue Version für die Zielbenutzer in Canary-Bereitstellungen zu aktivieren.

Ein weiteres gängiges Bereitstellungsmodell ist ein Blau-Grün-Ansatz. In diesem Modell werden zwei identische Sätze oder Pools der Workloadinfrastruktur bereitgestellt. Beide Pools können eine vollständige Produktionsauslastung verarbeiten. Der erste (blaue) Pool führt die aktuelle Version der Bereitstellung aus, in der sich alle Benutzer befinden. Der zweite (grüne) Pool wird mit dem neuen Feature aktualisiert und intern getestet. Nach internen Tests wird eine Teilmenge des Produktionsdatenverkehrs vom blauen Pool an den grünen Pool weitergeleitet. Wie bei Canary-Bereitstellungen ist der Rollout progressiv, da Sie in sukzessive größeren Rolloutwellen mehr Datenverkehr in den grünen Pool verschieben. Nachdem Sie den Rollout abgeschlossen haben, wird der Updatepool zum blauen Pool, und der grüne Pool ist für die nächste Bereitstellung bereit. Die beiden Pools sind logisch voneinander getrennt, um vor Fehlfunktionen zu schützen. Sie können eine Variante des blau-grünen Modells in einer Workload bereitstellen, die das Entwurfsmuster für Bereitstellungsstempel verwendet, indem Sie jeweils einen Stempel bereitstellen.

In beiden Modellen sollte die Zeit zwischen den einzelnen Phasen des Rollouts so lange sein, dass Sie die Integritätsmetriken der Workload überwachen können. Sie sollten ausreichend Backzeit und Zeit zwischen Rolloutgruppen bereitstellen, um sicherzustellen, dass Benutzer aus verschiedenen Regionen oder Benutzer, die unterschiedliche Aufgaben ausführen, Zeit haben, die Workload in ihrer normalen Kapazität zu verwenden. Die Backzeiten sollten in Stunden und Tagen und nicht in Minuten gemessen werden. Die Bake-Zeiten sollten auch für jede Rolloutgruppe erhöht werden, damit Sie im Laufe des Tages verschiedene Zeitzonen und Nutzungsmuster berücksichtigen können.

Integritätsmodelle

Entwickeln Sie ein robustes Integritätsmodell als Teil Ihrer Beobachtbarkeitsplattform und Ihrer Zuverlässigkeitsstrategien. Ihr Integritätsmodell sollte einen detaillierten Einblick in die Komponenten und die allgemeine Integrität der Workload bieten. Wenn Sie während eines Rollouts eine Warnung zu einer Integritätsänderung in Bezug auf einen Endbenutzer erhalten, sollte der Rollout sofort beendet werden, und eine Untersuchung der Ursache der Warnung sollte durchgeführt werden, um die nächste Vorgehensweise zu bestimmen. Wenn keine Probleme von Endbenutzern gemeldet werden und alle Integritätsindikatoren während der gesamten Bakezeit grün bleiben, sollte der Rollout fortgesetzt werden. Stellen Sie sicher, dass Sie Nutzungsmetriken in Ihr Integritätsmodell einschließen, um sicherzustellen, dass ein Mangel an vom Benutzer gemeldeten Problemen und negativen Integritätssignalen kein Problem ausblendet. Weitere Informationen finden Sie unter Erstellen eines Integritätsmodells.

Problemerkennung

Wenn Ihre Bereitstellung ein Problem in einer der Rolloutgruppen verursacht, muss der Rollout sofort beendet werden. Eine Untersuchung der Ursache des Problems und des Schweregrads der Auswirkungen muss durchgeführt werden, sobald die Warnung empfangen wird. Die Wiederherstellung nach dem Problem kann Folgendes umfassen:

  • Rollback der Bereitstellung durch Rückgängigmachen der in der Bereitstellung vorgenommenen Änderungen und Wiederherstellen der letzten bekannten Arbeitskonfiguration.

  • Rollforward der Bereitstellung, indem das Problem während des Rollouts behoben wird. Sie können Probleme während des Rollouts beheben, indem Sie einen Hotfix anwenden oder das Problem anderweitig minimieren.

  • Bereitstellen einer neuen Infrastruktur mithilfe der letzten bekannten Arbeitskonfiguration.

Ein Rollback von Änderungen, insbesondere Änderungen an Datenbanken, Schemas oder anderen zustandsbehafteten Komponenten, kann komplex sein. Ihre SDP-Richtlinien sollten klare Anweisungen zum Umgang mit Datenänderungen gemäß dem Datenbestandsentwurf für Ihre Workload enthalten. Ebenso muss das Rollforward sorgfältig behandelt werden, um sicherzustellen, dass SDP nicht vernachlässigt wird und dass der Hotfix oder andere Minimierungsbemühungen sicher ausgeführt werden.

Allgemeine SDP-Empfehlungen

  • Implementieren Sie die Versionsverwaltung für Ihre Buildartefakte, um sicherzustellen, dass Sie bei Bedarf ein Rollback und einen Rollforward durchführen können.

  • Verwenden Sie einen Releaseflow oder eine trunkbasierte Verzweigungsstruktur, die eine eng synchronisierte Zusammenarbeit im gesamten Entwicklungsteam erzwingt, anstelle einer Gitflow- oder umgebungsbasierten Verzweigungsstruktur.

  • Automatisieren Sie so viel wie möglich von Ihrer SDP. Eine ausführliche Anleitung zum Automatisieren von IaC- und Ci/CD-Prozessen (Continuous Integration und Continuous Delivery) für Anwendungen finden Sie unter Empfehlungen für die Implementierung von Automatisierung.

  • Verwenden Sie CI-Methoden, um Codeänderungen regelmäßig in Repositorys zu integrieren. CI-Methoden können Ihnen helfen, Integrationskonflikte zu identifizieren und die Wahrscheinlichkeit großer, riskanter Zusammenführungen zu verringern. Weitere Informationen finden Sie im Leitfaden zur Continuous Integration.

  • Verwenden Sie Featureflags, um neue Features oder Änderungen in der Produktion selektiv zu aktivieren oder zu deaktivieren. Featureflags können Ihnen helfen, die Offenlegung von neuem Code zu steuern und bei Problemen ein schnelles Rollback für die Bereitstellung durchzuführen.

  • Stellen Sie Änderungen an Stagingumgebungen bereit, die Ihre Produktionsumgebung Spiegel. Mit Übungsumgebungen können Sie Änderungen in einer kontrollierten Einstellung testen, bevor Sie in der Liveumgebung bereitstellen.

  • Richten Sie Überprüfungen vor der Bereitstellung ein, einschließlich Codeüberprüfungen, Sicherheitsüberprüfungen und Konformitätsprüfungen, um sicherzustellen, dass Änderungen sicher bereitgestellt werden können.

  • Implementieren Sie Trennschalter, um den Datenverkehr an einen Dienst automatisch anzuhalten, bei dem Probleme auftreten. Dies kann dazu beitragen, eine weitere Beeinträchtigung des Systems zu verhindern.

Notfall-SDP-Protokolle

Richten Sie präskriptive Protokolle ein, die definieren, wie Ihre SDP für einen Hotfix oder für Notfallprobleme wie eine Sicherheitsverletzung oder sicherheitsrelevante Gefährdung angepasst werden kann. Ihre Notfall-SDP-Protokolle können beispielsweise Folgendes umfassen:

  • Beschleunigung der Heraufstufungs- und Genehmigungsphase.

  • Beschleunigung von Rauchtests und Integrationstests.

  • Reduzierung der Backzeit.

In einigen Fällen kann der Notfall die Qualität einschränken und Gates testen, aber Gates sollten dennoch so schnell wie möglich als Out-of-Band-Übung ausgeführt werden. Stellen Sie sicher, dass Sie definieren, wer die SDP-Beschleunigung im Notfall genehmigen kann, und die Kriterien, die erfüllt sein müssen, damit die Beschleunigung genehmigt werden kann. Richten Sie Ihre Notfall-SDP-Protokolle mit Ihrem Notfallreaktionsplan aus, um sicherzustellen, dass alle Notfälle nach denselben Protokollen behandelt werden.

Überlegungen

Das Erstellen und Verwalten sicherer Bereitstellungsmethoden ist komplex. Ihr Erfolg bei der vollständigen Implementierung robuster Standards hängt von der Reife Ihrer Praktiken in vielen Bereichen der Softwareentwicklung ab. Die Verwendung von Automatisierung, IaC-only für Infrastrukturänderungen, Konsistenz in Verzweigungsstrategien, Die Verwendung von Featureflags und viele andere Methoden können dazu beitragen, eine sichere Bereitstellung sicherzustellen. Verwenden Sie diesen Leitfaden, um Ihre Workload zu optimieren und Ihre Pläne für Verbesserungen zu informieren, wenn Sich Ihre Methoden weiterentwickeln.

Azure-Erleichterung

  • Azure Pipelines und GitHub Actions unterstützen mehrstufige Bereitstellungen mithilfe von Genehmigungsgates, die Ihnen beim Entwerfen Ihres progressiven Rollouts für Bereitstellungen helfen können.

  • Verwenden Sie Azure App Service Stagingslots, um problemlos zwischen Codeversionen auszutauschen. Stagingslots sind für Tests in Stagingumgebungen hilfreich und können für blau-grüne Bereitstellungen verwendet werden.

  • Speichern und verwalten Sie Ihre Web-App-Featureflags in Azure App Configuration. Mithilfe dieses Diensts können Sie Features auf einer einheitlichen Verwaltungsebene erstellen, ändern und bereitstellen.

  • Stellen Sie Workloadanwendungen auf Ihrem virtuellen Computer mithilfe von VM-Anwendungen bereit.

  • Verwenden Sie Azure Load Balancer , um Bereitstellungsstrategien zu implementieren und die Integrität Ihrer Workloadanwendungen mithilfe nativer Ressourcen verfügbar zu machen.

  • Verwenden Sie die Application Health-Erweiterung, um die Anwendungsintegrität innerhalb einer VM-Skalierungsgruppe instance zu melden. Die Erweiterung testet auf einem lokalen Anwendungsendpunkt und aktualisiert die Integrität status basierend auf TCP/HTTP(S)-Antworten, die von der Anwendung empfangen wurden.

  • Verwenden Sie Azure Logic Apps , um bei jeder Aktualisierung eine neue Version der Anwendung zu erstellen. Azure verwaltet einen Verlauf der Anwendungsversionen und kann rückgängig machen oder zu jeder früheren Version heraufstufen.

  • Viele Azure-Datenbankdienste bieten Funktionen zur Zeitpunktwiederherstellung, die Ihnen beim Rollback helfen können. Dienste, die point-in-time-Wiederherstellung unterstützen, umfassen:

Beispiel

Ein Beispiel für die Verwendung dieses Bereitstellungsmodells finden Sie im Architekturleitfaden für die blaugrüne Bereitstellung von Azure Kubernetes Service (AKS)-Clustern.

Checkliste "Operational Excellence"

Sehen Sie sich den vollständigen Satz von Empfehlungen an.

Checkliste "Operational Excellence"