Best Practices für die Erstellung implementierbarer Architekturen

Eine implementierbare Architektur ist eine eigenständige, modulare Einheit der Cloudautomatisierung, die eine oder mehrere Cloudressourcen kombiniert, um ein einheitliches Architekturmuster bereitzustellen. Sie ermöglicht eine vereinfachte Implementierung, Skalierbarkeit und Modularität und ermöglicht Benutzern die einfache Bereitstellung und Verwaltung von Infrastrukturressourcen.

In diesem Handbuch werden bewährte Verfahren für die Erstellung gut entworfener und wartungsfähiger bereitstellbarer Architekturen beschrieben, die in Terraform geschrieben sind. Die Konzentration auf Schlüsselattribute wie Umfang, Zusammensetzbarkeit, Verbraucherfreundlichkeit und Qualitätsprüfung trägt dazu bei, robuste und zuverlässige Lösungen sicherzustellen. Der letzte Abschnitt dieses Handbuchs enthält Verweise auf Tools und Vorlagen, die Ihnen bei der Implementierung dieser Verfahren helfen.

Diese bewährten Verfahren gelten für die Erstellung bereitstellbarer Architekturen mit Terraform. Weitere Informationen finden Sie unter Implementierbare Architektur erstellen.

Lernvideo

Sie möchten es lieber in Aktion sehen? Sehen Sie sich das folgende Video an, um mehr über einsatzfähige Architekturen zu erfahren.

Videomitschrift

Eine verteilbare Architektur ist ein Architekturmuster mit Automatisierung für die Bereitstellung von Infrastruktur und Software in der Cloud. Sie ermöglicht es Unternehmen, die Konsistenz bei der Bereitstellung und Konfiguration von Infrastruktur und Software zu verbessern. Es erzwingt eine eigenwillige Architektur und Sicherheit, die den allgemeinen Support reduziert und die Zuverlässigkeit langfristig erhöht.

Dieses Muster wird durch Automatisierung zum Leben erweckt, die die einsatzfähige Architektur instanziiert. IBM Cloud Automatisierung wird mit Terraform für Infrastructure-as-a-Service-Automatisierung und Ansible für Softwarekonfiguration betrieben.

Das Verständnis der Kosten ist von entscheidender Bedeutung - Sie können die Kosten abschätzen, bevor Sie die Lösung einführen, und Änderungen der Ausgaben verfolgen, wenn Sie die Architektur aktualisieren oder anpassen. Und denken Sie daran, dass Ihnen bis zum Einsatz nichts in Rechnung gestellt wird.

Sicherheits- und Organisationsrichtlinien sind für den Einsatz in Unternehmen von entscheidender Bedeutung. Aus diesem Grund werden einsatzfähige Architekturen geprüft und vorab gescannt, um eine Reihe von Richtlinienanforderungen zu erfüllen, die Ihrem Unternehmen zu mehr Sicherheit verhelfen können. Standardisierte Einsätze vereinfachen auch die Sammlung von Beweisen für Audits.

Einsetzbare Architekturen enthalten Informationen darüber, wie Sie Unterstützung erhalten und welche Genehmigungen für den Einsatz der Architektur erforderlich sind.

Und schließlich können Sie einsatzfähige Architekturen aus einem privaten Katalog für andere Konten in Ihrem Unternehmen freigeben. Außerdem kann der Katalog Benutzer auf bestimmte Versionen einer einsatzfähigen Architektur beschränken. Dies gewährleistet Konsistenz und Standardisierung für alle.

Architekturmuster werden von domänenspezifischen Experten erstellt. Domänenübergreifende Architekturen werden durch die Verknüpfung von Architekturen aufgebaut, um eine komplexere, einsatzfähige Architektur zu schaffen.

Sie können Ihre eigenen einsatzfähigen Architekturen erstellen - oder Zeit sparen, indem Sie die vorgefertigten Architekturen von IBM Cloud aus dem IBM Cloud Katalog oder der Community Registry anpassen.

eine einsatzfähige Architektur wird durch ein Manifest als Code definiert, das die Architektur, den Speicherort des Codes, die Berechtigungen, die Kosten, den Support, die Beschreibung, das Symbol und andere Details beschreibt. Sie wird mit JSON definiert und befindet sich im Stammverzeichnis des Repo.

Sie können eine verteilbare Architektur in der Konsole eingeben oder ändern und das Manifest exportieren. Sie können eine einsatzfähige Architektur zum ersten Mal aus einem Release-Git-Snapshot erstellen. Verwenden Sie die Release-.tgz-Url als Ihre Quelle.

Bearbeiten Sie dann die Details des Katalogeintrags für Ihre einsatzfähige Architektur, z. B. das Symbol und den Namen. Sie können Abhängigkeiten und optionale Architekturen hinzufügen, die gut mit Ihrer eigenen funktionieren, aber nicht erforderlich sind.

Sie können auch Compliance-Ansprüche für die einsatzfähige Architektur verwalten. Diese Ansprüche werden überprüft, wenn Sie die einsatzfähige Architektur im Katalog validieren, bevor Sie sie veröffentlichen.

Schließlich können Sie, nachdem Sie eine Version Ihrer einsatzfähigen Architektur eingebunden haben, die Katalogmanifestdatei exportieren und in Ihrem Quell-Repository speichern. Die Verwendung der Konsole ist in der Regel der beste Ansatz für das Onboarding einer neuen verteilbaren Architektur, da Sie das Katalogmanifest einfach exportieren und später bei Bedarf bearbeiten können. Auf diese Weise müssen Sie die Katalogmanifestdatei nicht von Grund auf neu erstellen.

Öffnen Sie im Katalog IBM Cloud die Registerkarte Bereitstellbare Architekturen, um Architekturen zu finden, die von IBM unterstützt werden.

Die einsatzfähigen Architekturen in unserer Community-Registry können sich häufig ändern oder kurzfristig eingestellt werden, aber sie sind dennoch ein guter Ausgangspunkt für die Verwendung und Anpassung durch Sie.

Betrachten Sie die einsatzfähige Architektur VPC landing zone, die im Katalog IBM Cloud verfügbar ist. Es handelt sich um eine allgemein nützliche, einsatzfähige Architektur, da Sie eine VPC benötigen, wenn Sie eine Arbeitslast in der Cloud ausführen möchten.

VPC landing zone ist so konzipiert, dass es mit dem Profil IBM Cloud Framework for Financial Services übereinstimmt. Es trennt die Verwaltungsarbeitslasten von den Arbeitslasten, nutzt die Schlüsselverwaltung zur Verschlüsselung des Cloud-Objektspeichers und verwendet private Endpunkte für die Kommunikation. Sie können es so verwenden, wie es ist, oder es an Ihre Landezonenbedürfnisse anpassen.

Für eine komplexere einsatzfähige Architektur sollten Sie die Cloud Foundation für Sicherheit und Beobachtbarkeit in Betracht ziehen. Diese einsatzfähige Architektur wurde durch die Verknüpfung mehrerer Architekturen aus dem Katalog IBM Cloud erstellt. Damit können Sie die gesamte Palette der Sicherheitsdienste von IBM Cloud nutzen. Es ist anpassbar, so dass Sie nur die Dienste einbeziehen können, die Sie benötigen, und die, die Sie nicht benötigen, weglassen können.

Da Sie nun wissen, wo Sie einsatzfähige Architekturen finden können, stellt sich die Frage, wie Sie diese kontenübergreifend einsetzen und pflegen Sie verwenden ein IBM Cloud Projekt.

Im Projekt konfigurieren Sie die Eingabevariablen für die verteilbare Architektur. Sie können die Kosten, die Drift in Ihren Ressourcen und die Compliance-Scans überwachen und auf die neueste Version einer einsatzfähigen Architektur aktualisieren, sobald diese im Katalog verfügbar ist. Ein Projekt befindet sich in der Regel in einem Hub-Konto und verteilt Ressourcen auf verschiedene Spoke-Konten, die auch als Zielkonten bezeichnet werden.

Lesen Sie unsere Dokumentation, um mehr über die Ausführung sicherer Workloads in IBM Cloud zu erfahren. Oder schauen Sie sich den IBM Cloud Katalog an, um herauszufinden, welche einsatzfähigen Architekturen für Ihr Unternehmen in Frage kommen.

Designprinzipien

Umfang, Zusammensetzbarkeit und Verwendbarkeit sind die drei wichtigsten Designprinzipien, die Sie bei der Erstellung einer implementierbaren Architektur berücksichtigen müssen.

In der Planungs-und Forschungsphase sollten Sie das aktuelle Ökosystem von Angeboten sowie den Geschäftsanwendungsfall und die Anforderungen bewerten. Verwenden Sie Well-Architected Framework und Architecture Design Framework, um die erforderlichen Komponenten für die Architektur zu planen und zu entwerfen.

Bereich

Ein klar definierter Bereich für die implementierbare Architektur ist von entscheidender Bedeutung, da er umfassend genug sein sollte, um alle erforderlichen Ressourcen aufzunehmen, aber ausreichend konzentriert ist, um unnötige Komplexität zu vermeiden.

Es empfiehlt sich, Infrastrukturressourcen einzubeziehen, die in der Regel zusammen als Einheit eingesetzt werden, ähnliche Zugriffsrechte und Berechtigungen erfordern und denselben Lebenszyklus haben. Betrachten wir zum Beispiel Implementierbare VPC landing zone-Architektur. Diese implementierbare Architektur hat einen klar strukturierten Bereich, der die folgenden Infrastrukturressourcen umfasst:

Ressourcen in der VPC-Landingn-Zone DA
Ressource Beschreibung
VPCs Erstellt eine sichere VPC-Topologie
Netzwerkinfrastruktur Enthält Teilnetze, öffentliche Gateways, ACLs, Transit-Gateways und Sicherheitsgruppen
Edge-Netzbetrieb Isoliert den Datenverkehr zum öffentlichen Internet
Überwachung und Protokollierung Integriert Datenflussprotokolle für die Beobachtbarkeit und Prüfung des VPC-Datenverkehrs

Diese Ressourcen werden in der Regel zusammen als Einheit eingesetzt, erfordern ähnliche Netzwerkverwaltungsberechtigungen und haben den gleichen Lebenszyklus, d. h. sie sind gleich:

  • Zusammen erstellt werden, z. B. wenn eine neue VPC mit den zugehörigen Subnetzen, öffentlichen Gateways und Sicherheitsgruppen bereitgestellt wird.
  • Werden zusammen aktualisiert, z. B. wenn eine Änderung an der Netzkonfiguration der VPC vorgenommen wird, die Aktualisierungen an den Teilnetzen, öffentlichen Gateways und Sicherheitsgruppen erfordert.
  • Gemeinsam gelöscht werden, z. B. wenn eine VPC außer Betrieb genommen wird und alle zugehörigen Ressourcen, einschließlich Subnetze, öffentliche Gateways und Sicherheitsgruppen, entfernt werden.

Zusammensetzbarkeit

Ein grundlegendes Prinzip einer einsatzfähigen Architektur ist die Kompositionsfähigkeit, die die Schaffung einer umfassenderen einsatzfähigen Architektur durch das Zusammenfügen mehrerer einsatzfähiger Architekturen ermöglicht. Dieser modulare Ansatz ermöglicht maximale Flexibilität und Wiederverwendbarkeit von Automatisierungsressourcen.

Um die Zusammensetzbarkeit zu erreichen, sollte eine implementierbare Architektur für Folgendes entworfen werden:

  • Maximieren Sie die Menge der Informationen, die über die Ausgabewerte angezeigt werden, und halten Sie die Ausgabetypen einfach. Dieses Verfahren ermöglicht die Wiederverwendung der implementierbaren Architekturautomatisierung in einer Vielzahl von Szenarien und macht sie zu einem vielseitigen Baustein für verschiedene automatisierte Lösungen.

  • Lassen Sie unter anderem optionale Referenzen auf vorhandene bereitgestellte Ressourcen zu, wie z. B. Ressourcengruppen, IBM® Key Protect for IBM Cloud®-oder Hyper Protect Crypto Services-Instanzen und IBM Cloud Secrets Manager-Instanzen. Benutzer können dann vorhandene Instanzen konfigurieren oder in vorhandenen Ressourcengruppen bereitstellen und so die Vielseitigkeit Ihrer Automatisierung erhöhen. Die Implementierbare Secrets Manager-Architektur ist ein großartiges Beispiel für dieses Prinzip in Aktion. Dadurch, dass Benutzer vorhandene Secrets Manager-Instanzen, Ressourcengruppen und KMS-Verschlüsselungsschlüssel wiederverwenden können, bietet diese Automatisierung ein hohes Maß an Flexibilität und Anpassungsfähigkeit. Sie haben beispielsweise folgende Möglichkeiten:

    • Konfigurieren Sie eine vorhandene Secrets Manager-Instanz, indem Sie ihre ID übergeben und Gruppen geheimer Schlüssel in der vorhandenen Instanz erstellen.
    • Integrieren Sie ein vorhandenes Schlüsselmanagementsystem wie Key Protect oder Hyper Protect Crypto Services.
    • Implementieren Sie in einer vorhandenen Ressourcengruppe oder erstellen Sie eine neue mit anpassbaren Namenskonventionen.

Alternativ ermöglicht diese implementierbare Architektur auch die Erstellung einer neuen Instanz von Secrets Manager, einer neuen Ressourcengruppe und anderer Ressourcen völlig neu und stellt so eine eigenständige Lösung bereit.

Durch die Berücksichtigung der Kompositionsfähigkeit kann eine einsatzfähige Architektur leicht in eine komplexere Lösungsarchitektur integriert werden, indem sie mit anderen einsatzfähigen Architekturen kombiniert wird. Das Retrieval Augmented Generation Pattern zeigt beispielsweise, wie mehrere einsatzfähige Architekturen, einschließlich der einsatzfähigen Architektur Secrets Manager, kombiniert werden können, um eine komplexe Lösung aufzubauen. Bereitstellbare Architekturen, die auf Kompatibilität ausgelegt sind, bilden die Grundlage für diese komplexen Lösungen.

Wenn verteilbare Architekturen zusammen gestapelt werden, behält jede einzelne verteilbare Architektur ihren unabhängigen Konfigurationsstatus bei, so dass eine individuelle Verteilung, Aktualisierung oder Rücknahme der Verteilung möglich ist. Dieser modulare Ansatz ermöglicht es, Kosten-, Konformitäts-, Support- und Qualitätsgarantien aus den enthaltenen einsatzfähigen Architekturen abzuleiten, während die Gesamtlösung mit ihren eigenen Beschreibungen und Referenzarchitekturen eindeutig versioniert bleibt. Weitere Informationen finden Sie unter Was bedeutet es, einsatzfähige Architekturen zu stapeln?

Verbraucherfreundlichkeit

Eine bereitstellbare Architektur sollte unter Berücksichtigung der Verbraucherfreundlichkeit entworfen werden, damit Benutzer leicht verstehen und bereitstellen können. Zu diesem Zweck sollte die implementierbare Architektur eine umfassende Dokumentation bereitstellen, die Folgendes umfasst:

Voraussetzungen
Softwareabhängigkeiten und Infrastrukturanforderungen, die für die Bereitstellung erforderlich sind.
Detaillierte Beschreibungen der Eingabevariablen und Ausgabewerte
Einschließlich Zweck, Datentyp und Standardwerten.
Erforderliche Mindestberechtigungen
Erforderliche Berechtigungen für die Ausführung der Automatisierung der implementierbaren Architektur
Diagramme und Architekturübersichten
Visuelle Darstellungen der Komponenten und Beziehungen der bereitstellbaren Architektur
Vereinfachte Konfiguration
Einfache Implementierung und Verwaltung.
Reduzierter Ressourcenbedarf
Optimieren Sie die implementierbare Architektur, um den Hardware-und Ressourcenbedarf zu minimieren, z. B. niedrigere CPU-und Speicheranforderungen, wodurch sie kostengünstiger und effizienter wird.
Optimierte Bereitstellung
Schneller und einfacher Einstieg.

Eine weitere Facette, mit der sichergestellt wird, dass die implementierbare Architektur einfach genutzt werden kann, ist die Bereitstellung mehrerer Varianten, einschließlich einer Variante für den Schnelleinstieg. Es sollte eine Schnellstartversion der implementierbaren Architektur bereitgestellt werden, die kostengünstiger und schneller ausgeführt werden kann. Die QuickStart-Variante der bereitstellbaren Red Hat OpenShift Container Platform on VPC landing zone-Architektur erstellt beispielsweise eine vollständig anpassbare VPC-Umgebung (VPC = Virtual Private Cloud) in einer einzelnen Region und stellt einen einzelnen Red Hat OpenShift-Cluster in einer sicheren VPC für Workloads bereit. Diese Schnellstartvariante ist für Demonstrations-und Entwicklungszwecke konzipiert und kostet weniger als 400 US-Dollar pro Monat für die Ausführung.

Im Gegensatz dazu erstellt die Standardversion der bereitstellbaren Red Hat OpenShift Container Platform on VPC landing zone-Architektur, die auf der Referenzarchitektur IBM Cloud Framework for Financial Services basiert, sichere und kompatible Red Hat OpenShift Container Platform-Workload-Cluster in einem VPC-Netz (VPC = Virtual Private Cloud), die Ausführung kostet jedoch mehr als 4.000 $pro Monat. Darüber hinaus umfasst die Lösung erweiterte Features wie Management-VPC-Service, Workload-VPC-Service, Isolation von Management-VPC und Workload-VPC sowie erweiterte Entscheidungen über die Netzsicherheitsarchitektur.

Eingabevariablen

Verwenden Sie die folgenden bewährten Verfahren, um Benutzern die Konfiguration der Eingabevariablen der implementierbaren Architektur zu erleichtern:

Nur häufig geänderte Argumente zugänglich machen
Legen Sie nur die Variablen offen, die die meisten Benutzer ändern müssen, und vermeiden Sie einsatzfähige Architekturen mit einer großen Anzahl von Eingabevariablen, die die Benutzer überfordern würden. Für fortgeschrittene Benutzer sollten Sie die Bereitstellung eines einzelnen JSON-Eingabefelds zur weiteren Anpassung in Betracht ziehen. Als Beispiel wird in der implementierbaren Architektur der VPC-Landing-Zone ein einzelnes Feld namens override_json_string angezeigt, das fortgeschrittenen Benutzern die vollständige Kontrolle über die bereitgestellte Topologie gibt. Weitere Informationen finden Sie im Leitfaden zur Bereitstellung der VPC-Landing-Zone.
Eindeutige und beschreibende Benennung für vorhandene Ressourcen verwenden
Wenn Sie auf vorhandene Ressourcen verweisen, verwenden Sie Namen, die eindeutig angeben, worauf sie verweisen, z. B. existing_cluster_name anstelle von cluster_name, um Mehrdeutigkeit zu vermeiden.
Namen über IDs bevorzugen
Wenn Sie auf vorhandene Ressourcen verweisen, verwenden Sie Namen anstelle von IDs, um die Benutzerfreundlichkeit zu verbessern.
Akronyme vermeiden
Verwenden Sie anstelle von Akronymen vollständige Produktnamen, damit Personen, die mit den Produkten oder Services nicht vertraut sind, leichter verstehen können, worauf sie sich beziehen. Beispiel: secrets_manager anstelle von sm oder key_management anstelle von kms.
Erweiterte Eingabefunktionen verwenden
Damit der Service ' IBM Cloud Projects' geeignete Eingabewidgets für Variablen wiedergeben kann, ist die Konfiguration von Werten für Benutzer einfacher. Zum Beispiel:
  • VPC-Region: Eine Dropdown-Liste aller verfügbaren VPC-Regionen auf IBM Cloud.
  • VPC-SSH-Schlüssel: Ein sicheres Eingabefeld für das SSH-Schlüsselmanagement.
  • Cluster: Eine Dropdown-Liste verfügbarer Cluster auf IBM Cloud.

Weitere Informationen finden Sie unter Katalogmanifestwerte lokal bearbeiten.

Durch die Einhaltung dieser Richtlinien kann die implementierbare Architektur benutzerfreundlicher gestaltet werden, sodass Benutzer sie schnell verstehen und implementieren können.

Qualität

Um sicherzustellen, dass die implementierbare Architektur zuverlässig und konsistent ist, ist es wichtig, Qualitätsprüfungen zu implementieren und zu automatisieren. Diese Prüfungen sollten verschiedene Aspekte der implementierbaren Architektur abdecken, einschließlich Codequalität, Konfigurationsvalidierung, Tests und kontinuierliche Integration.

Codequalität

Nutzen Sie Linting und Codeformatierung. Erzwingen Sie konsistente Codierungsstile und -formatierungen, damit der Code einfach zu lesen und zu verwalten ist. Erkennen Sie Fehler und Warnungen im Code, um Probleme während der Implementierung zu verhindern. Erwägen Sie, über den Terraform-Code hinauszugehen und alle Tools einzubeziehen, die für alle Ressourcen in Ihrer verteilbaren Architektur relevant sind, wie Bash-Skripte, Python-Skripte, YAML- und JSON-Dateien und Golang.

Beispiele:

  • terraform_fmt zum Formatieren von Terraform-Code.
  • go-fmt zum Formatieren von Go-Code.
  • black zum Formatieren von Python-Code.
  • isort zum Sortieren von Python-Importen.
  • flake8, um Python-Code auf Fehler und Warnungen zu überprüfen.
  • shellcheck zum Überprüfen von Shell-Scripts auf Fehler und Warnungen.
  • golangci-lint, um den Go-Code auf Fehler und Warnungen zu überprüfen

Konfigurationsvalidierung

Verwenden Sie die statische Validierung, um die Syntax und Konfiguration der implementierbaren Architektur zu überprüfen und sicherzustellen, dass sie korrekt und konsistent ist. Überprüfen Sie die Konfiguration der implementierbaren Architektur, um Fehler während der Implementierung zu verhindern. Auch hier sollten Sie über den Terraform-Code hinausgehen und alle Tools einbeziehen, die für alle Ressourcen in Ihrer Deployment-Architektur relevant sind, wie z. B. Bash-Skripte, Python-Skripte, YAML- und JSON-Dateien und Golang.

Beispiele:

  • terraform_validate zum Validieren der Terraform-Konfiguration.
  • checkov für die Überprüfung auf Sicherheits-und Konformitätsprobleme im Terraform-Code.
  • tflint, um nach Fehlern und Warnungen zu suchen.
  • detect-secrets, um geheime Schlüssel im Code zu erkennen
  • hadolint, um Docker-Dateien auf Fehler und Warnungen zu überprüfen.
  • helmlint, um Helm-Diagramme auf Fehler und Warnungen zu überprüfen.

Testen

Wenn es um das Testen von Infrastrukturcode geht, gibt es keine reinen Komponententests in der Weise, wie Sie es für Anwendungscode denken könnten. Stattdessen beinhaltet die Teststrategie die Implementierung der Infrastruktur in einer realen Umgebung, die Validierung ihrer Funktionsweise und die anschließende Deimplementierung.

Automatisierte Validierungstestsuite

Es wird empfohlen, eine einfache automatisierte Testsuite zu haben, die die folgenden Grundlagen abdeckt:

Implementierungstests
Überprüfen Sie, ob der Infrastrukturcode erfolgreich in einer realen Umgebung implementiert werden kann. Erstellen Sie alle erforderlichen Ressourcen wie virtuelle Maschinen, Datenbanken und Netzwerke. Diese Tests stellen sicher, dass der Infrastrukturcode korrekt ist und erfolgreich auf eine reale Umgebung angewendet werden kann. Es wird empfohlen, die Eingabeparameter der implementierbaren Architektur in diesen Tests zu variieren, um eine breite Abdeckung sicherzustellen, die an der allgemeinen Nutzung ausgerichtet ist.
Zerstörungstests
Überprüfen Sie, ob der Infrastrukturcode erfolgreich deimplementiert oder gelöscht werden kann, und entfernen Sie alle erstellten Ressourcen. Diese Tests stellen sicher, dass der Infrastrukturcode sicher aus einer realen Umgebung entfernt werden kann, ohne verwaiste Ressourcen zu hinterlassen oder unbeabsichtigte Folgen zu haben.
Idempotenztests
Überprüfen Sie, ob der Infrastrukturcode mehrmals erneut angewendet werden kann, ohne unbeabsichtigte Änderungen oder Fehler zu verursachen. Mit anderen Worten, der Code sollte unabhängig davon, wie oft er angewendet wird, dasselbe Ergebnis erzeugen. Diese Tests sind in Umgebungen wie IBM Cloudkritisch, in denen die Plattform regelmäßig nach Änderungen sucht, um Abweichungen zwischen der bereitgestellten Infrastruktur und der Quelle der Wahrheit, d. h. dem Automatisierungscode, zu erkennen. Idempotency-Tests tragen dazu bei, dass der Infrastrukturcode wiederholte Bereitstellungen oder Aktualisierungen verarbeiten kann, ohne Probleme zu verursachen. Diese Tests tragen auch dazu bei, dass Drifterkennungsfunktionen Abweichungen zwischen dem beabsichtigten Status und dem tatsächlichen Status der Infrastruktur genau erkennen und beheben können. Weitere Informationen finden Sie unter Drift verwalten.
Versionsupgradetests
Stellen Sie sicher, dass der Infrastrukturcode erfolgreich von einer Version auf eine andere aktualisiert werden kann, ohne Fehler oder unbeabsichtigte Änderungen zu verursachen. Diese Tests stellen sicher, dass der Infrastrukturcode sicher aktualisiert werden kann, ohne dass vorhandene Ressourcen unterbrochen oder gelöscht werden oder unbeabsichtigte Folgen entstehen.

Erweiterte Testfälle

Zu den erweiterten Testfällen gehören folgende Szenarios:

Implementierbare Architektur mehrfach in demselben Account implementieren
Überprüfen Sie, ob der Infrastrukturcode mehrere Implementierungen in demselben Konto verarbeiten kann, ohne dass es zu Ressourcennamenskollisionen oder anderen Problemen kommt.
Implementierbare Architektur mit einem vertrauenswürdigen Profil implementieren
Stellen Sie sicher, dass der Infrastrukturcode mit einem vertrauenswürdigen Cloud Identity and Access Management-Profil implementiert werden kann. Weitere Informationen finden Sie unter Authentifizierungsmethode definieren.

Durch die Einbindung dieser Tests in Ihre automatisierte Testsuite können Sie sicherstellen, dass Ihr Infrastrukturcode zuverlässig, zuverlässig und sicher in der Produktion implementiert werden kann.

Continuous Integration

Um die Zuverlässigkeit, Konsistenz und Wartungsfreundlichkeit der implementierbaren Architektur sicherzustellen, wird ein Shift-Left-Ansatz empfohlen, bei dem Qualitätsprüfungen und Tests frühzeitig in den Entwicklungszyklus integriert werden. Dieser Ansatz hilft, Fehler und Mängel frühzeitig zu erkennen, die Wahrscheinlichkeit nachfolgender Probleme zu verringern und die Gesamtqualität zu verbessern.

Im Rahmen dieses Ansatzes werden die folgenden Qualitätsprüfungen empfohlen:

Clientseitige Qualitätskontrolle
Clientseitige Git Commit-Hooks sollten verwendet werden, um Prüfungen auf der Entwicklermaschine auszuführen, bevor Code festgeschrieben wird. Dazu gehören Prüfungen auf Codierungsstandards, Syntaxfehler und sensible Daten. Zur Automatisierung dieses Prozesses können Tools wie Pre-commit verwendet werden.
CI-Verfahren
Best Practices für die kontinuierliche Integration (CI) sollten befolgt werden. Die allgemeinen Verfahren für jedes Software-Engineering-Produkt gelten für die Entwicklung implementierbarer Architekturen, einschließlich:
  • Mit kleinen, fokussierten Pull-Requests (PRs) arbeiten, um zeitnahe Prüfungen zu ermöglichen und Zusammenführungskonflikte zu reduzieren
  • Regelmäßige Integration von Codeänderungen in den Hauptzweig, um langlebige Funktionszweige zu verhindern und die Komplexität der Zusammenführung zu reduzieren.
  • Automatisierte Tests und Codeprüfungen implementieren, um Codequalität und -konsistenz sicherzustellen.
  • Kontinuierliche Validierung der Konfiguration und Syntax der implementierbaren Architektur, um Richtigkeit und Konsistenz sicherzustellen.
CI-Pipeline
Eine CI-Pipeline sollte eingerichtet werden, um diese Verfahren zu automatisieren und sicherzustellen, dass jede Codeänderung in der implementierbaren Architektur systematisch getestet und validiert wird. Diese Pipeline stellt sicher, dass die bereitstellbare Architektur ordnungsgemäß und konsistent funktioniert und dass Fehler oder Fehler frühzeitig abgefangen werden.

Tools und Ressourcen

Eine umfassende Gruppe von Tools und Ressourcen wird bereitgestellt, um die Erstellung hochwertiger implementierbarer Architekturen zu vereinfachen. Kuratierte Terraform-Module sind ein Schlüsselelement mit über 60 wiederverwendbaren, sicheren und validierten Modulen, die eine Vielzahl von Infrastrukturanforderungen abdecken. Diese Module sind auf GitHub verfügbar und werden über ein Open-Source-Beitragsmodell unterstützt und auf dem aktuellen Stand gehalten. Sie werden durch Beiträge der IBM Cloud-Entwicklungsorganisation gestützt.

Neben den kuratierten Terraform-Modulen werden auch Best Practices und Vorlagen bereitgestellt, die Sie bei der implementierbaren Architektur und beim Modulauthoring unterstützen. Dazu gehören die Dokumentation, eine Vorlage für ein bereitstellbaresGitHub-Architekturrepository, die an den bewährten Verfahren für das Authoring ausgerichtet ist, und Richtlinien für das Modulauthoring, die sowohl für Terraform-Module als auch für auf Terraform basierende bereitstellbare Architekturen gelten. Diese Ressourcen können für den schnellen Einstieg in eine neue implementierbare Architektur verwendet werden.

Außerdem wird ein automatisiertes Testframework bereitgestellt, das auf der Terratest-Bibliothek basiert und in Go geschriebene Tests enthält. Das Framework deckt Idempotenz-Tests, Upgrade-Tests und GitHub, ab und verwendet Testhilfsfunktionen aus der Bibliothek https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper. Weitere Informationen finden Sie in der Testdokumentation.

Zur Unterstützung der CI-Pipeline-Entwicklung stehen eine Reihe von Tools und Ressourcen zur Verfügung, darunter:

  • Wiederverwendbare GitHub-Aktionen.
  • Automatisierte Generierung von Dokumentation.
  • Automatisiertes Onboarding in IBM Cloud.
  • Automatisierte Abhängigkeitsaktualisierungen durch angepasste Renovate.
  • Informationen zu den Setup-Tools für die lokale Entwicklung und zur Konfiguration der Hooks vor der Festschreibung finden Sie in der Dokumentation zur lokalen Entwicklungskonfiguration.

Diese Tools und Ressourcen wurden entwickelt, um die Erstellung hochwertiger implementierbarer Architekturen zu beschleunigen und zu vereinfachen.

Nächste Schritte

Nachdem Sie sich mit den Best Practices für die Erstellung einer implementierbaren Architektur vertraut gemacht haben, können Sie die Tools und Ressourcen verwenden und die folgende Dokumentation zu IBM Cloud lesen, bevor Sie Ihren Automatisierungscode entwickeln. Auf diese Weise können Sie sicherstellen, dass Sie Ihre Lösung für die gemeinsame Nutzung in IBM Cloudgründlich geplant und entworfen haben: