Wie entscheide ich, welche Art von Komponente erstellt werden soll?

Wie entscheiden Sie, ob Sie ein Modul, eine verteilbare Architektur oder mehrere verteilbare Architekturen zusammen erstellen sollten? Vergleichen Sie die Unterschiede und bewerten Sie die Anwendungsfälle in den folgenden Abschnitten als Entscheidungshilfe.

Vergleich von einsatzfähigen Architekturen und Modulen

Die folgende Tabelle enthält einen Vergleich und eine kurze Zusammenfassung der wichtigsten Unterschiede zwischen Modulen und Typen implementierbarer Architekturen.

Vergleich der Konzepte
Methode	Bereich	Kopplung	Implementierbar	Autor
Modul erstellen	Schmal	eng	Nein	Entwickler
Erstellen einer einsatzfähigen Architektur	Mittel bis breit	eng	Ja	Entwickler
Bereitstellbare Architekturen in den Stapel stellen	Breit	Lose	Ja	Jeder

Die folgende Tabelle kann Ihnen bei der Entscheidung helfen, ob Sie je nach Anwendungsfall ein Modul, eine verteilbare Architektur oder einen Stapel verteilbarer Architekturen verwenden sollten.

Helfen Sie mir bei der Auswahl der zu verwendenden Komponente
Zweck	Empfohlene Methode	Anmerkungen
Schnellere Automatisierung der Codierung	Module verwenden	Module stellen wiederverwendbare, kuratierte Automatisierung bereit, damit Entwickler implementierbare Architekturen schneller codieren können. Module sind für Entwickler, nicht für Konsumenten.
Stellen Sie sicher, dass die Cloud sicher und konform ist	Verwendung einer einsatzfähigen Architektur	Implementierbare Architekturen setzen Sicherheit und Compliance für eine Architektur durch. Wenn eine implementierbare Architektur zu klein ist, kann sie die Konformität nicht durchsetzen. Beispielsweise kann eine implementierbare Architektur, die nur eine virtuelle Serverinstanz implementiert, die Netzsicherheit nicht gewährleisten.
Geben Sie den Benutzern mit Guardrails die Wahl	Stapeln Sie verteilbare Architekturen zusammen	Durch das Stapeln von einsatzfähigen Architekturen können Sie einsatzfähige Architekturen austauschen oder zusätzliche einsatzfähige Architekturen hinzufügen und den Benutzern mehr Auswahlmöglichkeiten bieten. Da implementierbare Architekturen Sicherheit und Compliance durchsetzen, trägt das Stapeln dazu bei, dass die Gesamtlösung konform bleibt. Das Stapeln von einsatzfähigen Architekturen ist ein hervorragender Ansatz, um z. B. die zu verwendende Datenbank auszuwählen.
Benutzererstellte Lösungen oder Architekturen	Stapeln Sie verteilbare Architekturen zusammen	Durch das Stapeln einsatzfähiger Architekturen können Benutzer ihre eigenen wiederholbaren Muster erstellen und veröffentlichen, die dennoch sicher sind, da sie aus sicheren und konformen einsatzfähigen Architekturen bestehen.
Entkoppelte Architekturkomponenten	Stapeln Sie verteilbare Architekturen zusammen	Einsatzfähige Architekturen können unabhängig voneinander entwickelt und versioniert werden, aber dann für den Einsatz zusammengefügt werden.
Vereinfachte Funktionalität für den Benutzer	Verwendung einer einsatzfähigen Architektur	Implementierbare Architekturen können eine kleine oder einfache Liste von Eingaben für den Benutzer bereitstellen, auch für große oder komplexe Architekturen. Implementierbare Architekturen sind einfach zu verstehen und zu implementieren. Im Vergleich dazu ist das Stapeln implementierbarer Architekturen etwas komplexer, da die implementierbaren Architekturen zugänglich sind.

IBM Cloud-Projekte stellen sicher, dass Ressourcen über implementierbare Architekturen aus dem Katalog bereitgestellt werden und innerhalb der Sicherheits-und Compliance-Guardrails der Organisation arbeiten. Sie stellen außerdem sicher, dass diese Ressourcen auf dem neuesten Stand bleiben und nicht driften.

Abhängigkeiten für bereitstellbare Architekturen

Abhängigkeiten entstehen, wenn Ressourcen, die von einer bereitstellbaren Architektur bereitgestellt werden, von einer anderen benötigt werden. Das bedeutet, dass die Ressourcen, die eine bereitstellbare Architektur bereitstellt, bei der Bereitstellung einer anderen Architektur verwendet werden, wie in der folgenden Abbildung dargestellt.

Eine visuelle Darstellung einer bereitstellbaren Architektur mit einer Abhängigkeit. Die bereitstellbare Architektur A gibt Ressourcen aus, die dann als Eingaben in der bereitstellbaren Architektur B verwendet werden. — Abhängigkeiten der einsatzfähigen Architektur

Eine Möglichkeit, mit Abhängigkeiten zu arbeiten, ist das Stapeln von einsatzfähigen Architekturen und das Hinzufügen von Referenzen zwischen ihnen in einem Projekt. Zum Beispiel enthält die VSI on VPC landing zone einsatzfähige Architektur eine Variante, die die Red Hat OpenShift Container Platform auf VPC landing zone einsatzfähige Architektur erweitert. Erwägen Sie, diese Architekturen in einem Projekt zusammenzustapeln. Dieser Ansatz funktioniert gut, wenn die erforderliche Architektur noch nicht bereitgestellt ist. Sie müssen auch keinen Code bearbeiten, um bereitstellbare Architekturen zu stapeln.

Viele bereitstellbare Architekturen sind eigenständig und keine Erweiterungen anderer Architekturen, aber Sie können einige bereitstellbare Architekturen erweitern in der Die Architektur Abschnitt der Katalogdetailseite. Wählen Sie eine Option aus dem Wie möchten Sie diese Architektur aufbauen? Speisekarte.

Wenn Sie jedoch bereits Red Hat OpenShift Containerplattform und Sie müssen VSI bereitstellen. Die für VSI erforderlichen Ressourcen sind bereits bereitgestellt. Sie müssen nicht die Red Hat OpenShift Noch einmal: Container-Plattform-Architektur. Da die VSI-Architektur eine Erweiterung der Red Hat OpenShift Container Platform können Sie VSI einsetzen und die Architektur nutzt die Ressourcen aus der Red Hat OpenShift Containerplattform nach Bedarf.

Optionale und austauschbare einsatzbereite Architekturen

Wenn Sie eine einsatzfähige Architektur in einen privaten Katalog einbinden, können Sie sie durch Stapeln mit anderen Architekturen erweitern. Auf diese Weise können Sie eine besser anpassbare Lösung für Ihre Benutzer schaffen.

Warum Stacking bei der Einarbeitung?

Das Stapeln von Architekturen während des Onboardings ist ähnlich wie das Stapeln von Architekturen in einem Projekt. Wenn Sie eine Architektur einbinden, können Sie Abhängigkeiten einbeziehen, indem Sie die erforderlichen Architekturen zusammen mit ihr stapeln. Im Gegensatz zum Stapeln von Architekturen in einem Projekt umfasst das Stapeln von Architekturen während des Onboardings jedoch die folgenden Funktionen:

Sie können optionale Architekturen hinzufügen, die für verschiedene Anwendungsfälle zugeschnitten sind.
Sie können austauschbare Architekturen hinzufügen, zwischen denen die Benutzer wählen können.

Optionale Architekturen

Vielleicht funktioniert Ihre Architektur gut mit einer anderen einsatzfähigen Architektur, wird aber nicht benötigt, um eine Abhängigkeit zu erfüllen oder die Compliance einzuhalten. Sie können die verteilbare Architektur als optional hinzufügen, und die Benutzer können sich dafür entscheiden, sie einzubeziehen, wenn sie Ihre verteilbare Architektur zu einem Projekt hinzufügen. So kann beispielsweise eine Überwachungsarchitektur nützlich, aber nicht erforderlich sein.

Auswechselbare Architekturen

Jede Architektur, die Sie beim Onboarding mit Ihrer eigenen kombinieren, kann mit anderen Architekturen ausgetauscht werden. Bei austauschbaren Architekturen haben die Benutzer die Wahl zwischen mehreren Optionen, die dieselbe Funktionalität bieten. Sie können zum Beispiel zwei einsatzfähige Architekturen einbinden, die unterschiedliche Datenbanken erstellen, und der Benutzer kann entscheiden, welche Datenbankoption er mit Ihrer Architektur verwenden möchte.

Weitere Informationen finden Sie unter Erweitern einer verteilbaren Architektur während des Onboardings.

Optionale und austauschbare Architekturen können hinzugefügt werden, wenn Sie eine einsatzfähige Architektur in einen privaten Katalog aufnehmen. Derzeit unterstützt das Stapeln von einsatzfähigen Architekturen in einem Projekt keine optionalen oder austauschbaren Architekturen.

Terraform im Vergleich zu Ansible

In IBM Cloudmuss eine bereitstellbare Architektur Terraform verwenden, um die Eingaben und Ausgaben der bereitstellbaren Architektur (die Schnittstelle) zu deklarieren, da Ansible keine maschinenlesbare Schnittstellendefinition hat. Andernfalls kann der Autor einer bereitstellbaren Architektur eine beliebige Kombination aus Ansible-Vor-oder Nachscripts und Terraform verwenden, um die Arbeit der bereitstellbaren Architektur auszuführen. Wie entscheidet also ein Entwickler, welche Technologie verwendet werden soll und wofür?

Vergleich der Konfigurationssprachen
Die erste Spalte enthält Kategorien, die zum Vergleich von Terraform und Ansible. Die zweite Spalte enthält Informationen dazu, wie Terraform mit der Satzkategorie in Spalte 1 in Beziehung steht. Die dritte Spalte enthält Informationen dazu, wie Ansible mit der Satzkategorie in Spalte 1 in Beziehung steht.
	Terraform	Ansible
Sprache	Deklarativ	Verfahren
Syntax	HCL (ähnlich wie JSON)	YAML (und Aufrufe anderer Scripts)
Standardmethode	Veränderliche Infrastruktur	Unveränderliche Infrastruktur
Fokus	Infrastruktur	Konfiguration
Driftansicht	Vergleich mit gewünschtem Status	Idempotent-Tasks

Terraform eignet sich hervorragend zum Erstellen und Verwalten von Infrastruktur, während Ansible hervorragend zum Konfigurieren der Software und Betriebssysteme geeignet ist, die in dieser Infrastruktur ausgeführt werden. Da Ansible prozeduriert ist, können Sie auch einmalige Operationen mit Scripts ausführen. Verwaltungstasks wie die Wiederherstellung aus einer Sicherung sind in Ansibleeinfach.

Helfen Sie mir bei der Auswahl der zu verwendenden Konfigurationssprache
Zweck	Empfohlene Konfigurationssprache	Anmerkungen
Cloud-Infrastruktur oder -Services implementieren	Terraform	Terraform zielt auf diesen Anwendungsfall ab und ist besser in der Handhabung sich ändernder Infrastruktur. IBM Cloud stellt Terraform-Module und unterstützte bereitstellbare Architekturen zur Beschleunigung sicherer und konformer Infrastrukturmuster bereit. Mit dem Terraform-Statusmodell können Entwickler eine Vorschau der Änderungen anzeigen. Diese Änderungen können auf Konformität überprüft werden.
Software installieren oder konfigurieren	Ansible	Wenn ein vordefinierter Container oder ein Image einer virtuellen Maschine für den Anwendungsfall nicht geeignet ist, ist Ansible besser in der Handhabung der Softwareinstallation und -konfiguration. Ansible bietet umfassende Unterstützung für automatisierte Operationen wie Konfigurationsbearbeitung, Paketverwaltung und Prozessneustarts. Eine große Bibliothek mit Ansible-Modulen und -Playbooks ist verfügbar, um die Konfiguration von Tausenden häufig verwendeten Softwarepaketen zu vereinfachen.
CCDB-Integration	Ansible	Ein dynamischer Aufruf an einen lokalen Service wie eine CCDB kann in Terraform oder Ansible ausgeführt werden, ist jedoch in einer prozeduralen oder scriptbasierten Sprache einfacher zu erreichen.
Eingabevalidierung	Terraform oder Ansible	Terraform verfügt über eingeschränkte Möglichkeiten zur Eingabevalidierung, ist jedoch deklarativ und kann von Benutzerschnittstellen verwendet werden. Ansible bietet die Möglichkeit zur dynamischen Eingabevalidierung, bei der Eingaben für eine implementierbare Architektur anhand eines fernen Service überprüft werden.
Wartungsaktionen für Tag 2	Ansible	Die Wartung von Tag 2 ist im Allgemeinen prozeduraler Natur und wird am besten in Ansibleausgeführt. Beispiele sind manuelle Sicherung, Wiederherstellung oder Schlüsselrotationen.
Abweichungsmanagement	Terraform Ansible	Terraform kann verwendet werden, um festzustellen, ob eine Drift aufgetreten ist und was diese Drift ist. Dies kann Ihnen bei der Entscheidung helfen, wie Sie die Drift verwalten. Die Abweichungsinformationen sind leistungsfähig, da sie möglicherweise darauf hinweisen, dass Sie eine Änderung zur Automatisierung hinzufügen können. Ansible kann keine Abweichung erkennen. Aber indem Sie regelmäßig ein idempotentes ansible Skript anwenden, können Sie Drift verhindern.

Weitere Informationen zum Einschließen von Vor-oder Nachscripts in Ihre implementierbaren Architekturen finden Sie unter Scripts für implementierbare Architektur erstellen.

Nächste Schritte: Entscheiden, wo veröffentlicht werden soll

Nachdem Sie Ihre Architektur geplant und entschieden haben, welcher Komponententyp erstellt werden soll, sollten Sie überlegen, wo Sie Ihre Lösung gemeinsam nutzen oder veröffentlichen, damit andere Benutzer die von Ihnen erstellte Lösung nutzen können. Je nachdem, wo Sie die gemeinsame Nutzung oder Veröffentlichung planen, müssen Sie möglicherweise unterschiedliche Ebenen von Anforderungen oder Genehmigungen erfüllen.