Création d'une architecture déployable

Après avoir suivi les étapes de planification et de conception de votre architecture et décidé quel type de composant créer, vous pouvez commencer à créer le code automatisé qui donne vie à l'architecture. Cette rubrique vous guide lors de la création d'une architecture déployable constituée de modules.

Pour créer une architecture déployable, vous devez définir les fichiers requis, créer une release dans GitHub, puis intégrez-le à un catalogue privé afin que vous puissiez le partager avec d'autres personnes à l'intérieur ou à l'extérieur de votre organisation.

Vous disposez de quelques options pour créer une architecture déployable :

Créez votre propre architecture : Utilisez les instructions suivantes pour créer votre propre architecture déployable à partir de zéro.
Modifier le code existant : Téléchargez le code d'une architecture existante, modifiez-le pour l'adapter à vos besoins et créez une nouvelle architecture déployable avec vos modifications.
Empiler des architectures : Vous pouvez également empiler des architectures déployables dans un projet si ces architectures sont déjà disponibles dans un catalogue.

En savoir plus sur la structure d'une architecture déployable

Une architecture déployable, décrite dans cette documentation, est constituée d'un ou de plusieurs modules. Une architecture déployable est composée des éléments suivants dans le référentiel source:

d'une architecture déployable*Anatomie d'une architecture — d'une architecture déployable basée sur une

Code Terraform: Votre référentiel source inclut des fichiers Terraform. Ces fichiers déclarent l'infrastructure souhaitée (état final) et s'appuient sur les fournisseurs Terraform qui exécutent les demandes d'API réelles pour créer, mettre à jour et supprimer l'infrastructure. Certains des fournisseurs les plus couramment utilisés sont le fournisseur Terraform IBM Cloud® et le fournisseur d'API Helm/Kubernetes/Rest.
Scripts (facultatif): Utilisé comme un stop gap pour les fonctions qui peuvent ne pas exister (Bash/Python) ou pour les tâches opérationnelles ad hoc (Ansible). Pour plus d'informations, voir Création de scripts pour les architectures déployables.
Tests automatisés: Tests de validation utilisés pour déployer, vérifier et détruire l'infrastructure. Pour un exemple, voir le répertoire tests dans l'exemple de référentiel sample-deployable-architectures.
Documentation: Un diagramme d'architecture et un fichier Readme doivent être inclus dans votre référentiel source.
Fichier manifeste de catalogue: Définit comment l'architecture déployable est exposée dans le catalogue IBM Cloud. Outre les détails généraux du catalogue tels que le nom, la description et les fonctionnalités, il comprend les définitions des variantes qui renvoient à la configuration Terraform sous-jacente, les déclarations de conformité vérifiées lors de l'intégration au catalogue à l'aide de IBM Cloud® Security and Compliance Center Workload Protection, et les autorisations IAM nécessaires pour exécuter l'architecture déployable. Pour plus d'informations, voir Edition locale du manifeste de catalogue.
Variantes: Une architecture déployable peut inclure des variations de capacité ou de complexité. Par exemple, vous pouvez créer une variante de démarrage rapide avec des fonctionnalités de base pour un déploiement simple et peu coûteux, puis vous pouvez avoir une variante standard avec une architecture plus complexe qui serait utilisée en production. Chacune de ces variantes est elle-même une architecture déployable, qui est intégrée et configurée pour apparaître ensemble dans un catalogue. Ces variations sont sourcées dans le même référentiel dans des répertoires de travail différents et sont définies dans votre fichier ibm_catalog.json. Pour plus d'informations, voir Création d'une variante.

Spécifier les dépendances et étendre votre architecture

Si votre architecture déployable dépend d'une autre, vous pouvez inclure des informations sur cette dépendance lorsque vous intégrez votre architecture déployable à un catalogue. Vous pouvez également inclure des architectures optionnelles pour étendre les vôtres à différents cas d'utilisation. Il en résulte une solution personnalisable pour les utilisateurs, car ils peuvent choisir les architectures qu'ils souhaitent inclure avec la leur. Pour plus d'informations, voir Extension d'une architecture déployable pendant l'onboarding.

Vous pouvez également fournir des informations sur les autres architectures que vous souhaitez inclure avec la vôtre dans le fichier manifeste du catalogue de votre architecture déployable avant de l'embarquer.

Utilisez la section dependencies dans le fichier manifeste du catalogue pour créer une solution personnalisable avec des architectures optionnelles et obligatoires. Assurez-vous que dependency_version_2 est défini sur true dans le fichier manifeste du catalogue. L'ancienne façon de travailler avec les dépendances dans le fichier manifeste du catalogue est toujours prise en charge. Lorsque dependency_version_2 est défini sur false, vous pouvez définir install_type sur extension et fournir des informations sur les dépendances dans la section dependencies. Si vous le faites, chaque architecture de la liste des dépendances est nécessaire pour déployer la vôtre. Pour plus d'informations et pour définir ces valeurs, voir Modification locale du manifeste du catalogue.

Création d'une architecture déployable

Vous pouvez vous attendre à effectuer les tâches de haut niveau suivantes lors de la création de votre architecture déployable:

Créez votre référentiel source et ajoutez votre code.
Créez votre fichier manifeste ibm_catalog.json pour préparer la création d'une vignette dans le catalogue.
Créez une édition.
Intégrez votre code pour créer une vignette de catalogue dans un catalogue privé en l'examinant et en le validant.
Choisissez l'emplacement où vous souhaitez partager ou publier votre architecture déployable.

Les instructions suivantes pour la création d'une architecture déployable utilisent un exemple de référentiel public à enseigner par exemple.

Création de votre référentiel source

En utilisant les exigences définies par votre organisation, créez un référentiel GitHub que vous pouvez utiliser pour stocker le code source de votre architecture déployable. Pour obtenir de l'aide sur la création d'un référentiel, voir la documentationGitHub. Si vous disposez déjà d'un référentiel que vous souhaitez utiliser, vous pouvez ignorer cette étape. Vous pouvez choisir d'utiliser une autre organisation pour héberger votre code source, telle que GitLab, mais aux fins de cette documentation, GitHub est utilisé.

Création des fichiers Terraform requis

Passez en revue les sections suivantes pour savoir quels fichiers Terraform de base sont requis dans votre référentiel source GitHub pour créer le fichier .tgz requis dans le cadre de l'intégration de votre architecture déployable à un catalogue privé.

`main.tf`

Le fichier main.tf est l'endroit où vous placez le code qui met à disposition les ressources que vous souhaitez créer. Vous pouvez appeler directement un module depuis terraform-ibm-modules ou un module externe ou une ressource de fournisseur.

Voir les exemples:

`outputs.tf`

Le fichier outputs.tf contient des valeurs de sortie que vous pouvez inclure dans votre architecture déployable.

Voir les exemples:

`provider.tf`

Le fichier provider.tf contient la configuration du fournisseur, telle que le nom du fournisseur, la clé d'API et la région attendue par le code.

Voir les exemples:

`README.md`

Le fichier Readme contient des informations d'arrière-plan et d'utilisation sur l'architecture déployable, notamment les exigences, les modules, les ressources, les accès requis, les entrées et les sorties.

Si vous êtes le référentiel source se trouve dans l'organisation terraform-ibm-modules, la plupart du fichier Readme est généré. Vous n'ajoutez donc pas manuellement les informations comme les entrées et les sorties. Les noms et descriptions des variables sont générés dans le fichier readme à partir du variables.tf fichier.

Voir les exemples:

`variables.tf`

Le fichier variables.tf inclut les variables obligatoires et facultatives pour l'architecture déployable.

Voir les exemples:

`version.tf`

Le fichier version.tf stocke des informations sur la version Terraform et la version de fournisseur nécessaires à l'exécution de l'architecture déployable.

Tous les fournisseurs Terraform requis pour l'architecture déployable doivent être verrouillés dans une version exacte au lieu d'utiliser une plage pour garantir des résultats cohérents avec l'architecture déployable.

Voir les exemples:

Création d'un fichier manifeste de catalogue

Le manifeste de catalogue est un fichier dans la racine de votre référentiel appelé ibm_catalog.json. Ce fichier définit les métadonnées requises pour créer une tuile dans un catalogue, par exemple le nom, la description, les fonctionnalités, les définitions de variation qui renvoient à la configuration Terraform sous-jacente, les déclarations de conformité qui seront vérifiées lors de l'intégration à l'aide de Workload Protection, et les autorisations IAM nécessaires pour déployer l'architecture. Il définit également les configurations que vous souhaitez sélectionner par défaut lorsqu'un utilisateur tente de déployer votre architecture à partir du catalogue. Pour plus d'informations, voir Mappage des détails du catalogue vers le fichier manifeste.

Consultez l'exemple de l'exemple de référentiel qui illustre une variante de type fullstack et d'extension.

Vous pouvez créer votre fichier manifeste de catalogue à l'aide de deux méthodes différentes:

Vous pouvez créer ce fichier à partir de zéro à l'aide du modèle.

Vous pouvez démarrer le processus d'intégration avec l'exemple de base suivant dans votre référentiel source, puis télécharger le fichier manifeste après avoir apporté des modifications lors de l'intégration dans la console pour ajouter le fichier mis à jour à votre référentiel source.

Voici un fichier manifeste de base que vous pouvez ajouter à votre référentiel et éditer pour vous aider à démarrer avec cette option.

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

Etapes suivantes: Intégration de votre architecture déployable à un catalogue privé

Avec une édition Git créée qui inclut les fichiers requis dans votre référentiel source, vous pouvez intégrer une version de votre architecture déployable et toutes les variantes incluses. L'intégration est le processus de création d'une vignette de catalogue dans un catalogue privé en examinant les détails du catalogue et en validant un déploiement de test et les réclamations de conformité dans IBM Cloud. Pour le processus détaillé, voir Intégration d'architectures déployables.