Modifier localement le manifeste du catalogue

Le fichier manifeste du catalogue spécifie les informations sur votre solution embarquée que vous souhaitez partager avec les utilisateurs par le biais d'un catalogue. Vous pouvez fournir des informations sur les licences et la conformité, effectuer des réglages spécifiques et fournir des descriptions sur l'utilisation prévue de votre produit.

Vous préférez utiliser la console pour modifier les détails de votre catalogue? Vous pouvez effectuer les sélections en suivant l'assistant fourni, puis exporter le fichier de manifeste pour l'ajouter à votre répertoire de sources. Si vous empilez des architectures déployables dans un projet, le manifeste de catalogue est créé pour vous lorsque vous ajoutez vos architectures à un catalogue privé de votre projet.

Mappage des détails du catalogue au fichier manifeste

Pour mieux visualiser la façon dont le contenu ajouté au fichier de manifeste est affiché aux utilisateurs, voir les exemples suivants qui montrent la relation entre le site ibm_catalog.json et la page de détails du catalogue.

Voyons comment le nom, la description, les caractéristiques et les variantes de l'architecture déployable sont définis dans le fichier manifeste du catalogue et comment l'utilisateur voit ces informations sur la page de détails du catalogue.

Titre de l'architecture déployable, description, caractéristiques, correspondance textuelle avec le fichier source

Voyons comment la liste des caractéristiques des variations est utilisée pour aider les utilisateurs à comparer les variations en fonction de leur définition dans le fichier manifeste du catalogue.

Comparaison des caractéristiques de la variation de l'architecture déployable

Examinons l'endroit où les autorisations et les détails du diagramme d'architecture sont spécifiés dans le fichier manifeste du catalogue et comment ils sont affichés sur la page des détails du catalogue.

Permissions de déploiement de l'architecture et mappage du texte de l'architecture au fichier source

Et si votre architecture répond à un niveau spécifique de conformité qui est vérifié par les résultats de l'inventaire en utilisant Workload Protection, vous pouvez revendiquer cette conformité par variation. Vous définissez comment votre architecture répond à un certain niveau de conformité dans le fichier ibm_catalog.json en spécifiant la politique Workload Protection. Vous devez également déployer les ressources créées par votre architecture, car Workload Protection utilise ces ressources déployées pour vérifier la conformité. Pour plus d'informations, voir Gestion des informations de conformité pour votre architecture déployable.

L'exemple suivant montre comment les informations de conformité définies dans le fichier manifeste sont affichées aux utilisateurs.

Modifier votre manifeste

Pour modifier votre manifeste localement, vous pouvez suivre les étapes suivantes.

Copiez l'exemple de fichier manifeste suivant dans un éditeur local.
Nommez le fichier ibm_catalog.json.
Ajoutez vos configurations préférées dans le fichier en vous inspirant de l'exemple de manifeste. Pour en savoir plus sur chaque valeur, consultez les valeurs disponibles.
Ajoutez le fichier dans le dossier racine de votre dépôt de code source.
Ajoutez votre architecture déployable à votre catalogue.

Si votre architecture déployable est déjà intégrée à un catalogue privé, vous pouvez télécharger le manifeste depuis la console.

Exemple de fichier manifeste

L'extrait de code suivant peut être utilisé comme modèle.

{
   "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"
               }
            }
         ]
      }
   ]
}

Valeurs disponibles

Les sections suivantes contiennent des informations sur chaque valeur pouvant être référencée dans votre fichier de manifeste.

Produits

La valeur produits indique un tableau de produits de taille un ou plus. Si un fichier manifeste de catalogue existe à la racine de votre référentiel, seuls les produits contenus dans le fichier peuvent être importés. Les produits sont importés un par un. Les valeurs suivantes peuvent être incluses au niveau products:

`label`

Le nom d'affichage du produit. Cette valeur doit correspondre au nom d'affichage que vous avez fourni lors de l'inscription.

`name`

Nom du produit dans le programme.

`hidden`

Valeur booléenne qui contrôle la visibilité du produit. Lorsqu'il est défini sur true, le produit est caché du catalogue et des résultats de recherche, mais reste disponible par l'intermédiaire de son site direct URL.

`version`

La version du produit au format SemVer, y compris la version majeure, la version mineure et la révision, par exemple, 1.0.0. Cette valeur peut également être spécifiée lorsque le produit est intégré à un catalogue.

`product_kind`

Le type de produit que vous intégrez. Les valeurs valables sont logiciel, module ou solution. Une solution est également connue sous le nom d'architecture déployable.

`tags`

Un tableau de valeurs prédéfinies qui peut aider les utilisateurs à filtrer le catalogue afin d'identifier et d'en savoir plus sur votre produit. Pour afficher les options disponibles, exécutez la commande suivante : ibmcloud catalog filter options --all.

`keywords`

Un ensemble de mots ou de phrases spécifiques qu'un utilisateur pourrait essayer de rechercher.

`short_description`

Un résumé concis de ce qu'est votre produit et de sa valeur.

`long_description`

Une description détaillée de votre produit qui explique sa valeur et ses avantages pour les utilisateurs.

`provider_name`

Les utilisateurs peuvent filtrer le catalogue en fonction du fournisseur d'un produit. Lorsque vous intégrez un produit dans un catalogue privé, le nom du fournisseur est défini par défaut sur Community. Cependant, vous pouvez personnaliser ce champ pour afficher le nom de votre entreprise ou de votre organisation. IBM est une valeur réservée et ne peut être utilisée que pour les produits de construction IBM.

`offering_docs_url`

Un lien vers la documentation du produit à laquelle les utilisateurs peuvent accéder.

`offering_icon_url`

Un lien vers le site URL où se trouve l'icône que vous souhaitez voir apparaître sur la page d'entrée du catalogue du produit.

`support_details`

Informations d'assistance au format markdown pouvant inclure les contacts d'assistance, les lieux d'assistance et les méthodes d'assistance.

`features`

En-tête de section sur products pour les détails qui mettent en évidence les processus, les capacités et les résultats du produit. Ces caractéristiques au niveau du produit sont listées sur la page d'entrée de votre catalogue avec la description du produit. Par exemple, les caractéristiques peuvent inclure les exigences en matière de CPU, les fonctions de sécurité, etc. Chaque entrée est définie comme un tableau, comme le montre l'exemple du manifeste de la section précédente. Les valeurs suivantes peuvent être incluses dans la section features:

features[].title: Le nom de l'élément.
features[].description: Description concise de la caractéristique.

Modules

La valeur module_info indique des informations sur d'autres produits avec lesquels l'architecture déployable est compatible. Les valeurs suivantes peuvent être incluses dans la section module_info:

`works_with`

En-tête de section pour des informations sur un produit unique compatible avec l'architecture déployable. Les valeurs suivantes peuvent être incluses dans la section works_with:

works_with[].catalog_id (facultatif): ID du catalogue qui contient le produit. S'il n'est pas spécifié, le catalogue IBM Cloud est le catalogue par défaut.
works_with[].id (facultatif): ID du produit. L'ID n'est pas nécessaire si la valeur name est définie.
works_with[].name (facultatif): Nom programmatique du produit qui fonctionne avec l'architecture déployable.
works_with[].kind: Le format du module qui fonctionne avec votre architecture déployable. Le plus souvent, il s'agit de terraform.
works_with[].version: Version ou gamme de versions de produits qui fonctionnent avec l'architecture déployable au format SemVer.
works_with[].flavors[] (facultatif): Les noms programmatiques des variantes compatibles. Les variantes sont intégrées individuellement dans un catalogue et reçoivent un numéro de version. Un exemple de nom de variation pourrait être standard ou advanced.

Versions

Pour obtenir des informations sur les variantes de l'architecture déployable. Les saveurs sont désormais connues comme des variations de la console. Les valeurs suivantes peuvent être incluses au niveau flavors:

`label`

Nom d'affichage de la variation.

`name`

Variation du nom du programme.

`short_description`

Brève description de cette version de la variante.

`index`

L'ordre dans lequel les variations sont répertoriées dans la liste du catalogue.

`working_directory`

Pour un répertoire de travail qui se trouve au niveau de la racine de votre répertoire, vous n'avez pas besoin de spécifier le répertoire de travail. S'il n'est pas à la racine, indiquez le chemin à partir de la racine de votre référentiel. Par exemple, ./examples/.

`usage`

Informations sur la manière d'intégrer l'architecture ou de l'exécuter localement via Terraform.

`usage_template`

Similaire à usage. Avec un modèle, vous pouvez utiliser les variables comme un support où les valeurs peuvent être remplacées. La chaîne est stockée dans la propriété usage.

Valeurs et descriptions des modèles d'utilisation
Variable de modèle	Valeur de remplacement
${{version}}	La chaîne de la version de cette variante ou de cette saveur.
${{flavor}}	Le nom programmatique de la variation ou de la saveur.
${{kind}}	Le type de mise en œuvre. I.e. `terraform`.
${{id}}	L'identifiant de l'offre ou du produit.
${{name}}	Le nom technique de l'offre ou du produit.
${{catalogID}}	L'identifiant du catalogue dans lequel se trouve l'offre ou le produit.
${{workingDirectory}}	Le répertoire de travail de la saveur ou de la variante.

`licenses`

En-tête de section dans la section flavors qui fournit des informations sur les accords de licence de l'utilisateur final que les utilisateurs sont tenus d'accepter lorsqu'ils installent le produit. Les contrats de licence viennent s'ajouter aux contrats de services IBM Cloud.

{
	"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"
}

Les valeurs suivantes peuvent être incluses dans la section licenses:

licenses[].id: L'ID de la licence.
licenses[].name: Nom de la licence.
licenses[].type: Type de la licence. Par exemple, Apache.
licenses[].url: Une adresse URL où l'utilisateur peut accéder à l'accord de licence.
licenses[].description: Une description de la licence.

`compliance`

En-tête de section dans la section flavors qui indique les contrôles de conformité auxquels l'architecture satisfait avec les paramètres d'installation par défaut. L'évaluation et la validation des allégations est réalisée par Workload Protection.

L'exemple suivant montre la structure JSON de la section compliance:

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

Vous pouvez répertorier plusieurs politiques dans le fichier JSON de votre manifeste de catalogue, mais seule la première politique est ajoutée à vos informations de conformité dans un catalogue privé.

Les valeurs suivantes peuvent être incluses dans la section compliance:

compliance.authority: Workload Protection v1 est la seule autorité acceptée. Cela s'écrit de manière programmatique sous la forme scc-wp-v1.
compliance.profiles[]: Tableau des politiques qui contiennent les contrôles demandés. Vous pouvez consulter les politiques prédéfinies à l'adresse Workload Protection.
compliance.profiles[].profile_name: Nom de la stratégie. Par exemple, NIST. Vous trouverez le nom de la police sur le site Workload Protection.
compliance.profiles[].profile_version: La version de la politique. Par exemple, 1.0.0. Vous trouverez la version de la politique à l'adresse suivante : Workload Protection.
compliance.controls[]: Un ensemble de contrôles est prévu pour cette variante. Le manifeste du catalogue accepte un tableau de contrôles que vous pouvez revendiquer en spécifiant le nom du profil du contrôle, la version du profil et le nom du contrôle.
compliance.controls[].profile: Objet qui indique que vous ajoutez des contrôles à partir d'une politique spécifique.
compliance.controls[].profile.name: Le nom de la politique du contrôle réclamé. Par exemple, NIST. Vous trouverez le nom de la police sur le site Workload Protection.
compliance.controls[].profile.version: La version de la politique. Par exemple, 1.0.0. Vous trouverez la version de la politique à l'adresse suivante : Workload Protection.
compliance.controls[].names[]: Tableau des noms des contrôles réclamés. Par exemple : ["CM-7(b)", "AC-2(a)"].

Si vous avez inclus des contrôles dans votre fichier readme et dans le fichier manifeste de votre catalogue, le fichier manifeste est prioritaire. La meilleure pratique consiste à s'assurer que les contrôles répertoriés dans le fichier manifeste de votre catalogue correspondent aux contrôles figurant dans le fichier readme.

`change_notices` (facultatif)

Une liste des trois types de changements dont vous pourriez vouloir alerter vos utilisateurs lors de la publication d'une nouvelle version de votre architecture déployable. Vous pouvez spécifier breaking changes, new features, et general updates. Les ruptures sont des mises à jour qui suppriment des fonctionnalités disponibles dans une version précédente. Les nouvelles fonctionnalités mettent en évidence toute nouvelle fonctionnalité qu'un utilisateur pourrait rencontrer avec la nouvelle version. Les mises à jour englobent tous les changements que vous souhaitez mettre en évidence pour un utilisateur, tels qu'un comportement modifié qui n'interrompt pas nécessairement la fonctionnalité existante ou des changements qui facilitent l'utilisation de l'architecture déployable.

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

`iam_permissions` (facultatif)

Pour obtenir une liste de toutes les autorisations IAM requises pour qu'un utilisateur puisse travailler avec votre version d'architecture déployable. Les informations relatives aux autorisations IAM comprennent le nom programmatique du service requis et une liste de CRN pour les rôles nécessaires. Si vous créez le fichier manifeste de votre catalogue à partir de l'interface utilisateur, les CRN sont déjà inclus.

L'exemple suivant montre la structure JSON de la section 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:..."]
    }]
  }]
}]

Les valeurs suivantes peuvent être incluses dans la section iam_permissions:

iam_permissions[].service_name: Nom programmatique du service auquel les utilisateurs doivent avoir accès.
iam_permissions[].notes (facultatif): Fournir plus d'informations aux utilisateurs sur ce rôle ou sur la raison pour laquelle il est inclus. Exemple: This role is only required if you are using IBM Key Protect for encryption.
iam_permissions[].role_crns[]: En-tête de section pour indiquer une liste de rôles d'accès.
iam_permissions[].resources[]: Tableau de ressources pour une autorisation.
iam_permissions[].resources[].name: Nom de la ressource.
iam_permissions[].resources[].description: Description de la ressource.
iam_permissions[].resources[].role_crns[]: En-tête de section permettant d'indiquer une liste de rôles d'accès.

`architecture`

En-tête de section dans la section flavors qui spécifie des informations de haut niveau sur la version de l'architecture déployable qui comprend une description, des caractéristiques et un diagramme. Plusieurs diagrammes, avec des légendes, peuvent être fournis.

L'exemple suivant montre la structure JSON de la section architecture:

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

Les valeurs suivantes peuvent être incluses dans la section architecture:

architecture.features[]: Ensemble d'informations mettant en évidence les processus, les capacités et les résultats de la version ou, le cas échéant, de la variante d'architecture. Lors de l'onboarding à l'aide de la console, ces détails sont appelés "highlights". Ces détails apparaissent dans la boîte de sélection de la variation dans votre entrée de catalogue. Si votre produit existe en plusieurs variantes d'architecture, les utilisateurs peuvent comparer les fonctionnalités de chaque variante afin de déterminer celle qui correspond le mieux à leurs besoins.
architecture.features[].title: Nom de l'élément.
architecture.features[].description: Une description de la fonctionnalité.
architecture.diagrams[]: Tableau de diagrammes d'architecture comprenant la légende du diagramme, le site URL pour intégrer le SVG du diagramme, les métadonnées du diagramme telles que l'ID de l'élément et la description de l'élément, ainsi que la description de l'architecture de référence.
architecture.diagrams[].diagram: Objet contenant des informations sur un diagramme d'architecture singulier.
architecture.diagrams[].diagram.url: Le site URL pour le SVG du diagramme. Vous pouvez également intégrer un SVG.
architecture.diagrams[].diagram.api_url: L'API de gestion de catalogue URL au diagramme.
architecture.diagrams[].diagram.url_proxy: Objet contenant des informations sur une image mandatée.
architecture.diagrams[].diagram.url_proxy.url: L' URL e de l'image mise en cache.
architecture.diagrams[].diagram.url_proxy.sha: L'identifiant sha de l'image.
architecture.diagrams[].diagram.caption: Une étiquette courte pour le diagramme d'architecture.
architecture.diagrams[].diagram.type: Le type de support.
architecture.diagrams[].diagram.thumbnail_url: Un lien vers une vignette du diagramme.
architecture.diagrams[].description: Informations sur le diagramme d'architecture dans son ensemble, y compris les grandes lignes du système et les relations, contraintes et limites entre les composants de l'architecture déployable.

`dependencies`

Dans la section flavors pour une liste de produits compatibles avec l'architecture déployable. Les dépendances peuvent être obligatoires ou facultatives. Une dépendance incluse ici ne peut pas être ajoutée à la section swappable_dependencies. Les informations comprennent le nom programmatique du produit et les versions du produit. En option, vous pouvez inclure l'identifiant du catalogue et une liste de variations dépendantes.

L'exemple suivant montre la structure JSON de la section 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"
    }]
  }]
}]

Vous pouvez fournir des informations sur les architectures requises qui répondent à une dépendance et sur les architectures optionnelles qui fonctionnent avec les vôtres lorsque vous intégrez votre architecture déployable à un catalogue. Pour plus d'informations, voir Extension d'une architecture déployable pendant l'onboarding.

Les valeurs suivantes peuvent être incluses dans la section dependencies:

dependencies[].catalog_id (facultatif): ID du catalogue qui contient le produit. S'il n'est pas spécifié, le catalogue IBM Cloud est le catalogue par défaut.
dependencies[].id (facultatif): ID du produit. L'ID n'est pas nécessaire si la valeur name est définie.
dependencies[].name (facultatif): Nom programmatique du produit.
dependencies[].kind: Le type de format de la dépendance. Utilisez stack pour une architecture déployable composée d'architectures déployables groupées lorsqu'un fichier de configuration de pile est présent. Utilisez terraform pour les architectures déployables composées uniquement d'un ou plusieurs modules.
dependencies[].version: Une version ou une série de versions à inclure dans les dépendances au format SemVer.
dependencies[].flavors[] (facultatif): Tableau de noms de variations avec lesquelles l'architecture est compatible.
dependencies[].default_flavor (facultatif): Spécifie une variation par défaut qui est sélectionnée pour vos utilisateurs lorsque plusieurs variations sont compatibles ou nécessaires au déploiement de votre architecture. Vos utilisateurs peuvent sélectionner une variante différente si elle est incluse dans la propriété flavors. Cette valeur correspond à l' name e de la variation. Pour utiliser cette propriété, vous devez également définir dependency_version_2 sur true. Si elle n'est pas définie, aucune variation par défaut n'est fournie à vos utilisateurs.
dependencies[].optional: Précise si la dépendance est obligatoire ou non. La valeur par défaut est false. Pour utiliser cette propriété, vous devez également définir dependency_version_2 sur true.
dependencies[].description (facultatif): Fournissez une description d'une architecture optionnelle compatible avec la vôtre, afin que les utilisateurs puissent comprendre comment l'architecture fonctionne dans le cadre de la solution globale et pourquoi ils pourraient vouloir l'inclure. Pour utiliser cette propriété, vous devez également définir dependency_version_2 sur true.
dependencies[].on_by_default: Spécifie si une dépendance optionnelle est sélectionnée pour les utilisateurs lorsqu'ils ajoutent votre architecture déployable à un projet à partir d'un catalogue. Les utilisateurs peuvent désélectionner l'architecture s'ils ne la souhaitent pas. La valeur par défaut est false. Pour utiliser cette propriété, vous devez également définir dependency_version_2 et optional comme true.
dependencies[].input_mapping[] (facultatif): Tableau qui spécifie les valeurs référencées entre l'architecture compatible et l'architecture en cours d'intégration. Pour utiliser cette propriété, vous devez également définir dependency_version_2 sur true.
dependencies[].input_mapping[].dependency_output ou dependencies[].input_mapping[].dependency_input (facultatif): Spécifie la variable de la dépendance à laquelle l'architecture que vous intégrez fait référence. La valeur est le nom de la variable de la dépendance. Une seule de ces deux propriétés doit être fournie. Si reference_version est défini sur true, cette variable fait référence à la variable version_input de l'architecture que vous êtes en train d'intégrer.
dependencies[].input_mapping[].version_input (facultatif): Spécifie le nom de la variable d'entrée dans l'architecture que vous intégrez et qui fait référence à la valeur dependency_output ou dependency_input. Si reference_version est défini sur true, la variable dependency_input fait référence à la variable version_input de l'architecture que vous êtes en train d'intégrer.
dependencies[].input_mapping[].value (facultatif): Spécifie la valeur prédéfinie pour une entrée de l'architecture que vous êtes en train d'intégrer (version_input) ou de sa dépendance (dependency_input). La valeur spécifiée ici n'est utilisée que si version_input ou dependency_input est fourni et que dependency_output ne l'est pas. Si version_input est fourni, lorsque l'architecture et sa dépendance sont ajoutées à un projet par un utilisateur, la valeur de version_input de l'architecture est prédéfinie à la valeur spécifiée ici. Si dependency_input est fourni, lorsque l'architecture et sa dépendance sont ajoutées à un projet par un utilisateur, la valeur de dependency_input de la dépendance est prédéfinie à la valeur spécifiée ici.
dependencies[].input_mapping[].reference_version (facultatif): Indique le flux de références entre l'architecture que vous intégrez et sa dépendance. La valeur par défaut est false. Par défaut, l'entrée de l'architecture (version_input) doit faire référence à une entrée ou à une sortie de la dépendance (dependency_input ou dependency_output). Lorsque cet indicateur est défini sur true, le site dependency_input fait référence à une valeur du site version_input.

`dependency_version_2` (facultatif)

En référence à la section dependencies, dependency_version_2 Spécifie que la gestion des dépendances mise à jour est utilisée avec cette architecture déployable. Si vous utilisez la propriété optional ou les sections input_mapping à l'intérieur de la section dependencies, fixez cette valeur à true. Sinon, définissez-le sur false. Si cette propriété est définie sur true, toutes les dépendances dont la propriété optional est définie sur false sont nécessaires pour déployer l'architecture que vous êtes en train d'intégrer.

`swappable_dependencies` (facultatif)

En-tête de section pour une liste de produits compatibles avec l'architecture déployable. Contrairement à la matrice dependencies, les produits de cette section sont interchangeables. L'utilisateur peut choisir le produit qu'il souhaite utiliser pour répondre à la dépendance. Les dépendances permutables peuvent être obligatoires ou facultatives. Une dépendance incluse ici ne peut pas être ajoutée au tableau dependencies. Les informations comprennent le nom programmatique du produit et les versions du produit. En option, vous pouvez inclure l'identifiant du catalogue et une liste de variations dépendantes. Pour utiliser cette propriété, vous devez également définir dependency_version_2 sur true.

{
  "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"
        }
        ]
    }
  ]
}

Les valeurs suivantes peuvent être incluses dans la section swappable_dependencies:

swappable_dependencies[].name (facultatif): Utilisé lorsque l'architecture est intégrée à un catalogue pour vous aider à identifier le groupe spécifique de swappable_dependencies.
swappable_dependencies[].default_dependency (facultatif): Le site name de l'une des dépendances du groupe qui est sélectionné par défaut pour les utilisateurs.
swappable_dependencies[].dependencies: Tableau des dépendances qui peuvent être échangées au sein de ce groupe. Les valeurs de ce tableau sont les mêmes que celles documentées dans la section dependencies section.

`release_notes_url`

URL aux notes de mise à jour de l'architecture.

`configuration`

En-tête de section dans la section flavors qui spécifie la configuration des variables de déploiement pour une variation spécifique. Les types de données du catalogue sont utilisés pour étendre les types natifs et améliorer l'expérience de l'utilisateur lorsque vous travaillez dans la console IBM Cloud. Si vous exécutez votre code sur une machine locale ou dans un autre environnement, les variables ne sont pas utilisées. Un exemple pourrait être un type de catalogue password utilisé pour étendre les capacités d'une variable Terraform définie avec un type string afin qu'elle soit traitée comme sensible dans l'interface utilisateur.

L'exemple suivant montre la structure JSON de la section de configuration :

"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"
    }]
  }]
}]

Les valeurs suivantes peuvent être incluses dans la section configuration:

configuration[].key

La clé de configuration. La valeur doit correspondre au nom d'une variable de déploiement.

configuration[].type

Type d'entrée qu'un client peut définir ou sélectionner. Le type de données doit être pris en charge par le service de gestion des catalogues. Les types natifs de Terraform correspondent à certains des types pris en charge. Par exemple, le type Terraform map équivaut à object. Le type Terraform list équivaut à array. Un type Terraform string avec un attribut sensible équivaut à password. Les clients qui consomment votre architecture déployable doivent fournir des valeurs pour le type d'entrée que vous définissez dans le manifeste du catalogue.

Types prédéfinis pris en charge :

boolean nécessite la saisie d'une chaîne true ou false par les utilisateurs.
float exige un point décimal de la part des utilisateurs.
int nécessite la saisie d'un nombre entier par les utilisateurs.
number nécessite une valeur numérique. Le type number peut représenter à la fois des nombres entiers et des valeurs fractionnaires comme 4.56.
password nécessite la saisie d'une chaîne de caractères par l'utilisateur. La chaîne est expurgée dans la console et les journaux.
string nécessite une séquence de caractères Unicode représentant du texte. Vous pouvez éventuellement inclure une chaîne aléatoire à ajouter comme suffixe, ce qui permet d'éviter les collisions de noms pour les chaînes utilisées comme préfixes ou comme noms de base. Vous pouvez également spécifier la longueur de cette chaîne aléatoire. La chaîne générée est en minuscules, de a à z, sans caractères spéciaux et précédée d'un tiret, par exemple, myString-wx. Si une valeur par défaut est également donnée, le suffixe est ajouté. Si aucune valeur par défaut n'est donnée, la valeur est le suffixe sans le tiret. Par exemple :

"random_string": {
	"length": 2
}

object nécessite la saisie d'un objet Terraform par les utilisateurs. Pour plus d'informations, voir map.

Les types prédéfinis nécessitent une saisie manuelle de la part des utilisateurs.

Types personnalisés pris en charge :

array nécessite une liste de valeurs séparées par une virgule.
region demande à l'utilisateur de sélectionner une région pour déployer l'architecture déployable à partir d'une liste déroulante. Vous pouvez filtrer les régions disponibles pour les utilisateurs finaux. Par exemple, vous pouvez spécifier country_id:us,ca,jp dans le filtre Région pour limiter les régions disponibles à ces pays. Pour plus d'informations, voir Syntaxe de filtrage.
textarea exige des utilisateurs qu'ils saisissent un texte qui peut être divisé en plusieurs lignes. Par exemple, une description.
vpc exige que les utilisateurs sélectionnent un VPC par son nom dans une liste déroulante. Le résultat est le nom ou l'ID du VPC dont votre modèle a besoin.
vpc ssh key exige que les utilisateurs sélectionnent une clé SSH VPC pour l'authentification d'une machine virtuelle.
cluster exige que les utilisateurs sélectionnent un cluster Kubernetes Service ou Red Hat OpenShift. Le résultat correspond à l'identifiant du cluster.
power iaas exige que les utilisateurs sélectionnent une instance Power Virtual Server.
resource group exige que les utilisateurs sélectionnent un groupe de ressources. Le résultat est l'ID, le nom ou le CRN du groupe de ressources.
multi-line secure value exige des utilisateurs qu'ils saisissent un texte qui peut être divisé en plusieurs lignes et qui est expurgé dans la console et les journaux. Par exemple, si une clé longue est requise, la valeur est masquée dans les espaces de travail.
schematics workspace exige des utilisateurs qu'ils sélectionnent un espace de travail spécifique à partir d'une liste déroulante. Cette liste est filtrée dynamiquement sur la base des dépendances définies dans l'architecture déployable. Par exemple, si votre architecture déployable, example-da-1, dépend d'une autre architecture déployable, example-da-2, la liste déroulante d'entrée pour example-da-1 n'affiche que les espaces de travail associés à example-da-2. Les utilisateurs sélectionnent ensuite l'instance appropriée de l'espace de travail example-da-2 lorsqu'ils configurent example-da-1.
json editor offre aux utilisateurs un espace pour spécifier des entrées JSON plus importantes ou des fichiers de texte brut.
code editor donne aux utilisateurs le choix entre des entrées au format JSON ou HCL, ce qui est utile pour les entrées basées sur Terraform.
Platform resource exige que les utilisateurs sélectionnent une ressource d'instance dans une liste pour le type de ressource que vous spécifiez. Le type de ressource peut être VPC Subnet, VPC Image, VPC Floating IPs, Cloud Logs, Sysdig, Cloud Object Storage, Key Protect, ou Secrets Manager. Vous pouvez spécifier l'ID, le nom ou le CRN comme valeurs parmi lesquelles les utilisateurs peuvent choisir et autoriser des sélections uniques ou multiples. Le résultat est le nom ou l'identifiant dont votre code Terraform a besoin.
secret_group exige que les utilisateurs sélectionnent un groupe secret par nom à partir d'une instance spécifique de Secrets Manager. Le résultat est l'identifiant ou le nom du groupe secret. Pour répertorier les groupes d'une instance Secrets Manager spécifique, ce type doit être associé au type personnalisé platform resource, au type de ressource Secrets Manager et à une sortie de type valeur crn.
secret exige des utilisateurs qu'ils sélectionnent un secret par son nom à partir d'une instance spécifique de Secrets Manager. Le résultat est l'ID, le nom ou le CRN du secret. Pour répertorier les secrets d'une instance Secrets Manager spécifique, ce type doit être associé au moins au type personnalisé platform resource, au type de ressource Secrets Manager et à une sortie de type valeur crn. Vous pouvez éventuellement l'associer au type secret_group ainsi qu'à une sortie de type de valeur id pour dresser la liste des secrets d'un groupe de secrets spécifique dans cette instance Secrets Manager.
kms_key exige que les utilisateurs sélectionnent une clé à partir d'une instance spécifique de Key Protect. Le résultat est l'ID, le nom ou le CRN de la clé. Pour répertorier les clés d'une instance spécifique de Key Protect, ce type doit être associé au type personnalisé platform resource, au type de ressource Key Protect et à une sortie de type valeur crn.

configuration[].default_value

Valeur à définir par défaut.

configuration[].virtual (facultatif)

Indicateur précisant si une entrée doit être transmise au service Schematics. Si la valeur est fixée à true, l'entrée n'est pas transmise à Schematics. Attribuez la valeur true à toutes les entrées de votre architecture déployable qui sont référencées dans des architectures compatibles, mais qui ne sont pas utilisées dans l'architecture déployable que vous êtes en train d'intégrer. Ajouter des références à input_mapping dans les dependencies ou swappable_dependencies du manifeste du catalogue.

configuration[].description

Une description de la variable que vous souhaitez afficher dans l'interface utilisateur pour les utilisateurs de votre architecture déployable.

configuration[].display_name

Le nom affiché pour le type de configuration.

configuration[].required

Un booléen qui indique si les utilisateurs doivent spécifier le paramètre lors de l'installation.

configuration[].hidden

Un booléen qui indique si le paramètre doit être caché aux utilisateurs pendant l'installation.

configuration[].options[]

Tableau d'options que les utilisateurs peuvent choisir pour un paramètre.

configuration[].custom_config

Objet indiquant qu'une configuration personnalisée peut être utilisée.

configuration[].custom_config.type

L'ID du type de widget utilisé pour la configuration.

configuration[].custom_config.grouping

L'endroit où le type de configuration doit apparaître dans le catalogue. Les valeurs valables sont Target, Resource, et Deployment.

configuration[].custom_config.original_grouping

L'endroit où le type de configuration est apparu à l'origine. Les valeurs valables sont Target, Resource, et Deployment.

configuration[].custom_config.grouping_index

L'ordre de cet élément de configuration lorsqu'il y en a plusieurs.

configuration[].custom_config.config_constraints

Carte des paramètres de contrainte qui sont donnés au widget personnalisé.

configuration[].custom_config.associations

Objet pour les paramètres associés à la configuration.

configuration[].configuration_group

Le nom d'un groupe de configuration associé.

configuration[].value_constraints[]

Tableau de contraintes de valeur, où chaque contrainte définit des règles de validation.

configuration[].value_constraints[].type

Le type de la contrainte. Pour l'instant, seul le format regex est pris en charge.

configuration[].value_constraints[].value

Une expression régulière JavaScript.

configuration[].value_constraints[].description

Un message à afficher si la valeur fournie ne correspond pas à l'expression régulière spécifiée.

`schematics_env_values`

Dans la section flavors, schematics_env_values spécifie une liste de valeurs et de noms de variables qui doivent être transmis au service Schematics pour être utilisés comme variables d'environnement pendant l'exécution de Terraform. Il peut s'agir d'une valeur sécurisée, d'un paramètre de l'enregistrement Terraform ou d'autre chose. Vous pouvez choisir de spécifier une chaîne ou de créer une référence à Secrets Manager. Si les deux sont spécifiés, c'est la référence Secrets Manager qui est utilisée.

L'exemple suivant montre la structure JSON de la section schematics_env_values :

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

Les valeurs suivantes peuvent être incluses dans la section schematics_env_values:

schematics_env_values.value: Une chaîne JSON comprenant un tableau de variables d'environnement et leurs valeurs.
schematics_env_values.value[].name: Indique le nom de la variable d'environnement.
schematics_env_values.value[].value: Spécifie la valeur de la variable d'environnement.
schematics_env_values.value[].secure: Indique si la valeur de la variable d'environnement doit être affichée en clair dans le journal d'exécution. Les valeurs possibles sont true ou false.
schematics_env_values.value[].hidden: Spécifie s'il faut ou non inclure cette variable dans le journal d'exécution. Les valeurs possibles sont true ou false.
schematics_env_values.sm_ref: Une référence à une instance de Secrets Manager qui contient vos variables d'environnement sauvegardées en tant que secret. Le secret doit être une chaîne JSON comprenant un tableau de variables d'environnement et leurs valeurs.

L'exemple de chaîne JSON suivant inclut deux variables, TF_LOG et TF_IGNORE, et leurs valeurs qui sont ajoutées en tant que variables d'environnement pendant l'exécution de Terraform :

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

Utilisez des caractères d'échappement pour les guillemets de la liste.

L'exemple suivant utilise une référence à un secret dans 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` (facultatif)

Une valeur semver qui indique la version la plus ancienne compatible avec la version actuelle. Si aucune version antérieure n'est compatible avec la version actuelle, indiquez la valeur de la version actuelle dans ce champ. Par défaut, la version actuelle est compatible avec toutes les versions antérieures.

`ignore_readme`

S'il est défini sur true, le fichier readme n'est pas utilisé lorsque vous embarquez dans cette version, et le champ long_description est vide. Si le champ long_description est vide, un lien vers le fichier readme n'apparaît pas dans le menu Related Links du catalogue de la version.

`terraform_version`

La version du runtime Hashicorp Terraform nécessaire pour valider et installer la version. La définition de cette valeur dans le manifeste remplace ce qui est spécifié dans le code source.

`outputs`

En-tête de section pour des informations sur les valeurs de sortie de Terraform.

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

Les valeurs suivantes peuvent être incluses dans la section outputs:

outputs[].key: Spécifie la valeur de sortie.
outputs[].description: Un bref résumé de la valeur de sortie.

`install_type`

Spécifie si une architecture déployable est fullstack ou extension. Les architectures répertoriées en tant qu'extensions nécessitent des conditions préalables. Le tableau dependencies doit également être complété si vous définissez cette valeur sur extension. Cette propriété est ignorée si dependency_version_2 est défini comme true.

`scripts`

Une liste de scripts contenus dans le même référentiel qui peuvent être exécutés par un projet au cours d'une étape particulière d'une action spécifiée. Chaque clé de la carte doit correspondre au format action et stage de l'entrée. Stage doit être pre ou post. Action doit être validate, deploy ou undeploy.

{
   "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."
}

Modifier localement le manifeste du catalogue

Modifier localement le manifeste du catalogue

Mappage des détails du catalogue au fichier manifeste

Modifier votre manifeste

Exemple de fichier manifeste

Valeurs disponibles

Produits

label

name

hidden

version

product_kind

tags

keywords

short_description

long_description

provider_name

offering_docs_url

offering_icon_url

support_details

features

Modules

works_with

Versions

label

name

short_description

index

working_directory

usage

usage_template

licenses

compliance

change_notices (facultatif)

iam_permissions (facultatif)

architecture

dependencies

dependency_version_2 (facultatif)

swappable_dependencies (facultatif)

release_notes_url

configuration

schematics_env_values

minimum_compatible_version (facultatif)

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` (facultatif)

`iam_permissions` (facultatif)

`architecture`

`dependencies`

`dependency_version_2` (facultatif)

`swappable_dependencies` (facultatif)

`release_notes_url`

`configuration`

`schematics_env_values`

`minimum_compatible_version` (facultatif)

`ignore_readme`

`terraform_version`

`outputs`

`install_type`

`scripts`