Problemloses Bereitstellen
 Erreichen Sie den gewünschten Bereitstellungsstatus mit Vorhersagbarkeit. |
|---|
Erstellen Sie eine Workload-Lieferkette, mit der Sie das Ziel der Vorhersagbarkeit in allen Ihren Umgebungen über die Hostingplattformen, Anwendungen, Daten und Konfigurationsressourcen der Workload hinweg konsistent erreichen können. Der Bereitstellungsmechanismus muss Automatisierung, Tests, Überwachung und Versionsverwaltung unterstützen. Es sollte modularisiert und auf Bedarf ausführbar sein. Es sollte nicht als monolithischer End-to-End-Prozess dargestellt werden. Die Lieferkette ist nicht unbedingt auf eine schnellere Ausführung ausgelegt, sondern darauf, Konsistenz und Selbstdokumentation über mehrere Iterationen zu erzielen.
Das Workloadteam ist für die Lieferkette in Bezug auf seine eigene Workload verantwortlich.
Beispielszenario
Contoso Manufacturing hat eine Java-basierte Anwendung entwickelt, mit der die Fertigungsprozesse überwacht und optimiert werden. Die Workload wurde kürzlich zu Azure migriert und wird jetzt auf Azure Spring Apps, Azure Database for MySQL und Azure IoT Hub ausgeführt.
Bereitstellen der Infrastruktur durch Code
Verwenden Sie Infrastructure as Code (IaC), um die wiederholbaren Aspekte der Lieferkette zu definieren, die produktionsbereit sind. Bevorzugen Sie deklarative Ansätze gegenüber imperativen Methoden.
Deklarative IaC-Technologien sind auf Automatisierung und Wiederverwendbarkeit ausgelegt. Sie können Infrastrukturbereitstellungen von Einzelpersonen an Tools auslagern und eine konsistente Qualität erzielen.
Aus Sicht der Infrastruktur bedeutet eine geringere Auswahl an Technologien eine geringere Varianz bei den Tools und eine leichtere Erkennung von Konfigurationsabweichungen. Die Wartung wird ebenfalls einfacher. Wenn Sie Entscheidungen auf die vorhandenen Qualifikationen des Teams abstimmen, kann das Team sie leicht übernehmen.
Herausforderung von Contoso
- Die lokale Version der Workload verwendete eine Kombination aus Skripts und manuellen Schritten, um die Infrastruktur zu erstellen und die Anwendung in allen Umgebungen bereitzustellen. Zu Beginn der Azure-Migration hat das Team Änderungen an den vorhandenen imperativen Skripts vorgenommen, um sie auf die neue Plattform auszurichten und möglichst viel von der vorhandenen Automatisierungscodebasis wiederverwenden zu können. Dieser Ansatz wurde auch aufgrund mangelnden Kompetenzen in Azure- und IaC-Technologien wie Bicep übernommen.
- Je weiter die Migration voranschritt und je vertrauter das Team mit der Plattform wurde, desto mehr kam es zu der Überzeugung, dass die Verwendung eines IaC-Ansatzes mit Bicep langfristig die bessere Lösung sein würde.
Umsetzung und Ergebnisse
- Da das Team nicht über das nötige Fachwissen verfügte, beauftragte es erfahrene Auftragnehmer mit der Migration und Erweiterung der Automatisierungsskripte für die Bereitstellung der Workload. Diese Auftragnehmer arbeiteten in der Anfangsphase des Projekts eng mit dem Entwicklungsteam zusammen und gaben gleichzeitig ihr Wissen an das übrige Team weiter.
- Die resultierende Bicep-basierte Implementierung bietet eine zuverlässigere, besser verwaltbare und effizientere Möglichkeit, Infrastruktur in Azure bereitzustellen. Der Code ist jetzt besser lesbar und wartbar, mit hervorragender Toolunterstützung in VSCode. Er ist auch vollständig idempotent und vereinfacht die Zustandsverwaltung, was mit der vorherigen/imperativen Version nie vollständig erreicht werden konnte.
Behandeln Sie Ihre IaC genauso wie Ihren Anwendungscode.
Befolgen Sie die Softwareempfehlungen für die Entwicklung und Wartung von IaC: Modularisieren Sie in Maßen, vermeiden Sie benutzerdefinierte oder geringwertige Abstraktionen, und verfolgen Sie einen mehrschichtigen Ansatz, um verschiedene Lebenszyklen zu berücksichtigen. Bilden Sie grundlegende Ebenen, wobei die unteren Ebenen konstant bleiben und sich die oberen Ebenen nach Bedarf ändern.
Bereitstellungsartefakte, z. B. Anwendungsbinärdateien, IaC-Vorlagen und Parameter, sind Teil der Angriffsfläche. Wenden Sie Sicherheitsmaßnahmen an, z. B. Verwaltung von Geheimnissen, Zugriffssteuerung und andere Grundsätze der Sicherheitssäule.
Artefakte unterliegen der gleichen technischen Strenge wie der Anwendungscode. Qualitätslenkung durch Peer Review und Tests bieten Ihnen Konfidenz in die Bereitstellung.
Ein mehrstufiger Ansatz erleichtert die Wartung und schafft Grenzen, die klare Verantwortlichkeiten festlegen.
Durch das Hinzufügen von Sicherheitskontrollen zu Artefakten wird das System während des Bereitstellungsprozesses gehärtet.
Herausforderung von Contoso
- Das Projektteam verfügte zu Beginn der Migration über ein großzügiges Budget, sodass es sehr erfahrene Auftragnehmer engagierte, die in kurzer Zeit hohe Qualität lieferten. Die Auftragnehmer nutzten für ihre Entwicklung ein separates Repository, das im Gegensatz zum Hauptanwendungscode nicht regelmäßig auf Sicherheit geprüft wurde.
- Das Team bereitet sich auf die Veröffentlichung einer umfassenden Neugestaltung der Lösung vor, und der Bereitstellungscode muss erheblich geändert werden. Aufgrund der knappen Entwicklungsressourcen werden die letzten Änderungen von zwei Praktikanten vorgenommen. Als einer der leitenden Entwickler im Team von den Praktikanten um Hilfe gebeten wird, bemerkt er mehrere Commits im Repository, die nicht den Entwicklungsstandards des Teams entsprechen, darunter auch hartkodierte Anwendungsgeheimnisse wie API-Schlüssel in der Codebasis.
Umsetzung und Ergebnisse
- Das Team entscheidet sich, die Codebasis für Build- und Bereitstellung in dasselbe Repository zu verschieben, das für den Anwendungscode verwendet wird, und die gleiche technische Strenge anzuwenden wie in anderen Bereichen der Codebasis. Der Code wird vor dem ersten Commit an die Teamstandards angepasst, Anwendungsgeheimnisse werden entfernt, und alle anderen Qualitätsstandards und -tools des Teams werden auf ihn angewendet.
- Dadurch hat das Team diesen Abschnitt der Codebasis gesichert und gleichzeitig die Codequalität erhöht. Künftig werden Änderungen in diesem Bereich der Codebasis denselben Standards folgen und dieselben Tools nutzen, die für die Codebasis der Kernanwendung verwendet werden, einschließlich Peer Code Reviews und automatischer Überprüfung des Codes mit Qualitäts- und Sicherheitstools.
Standardisieren der Bereitstellungen mit einem einzigen Manifest
Entwickeln Sie ein gemeinsames Bereitstellungsmanifest, das in allen Umgebungen verwendet wird. Verwenden Sie dieses Manifest als Standardmechanismus für Greenfield-Projekte, inkrementelle Workloadupdates oder die Notfallwiederherstellung.
Mit diesem Ansatz können Sie den mit der Wartung mehrerer Ressourcen verbundenen Aufwand vermeiden.
Im Katastrophenfall erfolgt die Wiederherstellung schnell und zuverlässig, da Sie ein bewährtes Manifest einsetzen können, anstatt eine improvisierte Umgebung zu erstellen.
Herausforderung von Contoso
- Contoso Manufacturing verwendet eine vollständig automatisierte Pipeline zum Bereitstellen der Infrastruktur, des Anwendungscodes und der Konfigurationsänderungen in der Entwicklungs- und Produktionsumgebung. Die Anwendung ist so konfiguriert, dass sie in einer einzelnen Region hoch verfügbar ist. Die meisten Anwendungskomponenten sind zustandslos, mit Ausnahme der MySQL-Datenbank. Die Datenbank wird gemäß dem festgelegten RTO/RPO gesichert, und die Sicherung wird in eine sekundäre Region repliziert.
- Wenn ein schwerwiegender Fehler oder ein Katastrophenfall in der primären Region auftritt, plant das Team, eine neue Umgebung zum Hosten der Anwendung in der sekundären Region zu erstellen. Während einer geplanten Übung zum Testen der DR-Verfahren schlagen die Bereitstellungsskripts bei dem Versuch fehl, die Umgebung in der sekundären Region neu zu erstellen, weil mehrere Ressourcen nicht verfügbar sind und andere Diensteinschränkungen bestehen.
Umsetzung und Ergebnisse
- Das Team entschärft die Probleme, die beim Bereitstellen in der sekundären Region aufgetreten sind, indem es einige Ressourcen durch entsprechende SKUs ersetzt, die in beiden Regionen verfügbar sind, und einige Optionen konfigurierbar macht, sodass in der sekundären Region ein anderer, aber gültiger Wert verwendet werden kann.
- Die Übung hat das Vertrauen des Teams in seine Fähigkeit gestärkt, das System bei großen Infrastrukturausfällen wiederherstellen zu können.