Meilleures pratiques pour la création d'architectures déployables

Une architecture déployable est une unité modulaire autonome d'automatisation de cloud qui combine une ou plusieurs ressources de cloud pour fournir un modèle d'architecture commun. Il permet un déploiement simplifié, l'évolutivité et la modularité, permettant aux utilisateurs de mettre à disposition et de gérer facilement les ressources d'infrastructure.

Ce guide décrit les meilleures pratiques pour la génération d'architectures déployables bien conçues et maintenables qui sont écrites dans Terraform. En se concentrant sur des attributs clés tels que la portée, la composabilité, la consommabilité et les contrôles de qualité, vous garantisdez des solutions robustes et fiables. La dernière section de ce guide contient des références à des outils et à des modèles qui aident à mettre en oeuvre ces pratiques.

Ces meilleures pratiques s'appliquent à la création d'architectures déployables avec Terraform. Pour plus d'informations, voir Création d'une architecture déployable.

Regarder et apprendre

Vous préférez le voir à l'œuvre? Consultez la vidéo suivante pour en savoir plus sur les architectures déployables.

Transcription vidéo

Une architecture déployable est un modèle d'architecture avec automatisation pour le déploiement de l'infrastructure et des logiciels sur le nuage. Il permet aux organisations d'assurer la cohérence dans la manière dont l'infrastructure et les logiciels sont déployés et configurés. Il met en place une architecture et une sécurité adaptées aux besoins, ce qui réduit l'assistance globale et augmente la fiabilité à long terme.

Ce modèle prend vie grâce à l'automatisation qui instancie l'architecture déployable. L'automatisation IBM Cloud est pilotée par Terraform pour l'automatisation de l'infrastructure en tant que service et par Ansible pour la configuration des logiciels.

La compréhension des coûts est cruciale - vous pouvez estimer les coûts avant le déploiement et suivre l'évolution des dépenses au fur et à mesure que vous mettez à jour ou personnalisez l'architecture. Et n'oubliez pas que rien ne vous est facturé tant que vous n'êtes pas déployé.

Les politiques de sécurité et d'organisation sont essentielles pour les déploiements en entreprise. C'est pourquoi les architectures déployables sont vérifiées et pré-scannées pour adhérer à un ensemble d'exigences politiques, ce qui peut aider votre organisation à rester sécurisée. Les déploiements standardisés simplifient également la collecte de preuves pour les audits.

Les architectures déployables fournissent des informations sur la manière d'obtenir un soutien ainsi que l'autorisation nécessaire pour déployer l'architecture.

Enfin, vous pouvez partager les architectures déployables d'un catalogue privé avec d'autres comptes de votre organisation. En outre, le catalogue peut limiter les utilisateurs à des versions spécifiques d'une architecture déployable. Cela permet d'assurer la cohérence et la normalisation pour tout le monde.

Les modèles d'architecture sont créés par des experts du domaine. Les architectures interdomaines sont construites en reliant les architectures entre elles pour créer une architecture déployable plus complexe.

Vous pouvez créer vos propres architectures déployables ou gagner du temps en personnalisant les architectures prêtes à l'emploi de IBM Cloud à partir du catalogue IBM Cloud ou du registre communautaire.

une architecture déployable est définie par un manifeste sous forme de code, qui décrit l'architecture, l'emplacement du code, les autorisations, les coûts, le support, la description, l'icône et d'autres détails. Il est défini avec JSON et se trouve à la racine du repo.

Vous pouvez saisir ou modifier une architecture déployable dans la console et exporter le manifeste. Vous pouvez créer une architecture déployable pour la première fois à partir d'un snapshot git. Utilisez l'url.tgz de la version comme source.

Ensuite, modifiez les détails de l'entrée du catalogue pour votre architecture déployable, comme l'icône et le nom. Vous pouvez ajouter des dépendances et des architectures optionnelles qui fonctionnent bien avec les vôtres, mais qui ne sont pas obligatoires.

Vous pouvez également gérer les demandes de conformité pour l'architecture déployable. Ces affirmations sont vérifiées lorsque vous validez l'architecture déployable dans le catalogue avant de la publier.

Enfin, après avoir intégré une version de votre architecture déployable, vous pouvez exporter le fichier manifeste du catalogue et l'enregistrer dans votre référentiel source. L'utilisation de la console est généralement la meilleure approche pour l'intégration d'une nouvelle architecture déployable, car vous pouvez facilement exporter le manifeste du catalogue et le modifier ultérieurement si nécessaire. De cette façon, vous n'avez pas besoin de créer le fichier manifeste du catalogue à partir de zéro.

Dans le catalogue IBM Cloud, ouvrez l'onglet Architectures déployables pour trouver les architectures prises en charge par IBM.

Les architectures déployables de notre registre communautaire peuvent changer fréquemment ou être abandonnées à court terme, mais elles constituent toujours un bon point de départ pour vous permettre de les utiliser et de les personnaliser.

Prenons l'exemple de l'architecture déployable VPC landing zone, disponible dans le catalogue IBM Cloud. Il s'agit d'une architecture déployable généralement utile, car vous avez besoin d'un VPC si vous avez l'intention d'exécuter une charge de travail dans le nuage.

VPC landing zone est conçu pour être conforme au profil IBM Cloud Framework for Financial Services. Il sépare les charges de travail de gestion des charges de travail des travailleurs, utilise la gestion des clés pour crypter le stockage d'objets dans le nuage et utilise des points d'extrémité privés pour les communications. Vous pouvez l'utiliser tel quel ou l'adapter à vos besoins en matière de zone d'atterrissage.

Pour une architecture déployable plus complexe, envisagez une fondation Cloud pour la sécurité et l'observabilité. Cette architecture déployable a été réalisée en reliant plusieurs architectures du catalogue IBM Cloud. Grâce à lui, vous pouvez tirer parti de la gamme complète de services de sécurité proposés par IBM Cloud. Il est personnalisable, de sorte que vous pouvez choisir d'inclure uniquement les services dont vous avez besoin et de laisser de côté ceux qui ne le sont pas.

Maintenant que vous savez où trouver des architectures déployables, comment les déployer et les maintenir sur l'ensemble des comptes? Vous utilisez un projet IBM Cloud.

Dans le projet, vous configurez les variables d'entrée pour l'architecture déployable. Vous pouvez contrôler les coûts, la dérive de vos ressources, les analyses de conformité et passer à la dernière version d'une architecture déployable lorsqu'elle est disponible dans le catalogue. Un projet est généralement situé dans un compte pivot et déploie des ressources sur différents comptes satellites, également appelés comptes cibles.

Consultez notre documentation pour en savoir plus sur l'exécution de charges de travail sécurisées sur IBM Cloud. Ou plongez-vous dans le catalogue IBM Cloud pour découvrir quelles architectures déployables pourraient convenir à votre entreprise.

Principes de conception

La portée, la composabilité et la consommabilité sont les trois principes de conception principaux que vous devez prendre en compte lorsque vous créez une architecture déployable.

Dans la phase de planification et de recherche, vous devez évaluer l'écosystème actuel des offres et évaluer le cas d'utilisation métier et les exigences. Utilisez Well-Architected Framework et Architecture Design Framework pour planifier et concevoir les composants requis pour l'architecture.

Portée

Une portée bien définie pour l'architecture déployable est cruciale, car elle devrait être suffisamment complète pour inclure toutes les ressources nécessaires, tout en étant suffisamment ciblée pour éviter toute complexité inutile.

Une bonne pratique consiste à inclure les ressources d'infrastructure qui sont généralement déployées ensemble en tant qu'unité, qui nécessitent des accès et des autorisations similaires et qui ont le même cycle de vie. Prenons l'exemple de l'architecture déployableVPC landing zone. Cette architecture déployable a une portée bien définie qui inclut les ressources d'infrastructure suivantes:

Ressources dans la zone d'atterrissage VPC DA
Ressource Description
Clouds privés virtuels Crée une topologie VPC sécurisée
Infrastructure réseau Inclut des sous-réseaux, des passerelles publiques, des listes de contrôle d'accès, des passerelles de transit et des groupes de sécurité
Mise en réseau de périphérie Isole le trafic vers l'Internet public
Surveillance et journalisation Intègre les journaux de flux pour l'observabilité et l'audit du trafic VPC

Ces ressources sont généralement déployées ensemble en tant qu'unité, nécessitent des autorisations administratives réseau similaires et ont le même cycle de vie, ce qui signifie qu'elles :

  • Sont créés ensemble, par exemple lorsqu'un nouveau VPC est mis à disposition avec ses sous-réseaux, passerelles publiques et groupes de sécurité associés.
  • Sont mis à jour ensemble, par exemple lorsqu'une modification est apportée à la configuration réseau du VPC, qui nécessite des mises à jour des sous-réseaux, des passerelles publiques et des groupes de sécurité.
  • Sont supprimés ensemble, par exemple lorsqu'un VPC est mis hors service et que toutes ses ressources associées, y compris les sous-réseaux, les passerelles publiques et les groupes de sécurité, sont supprimées.

Composabilité

L'un des principes fondamentaux d'une architecture déployable est la composabilité, qui permet de créer une architecture déployable plus large en empilant plusieurs architectures déployables. Cette approche modulaire permet une flexibilité et une réutilisation maximales des ressources d'automatisation.

Pour obtenir la composabilité, une architecture déployable doit être conçue pour:

  • Maximisez la quantité d'informations générées par les valeurs de sortie, tout en maintenant les types de sortie simples. Cette pratique permet de réutiliser l'automatisation de l'architecture déployable dans un large éventail de scénarios et en fait un bloc fonctionnel polyvalent pour diverses solutions automatisées.

  • Autorisez les références facultatives aux ressources déployées existantes, telles que les groupes de ressources, les instances IBM® Key Protect for IBM Cloud® ou Hyper Protect Crypto Services et les instances IBM Cloud Secrets Manager, entre autres. Les utilisateurs peuvent ensuite configurer des instances existantes ou les déployer dans des groupes de ressources existants, ce qui augmente la polyvalence de votre automatisation. L' architecture déployableSecrets Manager est un excellent exemple de ce principe en action. En permettant aux utilisateurs de réutiliser les instances Secrets Manager, les groupes de ressources et la clé de chiffrement KMS existantes, cette automatisation offre un haut degré de flexibilité et d'adaptabilité. Par exemple, vous pouvez effectuer les tâches suivantes :

    • Configurez une instance Secrets Manager existante en transmettant son ID et créez des groupes de secrets dans l'instance existante.
    • Intégration à un système de gestion de clés existant tel que Key Protect ou Hyper Protect Crypto Services.
    • Déployez dans un groupe de ressources existant ou créez-en un nouveau avec des conventions de dénomination personnalisables.

Cette architecture déployable permet également de créer une nouvelle instance Secrets Manager, un nouveau groupe de ressources et d'autres ressources à partir de zéro, fournissant une solution autonome.

En adoptant la composabilité, une architecture déployable peut être facilement intégrée dans une architecture de solution plus complexe en l'empilant avec d'autres architectures déployables. Par exemple, le modèle de génération augmentée de récupération montre comment plusieurs architectures déployables, y compris l'architecture déployable Secrets Manager, peuvent être combinées pour construire une solution complexe. Les architectures déployables, conçues dans une optique de composabilité, constituent la base de ces solutions complexes.

Lorsque des architectures déployables sont empilées, chaque architecture déployable membre conserve son état de configuration indépendant, ce qui permet de la déployer, de la mettre à jour ou de l'annuler individuellement. Cette approche modulaire permet d'obtenir des garanties de coût, de conformité, de support et de qualité à partir des architectures déployables incluses, tandis que la solution globale reste unique avec ses propres descriptions et son architecture de référence. Pour plus d'informations, voir Que signifie empiler des architectures déployables?

Convivialité

Une architecture déployable doit être conçue en gardant à l'esprit la consommabilité, ce qui permet aux utilisateurs de la comprendre et de la déployer facilement. Pour ce faire, l'architecture déployable doit fournir une documentation complète qui inclut les éléments suivants:

Prérequis
Dépendances logicielles et exigences d'infrastructure requises pour le déploiement.
Description détaillée des variables d'entrée et des valeurs de sortie
Inclusion de l'objectif, du type de données et des valeurs par défaut.
Droits minimaux nécessaires
Droits requis pour exécuter l'automatisation de l'architecture déployable.
Diagrammes et mappes d'architecture
Représentations visuelles des composants et des relations de l'architecture déployable.
Configuration simplifiée
Facile à déployer et à gérer.
Réduction des besoins en ressources
Optimisez l'architecture déployable pour réduire les exigences en matière de matériel et de ressources, telles que les besoins en UC et en mémoire, ce qui la rend plus abordable et plus efficace.
Déploiement fluide
Plus rapide et plus facile à démarrer.

Une autre facette permettant de s'assurer que l'architecture déployable est facilement consommable est de prévoir des variations multiples, y compris une variation de démarrage rapide. Une version de démarrage rapide de l'architecture déployable doit être fournie, ce qui est moins cher et plus rapide à utiliser. Par exemple, la variante QuickStart de l'architecture déployable Red Hat OpenShift Container Platform sur la VPC landing zone crée un environnement VPC (Virtual Private Cloud) entièrement personnalisable dans une seule région, en fournissant un cluster Red Hat OpenShift unique dans un VPC sécurisé pour les charges de travail. Cette variante de démarrage rapide est conçue à des fins de démonstration et de développement et coûte moins de 400 $ par mois pour s'exécuter.

En revanche, la version standard de l'architecture déployable Red Hat OpenShift Container Platform on VPC landing zone, basée sur l'architecture de référence IBM Cloud Framework for Financial Services, crée des Red Hat OpenShift clusters de charge de travail Container Platform sur un réseau VPC (Virtual Private Cloud), mais coûte plus de 4 000 $ par mois à exécuter. Il inclut également des fonctions avancées telles que le service VPC de gestion, le service VPC de charge de travail, l'isolement du VPC de gestion et du VPC de charge de travail, ainsi que des décisions d'architecture de sécurité réseau avancées.

Variables d'entrée

Pour faciliter la configuration des variables d'entrée de l'architecture déployable par les utilisateurs, utilisez les meilleures pratiques suivantes:

Exposer uniquement les arguments fréquemment modifiés
N'exposez que les variables que la plupart des utilisateurs auront besoin de modifier, en évitant les architectures déployables comportant un nombre élevé de variables d'entrée qui risqueraient de submerger les utilisateurs. Pour les utilisateurs avancés, envisagez de fournir une zone d'entrée JSON unique pour une personnalisation ultérieure. A titre d'exemple, l'architecture déployable de la zone d'arrivée VPC présente une zone unique nommée override_json_string qui donne un contrôle total aux utilisateurs avancés sur la topologie déployée. Pour plus d'informations, voir le guide de déploiement de la zone d'arrivée VPC.
Utiliser un nom clair et descriptif pour les ressources existantes
Lorsque vous faites référence à des ressources existantes, utilisez des noms qui indiquent clairement ce à quoi elles font référence, par exemple existing_cluster_name au lieu de cluster_name, afin d'éviter toute ambiguïté.
Préférer les noms aux ID
Lorsque vous faites référence à des ressources existantes, utilisez des noms au lieu d'ID pour une meilleure utilisation par l'utilisateur.
Eviter les acronymes
Au lieu d'utiliser des acronymes, utilisez des noms de produits complets pour permettre aux personnes qui ne sont pas familières avec les produits ou les services de comprendre ce à quoi ils font référence. Par exemple, secrets_manager au lieu de sm ou key_management au lieu de kms.
Utiliser les fonctions de saisie avancées
Pour activer le service de projets IBM Cloud afin de rendre des widgets d'entrée appropriés pour les variables, ce qui facilite la configuration des valeurs par les utilisateurs. Exemple :
  • Région VPC: liste déroulante de toutes les régions VPC disponibles sur IBM Cloud.
  • Clé SSH VPC: zone d'entrée sécurisée pour la gestion des clés SSH.
  • Cluster: liste déroulante des clusters disponibles sur IBM Cloud.

Pour plus d'informations, voir Edition locale des valeurs de manifeste de catalogue.

En suivant ces instructions, l'architecture déployable peut être rendue plus consommable, ce qui permet aux utilisateurs de la comprendre et de la déployer rapidement.

Qualité

Pour garantir la fiabilité et la cohérence de l'architecture déployable, il est essentiel d'implémenter et d'automatiser les contrôles de qualité. Ces vérifications doivent couvrir divers aspects de l'architecture déployable, notamment la qualité du code, la validation de la configuration, les tests et l'intégration continue.

qualité du code

Optimisez le lignage et le formatage du code. Appliquez des styles de codage et un formatage cohérents pour faciliter la lecture et la gestion du code. Détectez les erreurs et les avertissements dans le code pour éviter les problèmes lors du déploiement. Envisagez d'aller au-delà du simple code Terraform et d'incorporer tous les outils pertinents pour toutes les ressources de votre architecture déployable, tels que les scripts Bash, les scripts Python, les fichiers YAML et JSON, et Golang.

Exemples :

  • terraform_fmt pour formater le code Terraform.
  • go-fmt pour formater le code Go.
  • black pour formater le code Python.
  • isort pour trier les importations Python.
  • flake8 pour vérifier si le code Python contient des erreurs et des avertissements.
  • shellcheck pour rechercher les erreurs et les avertissements dans les scripts de shell.
  • golangci-lint pour rechercher les erreurs et les avertissements dans le code Go.

Validation de la configuration

Utilisez la validation statique pour vérifier la syntaxe et la configuration de l'architecture déployable afin de s'assurer qu'elle est correcte et cohérente. Validez la configuration de l'architecture déployable pour éviter les erreurs lors du déploiement. Encore une fois, pensez à aller au-delà du code Terraform et à incorporer tous les outils pertinents pour toutes les ressources de votre architecture déployable, tels que les scripts Bash, les scripts Python, les fichiers YAML et JSON, et Golang.

Exemples :

  • terraform_validate pour valider la configuration Terraform.
  • checkov pour vérifier les problèmes de sécurité et de conformité dans le code Terraform.
  • tflint pour rechercher les erreurs et les avertissements.
  • detect-secrets pour détecter les secrets dans le code.
  • hadolint pour rechercher les erreurs et les avertissements dans les fichiers Docker.
  • helmlint pour rechercher les erreurs et les avertissements dans les chartes Helm.

Tests

Lorsqu'il s'agit de tester le code d'infrastructure, il n'y a pas de test d'unité pur comme vous pouvez le penser pour le code d'application. Au lieu de cela, la stratégie de test implique le déploiement de l'infrastructure dans un environnement réel, la validation de son fonctionnement, puis l'annulation de son déploiement.

Suite de tests de validation automatisée

Il est recommandé de disposer d'une suite de tests automatisée de base qui couvre les éléments fondamentaux suivants:

Tests de déploiement
Vérifiez que le code d'infrastructure peut être déployé dans un environnement réel. Créez toutes les ressources nécessaires, telles que les machines virtuelles, les bases de données et les réseaux. Ces tests permettent de s'assurer que le code d'infrastructure est correct et qu'il peut être appliqué à un environnement réel. Il est recommandé de faire varier les paramètres d'entrée de l'architecture déployable dans ces tests afin de garantir une large couverture alignée sur une utilisation commune.
Tests de destruction
Vérifiez que le déploiement ou la destruction du code d'infrastructure a abouti, en supprimant toutes les ressources créées. Ces tests garantissent que le code d'infrastructure peut être supprimé en toute sécurité d'un environnement réel, sans laisser de ressources orphelines ni entraîner des conséquences inattendues.
Tests d'idempotence
Vérifiez que le code d'infrastructure peut être réappliqué plusieurs fois sans provoquer de modifications ou d'erreurs inattendues. En d'autres termes, le code doit produire le même résultat quel que soit le nombre de fois où il est appliqué. Ces tests sont critiques dans des environnements tels que IBM Cloud, où la plateforme recherche périodiquement les modifications pour détecter la dérive entre l'infrastructure déployée et la source de données, qui est le code d'automatisation. Les tests d'identification permettent de s'assurer que le code d'infrastructure peut gérer des déploiements ou des mises à jour répétés sans provoquer de problèmes. Ces tests permettent également de s'assurer que les fonctions de détection de dérive permettent d'identifier et de corriger avec précision les différences entre l'état prévu et l'état réel de l'infrastructure. Pour plus d'informations, voir Gestion de la dérive.
Tests de mise à niveau de version
Vérifiez que le code d'infrastructure peut être correctement mis à niveau d'une version à une autre, sans provoquer d'erreurs ou de modifications non intentionnelles. Ces tests garantissent que le code d'infrastructure peut être mis à niveau en toute sécurité, sans perturber ou détruire les ressources existantes ou causer des conséquences inattendues.

Scénarios de test avancés

Les scénarios de test avancés incluent des scénarios tels que:

Déploiement de l'architecture déployable plusieurs fois dans le même compte
Vérifiez que le code d'infrastructure peut gérer plusieurs déploiements dans le même compte, sans provoquer de conflits de nom de ressource ou d'autres problèmes.
Déploiement de l'architecture déployable avec un profil sécurisé
Vérifiez que le code d'infrastructure peut être déployé avec un profil sécurisé Cloud Identity and Access Management. Pour plus d'informations, voir Définition d'une méthode d'authentification.

En incluant ces tests dans votre suite de tests automatisés, vous pouvez vous assurer que votre code d'infrastructure est fiable, robuste et sûr à déployer en production.

Intégration continue

Pour garantir la fiabilité, la cohérence et la facilité de maintenance de l'architecture déployable, une approche de gauche à gauche est recommandée, dans laquelle les contrôles et les tests de qualité sont intégrés dès le début du cycle de développement. Cette approche permet de détecter rapidement les erreurs et les défauts, ce qui réduit la probabilité de problèmes en aval et améliore la qualité globale.

Dans le cadre de cette approche, les contrôles de qualité suivants sont recommandés:

Contrôle de la qualité côté client
Les points d'ancrage de validation Git côté client doivent être utilisés pour exécuter des vérifications sur la machine du développeur avant de valider le code. Cela inclut des vérifications des normes de codage, des erreurs de syntaxe et des données sensibles. Des outils tels que Pré-validation peuvent être utilisés pour automatiser ce processus.
Pratiques d'EC
Les meilleures pratiques en matière d'intégration continue (IC) doivent être suivies. Les pratiques générales de tout produit d'ingénierie logicielle s'appliquent au développement de l'architecture déployable, notamment:
  • Travailler avec de petites demandes d'extraction ciblées (DA) pour faciliter les examens en temps opportun et réduire les conflits de fusion.
  • L'intégration régulière des modifications de code dans la branche principale permet d'éviter les branches de fonction à longue durée de vie et de réduire la complexité de la fusion.
  • Implémentation de tests automatisés et de révisions de code pour garantir la qualité et la cohérence du code.
  • Validation en continu de la configuration et de la syntaxe de l'architecture déployable pour garantir l'exactitude et la cohérence.
Pipeline CI
Un pipeline d'EC doit être configuré pour automatiser ces pratiques, en veillant à ce que chaque changement de code dans l'architecture déployable soit systématiquement testé et validé. Ce pipeline garantit que l'architecture déployable fonctionne correctement et de manière cohérente, et que les erreurs ou les incidents sont interceptés de manière précoce.

Outils et ressources

Un ensemble complet d'outils et de ressources est fourni pour faciliter la création d'architectures déployables de haute qualité. Les modules Terraform organisés sont un élément clé, avec plus de 60 modules réutilisables, sécurisés et validés qui couvrent un large éventail de besoins en infrastructure. Ces modules sont disponibles sur GitHub et sont pris en charge et maintenus à jour via un modèle de contribution open source, et soutenus par des contributions de l'organisation de développement IBM Cloud.

Outre les modules Terraform organisés, les meilleures pratiques et les modèles sont également fournis pour faciliter la création de modules et l'architecture déployable. Cela inclut la documentation, un modèle de référentiel d'architecture déployableGitHub aligné sur les meilleures pratiques de création et des instructions de création de module qui s'appliquent aux modules Terraform et aux architectures déployables basées sur Terraform. Ces ressources peuvent être utilisées pour démarrer rapidement sur une nouvelle architecture déployable.

Un cadre de test automatisé est également fourni, et basé sur la bibliothèque Terratest, avec des tests écrits en Go. Le cadre couvre les tests d'idempotence, les tests de mise à niveau et GitHub, et utilise les fonctions d'aide aux tests de la bibliothèque https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper. Pour plus d'informations, voir notre documentation de test.

Pour prendre en charge le développement de pipelines d'EC, une gamme d'outils et de ressources sont disponibles, notamment:

  • Actions GitHub réutilisables.
  • Génération automatisée de la documentation.
  • Intégration automatisée à IBM Cloud.
  • Mises à jour de dépendance automatisées à l'aide de la rénovation personnalisée.
  • Les outils de configuration de développement local et la configuration des points d'ancrage de pré-validation, voir notre documentation de configuration de développement local pour plus d'informations.

Ces outils et ressources sont conçus pour accélérer et faciliter la création d'architectures déployables de haute qualité.

Etapes suivantes

Maintenant que vous comprenez les meilleures pratiques de génération d'une architecture déployable, vous pouvez utiliser les outils et les ressources et consulter la documentation IBM Cloud suivante avant de développer votre code d'automatisation. Cela vous permet de planifier et de concevoir de manière approfondie votre solution à partager dans IBM Cloud: