DevOps-Muster

Erstellen Sie Code an einem einzigen Standort und stellen Sie ihn in mehreren Zielumgebungen bereit, wie Entwicklungs-, Test- und Produktionsumgebungen, die sich möglicherweise in Ihrem lokalen Rechenzentrum, in privaten Clouds oder in der öffentlichen Cloud befinden.

Kontext und Problem

Anwendungsbereitstellungskontinuität, Sicherheit und Zuverlässigkeit sind für Organisationen und für Entwicklungsteams von entscheidender Bedeutung.

Apps erfordern häufig umgestalteten Code für die Ausführung in jeder Zielumgebung. Dies bedeutet, dass eine App nicht vollständig portierbar ist. Sie muss aktualisiert, getestet und überprüft werden, während sie durch jede Umgebung wechselt. Beispielsweise muss in einer Entwicklungsumgebung geschriebener Code umgeschrieben werden, damit er in einer Testumgebung funktioniert, und danach für die Produktionsumgebung erneut umgeschrieben werden. Darüber hinaus ist dieser Code an den Host gebunden. Dies erhöht die Kosten und Komplexität der Aufrechterhaltung Ihrer App. Jede Version der App ist an jede Umgebung gebunden. Die erhöhte Komplexität und Duplizierung erhöhen das Sicherheits- und Codequalitätsrisiko. Außerdem kann der Code nicht sofort erneut bereitgestellt werden, wenn Sie Hosts entfernen, bei deren Wiederherstellung ein Fehler aufgetreten ist, oder Sie weitere Hosts zum Bewältigen höherer Anforderungen bereitstellen.

Lösung

Mit dem DevOps-Muster können Sie eine App erstellen, testen und bereitstellen, die auf mehreren Clouds ausgeführt wird. Dieses Muster vereint die Praxis der kontinuierlichen Integration und der kontinuierlichen Lieferung. Mit fortlaufender Integration wird Code jedes Mal erstellt und getestet, wenn ein Teammitglied eine Änderung an der Versionssteuerung festschreibt. Die kontinuierliche Bereitstellung automatisiert jeden Schritt von einem Build zu einer Produktionsumgebung. Gemeinsam erstellen diese Prozesse einen Veröffentlichungsprozess, der die Bereitstellung in verschiedenen Umgebungen unterstützt. Mit diesem Muster können Sie Ihren Code entwerfen und dann denselben Code in einer lokalen Umgebung, verschiedenen privaten Clouds und den öffentlichen Clouds bereitstellen. Unterschiede in der Umgebung erfordern eine Änderung an einer Konfigurationsdatei anstelle von Änderungen am Code.

Mit einer konsistenten Reihe von Entwicklungstools in lokalen, privaten Cloud- und öffentlichen Cloudumgebungen können Sie eine Praxis für kontinuierliche Integration und kontinuierliche Bereitstellung implementieren. Apps und Dienste, die mit dem DevOps-Muster bereitgestellt werden, sind austauschbar und können an einem dieser Standorte ausgeführt werden, wobei lokale und öffentliche Cloudfeatures und -funktionen genutzt werden.

Die Verwendung einer DevOps-Releasepipeline hilft Ihnen dabei:

• Initiieren Sie einen neuen Build basierend auf Code-Commits in ein einzelnes Repository.
• Stellen Sie ihren neu erstellten Code automatisch für Benutzerakzeptanztests in der öffentlichen Cloud bereit.
• Automatische Bereitstellung in einer privaten Cloud, nachdem Ihr Code Tests bestanden hat.

Probleme und Überlegungen

Das DevOps-Muster soll unabhängig von der Zielumgebung die Konsistenz für alle Bereitstellungen sicherstellen. Die Funktionen variieren jedoch in cloud- und lokalen Umgebungen. Berücksichtigen Sie die folgenden Punkte:

• Sind die Funktionen, Endpunkte, Dienste und anderen Ressourcen in Ihrer Bereitstellung an den Zielbereitstellungsorten verfügbar?
• Sind Konfigurationsartefakte an Speicherorten gespeichert, auf die über Clouds zugegriffen werden kann?
• Funktionieren Bereitstellungsparameter in allen Zielumgebungen?
• Sind ressourcenspezifische Eigenschaften in allen Zielclouds verfügbar?

Weitere Informationen finden Sie unter Entwickeln von Azure Resource Manager-Vorlagen für cloudbasierte Konsistenz.

Berücksichtigen Sie außerdem die folgenden Punkte, wenn Sie entscheiden, wie dieses Muster implementiert werden soll:

Skalierbarkeit

Bereitstellungsautomatisierungssysteme sind der wichtigste Kontrollpunkt in den DevOps-Mustern. Implementierungen können variieren. Die Auswahl der richtigen Servergröße hängt von der Größe der erwarteten Workload ab. VMs kosten mehr Skalierung als Container. Um Container für die Skalierung zu verwenden, muss ihr Buildprozess jedoch mit Containern ausgeführt werden.

Verfügbarkeit

Verfügbarkeit im Kontext von DevPattern bedeutet, dass sie alle Statusinformationen wiederherstellen können, die Ihrem Workflow zugeordnet sind, z. B. Testergebnisse, Codeabhängigkeiten oder andere Artefakte. Um Ihre Verfügbarkeitsanforderungen zu bewerten, sollten Sie zwei allgemeine Metriken berücksichtigen:

• Die Wiederherstellungszeit (Recovery Time Objective, RTO) gibt an, wie lange Sie ohne System gehen können.

• Recovery Point Objective (RPO) gibt an, wie viele Daten Sie verlieren können, wenn sich eine Dienstunterbrechung auf das System auswirkt.

In der Praxis impliziert RTO und RPO Redundanz und Sicherung. In der globalen Azure-Cloud stellt die Verfügbarkeit keine Frage der Hardwarewiederherstellung dar – das ist Teil von Azure – sondern stellt sicher, dass Sie den Status Ihrer DevOps-Systeme beibehalten. Bei Azure Stack Hub kann die Hardwarewiederherstellung eine Berücksichtigung darstellen.

Ein weiterer wichtiger Aspekt beim Entwerfen des systems, das für die Bereitstellungsautomatisierung verwendet wird, ist die Zugriffssteuerung und die ordnungsgemäße Verwaltung der Rechte, die für die Bereitstellung von Diensten in Cloudumgebungen erforderlich sind. Welche Rechte sind zum Erstellen, Löschen oder Ändern von Bereitstellungen erforderlich? Beispielsweise ist in der Regel eine Gruppe von Rechten erforderlich, um eine Ressourcengruppe in Azure und eine andere zum Bereitstellen von Diensten in der Ressourcengruppe zu erstellen.

Managebarkeit

Der Entwurf eines systems, das auf dem DevOps-Muster basiert, muss Automatisierung, Protokollierung und Warnung für jeden Dienst im gesamten Portfolio berücksichtigen. Verwenden Sie gemeinsame Dienste, ein Anwendungsteam oder beides, und verfolgen Sie auch Sicherheitsrichtlinien und Governance.

Stellen Sie Produktionsumgebungen und Entwicklungs-/Testumgebungen in separaten Ressourcengruppen auf Azure oder Azure Stack Hub bereit. Anschließend können Sie die Ressourcen der einzelnen Umgebungen überwachen und die Abrechnungskosten nach Ressourcengruppe zusammenfassen. Sie können Ressourcen auch als Gruppe löschen, was für Testumgebungen nützlich ist.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster, wenn:

• Sie können Code in einer Umgebung entwickeln, die den Anforderungen Ihrer Entwickler entspricht, und in einer Umgebung bereitstellen, die für Ihre Lösung spezifisch ist, wo es schwierig sein kann, neuen Code zu entwickeln.
• Sie können den Code und die Tools verwenden, die Ihre Entwickler wünschen, solange sie den kontinuierlichen Integrations- und kontinuierlichen Übermittlungsprozess im DevOps-Muster verfolgen können.

Dieses Muster wird nicht empfohlen:

• Wenn Sie Infrastruktur, Bereitstellungsressourcen, Konfiguration, Identität und Sicherheitsaufgaben nicht automatisieren können.
• Wenn Teams keinen Zugriff auf hybride Cloudressourcen haben, um einen Ansatz für kontinuierliche Integration/Kontinuierliche Entwicklung (CI/CD) zu implementieren.

Nächste Schritte

Weitere Informationen zu themen, die in diesem Artikel eingeführt wurden:

• Weitere Informationen zu Azure DevOps und verwandten Tools, einschließlich Azure Repos und Azure Pipelines, finden Sie in der Azure DevOps-Dokumentation.
• Sehen Sie sich die Azure Stack-Produktfamilie von Produkten und Lösungen an, um mehr über das gesamte Portfolio von Produkten und Lösungen zu erfahren.

Wenn Sie bereit sind, das Lösungsbeispiel zu testen, fahren Sie mit dem Bereitstellungshandbuch für hybride CI/CD-Lösungfort. Das Bereitstellungshandbuch enthält schrittweise Anleitungen zum Bereitstellen und Testen der zugehörigen Komponenten. Sie erfahren, wie Sie eine App in Azure und Azure Stack Hub mit einer Hybrid-Pipeline für kontinuierliche Integration/kontinuierliche Übermittlung (CI/CD) bereitstellen.