Comment choisir le type de composant à créer?
Comment décidez-vous de créer un module, une architecture déployable ou d'empiler des architectures déployables? Comparons les différences et évaluons les cas d'utilisation dans les sections suivantes pour vous aider à décider.
Comparaison des architectures et des modules déployables
Le tableau suivant fournit une comparaison et un récapitulatif rapide des principales différences entre les modules et les types d'architectures déployables.
| Méthode | Portée | couplage | Déployable | Auteur |
|---|---|---|---|---|
| Créer un module | Etroit | serré | Non | Développeur |
| Créer une architecture déployable | Moyen à large | serré | Oui | Développeur |
| Architectures déployables de la pile | Broad | Desserré | Oui | Tout le monde |
Le tableau suivant peut vous aider à décider si vous devez utiliser un module, une architecture déployable ou une pile d'architectures déployables en fonction de votre cas d'utilisation.
| Objectif | Méthode recommandée | Remarques |
|---|---|---|
| Accélérez l'automatisation du codage | Utiliser des modules | Les modules fournissent une automatisation réutilisable et organisée pour que les développeurs d'architectures déployables codent plus rapidement. Les modules sont destinés aux développeurs et non aux consommateurs. |
| Vérifiez que le cloud est sécurisé et conforme | Utiliser une architecture déployable | Les architectures déployables appliquent la sécurité et la conformité pour une architecture. Si une architecture déployable est trop petite dans la portée, elle ne peut pas imposer la conformité. Par exemple, une architecture déployable qui déploie uniquement une instance de serveur virtuel ne peut pas garantir la sécurité du réseau. |
| Donner aux utilisateurs un choix avec des glissières de sécurité | Empiler des architectures déployables | En empilant des architectures déployables, vous pouvez échanger des architectures déployables ou ajouter des architectures déployables et offrir plus de choix aux utilisateurs. Etant donné que les architectures déployables appliquent la sécurité et la conformité, l'empilement permet de garantir la conformité de la solution globale. L'empilement d'architectures déployables est une excellente approche pour des questions telles que le choix de la base de données à utiliser. |
| Solutions ou architectures créées par l'utilisateur | Empiler des architectures déployables | L'empilement d'architectures déployables permet aux utilisateurs de créer et de publier leurs propres modèles reproductibles qui restent sûrs, car ils sont composés d'architectures déployables sûres et conformes. |
| Composants d'architecture découplés | Empiler des architectures déployables | Les architectures déployables peuvent être développées et mises à jour de manière indépendante, puis empilées pour être déployées. |
| Expérience utilisateur simplifiée | Utiliser une architecture déployable | Les architectures déployables peuvent fournir une liste réduite ou simple d'entrées à l'utilisateur, même pour des architectures volumineuses ou complexes. Les architectures déployables sont simples à comprendre et à déployer. En comparaison, l'empilement des architectures déployables est un peu plus complexe à mesure que les architectures déployables sont exposées. |
Les projetsIBM Cloud garantissent que les ressources sont déployées via des architectures déployables à partir du catalogue et fonctionnent dans les glissières de sécurité et de conformité de l'organisation. Ils veillent également à ce que ces ressources soient mises à jour et à ce qu'elles ne dérivent pas.
Dépendances pour les architectures déployables
Des dépendances apparaissent lorsque les ressources provisionnées par une architecture déployable sont requises par une autre. Autrement dit, les ressources fournies par une architecture déployable sont utilisées lors du déploiement d’une autre architecture, comme illustré dans l’image suivante.
Une façon de travailler avec les dépendances est d' empiler des architectures déployables et d'ajouter des références entre elles dans un projet. Par exemple, l'architecture déployable VSI on VPC landing zone inclut une variante qui étend l'architecture déployable de la zone d'atterrissage Red Hat OpenShift Container Platform sur VPC landing zone. Envisagez d'empiler ces architectures dans un projet. Cette approche fonctionne bien si l'architecture prérequise n'est pas encore déployée. Vous n'avez pas non plus besoin de modifier le code pour empiler les architectures déployables.
De nombreuses architectures déployables sont autonomes et ne sont pas des extensions d'autres architectures, mais vous pouvez choisir d'étendre certaines architectures déployables dans le Architecture section de la page de détails du catalogue. Sélectionnez une option dans le Comment voulez-vous construire cette architecture ? menu.
Cependant, si vous avez déjà déployé Red Hat OpenShift Container Platform et que vous devez déployer VSI, les ressources requises pour VSI sont déjà provisionnées. Vous n'avez pas besoin de déployer le Red Hat OpenShift Encore une fois l’architecture de Container Platform. Puisque l'architecture VSI est une extension du Red Hat OpenShift Container Platform, vous pouvez déployer VSI et l'architecture utilise les ressources du Red Hat OpenShift Plateforme de conteneurs selon les besoins.
Architectures déployables optionnelles et interchangeables
Lorsque vous intégrez une architecture déployable à un catalogue privé, vous pouvez l'étendre en l'associant à d'autres architectures. Vous pouvez ainsi créer une solution plus personnalisable pour vos utilisateurs.
- Pourquoi empiler les données lors de l'accueil des nouveaux arrivants?
- L'empilement des architectures lors de l'onboarding est similaire à l'empilement des architectures dans un projet. Lorsque vous intégrez une architecture, vous pouvez inclure des dépendances en empilant les architectures requises. Toutefois,
contrairement à l'empilement des architectures dans un projet, l'empilement des architectures lors de l'intégration comprend les fonctionnalités suivantes :
- Vous pouvez ajouter des architectures optionnelles adaptées à différents cas d'utilisation.
- Vous pouvez ajouter des architectures interchangeables entre lesquelles les utilisateurs peuvent choisir.
- Architectures optionnelles
- Il se peut que votre architecture fonctionne bien avec une autre architecture déployable, mais qu'elle ne soit pas nécessaire pour répondre à une dépendance ou satisfaire à la conformité. Vous pouvez ajouter l'architecture déployable en tant qu'option, et les utilisateurs peuvent choisir de l'inclure lorsqu'ils ajoutent votre architecture déployable à un projet. Par exemple, une architecture de surveillance peut être utile mais pas nécessaire.
- Architectures interchangeables
- Toute architecture que vous empilez avec la vôtre lors de l'onboarding peut être échangée avec d'autres architectures. Les architectures interchangeables permettent aux utilisateurs de choisir entre plusieurs options qui offrent la même fonctionnalité. Par exemple, vous pouvez inclure deux architectures déployables qui créent des bases de données différentes, et l'utilisateur peut décider de l'option de base de données qu'il souhaite utiliser avec votre architecture.
Pour plus d'informations, voir Extension d'une architecture déployable pendant l'onboarding.
Des architectures optionnelles et interchangeables peuvent être ajoutées au fur et à mesure que vous intégrez une architecture déployable dans un catalogue privé. Actuellement, l'empilement d'architectures déployables dans un projet ne prend pas en charge les architectures optionnelles ou interchangeables.
Terraform et Ansible
Dans IBM Cloud, une architecture déployable doit utiliser Terraform pour déclarer les entrées et les sorties de l'architecture déployable (l'interface) car Ansible ne possède pas de définition d'interface lisible par la machine. Sinon, l'auteur d'une architecture déployable peut utiliser n'importe quelle combinaison de préscripts ou de post-scripts Ansible et de Terraform pour exécuter le travail de l'architecture déployable. Alors, comment un développeur décide-t-il quelle technologie utiliser et pour quoi?
| Terraform | Ansible | |
|---|---|---|
| Langue | Déclaratif | Procédure |
| Syntaxe | HCL (similaire à JSON) | YAML (et appels à d'autres scripts) |
| Approche par défaut | Infrastructure modifiable | Infrastructure immuable |
| Focaliser | Infrastructure | Configuration |
| Dérive | Comparaison avec l'état souhaité | Tâches idempotent |
Terraform est excellent pour la création et la gestion de l'infrastructure, tandis que Ansible est excellent pour la configuration des logiciels et des systèmes d'exploitation qui s'exécutent sur cette infrastructure. Etant donné que Ansible est procédural, vous pouvez également effectuer des opérations uniques de script. Les tâches de maintenance, telles que la restauration à partir d'une sauvegarde, sont faciles dans Ansible.
| Objectif | Langue de configuration recommandée | Remarques |
|---|---|---|
| Déployez l'infrastructure ou les services de cloud | Terraform | Terraform cible ce cas d'utilisation et est mieux à même de gérer l'évolution de l'infrastructure. IBM Cloud fournit des modules Terraform et des architectures déployables prises en charge pour accélérer les canevas d'infrastructure sécurisés et conformes. Le modèle d'état Terraform permet aux développeurs de prévisualiser les modifications. Ces modifications peuvent être analysées à des fins de conformité. |
| Installer ou configurer des logiciels | Ansible | Si une image de machine virtuelle ou de conteneur préconfigurée n'est pas adaptée au cas d'utilisation, Ansible est mieux adapté à la gestion de l'installation et de la configuration du logiciel. Ansible offre une prise en charge étendue des opérations automatisées telles que les éditions de configuration, la gestion de package et les redémarrages de processus. Une grande bibliothèque de modules et de protocoles Ansible est disponible pour faciliter la configuration de milliers de progiciels couramment utilisés. |
| Intégration de la base de données centrale | Ansible | La création d'un appel dynamique à un service sur site tel qu'une base de données CCDB peut être effectuée dans Terraform ou Ansible, mais elle est plus facile à effectuer dans un langage de procédure ou de script. |
| Validation de l'entrée | Terraform ou Ansible | Terraform a une capacité limitée à effectuer la validation des entrées, mais il est déclaratif et peut être utilisé par les interfaces utilisateur. Ansible ajoute la possibilité d'effectuer une validation d'entrée dynamique où les entrées d'une architecture déployable sont vérifiées par rapport à un service distant. |
| Actions de maintenance du jour 2 | Ansible | La maintenance du jour 2 est généralement de nature procédurale et doit être effectuée au mieux dans Ansible. Par exemple, la sauvegarde manuelle, la restauration ou les rotations de clés. |
| Gestion de la dérive |
|
|
Pour plus d'informations sur l'inclusion de préscripts ou de post-scripts avec vos architectures déployables, voir Création de scripts pour l'architecture déployable.
Prochaines étapes: Détermination de l'emplacement de publication
Une fois que vous avez planifié votre architecture et déterminé le type de composant à créer, vous devez déterminer où vous prévoyez de partager ou de publier votre solution, afin que les autres utilisateurs puissent tirer parti de la solution que vous créez. Selon l'endroit où vous prévoyez de partager ou de publier, vous pouvez avoir différents niveaux d'exigences ou d'approbations à exécuter.