Implementierbare Architektur erstellen

Nachdem Sie die Schritte zum Planen und Entwerfen Ihrer Architektur ausgeführt und entschieden haben, welcher Komponententyp erstellt werden soll, können Sie mit der Erstellung des automatisierten Codes beginnen, der die Architektur zum Leben erweckt. Dieser Artikel führt Sie durch die Erstellung einer implementierbaren Architektur aus Modulen.

Um eine bereitstellbare Architektur zu erstellen, müssen Sie die erforderlichen Dateien definieren, eine Version erstellen in GitHub, und integrieren Sie es dann in einen privaten Katalog, sodass Sie es mit anderen innerhalb oder außerhalb Ihrer Organisation teilen können.

Sie haben mehrere Möglichkeiten, eine einsatzfähige Architektur zu erstellen:

Bauen Sie Ihre eigene: Verwenden Sie die folgenden Anweisungen, um Ihre eigene einsatzfähige Architektur von Grund auf zu erstellen.
Ändern Sie vorhandenen Code: Laden Sie den Code einer bestehenden Architektur herunter, passen Sie ihn an Ihre Bedürfnisse an und erstellen Sie eine neue einsatzfähige Architektur mit Ihren Änderungen.
Architekturen stapeln: Sie können auch einsatzfähige Architekturen in einem Projekt stapeln, wenn diese Architekturen bereits in einem Katalog verfügbar sind.

Informationen zur Struktur einer implementierbaren Architektur

Eine implementierbare Architektur, die in dieser Dokumentation beschrieben wird, besteht aus mindestens einem Modul. Eine implementierbare Architektur besteht aus den folgenden Komponenten im Quellenrepository:

einer verlegbaren Architektur*Anatomie einer verlegbaren — einer terraformbasierten verlegbaren

Terraform-Code: Ihr Quellenrepository enthält Terraform-Dateien. Diese Dateien deklarieren die gewünschte Infrastruktur (Endstatus) und stützen sich auf Terraform-Provider, die die tatsächlichen API-Anforderungen zum Erstellen, Aktualisieren und Löschen der Infrastruktur ausführen. Einige der am häufigsten verwendeten Provider sind IBM Cloud® Terraform-Provider und Helm/Kubernetes/REST-API-Provider.
Skripte (optional): Wird als Stopplücke für möglicherweise nicht vorhandene Funktionen (Bash/Python) oder für Ad-hoc-Betriebstasks (Ansible) verwendet. Weitere Informationen finden Sie unter Scripts für implementierbare Architekturen erstellen.
Automatisierte Tests: Validierungstests, die zum Bereitstellen, Verifizieren und Löschen der Infrastruktur verwendet werden. Ein Beispiel finden Sie im Verzeichnis tests im Beispielrepository sample-deployable-architectures.
Dokumentation: Das Quellenrepository muss ein Architekturdiagramm und eine Readme-Datei enthalten.
Katalogmanifestdatei: Definiert, wie die bereitstellbare Architektur im IBM Cloud-Katalog zugänglich gemacht wird Zusätzlich zu den allgemeinen Katalogdetails wie Name, Beschreibung und Funktionen enthält er die Variationsdefinitionen, die auf die zugrunde liegende Terraform-Konfiguration verweisen, Compliance-Anforderungen, die beim Onboarding in IBM Cloud® Security and Compliance Center Workload Protection den Katalog mithilfe von überprüft werden, sowie die erforderlichen IAM-Berechtigungen für die Ausführung der bereitstellbaren Architektur. Weitere Informationen finden Sie unter Katalogmanifest lokal bearbeiten.
Varianten: Eine implementierbare Architektur kann Variationen von Funktionalität oder Komplexität enthalten. Sie könnten beispielsweise eine Variante für den Schnelleinstieg mit Basisfunktionalität für eine einfache, kostengünstige Implementierung erstellen und dann eine Standardvariante mit einer komplexeren Architektur haben, die in der Produktion verwendet werden würde. Jede dieser Varianten ist selbst eine implementierbare Architektur, die integriert und so konfiguriert wird, dass sie zusammen in einem Katalog angezeigt wird. Diese Varianten stammen aus demselben Repository in verschiedenen Arbeitsverzeichnissen und sind in Ihrer Datei ibm_catalog.json definiert. Weitere Informationen finden Sie unter Erstellen einer Variation.

Angabe von Abhängigkeiten und Erweiterung Ihrer Architektur

Wenn Ihre verteilbare Architektur von einer anderen abhängt, können Sie Informationen über diese Abhängigkeit aufnehmen, wenn Sie Ihre verteilbare Architektur in einen Katalog einbinden. Sie können auch optionale Architekturen einbeziehen, um Ihre eigene für verschiedene Anwendungsfälle zu erweitern. Das Ergebnis ist eine anpassbare Lösung für die Benutzer, denn sie können wählen, welche Architekturen sie zusammen mit ihrer eigenen einbeziehen möchten. Weitere Informationen finden Sie unter Erweitern einer verteilbaren Architektur während des Onboardings.

Sie können auch Informationen über andere Architekturen, die Sie zusammen mit Ihrer eigenen einbinden möchten, in der Katalogmanifestdatei für Ihre einsatzfähige Architektur bereitstellen, bevor Sie diese einbinden.

Verwenden Sie den Abschnitt dependencies in der Katalogmanifestdatei, um eine anpassbare Lösung mit optionalen und erforderlichen Architekturen zu erstellen. Stellen Sie sicher, dass dependency_version_2 in der Katalogmanifestdatei auf true eingestellt ist. Die bisherige Art der Arbeit mit Abhängigkeiten in der Katalogmanifestdatei wird weiterhin unterstützt. Wenn dependency_version_2 auf false gesetzt ist, können Sie install_type auf extension setzen und Informationen über die Abhängigkeiten im Abschnitt dependencies bereitstellen. Wenn Sie dies tun, ist jede Architektur in der Liste der Abhängigkeiten erforderlich, um Ihre eigene bereitzustellen. Weitere Informationen und die Einstellung dieser Werte finden Sie unter Lokale Bearbeitung des Katalogmanifests.

Implementierbare Architektur erstellen

Sie können erwarten, die folgenden allgemeinen Tasks auszuführen, während Sie Ihre implementierbare Architektur erstellen:

Erstellen Sie Ihr Quellenrepository und fügen Sie Ihren Code hinzu.
Erstellen Sie Ihre Manifestdatei ibm_catalog.json, um die Erstellung einer Kachel im Katalog vorzubereiten.
Erstellen Sie ein Release.
Integrieren Sie Ihren Code in eine Kachel zum Erstellen eines Katalogs in einem privaten Katalog, indem Sie ihn überprüfen und validieren.
Wählen Sie aus, wo Sie Ihre bereitstellbare Architektur gemeinsam nutzen oder veröffentlichen wollen.

Die folgenden Anweisungen zum Erstellen einer implementierbaren Architektur verwenden ein öffentliches Beispielrepository, um anhand eines Beispiels zu lehren.

Quellenrepository erstellen

Erstellen Sie mithilfe der Anforderungen, die von Ihrer Organisation definiert werden, ein GitHub-Repository, in dem Sie den Quellcode für Ihre bereitstellbare Architektur speichern können. Hilfe zum Erstellen eines Repositorys finden Sie in der Dokumentation zuGitHub. Wenn Sie bereits über ein Repository verfügen, das Sie verwenden möchten, können Sie diesen Schritt überspringen. Sie können Ihren Quellcode auch bei einer anderen Organisation hosten lassen, beispielsweise GitLab, aber für die Zwecke dieser Dokumentation, GitHub wird eingesetzt.

Erforderliche Terraform-Dateien erstellen

Lesen Sie die folgenden Abschnitte, um zu verstehen, welche Terraform-Basisdateien in Ihrem GitHub-Quellenrepository erforderlich sind, um die Datei .tgz zu erstellen, die als Teil des Onboardings Ihrer bereitstellbaren Architektur in einen privaten Katalog erforderlich ist.

`main.tf`

In der Datei main.tf stellen Sie den Code bereit, der die Ressourcen bereitstellt, die Sie erstellen möchten. Sie können ein Modul direkt über terraform-ibm-modules oder ein externes Modul oder eine Providerressource aufrufen.

Siehe Beispiele:

`outputs.tf`

Die Datei outputs.tf enthält Ausgabewerte, die Sie in Ihre implementierbare Architektur einschließen können.

Siehe Beispiele:

`provider.tf`

Die Datei provider.tf enthält die Providerkonfiguration wie den Providernamen, den API-Schlüssel und die Region, die der Code erwartet.

Siehe Beispiele:

`README.md`

Die Readme-Datei enthält Hintergrund-und Nutzungsinformationen zur implementierbaren Architektur, einschließlich Abschnitten zu Anforderungen, Modulen, Ressourcen, erforderlichen Zugriffen, Eingaben und Ausgaben.

Wenn sich das Quellenrepository in der terraform-ibm-modules-Organisation befindet, wird ein Großteil der Readme-Datei generiert. Sie fügen also die Informationen wie die Ein-und Ausgaben nicht manuell hinzu. Variablennamen und Beschreibungen werden aus der variables.tf Datei in die Readme-Datei generiert.

Siehe Beispiele:

`variables.tf`

Die Datei variables.tf enthält die erforderlichen und optionalen Variablen für die implementierbare Architektur.

Siehe Beispiele:

`version.tf`

In der Datei version.tf werden Informationen zur Terraform-Version und zur Providerversion gespeichert, die für die Ausführung der bereitstellbaren Architektur erforderlich sind.

Alle erforderlichen Terraform-Provider für die bereitstellbare Architektur sollten in einer exakten Version gesperrt werden, anstatt einen Bereich zu verwenden, um konsistente Ergebnisse mit der bereitstellbaren Architektur sicherzustellen.

Siehe Beispiele:

Erstellen einer Katalog-Manifestdatei

Das Katalogmanifest ist eine Datei im Stammverzeichnis Ihres Repositorys, die als ibm_catalog.json bezeichnet wird. Diese Datei definiert die erforderlichen Metadaten zum Erstellen einer Kachel in einem Katalog, z. B. den Namen, die Beschreibung, die Funktionen, Variationsdefinitionen, die auf die zugrunde liegende Terraform-Konfiguration verweisen, Compliance-Anforderungen, die während der Workload Protection Onboarding-Phase mithilfe von überprüft werden, sowie die erforderlichen IAM-Berechtigungen für die Bereitstellung der Architektur. Außerdem werden die Konfigurationen definiert, die standardmäßig ausgewählt werden sollen, wenn ein Benutzer versucht, Ihre Architektur aus dem Katalog bereitzustellen. Weitere Informationen finden Sie unter Katalogdetails der Manifestdatei zuordnen.

Sehen Sie sich das Beispiel aus dem Beispielrepository an, das eine Variante des Fullstack-und Erweiterungstyps zeigt.

Sie können Ihre Katalogmanifestdatei mit zwei verschiedenen Methoden erstellen:

Sie können diese Datei mithilfe der Vorlage völlig neu erstellen.

Sie können den Onboarding-Prozess mit dem folgenden Basisbeispiel in Ihrem Quellenrepository starten und anschließend die Manifestdatei herunterladen, nachdem Sie Änderungen während des Onboardings in der Konsole vorgenommen und die aktualisierte Datei Ihrem Quellenrepository hinzugefügt haben.

Im Folgenden sehen Sie eine Basismanifestdatei, die Sie zu Ihrem Repository hinzufügen und bearbeiten können, um Sie bei den ersten Schritten mit dieser Option zu unterstützen.

{
    "products": [
        {
            "flavors": [
                {
                    "architecture": {},
                    "compliance": {},
                    "install_type": "fullstack"
                }
            ],
            "label": "catalog-create-sample-da-0.0.1",
            "name": "catalog-create-sample-da-0.0.1",
            "offering_icon_url": "url",
            "product_kind": "solution",
            "provider_name": "Community",
            "short_description": "A simple deployable architecture.",
            "tags": [
                "dev_ops"
            ],
            "version": "0.0.1"
        }
    ]
}

Nächste Schritte: Onboarding Ihrer implementierbaren Architektur in einem privaten Katalog

Mit einem erstellten Git-Release, das die erforderlichen Dateien in Ihrem Quellenrepository enthält, können Sie eine Version Ihrer implementierbaren Architektur und alle enthaltenen Varianten integrieren. Onboarding ist der Prozess zum Erstellen einer Katalogkachel in einem privaten Katalog, indem die Katalogdetails geprüft und eine Testbereitstellung sowie die Konformitätsanforderungen in IBM Cloudvalidiert werden. Informationen zum schrittweisen Prozess finden Sie unter Implementierbare Architekturen integrieren.