Lokale Bearbeitung des Katalogmanifests

Die Katalogmanifestdatei gibt die Informationen über Ihre eingebaute Lösung an, die Sie den Benutzern über einen Katalog zur Verfügung stellen möchten. Sie können Informationen zur Lizenzierung und Konformität bereitstellen, spezifische Einstellungen vornehmen und Beschreibungen zum Verwendungszweck Ihres Produkts bereitstellen.

Sie ziehen es vor, die Konsole zur Bearbeitung Ihrer Katalogdetails zu verwenden? Sie können die Auswahl treffen, indem Sie der bereitgestellten Assistenten und exportieren Sie dann die Manifestdatei folgen, um sie zu Ihrem Quellcode-Repository hinzuzufügen. Wenn Sie einsatzfähige Architekturen in einem Projekt stapeln, wird das Katalogmanifest für Sie erstellt, wenn Sie Ihre Architekturen zu einem privaten Katalog aus Ihrem Projekt hinzufügen.

Zuordnung von Katalogdetails zur Manifestdatei

Um zu veranschaulichen, wie der der Manifestdatei hinzugefügte Inhalt den Benutzern angezeigt wird, sehen Sie sich die folgenden Beispiele an, die die Beziehung zwischen der ibm_catalog.json und der Katalogdetailseite zeigen.

Sehen wir uns an, wie der Name der einsatzfähigen Architektur, die Beschreibung, die Funktionen und die Varianten in der Katalogmanifestdatei definiert werden und wie der Benutzer die Informationen auf der Katalogdetailseite sieht.

Titel der einsatzfähigen Architektur, Beschreibung, Textabbildung der Merkmale in der Quelldatei

Schauen wir uns an, wie die Liste der Variationsmerkmale verwendet wird, um den Benutzern den Vergleich von Variationen auf der Grundlage der Definition in der Katalogmanifestdatei zu erleichtern.

Vergleich der Merkmale von einsatzfähigen Architekturvarianten

Sehen wir uns an, wo in der Katalogmanifestdatei die Berechtigungen und Architekturdiagrammdetails angegeben sind und wie sie auf der Katalogdetailseite angezeigt werden.

Einsetzbare Architekturberechtigungen und Architekturtext-Zuordnung zur Quelldatei

Wenn Ihre Architektur ein bestimmtes Maß an Konformität erfüllt, das mit Hilfe von Workload Protection anhand von Inventarisierungsergebnissen überprüft wird, können Sie diese Konformität pro Variante geltend machen. Sie legen in der Datei ibm_catalog.json fest, wie Ihre Architektur ein bestimmtes Maß an Konformität erfüllt, indem Sie die Richtlinie Workload Protection angeben. Sie müssen auch die Ressourcen bereitstellen, die Ihre Architektur erstellt, da Workload Protection diese bereitgestellten Ressourcen zur Überprüfung der Konformität verwendet. Weitere Informationen finden Sie unter Verwalten von Konformitätsinformationen für Ihre einsatzfähige Architektur.

Im folgenden Beispiel sehen Sie, wie die in der Manifestdatei definierten Konformitätsinformationen den Benutzern angezeigt werden.

Einhaltung der Vorschriften für einsatzfähige Architekturen

Bearbeiten des Manifests

Um Ihr Manifest lokal zu bearbeiten, können Sie die folgenden Schritte ausführen.

Kopieren Sie die folgende Beispiel-Manifestdatei in einen lokalen Editor.
Ordnen Sie der Datei den Namen ibm_catalog.json zu.
Fügen Sie Ihre bevorzugten Konfigurationen in die Datei ein, indem Sie das Beispielmanifest als Anleitung verwenden. Um mehr über die einzelnen Werte zu erfahren, sehen Sie sich die verfügbaren Werte an.
Fügen Sie die Datei in das Stammverzeichnis Ihres Quellcode-Repositorys ein.
Fügen Sie Ihre einsatzfähige Architektur zu Ihrem Katalog hinzu.

Wenn Ihre einsatzfähige Architektur bereits in einen privaten Katalog eingebunden ist, können Sie das Manifest herunterladen von der Konsole aus aufrufen.

Beispiel einer Manifestdatei

Der folgende Codeschnipsel kann als Vorlage verwendet werden.

{
   "products": [
      {
         "name": "",
         "label": "",
         "product_kind": "",
         "tags": [
            "tag 1",
            "tag 2"
         ],
         "keywords": [
            "keyword 1",
            "keyword 2",
            "keyword 3"
         ],
         "short_description": "Short description of your product.",
         "long_description": "A longer description of your product.",
         "offering_docs_url": "URL",
         "offering_icon_url": "URL or emebbed image",
         "provider_name": "Community",
         "module_info": {
            "works_with": [
               {
                  "catalog_id": "",
                  "name": "module name",
                  "kind": "terraform",
                  "version": "0.1.0",
                  "flavor": "Variation name"
               }
            ]
         },
         "support_details": "Explanation of support.",
         "features": [
            {
               "title": "Feature 1 title"
               "description": "Feature 1 description"
            },
            {
               "title": "Feature 2 title"
               "description": "Feature 2 description"
            }
         ],
         "flavors": [
            {
               "label": "Display name",
               "name": "Programatic name",
               "index": 1,
               "install_type": "Install type",
               "working_directory": "Directory path",
               "usage_template": "template",
               "scripts": [
                  {
                     "type": "ansible",
                     "short_description": "Short description of what your script is intended to do.",
                     "path": "Path to script location.",
                     "stage": "The stage. For example, pre.",
                     "action": "The action. For example, validate."
                  }
               ],
               "change_notices": {
                  "breaking": [
                     {
                        "title": "Title of breaking change",
                        "description": "Description of the change."
                     }
                  ],
                  "new": [
                     {
                        "title": "Title of new feature",
                        "description": "Description of the new feature or capability."
                     }
                  ],
                  "update": [
                     {
                        "title": "Title of general update",
                        "description": "Description of the general update."
                     }
                  ]
               },
               "compliance": {
                  "authority": "scc-v3",
                  "controls": [
                     {
                        "profile": {
                           "name": "Security and Compliance Center profile name",
                           "version": "Profile version"
                        },
                        "names": [
                           "Control name 1 e.g. AC-2(a)",
                           "Control name 2",
                           "Control name 3"
                        ]
                     }
                  ]
               },
               "configuration": [
                  {
                     "key": "key type e.g. ssh_key",
                     "required": true
                  },
                  {
                     "key": "Key type e.g. ibmcloud_api_key",
                     "required": true,
                     "type": "The data type"
                  }
               ],
               "outputs": [
                  {
                     "description": "Output description",
                     "key": "key"
                  },
                  {
                     "description": "Output description",
                     "key": "key"
                  }
               ],
               "dependencies": [
                  {
                     "catalog_id": "ID",
                     "id": "ID",
                     "name": "Product programmatic name",
                     "kind": "Format kind",
                     "version": "Versions or range of versions",
                     "flavors": [
                        "Variation name 1",
                        "Variation name 2",
                        "Variation name 3"
                     ],
                     "install_type": "fullstack or extension",
                  }
               ],
               "iam_permissions" [
                  {
                     "role_crns": [
                        "CRN 1 e.g. crn:v1:bluemix:public:iam::::serviceRole:Manager",
                        "CRN 2 e.g. crn:v1:bluemix:public:iam::::role:Administrator"
                     ],
                     "service_name": "Programatic service name e.g. is.vpc"
                  }
               ],
               "licenses": [
                  {
                     "name": "License name",
                     "smref": "Link to the license"
                  }
               ],
               "schematics_env_values": {
                  "value": "value",
                  "smref": " "
               },
               "architecture": {
                  "descriptions": " ",
                  "features": [
                     {
                        "title": "Feature 1 title",
                        "description": "Feature 1 description"
                     },
                     {
                        "title": "Feature 1 title",
                        "description": "Feature 1 description"
                     }
                  ],
                  "diagram": {
                     "caption": "Diagram caption",
                     "url": "Link to diagram or embedded image",
                     "metadata": []
                  },
                  "description": "Description of the diagram"
               }
            }
         ]
      }
   ]
}

Verfügbare Werte

Die folgenden Abschnitte enthalten Informationen zu jedem Wert, auf den in der Manifestdatei verwiesen werden kann.

Produkte

Der Wert products gibt eine Reihe von Produkten mit der Größe eins oder mehr an. Wenn im Stammverzeichnis Ihres Repositorys eine Katalogmanifestdatei vorhanden ist, können nur die in der Datei enthaltenen Produkte importiert werden. Die Produkte werden nacheinander eingeführt. Die folgenden Werte können auf der Ebene products aufgenommen werden:

`label`

Der Name der Produktanzeige. Dieser Wert muss mit dem Anzeigenamen übereinstimmen, den Sie beim Onboarding angeben.

`name`

Der programmorientierte Name des Produkts.

`hidden`

Ein boolescher Wert, der die Sichtbarkeit des Produkts steuert. Bei der Einstellung true wird das Produkt aus dem Katalog und den Suchergebnissen ausgeblendet, bleibt aber über seine direkte URL verfügbar.

`version`

Die Version des Produkts im Format SemVer, einschließlich der Hauptversion, der Nebenversion und der Revision, z. B. 1.0.0. Dieser Wert kann auch angegeben werden, wenn das Produkt in einen Katalog aufgenommen wird.

`product_kind`

Die Art von Produkt, das Sie einführen. Gültige Werte sind Software, Modul oder Lösung. Eine Lösung wird auch als einsatzfähige Architektur bezeichnet.

`tags`

Eine Reihe von vordefinierten Werten, die den Benutzern helfen können, den Katalog zu filtern, um mehr über Ihr Produkt zu erfahren. Um die verfügbaren Optionen anzuzeigen, führen Sie den folgenden Befehl aus: ibmcloud catalog filter options --all.

`keywords`

Eine Reihe von bestimmten Wörtern oder Ausdrücken, nach denen ein Benutzer suchen könnte.

`short_description`

Eine prägnante Zusammenfassung dessen, was Ihr Produkt ist und welchen Wert es hat.

`long_description`

Eine detaillierte Beschreibung Ihres Produkts, die den Wert und die Vorteile des Produkts für die Nutzer erläutert.

`provider_name`

Benutzer können den Katalog nach dem Anbieter eines Produkts filtern. Wenn Sie ein Produkt in einen privaten Katalog aufnehmen, wird der Anbietername standardmäßig auf Community gesetzt. Sie können dieses Feld jedoch so anpassen, dass der Name Ihres Unternehmens oder Ihrer Organisation angezeigt wird. IBM ist ein reservierter Wert und kann nur für IBM build-Produkte verwendet werden.

`offering_docs_url`

Ein Link zur Dokumentation über das Produkt, auf die Benutzer zugreifen können.

`offering_icon_url`

Ein Link zu URL, wo sich das Symbol befindet, das auf der Katalogeintragsseite des Produkts erscheinen soll.

`support_details`

Supportinformationen im Markdown-Format, die Supportkontakte, Supportstandorte und Supportmethoden enthalten können.

`features`

Abschnittsüberschrift auf products für Details, die die Prozesse, Fähigkeiten und Ergebnisse des Produkts hervorheben. Diese Merkmale auf Produktebene werden auf Ihrer Katalogeintragsseite zusammen mit Ihrer Produktbeschreibung aufgeführt. Zu den Merkmalen gehören zum Beispiel CPU-Anforderungen, Sicherheitsmerkmale und vieles mehr. Jeder Eintrag ist als Array definiert, wie im Beispielmanifest im vorherigen Abschnitt gezeigt. Die folgenden Werte können in den Abschnitt features aufgenommen werden:

features[].title: Der Name des Merkmals.
features[].description: Eine knappe Beschreibung des Merkmals.

Module

Der Wert module_info enthält Informationen über andere Produkte, mit denen die einsatzfähige Architektur kompatibel ist. Die folgenden Werte können in den Abschnitt module_info aufgenommen werden:

`works_with`

Abschnittsüberschrift für Informationen über ein einzelnes Produkt, das mit der verteilbaren Architektur kompatibel ist. Die folgenden Werte können in den Abschnitt works_with aufgenommen werden:

works_with[].catalog_id (fakultativ): ID des Katalogs, in dem das Produkt enthalten ist. Wenn nicht angegeben, wird der Katalog IBM Cloud als Standard verwendet.
works_with[].id (fakultativ): ID des Produkts. Die ID ist nicht erforderlich, wenn der Wert name eingestellt ist.
works_with[].name (fakultativ): Programmatische Bezeichnung des Produkts, das mit der verteilbaren Architektur arbeitet.
works_with[].kind: Das Format des Moduls, das mit Ihrer verteilbaren Architektur funktioniert. Meistens ist dies terraform.
works_with[].version: Version oder Bereich von Produktversionen, die mit der einsatzfähigen Architektur im Format SemVer funktionieren.
works_with[].flavors[] (fakultativ): Die programmatischen Namen der kompatiblen Varianten. Die Variationen werden einzeln in einen Katalog aufgenommen und erhalten eine Versionsnummer. Ein Beispiel für einen Variationsnamen könnte standard oder advanced sein.

Varianten

Informationen zu den einsatzfähigen Architekturvarianten finden Sie in der Kopfzeile des Abschnitts. Die Geschmacksrichtungen sind nun als Variationen der Konsole bekannt. Die folgenden Werte können auf der Ebene flavors aufgenommen werden:

`label`

Name der Anzeige der Variation.

`name`

Variation programmatischer Name.

`short_description`

Eine kurze Beschreibung für diese Version der Variante.

`index`

Die Reihenfolge, in der die Varianten im Katalog aufgeführt sind.

`working_directory`

Bei einem Arbeitsverzeichnis, das sich auf der Root-Ebene Ihres Repos befindet, müssen Sie das Arbeitsverzeichnis nicht angeben. Wenn es sich nicht im Stammverzeichnis befindet, geben Sie den Pfad vom Stammverzeichnis Ihres Repositorys an. Beispiel: ./examples/.

`usage`

Informationen darüber, wie die Architektur eingebettet oder lokal über Terraform ausgeführt werden kann.

`usage_template`

Ähnlich wie bei usage. Mit einer Vorlage können Sie Variablen als Platzhalter verwenden, in denen die Werte ersetzt werden können. Die Zeichenfolge wird in der Eigenschaft usage gespeichert.

Werte und Beschreibungen der Verwendungsvorlagen
Template-Variable	Wert für Ersatz
${{version}}	Die Versionszeichenfolge dieser Variante oder Geschmacksrichtung.
${{flavor}}	Der programmatische Name der Variation oder des Flavors.
${{kind}}	Die Art der Umsetzung. I.e. `terraform`.
${{id}}	Die Angebots- oder Produkt-ID.
${{name}}	Die programmatische Bezeichnung des Angebots oder Produkts.
${{catalogID}}	Die ID des Katalogs, in dem sich das Angebot oder Produkt befindet.
${{workingDirectory}}	Das Arbeitsverzeichnis des Flavors oder der Variante.

`licenses`

Abschnittsüberschrift innerhalb des Abschnitts flavors, die Informationen über die Endbenutzer-Lizenzvereinbarungen enthält, die der Benutzer bei der Installation des Produkts akzeptieren muss. Die Lizenzvereinbarungen gelten zusätzlich zur IBM Cloud-Servicevereinbarung.

{
	"id": "string, license id",
	"name": "string, license display name",
	"type": "string, type of license, e.g. Apache xxx",
	"url": "string, URL for the license text",
	"description": "string, license description"
}

Die folgenden Werte können in den Abschnitt licenses aufgenommen werden:

licenses[].id: Die Lizenz-ID.
licenses[].name: Der Name der Lizenz.
licenses[].type: Der Typ der Lizenz. Zum Beispiel Apache.
licenses[].url: Eine URL, wo der Benutzer die Lizenzvereinbarung einsehen kann.
licenses[].description: Eine Beschreibung der Lizenz.

`compliance`

Abschnittsüberschrift innerhalb des Abschnitts flavors, die angibt, welche Konformitätskontrollen die Architektur mit den Standardinstallationseinstellungen erfüllt. Die Bewertung und Validierung der geltend gemachten Ansprüche wird von Workload Protection abgeschlossen.

Das folgende Beispiel zeigt die JSON-Struktur für den Abschnitt compliance:

"flavors": [{
  "compliance": {
    "authority": "scc-wp-v1",
    "profiles": [{
      "profile_name": "",
      "profile_version": ""
    }],
    "controls": [{
      "profile": {
        "name": "",
        "version": ""
      },
      "names": []
    }]
  }
}]

Sie können mehrere Richtlinien in Ihrer Katalogmanifest-JSON-Datei auflisten, aber nur die erste Richtlinie wird zu Ihren Compliance-Informationen in einem privaten Katalog hinzugefügt.

Die folgenden Werte können in den Abschnitt compliance aufgenommen werden:

compliance.authority: Workload Protection v1 ist die einzige akzeptierte Behörde. Dies wird programmatisch als scc-wp-v1 geschrieben.
compliance.profiles[]: Array von Richtlinien, die die beanspruchten Kontrollen enthalten. Sie können sich vordefinierte Richtlinien in Workload Protection ansehen.
compliance.profiles[].profile_name: Der Name der Richtlinie. Beispiel: NIST. Sie finden den Namen der Richtlinie unter Workload Protection.
compliance.profiles[].profile_version: Die Version der Police. Beispiel: 1.0.0. Die Version der Richtlinie finden Sie unter Workload Protection.
compliance.controls[]: Bei dieser Variante wird eine Reihe von Kontrollen gefordert. Das Katalogmanifest akzeptiert ein Array von Steuerelementen, die Sie beanspruchen können, indem Sie den Profilnamen, die Profilversion und den Namen des Steuerelements angeben.
compliance.controls[].profile: Objekt, das anzeigt, dass Sie Kontrollen aus einer bestimmten Richtlinie hinzufügen.
compliance.controls[].profile.name: Der Name der Richtlinie für die beanspruchte Kontrolle. Beispiel: NIST. Sie finden den Namen der Richtlinie unter Workload Protection.
compliance.controls[].profile.version: Die Version der Police. Beispiel: 1.0.0. Die Version der Richtlinie finden Sie unter Workload Protection.
compliance.controls[].names[]: Array mit den Namen der beanspruchten Kontrollen. Beispiel: ["CM-7(b)", "AC-2(a)"].

Wenn Sie Steuerelemente in Ihrer Readme-Datei und in Ihrer Katalogmanifestdatei enthalten haben, hat die Manifestdatei Vorrang. Am besten stellen Sie sicher, dass die Steuerelemente, die in Ihrer Katalogmanifestdatei aufgeführt sind, mit den Steuerelementen in Ihrer Readme-Datei übereinstimmen.

`change_notices` (fakultativ)

Eine Liste der drei Arten von Änderungen, auf die Sie Ihre Benutzer hinweisen möchten, wenn Sie eine neue Version Ihrer verteilbaren Architektur herausgeben. Sie können breaking changes, new features, und general updates angeben. Einschneidende Änderungen sind Aktualisierungen, die Funktionen aufheben, die in einer früheren Version verfügbar waren. Neue Funktionen heben alle neuen Funktionen hervor, auf die ein Benutzer in der neuen Version stoßen könnte. Aktualisierungen umfassen alle Änderungen, auf die Sie den Benutzern hinweisen möchten, wie z. B. ein geändertes Verhalten, das nicht notwendigerweise die bestehende Funktionalität beeinträchtigt, oder Änderungen, die die Nutzung der einsatzfähigen Architektur erleichtern.

"change_notices": {
   "breaking": [
      {
         "title": "",
         "description": ""
      }
   ],
   "new_features": [
      {
         "title": "",
         "description": ""
      }
   ],
   "updates": [
      {
         "title": "",
         "description": ""
      }
  ]
}

`iam_permissions` (fakultativ)

Kopfzeile des Abschnitts finden Sie eine Liste aller IAM-Berechtigungen, die für einen Benutzer erforderlich sind, um mit Ihrer bereitstellbaren Architekturversion zu arbeiten. Die IAM-Berechtigungsinformationen umfassen den programmatischen Namen des erforderlichen Dienstes und eine Liste der CRNs für die benötigten Rollen. Wenn Sie Ihre Katalogmanifestdatei über die Benutzeroberfläche erstellen, sind die CRNs bereits enthalten.

Das folgende Beispiel zeigt die JSON-Struktur für den Abschnitt iam_permissions:

"flavors": [{
  "iam_permissions": [{
    "service_name": "IAM defined service name",
    "notes": "Optional notes about this permission",
    "role_crns": ["crn:v1:..."],
    "resources": [{
      "name": "resource name",
      "description": "resource description",
      "role_crns": ["crn:v1:..."]
    }]
  }]
}]

Die folgenden Werte können in den Abschnitt iam_permissions aufgenommen werden:

iam_permissions[].service_name: Der programmatische Name des Dienstes, auf den die Benutzer Zugriff haben müssen.
iam_permissions[].notes (fakultativ): Geben Sie den Benutzern weitere Informationen über diese Rolle oder warum sie enthalten ist. Beispiel: This role is only required if you are using IBM Key Protect for encryption.
iam_permissions[].role_crns[]: Abschnittsüberschrift zur Angabe einer Liste von Zugriffsrollen.
iam_permissions[].resources[]: Array von Ressourcen für eine Berechtigung.
iam_permissions[].resources[].name: Der Name der Ressource.
iam_permissions[].resources[].description: Eine Beschreibung der Ressource.
iam_permissions[].resources[].role_crns[]: Abschnittskopf, um eine Liste von Zugriffsrollen zu erstellen.

`architecture`

Abschnittsüberschrift innerhalb des Abschnitts flavors, die Informationen auf hoher Ebene über die Version der einsatzfähigen Architektur enthält, darunter eine Beschreibung, Funktionen und ein Diagramm. Es können mehrere Diagramme mit Beschriftungen bereitgestellt werden.

Das folgende Beispiel zeigt die JSON-Struktur für den Abschnitt architecture:

"flavors": [{
  "architecture": {
    "features": [{
      "title": "",
      "description": ""
    }],
    "diagrams": [{
      "diagram": {
        "caption": "",
        "url": "",
        "type": "image/svg+xml",
        "thumbnail_url": ""
      },
      "description": ""
    }]
  }
}]

Die folgenden Werte können in den Abschnitt architecture aufgenommen werden:

architecture.features[]: Eine Zusammenstellung von Informationen, die die Prozesse, Funktionen und Ergebnisse der Version bzw. gegebenenfalls der Architekturvariante beleuchtet. Beim Onboarding über die Konsole werden diese Details als Highlights bezeichnet. Diese Angaben erscheinen in der Variationsauswahlbox in Ihrem Katalogeintrag. Wenn Ihr Produkt mehrere Architekturvarianten aufweist, können Nutzer die Funktionen der einzelnen Varianten vergleichen, um zu entscheiden, welche Variante ihren Anforderungen entspricht.
architecture.features[].title: Name des Merkmals.
architecture.features[].description: Eine Beschreibung der Funktion.
architecture.diagrams[]: Array von Architekturdiagrammen, das die Diagrammunterschrift, die URL zur Einbettung der SVG des Diagramms, die Diagramm-Metadaten wie Element-ID und Elementbeschreibung sowie die Beschreibung der Referenzarchitektur enthält.
architecture.diagrams[].diagram: Objekt mit Informationen über ein einzelnes Architekturdiagramm.
architecture.diagrams[].diagram.url: Die URL zum SVG des Diagramms. Sie können auch ein SVG einbetten.
architecture.diagrams[].diagram.api_url: Die Katalogverwaltungs-API URL zum Diagramm.
architecture.diagrams[].diagram.url_proxy: Objekt mit Informationen über ein Proxy-Bild.
architecture.diagrams[].diagram.url_proxy.url: Die URL zum Proxy-Bild.
architecture.diagrams[].diagram.url_proxy.sha: Der sha Bezeichner des Bildes.
architecture.diagrams[].diagram.caption: Eine kurze Bezeichnung für das Architekturdiagramm.
architecture.diagrams[].diagram.type: Die Art der Medien.
architecture.diagrams[].diagram.thumbnail_url: Ein Link zu einer Miniaturansicht des Diagramms.
architecture.diagrams[].description: Informationen über das Architekturdiagramm als Ganzes, einschließlich des Umrisses des Systems und der Beziehungen, Beschränkungen und Grenzen zwischen den Komponenten der einsatzfähigen Architektur.

`dependencies`

In der Kopfzeile des Abschnitts flavors finden Sie eine Liste der Produkte, die mit der einsatzfähigen Architektur kompatibel sind. Abhängigkeiten können erforderlich oder optional sein. Eine hier enthaltene Abhängigkeit kann nicht auch dem Abschnitt swappable_dependencies hinzugefügt werden. Die Informationen umfassen den programmatischen Namen des Produkts und die Produktversionen. Optional können Sie die Katalog-ID und eine Liste der abhängigen Varianten angeben.

Das folgende Beispiel zeigt die JSON-Struktur für den Abschnitt dependencies:

"flavors": [{
  "dependencies": [{
    "catalog_id": "catalog ID",
    "id": "offering ID",
    "name": "offering name",
    "kind": "terraform",
    "version": "SemVer version e.g. 3.1.2",
    "flavors": ["flavor name"],
    "install_type": "fullstack or extension",
    "optional": true,
    "description": "Description of optional dependency",
    "on_by_default": false,
    "input_mapping": [{
      "dependency_output": "kms_instance_crn",
      "version_input": "existing_kms_instance_crn"
    }]
  }]
}]

Sie können Informationen über erforderliche Architekturen, die eine Abhängigkeit erfüllen, und optionale Architekturen, die mit Ihrer eigenen funktionieren, bereitstellen, wenn Sie Ihre verteilbare Architektur in einen Katalog aufnehmen. Weitere Informationen finden Sie unter Erweitern einer verteilbaren Architektur während des Onboardings.

Die folgenden Werte können in den Abschnitt dependencies aufgenommen werden:

dependencies[].catalog_id (fakultativ): ID des Katalogs, in dem das Produkt enthalten ist. Wenn nicht angegeben, wird der Katalog IBM Cloud als Standard verwendet.
dependencies[].id (fakultativ): Die Produkt-ID. Die ID ist nicht erforderlich, wenn der Wert name eingestellt ist.
dependencies[].name (fakultativ): Programmatischer Name des Produkts.
dependencies[].kind: Die Formatart der Abhängigkeit. Verwenden Sie stack für eine einsatzfähige Architektur, die aus gruppierten einsatzfähigen Architekturen besteht, für die eine Stack-Konfigurationsdatei vorhanden ist. Verwenden Sie terraform für einsatzfähige Architekturen, die nur aus einem oder mehreren Modulen bestehen.
dependencies[].version: Eine Version oder ein Bereich von Versionen, die als Abhängigkeiten im Format SemVer aufgenommen werden sollen.
dependencies[].flavors[] (fakultativ): Array von Variationsnamen, mit denen die Architektur kompatibel ist.
dependencies[].default_flavor (fakultativ): Gibt eine Standardvariante an, die für Ihre Benutzer ausgewählt wird, wenn mehrere Varianten mit Ihrer Architektur kompatibel oder für die Bereitstellung erforderlich sind. Ihre Benutzer können eine andere Variante auswählen, wenn diese in der Eigenschaft flavors enthalten ist. Der Wert entspricht dem name der Variation. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 auf true setzen. Wenn diese Option nicht gesetzt ist, wird keine Standardvariante für Ihre Benutzer bereitgestellt.
dependencies[].optional: Gibt an, ob die Abhängigkeit erforderlich oder nicht erforderlich ist. Der Standardwert ist false. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 auf true setzen.
dependencies[].description (fakultativ): Geben Sie eine Beschreibung für eine optionale Architektur, die mit Ihrer eigenen kompatibel ist, damit die Benutzer verstehen können, wie die Architektur innerhalb der Gesamtlösung funktioniert und warum sie sie möglicherweise einbeziehen möchten. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 auf true setzen.
dependencies[].on_by_default: Gibt an, ob eine optionale Abhängigkeit für Benutzer ausgewählt wird, wenn sie Ihre verteilbare Architektur einem Projekt aus einem Katalog hinzufügen. Die Benutzer können die Architektur abwählen, wenn sie sie nicht wünschen. Der Standardwert ist false. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 und optional auf true setzen.
dependencies[].input_mapping[] (fakultativ): Array, das die Werte angibt, auf die zwischen der kompatiblen Architektur und der Architektur, die Sie einbinden, verwiesen wird. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 auf true setzen.
dependencies[].input_mapping[].dependency_output oder dependencies[].input_mapping[].dependency_input (fakultativ): Gibt die Variable aus der Abhängigkeit an, auf die die Architektur, die Sie einbinden, verweist. Der Wert ist der Name der Variablen aus der Abhängigkeit. Es sollte nur eine dieser beiden Eigenschaften angegeben werden. Wenn reference_version auf true gesetzt ist, verweist diese Variable auf die Variable version_input aus der Architektur, die Sie gerade einbinden.
dependencies[].input_mapping[].version_input (fakultativ): Gibt den Namen der Eingabevariablen in der Architektur an, die Sie einbinden und die auf den Wert dependency_output oder dependency_input verweist. Wenn reference_version auf true gesetzt ist, verweist die Variable dependency_input auf die Variable version_input aus der Architektur, die Sie einbinden.
dependencies[].input_mapping[].value (fakultativ): Gibt den voreingestellten Wert für eine Eingabe aus der Architektur an, die Sie einbinden (version_input) oder deren Abhängigkeit (dependency_input). Der hier angegebene Wert wird nur verwendet, wenn version_input oder dependency_input angegeben ist und dependency_output nicht angegeben ist. Wenn version_input angegeben wird, wird beim Hinzufügen der Architektur und ihrer Abhängigkeit zu einem Projekt durch einen Benutzer die version_input der Architektur auf den hier angegebenen Wert voreingestellt. Wenn dependency_input angegeben wird, wird beim Hinzufügen der Architektur und ihrer Abhängigkeit zu einem Projekt durch einen Benutzer die dependency_input der Abhängigkeit auf den hier angegebenen Wert voreingestellt.
dependencies[].input_mapping[].reference_version (fakultativ): Zeigt den Fluss der Referenzen zwischen der Architektur, die Sie einbinden, und ihrer Abhängigkeit an. Der Standardwert ist false. Standardmäßig verweist der Architektur-Input (version_input) entweder auf einen Input oder einen Output aus der Abhängigkeit (dependency_input oder dependency_output). Wenn dieses Flag auf true gesetzt ist, verweist dependency_input auf einen Wert aus version_input.

`dependency_version_2` (fakultativ)

Peer zum Abschnitt dependencies, dependency_version_2 Gibt an, dass die aktualisierte Behandlung von Abhängigkeiten mit dieser einsatzfähigen Architektur verwendet wird. Wenn Sie die Eigenschaft optional oder die Abschnitte input_mapping innerhalb des Abschnitts dependencies verwenden, setzen Sie diesen Wert auf true. Falls nicht, setzen Sie den Wert auf false. Wenn diese Eigenschaft auf true gesetzt ist, sind alle Abhängigkeiten, bei denen die Eigenschaft optional auf false gesetzt ist, für die Bereitstellung der Architektur, die Sie einführen, erforderlich.

`swappable_dependencies` (fakultativ)

In der Kopfzeile des Abschnitts finden Sie eine Liste der Produkte, die mit der verteilbaren Architektur kompatibel sind. Im Gegensatz zum Array dependencies sind die Produkte in diesem Bereich austauschbar. Der Nutzer kann wählen, welches Produkt er verwenden möchte, um die Abhängigkeit zu erfüllen. Auswechselbare Abhängigkeiten können erforderlich oder optional sein. Eine hier enthaltene Abhängigkeit kann nicht auch dem Array dependencies hinzugefügt werden. Die Informationen umfassen den programmatischen Namen des Produkts und die Produktversionen. Optional können Sie die Katalog-ID und eine Liste der abhängigen Varianten angeben. Um diese Eigenschaft zu verwenden, müssen Sie auch dependency_version_2 auf true setzen.

{
  "optional": "true or false",
  "name": "Name for this group of swappable dependencies",
  "default_dependency": "the name of the dependency that is selected by default",
  "dependencies": [
    {
      	"name": "offering name",
      	"id": "offering ID",
      	"kind": "terraform",
      	"version": "SemVer version e.g. 3.1.2",
      	"flavors": [
           "flavor name"
        ],
      	"install_type": "fullstack or extension",
      	"catalog_id": "catalog ID",
      	"input_mapping": [
        {
            "dependency_output": "kms_instance_crn",
            "version_input": "existing_kms_instance_crn"
        }
        ]
    },
    {
      	"name": "offering name",
      	"id": "offering ID",
      	"kind": "terraform",
      	"version": "SemVer version e.g. 3.1.2",
      	"flavors": [
           "flavor name"
        ],
      	"install_type": "fullstack or extension",
      	"catalog_id": "catalog ID",
      	"input_mapping": [
        {
            "dependency_output": "kms_instance_crn",
            "version_input": "existing_kms_instance_crn"
        }
        ]
    }
  ]
}

Die folgenden Werte können in den Abschnitt swappable_dependencies aufgenommen werden:

swappable_dependencies[].name (fakultativ): Wird verwendet, wenn die Architektur in einen Katalog eingebunden wird, um die spezifische Gruppe von swappable_dependencies zu identifizieren.
swappable_dependencies[].default_dependency (fakultativ): Die name einer der Abhängigkeiten in der Gruppe, die standardmäßig für Benutzer ausgewählt ist.
swappable_dependencies[].dependencies: Array der Abhängigkeiten, die innerhalb dieser Gruppe ausgetauscht werden können. Die Werte in diesem Array sind die gleichen wie die Werte, die im Abschnitt dependencies abschnitt.

`release_notes_url`

URL zu den Versionshinweisen der Architektur.

`configuration`

Abschnittsüberschrift innerhalb des Abschnitts flavors, die die Konfiguration der Einsatzvariablen für eine bestimmte Variante angibt. Katalogdatentypen werden verwendet, um die nativen Typen zu erweitern und die Arbeit in der IBM Cloud-Konsole für den Benutzer zu erleichtern. Wenn Sie Ihren Code auf einem lokalen Rechner oder in einer anderen Umgebung ausführen, werden die Variablen nicht verwendet. Ein Beispiel wäre ein Katalogtyp von password, der verwendet wird, um die Möglichkeiten einer Terraform-Variable zu erweitern, die mit einem Typ von string definiert wurde, so dass sie in der Benutzeroberfläche als sensibel behandelt wird.

Das folgende Beispiel zeigt die JSON-Struktur für den Konfigurationsabschnitt:

"flavors": [{
  "configuration": [{
    "key": "deployment_variable_name",
    "type": "string",
    "default_value": "default value",
    "description": "Description shown to users",
    "display_name": "Display Name",
    "required": true,
    "hidden": false,
    "options": ["option1", "option2"],
    "custom_config": {
      "type": "widget_id",
      "grouping": "Target",
      "grouping_index": 1
    },
    "value_constraints": [{
      "type": "regex",
      "value": "^.{12,30}$",
      "description": "Must be between 12 and 30 characters"
    }]
  }]
}]

Die folgenden Werte können in den Abschnitt configuration aufgenommen werden:

configuration[].key

Der Konfigurationsschlüssel. Der Wert sollte mit dem Namen einer Bereitstellungsvariablen übereinstimmen.

configuration[].type

Die Art der Eingabe, die ein Kunde definieren oder auswählen kann. Der Datentyp muss vom Katalogverwaltungsdienst unterstützt werden. Die nativen Terraform-Typen werden auf einige der unterstützten Typen abgebildet. Zum Beispiel entspricht der Terraform-Typ map dem object. Der Terraform-Typ list entspricht dem array. Ein Terraform-Typ string mit einem sensitiven Attribut entspricht password. Kunden, die Ihre verteilbare Architektur nutzen, müssen Werte für den Eingabetyp bereitstellen, den Sie im Katalogmanifest definieren.

Unterstützte vordefinierte Typen:

boolean erfordert die Eingabe einer Zeichenkette true oder false durch den Benutzer.
float verlangt von den Benutzern einen Dezimalpunkt.
int erfordert eine ganzzahlige Eingabe von den Benutzern.
number erfordert einen numerischen Wert. Der Typ number kann sowohl ganze Zahlen als auch Bruchzahlen wie 4.56 darstellen.
password erfordert die Eingabe einer Zeichenkette durch den Benutzer. Die Zeichenfolge wird in der Konsole und in den Protokollen unkenntlich gemacht.
string erfordert eine Folge von Unicode-Zeichen, die Text darstellen. Sie können optional eine zufällige Zeichenkette als Suffix hinzufügen, um Namenskollisionen bei Zeichenketten zu vermeiden, die als Präfixe oder als Basisnamen verwendet werden. Sie können auch die Länge dieser Zufallszeichenfolge angeben. Die generierte Zeichenkette ist klein, a-z, ohne Sonderzeichen und mit einem Bindestrich vorangestellt, z. B. myString-wx. Wenn auch ein Standardwert angegeben wird, wird das Suffix hinzugefügt. Wird kein Standardwert angegeben, so ist der Wert das Suffix ohne den Bindestrich. Beispiel:

"random_string": {
	"length": 2
}

object erfordert die Eingabe eines Terraform-Objekts durch die Benutzer. Weitere Informationen finden Sie unter map.

Vordefinierte Typen erfordern eine manuelle Eingabe durch den Benutzer.

Unterstützte benutzerdefinierte Typen:

array erfordert eine durch ein Komma getrennte Liste von Werten.
region erfordert, dass der Benutzer aus einer Dropdown-Liste eine Region auswählt, in der die verteilbare Architektur eingesetzt werden soll. Sie können die Regionen filtern, die den Endbenutzern zur Verfügung stehen. Sie können zum Beispiel country_id:us,ca,jp im Filter Region angeben, um die verfügbaren Regionen auf diese Länder zu beschränken. Weitere Informationen finden Sie unter Filtersyntax.
textarea verlangt vom Benutzer die Eingabe von Text, der in mehrere Zeilen aufgeteilt werden kann. Zum Beispiel eine Beschreibung.
vpc erfordert, dass die Benutzer einen VPC nach Namen aus einer Dropdown-Liste auswählen. Die Ausgabe ist der VPC-Name oder die ID, die Ihre Vorlage benötigt.
vpc ssh key erfordert, dass Benutzer einen VPC SSH-Schlüssel für die Authentifizierung bei einer virtuellen Maschine auswählen.
cluster erfordert die Auswahl eines Kubernetes Service oder Red Hat OpenShift Clusters. Die Ausgabe ist die Cluster-ID.
power iaas müssen die Benutzer eine Instanz von Power Virtual Server auswählen.
resource group müssen die Benutzer eine Ressourcengruppe auswählen. Die Ausgabe ist die ID, der Name oder die CRN der Ressourcengruppe.
multi-line secure value verlangt von den Benutzern die Eingabe von Text, der in mehrere Zeilen aufgeteilt werden kann und in der Konsole und den Protokollen geschwärzt wird. Wenn zum Beispiel ein langer Schlüssel erforderlich ist, wird der Wert in Arbeitsbereichen ausgeblendet.
schematics workspace müssen die Benutzer einen bestimmten Arbeitsbereich aus einer Dropdown-Liste auswählen. Diese Liste wird auf der Grundlage der in der verteilbaren Architektur definierten Abhängigkeiten dynamisch gefiltert. Wenn beispielsweise Ihre einsatzfähige Architektur example-da-1 von einer anderen einsatzfähigen Architektur example-da-2 abhängt, zeigt die Dropdown-Liste für example-da-1 nur Arbeitsbereiche an, die mit example-da-2 verbunden sind. Die Benutzer wählen dann beim Einrichten von example-da-1 die entsprechende Instanz des Arbeitsbereichs von example-da-2 aus.
json editor bietet den Benutzern die Möglichkeit, größere JSON-Eingaben oder reine Textdateien anzugeben.
code editor gibt den Benutzern die Wahl zwischen JSON- und HCL-formatierten Eingaben, was für Terraform-basierte Eingaben nützlich ist.
Platform resource verlangt von den Benutzern, dass sie eine Instanzressource aus einer Liste für den von Ihnen angegebenen Ressourcentyp auswählen. Der Ressourcentyp kann VPC Subnet, VPC Image, VPC Floating IPs, Cloud Logs, Sysdig, Cloud Object Storage, Key Protect, oder Secrets Manager sein. Sie können die ID, den Namen oder die CRN als die Werte angeben, aus denen die Benutzer wählen können, und eine einfache oder mehrfache Auswahl zulassen. Die Ausgabe ist der Name oder die ID, die Ihr Terraform-Code benötigt.
secret_group erfordert, dass die Benutzer eine geheime Gruppe anhand ihres Namens aus einer bestimmten Secrets Manager-Instanz auswählen. Die Ausgabe ist die ID oder der Name der geheimen Gruppe. Um Gruppen aus einer bestimmten Instanz von Secrets Manager aufzulisten, muss dieser Typ mit dem benutzerdefinierten Typ platform resource, mit dem Ressourcentyp Secrets Manager und mit einer Ausgabe vom Typ crn verbunden sein.
secret erfordert, dass die Benutzer ein Geheimnis namentlich aus einer bestimmten Instanz von Secrets Manager auswählen. Die Ausgabe ist die ID, der Name oder die CRN des Geheimnisses. Um Geheimnisse einer bestimmten Instanz von Secrets Manager aufzulisten, muss dieser Typ mindestens mit dem benutzerdefinierten Typ platform resource, mit dem Ressourcentyp Secrets Manager und mit einer Ausgabe des Werttyps crn verbunden sein. Sie können ihn optional auch mit dem Typ secret_group verknüpfen und einen Wert vom Typ id ausgeben, um die Geheimnisse einer bestimmten Geheimhaltungsgruppe in dieser Secrets Manager-Instanz aufzulisten.
kms_key erfordert, dass die Benutzer einen Schlüssel aus einer bestimmten Key Protect-Instanz auswählen. Die Ausgabe ist die ID, der Name oder die CRN des Schlüssels. Um die Schlüssel einer bestimmten Instanz von Key Protect aufzulisten, muss dieser Typ mit dem benutzerdefinierten Typ platform resource, mit dem Ressourcentyp Key Protect und mit einer Ausgabe vom Typ crn verbunden sein.

configuration[].default_value

Der Wert, der als Standard festgelegt werden soll.

configuration[].virtual (fakultativ)

Kennzeichen, das angibt, ob eine Eingabe an den Dienst Schematics übergeben werden soll. Bei der Einstellung true wird die Eingabe nicht an Schematics übergeben. Setzen Sie dieses Flag auf true für alle Eingaben innerhalb Ihrer verteilbaren Architektur, auf die in kompatiblen Architekturen verwiesen wird, die aber nicht in der verteilbaren Architektur verwendet werden, die Sie gerade einbinden. Fügen Sie Referenzen in input_mapping innerhalb der dependencies oder swappable_dependencies abschnitt des Katalogmanifests.

configuration[].description

Eine Beschreibung der Variable, die Sie in der Benutzeroberfläche für die Benutzer Ihrer verteilbaren Architektur anzeigen möchten.

configuration[].display_name

Der Name, der für den Konfigurationstyp angezeigt wird.

configuration[].required

Ein boolescher Wert, der angibt, ob die Benutzer den Parameter während der Installation angeben müssen.

configuration[].hidden

Ein boolescher Wert, der angibt, ob der Parameter während der Installation vor Benutzern verborgen werden soll.

configuration[].options[]

Array von Optionen, aus denen die Benutzer für einen Parameter wählen können.

configuration[].custom_config

Objekt, um anzuzeigen, dass eine benutzerdefinierte Konfiguration verwendet werden kann.

configuration[].custom_config.type

Die ID des für die Konfiguration verwendeten Widgettyps.

configuration[].custom_config.grouping

Wo der Konfigurationstyp im Katalog erscheinen soll. Gültige Werte sind Target, Resource, und Deployment.

configuration[].custom_config.original_grouping

Wo der Konfigurationstyp ursprünglich erschien. Gültige Werte sind Target, Resource, und Deployment.

configuration[].custom_config.grouping_index

Die Reihenfolge dieser Konfigurationselemente, wenn es mehrere gibt.

configuration[].custom_config.config_constraints

Karte der Constraint-Parameter, die an das benutzerdefinierte Widget übergeben werden.

configuration[].custom_config.associations

Objekt für Parameter, die mit der Konfiguration verbunden sind.

configuration[].configuration_group

Der Name einer zugehörigen Konfigurationsgruppe.

configuration[].value_constraints[]

Array von Wertbeschränkungen, wobei jede Beschränkung Validierungsregeln definiert.

configuration[].value_constraints[].type

Der Typ der Einschränkung. Derzeit wird ausschließlich regex unterstützt.

configuration[].value_constraints[].value

Ein JavaScript regulärer Ausdruck.

configuration[].value_constraints[].description

Eine Meldung, die angezeigt wird, wenn der angegebene Wert nicht mit dem angegebenen regulären Ausdruck übereinstimmt.

`schematics_env_values`

Im Abschnitt flavors gibt schematics_env_values eine Liste der Werte und Variablennamen an, die an den Dienst Schematics übergeben werden müssen, um während der Ausführung von Terraform als Umgebungsvariablen verwendet zu werden. Dies kann ein sicherer Wert, eine Einstellung der Terraform-Protokollierung oder etwas anderes sein. Sie können entweder eine Zeichenkette angeben oder einen Verweis auf Secrets Manager erstellen. Wenn beides angegeben ist, wird die Referenz Secrets Manager verwendet.

Das folgende Beispiel zeigt die JSON-Struktur für den Abschnitt schematics_env_values:

"flavors": [{
  "schematics_env_values": {
    "value": "[{\"name\": \"TF_LOG\",\"value\": \"TRACE\",\"secure\": true,\"hidden\": true}]",
    "sm_ref": "cmsm_v1:{...}"
  }
}]

Die folgenden Werte können in den Abschnitt schematics_env_values aufgenommen werden:

schematics_env_values.value: Eine JSON-Zeichenfolge, die ein Array von Umgebungsvariablen und deren Werte enthält.
schematics_env_values.value[].name: Gibt den Namen der Umgebungsvariablen an.
schematics_env_values.value[].value: Gibt den Wert der Umgebungsvariablen an.
schematics_env_values.value[].secure: Gibt an, ob der Wert der Umgebungsvariablen im Ausführungsprotokoll im Klartext angezeigt werden soll oder nicht. Mögliche Werte sind true oder false.
schematics_env_values.value[].hidden: Gibt an, ob diese Variable in das Ausführungsprotokoll aufgenommen werden soll oder nicht. Mögliche Werte sind true oder false.
schematics_env_values.sm_ref: Ein Verweis auf eine Secrets Manager-Instanz, die Ihre Umgebungsvariablen enthält, die als Geheimnis gespeichert werden. Das Geheimnis muss eine JSON-Zeichenkette sein, die ein Array von Umgebungsvariablen und deren Werte enthält.

Der folgende Beispiel-JSON-String enthält zwei Variablen, TF_LOG und TF_IGNORE, und ihre Werte, die während der Terraform-Ausführung als Umgebungsvariablen hinzugefügt werden:

"schematics_env_values": {
    "value": "[{\"name\": \"TF_LOG\",\"value\": \"TRACE\",\"secure\": true,\"hidden\": true},{\"name\": \"TF_IGNORE\",\"value\": \"TRACE\",\"secure\": false,\"hidden\": false}]"
}

Verwenden Sie Escape-Zeichen für die Anführungszeichen innerhalb der Liste.

Das folgende Beispiel verwendet einen Verweis auf ein Geheimnis in Secrets Manager:

"schematics_env_values": {
    "sm_ref": "cmsm_v1:{\"name\": \"envVarSecret\",\"id\":\"1234567890\",\"service_id\":\"crn:v1:bluemix:public:secrets-manager:eu-gb:a/1234567890:1234567890::\",\"service_name\":\"My SM instance\",\"group_id\":\"1234567890\",\"group_name\":\"My SM group\",\"resource_group_id\":\"1234567890\",\"region\":\"eu-gb\",\"type\":\"arbitrary\"}"
}

`minimum_compatible_version` (fakultativ)

Ein Semver-Wert, der die früheste Version angibt, die mit der aktuellen Version kompatibel ist. Wenn keine früheren Versionen mit der aktuellen Version kompatibel sind, geben Sie in diesem Feld den Wert der aktuellen Version an. Standardmäßig ist die aktuelle Version mit allen früheren Versionen kompatibel.

`ignore_readme`

Bei true wird die Liesmich-Datei nicht verwendet, wenn Sie diese Version an Bord nehmen, und das Feld long_description ist leer. Wenn das Feld long_description leer ist, erscheint kein Link zur Readme-Datei im Menü Verwandte Links in der Katalogliste für die Version.

`terraform_version`

Die Hashicorp Terraform-Laufzeitversion, die zur Validierung und Installation der Version benötigt wird. Die Einstellung dieses Wertes im Manifest setzt die Angaben im Quellcode außer Kraft.

`outputs`

Abschnittsüberschrift für Informationen über Terraform-Ausgabewerte.

{
   "key": "name of the output value as defined in the Terraform",
   "description": "The description of the key"
}

Die folgenden Werte können in den Abschnitt outputs aufgenommen werden:

outputs[].key: Gibt den Ausgabewert an.
outputs[].description: Eine kurze Zusammenfassung des Ausgabewerts.

`install_type`

Gibt an, ob eine einsatzfähige Architektur fullstack oder extension ist. Für die als Erweiterungen aufgeführten Architekturen sind Voraussetzungen erforderlich. Das Array dependencies muss ebenfalls ausgefüllt werden, wenn Sie diesen Wert auf extension setzen. Diese Eigenschaft wird ignoriert, wenn dependency_version_2 auf true eingestellt ist.

`scripts`

Eine Liste von Skripten, die in demselben Repository enthalten sind und von einem Projekt in einer bestimmten Phase einer bestimmten Aktion ausgeführt werden können. Jeder Schlüssel in der Karte muss mit dem Format action und stage im Eintrag übereinstimmen. Stage muss entweder pre oder post sein. Action muss validate, deploy oder undeploy sein.

{
   "short_description": "description for the script",
   "type": "type of script. i.e. ansible",
   "path": "the path to the script in the repo. Must begin with scripts/...",
   "stage": "pre or post",
   "action": "The action that executes the script. Options include validate, deploy, or undeploy."
}

Lokale Bearbeitung des Katalogmanifests

Lokale Bearbeitung des Katalogmanifests

Zuordnung von Katalogdetails zur Manifestdatei

Bearbeiten des Manifests

Beispiel einer Manifestdatei

Verfügbare Werte

Produkte

label

name

hidden

version

product_kind

tags

keywords

short_description

long_description

provider_name

offering_docs_url

offering_icon_url

support_details

features

Module

works_with

Varianten

label

name

short_description

index

working_directory

usage

usage_template

licenses

compliance

change_notices (fakultativ)

iam_permissions (fakultativ)

architecture

dependencies

dependency_version_2 (fakultativ)

swappable_dependencies (fakultativ)

release_notes_url

configuration

schematics_env_values

minimum_compatible_version (fakultativ)

ignore_readme

terraform_version

outputs

install_type

scripts

`label`

`name`

`hidden`

`version`

`product_kind`

`tags`

`keywords`

`short_description`

`long_description`

`provider_name`

`offering_docs_url`

`offering_icon_url`

`support_details`

`features`

`works_with`

`label`

`name`

`short_description`

`index`

`working_directory`

`usage`

`usage_template`

`licenses`

`compliance`

`change_notices` (fakultativ)

`iam_permissions` (fakultativ)

`architecture`

`dependencies`

`dependency_version_2` (fakultativ)

`swappable_dependencies` (fakultativ)

`release_notes_url`

`configuration`

`schematics_env_values`

`minimum_compatible_version` (fakultativ)

`ignore_readme`

`terraform_version`

`outputs`

`install_type`

`scripts`