Modèle de données CDM

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 10 minutes de lecture
  • Le CDM modèle de données est une structure de données standardisée qui prend en charge le cycle de vie plus large de la livraison de logiciels : automatisation, validation de la qualité, CSDMetc. CDM importe les données de configuration existantes, les valide à l’aide de politiques que vous définissez et exporte les données de configuration valides vers le pipeline existant DevOps de votre entreprise pour implémenter des applications, des services et une infrastructure.

    Important :
    À partir de la version Washington DC, DevOps Config ne sera plus disponible. L'application sera masquée et ne sera plus installée sur les nouvelles instances, mais continuera d'être prise en charge. Pour en savoir plus, consultez l'article Processus de retrait [KB0867184] dans la base de connaissances Now Support.

    CDM Vue d’ensemble du modèle de données

    Le CDM modèle de données ne change pas votre façon de concevoir la configuration. Vous utilisez plutôt l’API REST et l’interface CDM utilisateur pour mapper vos données de configuration JSON, YAML, INI, XML et autres existantes dans une structure de données intuitive qui offre les avantages suivants :
    • Met en œuvre un contrôle rigoureux et transparent des versions et des changements.
    • Vous permet de chiffrer les données sensibles et assure un contrôle d’accès approprié pour les données.
    • Active la validation automatisée des données de configuration.
    • Permet de réutiliser les structures de données de configuration à l’aide de variables, y compris des valeurs, et des valeurs de superposition.

    Structure du modèle de CDM données

    Un application dans CDM est la collection complète de données de configuration d’un service d’application, d’un modèle d’application ou groupe de CI dynamique d’une [infrastructure] dans le CMDB. L’utilisateur CDM crée un enregistrement d’application qui inclut les dossiers vides suivants dans une structure hiérarchique standard. Une fois que le système a ingéré vos données de configuration existantes, vous structurez les données en composants dans le dossier approprié. Vous créez des collections de composants, puis vous combinez les collections dans un déployable , c’est-à-dire un jeu de données de configuration (pour un environnement de développement, de test ou de production) qui peut être déployé par votre processus de livraison. Chaque composant, collection, variable et déployable est un nœud dans la structure.

    Structure des dossiers d’une nouvelle CDM application

    Composants
    Les composants sont les blocs de construction qui représentent généralement les données de configuration pour un élément logique d’une application ou une partie d’un service d’infrastructure. Par exemple, une application monolithique, un micro-service, un serveur physique ou un modèle Docker.

    Un composant peut inclure des composants descendants, directs ou inclus. Un composant peut inclure des variables qui peuvent prendre différentes valeurs dans les collections et déployables.

    Vous pouvez regrouper des composants dans une bibliothèque de composants partagés.

    Conseil :
    Il est souvent utile de définir une valeur par défaut pour une variable dans un composant ou une collection. Il s’agit d’une stratégie puissante, car vous pouvez créer une grande variété d’éléments déployables à partir d’un petit ensemble de composants et de collections. Les déployables qui héritent d’un composant ou d’une collection peuvent utiliser des remplacements, des superpositions et des paramètres variables pour répondre aux besoins du type d’environnement. Par exemple, le développement déployable peut utiliser les mêmes composants et collections que le test déployable. Développement utilise la valeur de variable de base de données par défaut. Test, en revanche, utilise une valeur différente qui convient à l’environnement de test.
    Dossier des variables des composants
    Le dossier des variables des composants peut contenir des variables que n’importe quel CDI du dossier Composants peut utiliser. Il n’existe qu’un seul dossier de variables de composants .
    Collections

    Une collection est l’ensemble des composants qui, ensemble, définissent une version. Vous pouvez considérer une collection comme une composition de sortie.

    Une collection peut inclure des paramètres variables ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration d’ordinateur virtuel utilisées dans la version-1 sont différentes de celles utilisées dans la version-2. release-1 peut utiliser la valeur 2Gb pour le paramètre de mémoire (« memory » : « 2Gb ») et release-2 peut spécifier une valeur différente (« memory » : « 4Gb »). En outre, une collection peut inclure des paramètres de configuration qui n’apparaissent pas dans ses composants. De telles valeurs sont appelées superpositions.

    Une collection peut représenter une version particulière d’une application, d’une localisation ou d’un ensemble de fonctionnalités. Par exemple, une collection nommée collection-2 peut inclure l’ensemble des composants ou des versions de composant qui représentent la fonctionnalité de la version 2.0 pour l’application. En revanche, une collection nommée collection-3 qui représente la fonctionnalité de la version 3.0 peut inclure le même ensemble de composants ou de versions de composants, des composants supplémentaires ou des versions de composants, ainsi que d’autres paramètres variables, de remplacement et de superposition.

    Dossier des variables des collections
    Le dossier de variables de collection peut contenir des variables que n’importe quel CDI du dossier Collections peut utiliser. Chaque collection dispose d’un dossier Vars de collection. Une variable de collection a une priorité supérieure à celle d’une variable de composant.
    Déployables

    Vous ajoutez et configurez des déployables dans la structure de données. A déployable est un jeu de données de configuration (pour un environnement DEV, TEST ou PROD) qui peut être déployé par votre processus de livraison. Chacun déployable dans une application représente la configuration d’un service dans le CMDBfichier .

    Un élément déployable est constitué de la collection ou de l’ensemble des collections qui définissent la version pour un environnement particulier. La combinaison collections + environnement est liée à un service d’application dans le CMDB ou à un service d’infrastructure.

    A déployable peut inclure des paramètres variables ou de remplacement spécifiques à l’environnement. Par exemple, la variable de base de données a une valeur dans l’environnement de développement et une valeur différente dans l’environnement de production. Une valeur de remplacement dans la production déployable peut spécifier un paramètre de conteneur requis qui n’est pas nécessaire dans l’environnement de développement.

    Un exemple déployable nommé DEV-2 inclurait la collection collection-2 et spécifierait les paramètres de variable, de remplacement et de superposition spécifiques à l’environnement de développement de la version 2.0. En revanche, le déployablePROD-2 nommé inclurait également la collection collection-2 mais, à la place, spécifierait des paramètres spécifiques à l’environnement de production de la version 2.0.

    Lorsque vous êtes satisfait d’un ensemble de changements, vous pouvez enregistrer et valider les changements. Le système vérifie les conflits avec les ensembles de changements validés par d’autres utilisateurs. S’il n’y a pas de conflit, le système conserve les modifications, puis génère un instantané de toutes les déployable modifications affectées par celles-ci. Un instantané représente un ensemble de données de configuration potentiellement exportable. Le système valide les données de configuration en exécutant des politiques sur chaque instantané et en renvoyant les résultats de validation.

    Dossier des variables déployables
    Le dossier des variables déployables peut contenir des variables que n’importe quel CDI du dossier Déployables peut utiliser. Chaque déployable dispose d’un dossier Vars déployable. Une variable déployable a une priorité plus élevée qu’une variable de collection.

    Exemple

    Dans le diagramme suivant de l’exemple d’application BookStore, les nombres identifient les relations entre les composants, les collections et déployables.
    1. Les composants sont regroupés pour former des ensembles qui représentent des environnements ou des versions d’environnements. La collection FS2 (ensemble de fonctionnalités 2) contient des données de configuration pour la version Core 2 de l’application qui est actuellement en cours de développement et de test. FS1, en revanche, contient la version antérieure de Core 1 qui a été minutieusement testée et qui exécute actuellement l’application dans l’environnement de production.
    2. Dans l’exemple, FS2 (la collection utilisée dans les environnements de test) et FS1 (la collection utilisée dans l’environnement de production) utilisent des données de configuration pour les deux S3 et un domaine particulier VM template. Les collections FS1 et FS2 héritent donc toutes deux de ces deux composants. Étant donné que les collections représentent des ensembles de fonctionnalités différents, il est probable que FS1 et FS2 utilisent des variables ou des remplacements pour spécifier quelques paramètres différents pour les composants.
    3. Chaque déployable comprend la collection adaptée à son environnement (développement, test ou production). Dans l’exemple, le déployable TEST utilise la collection FS2, la version la plus récente de l’ensemble de fonctionnalités et d’autres paramètres de configuration utilisés dans les environnements de test. Le déployable PROD, en revanche, utilise FS1 dans l’environnement de production. FS1 est la version antérieure de la collecte des données de configuration qui avait été validée pour la production.

      Dans chaque déployable, les variables sont définies sur des valeurs appropriées à l’environnement. Par exemple, dans PROD, la variable de base de données est définie sur prod1 (la base de données de production). L’élément déployable TEST, quant à lui, spécifie l’une des bases de données utilisée par l’équipe de test, test3.

    Ce diagramme est simplifié. Dans votre implémentation, déployables il est possible d’inclure plusieurs collections, des paramètres variables et de remplacement, ainsi que des paramètres de superposition (paramètres qui n’apparaissent pas dans les composants et collections qui composent le déployable). En outre, vous pouvez avoir plusieurs déployables pour chaque type d’environnement.

    Comment les composants et les collections fournissent du contenu que vous pouvez intégrer dans des déployables pour une variété d’environnements

    Définitions

    CDI
    Un élément de données de configuration (CDI) est simplement un nœud clé-valeur.
    Variable
    Une variable est un élément clé-valeur qui peut être référencé dans un CDI.
    Nœuds parents et nœuds enfants (terminaux)
    • Les CDI et les variables sont des éléments clé-valeur. Les CDI et les variables ne peuvent être que des nœuds enfants.
    • Les nœuds de composants, de collections, d’éléments déployables et de dossiers peuvent être des nœuds parents, c’est-à-dire des nœuds qui peuvent avoir des éléments clé-valeur ou d’autres nœuds parents.
    Composants
    Les composants sont les blocs de construction qui représentent généralement les données de configuration pour un élément logique d’une application ou une partie d’un service d’infrastructure. Par exemple, une application monolithique, un micro-service, un serveur physique ou un modèle Docker.

    Un composant peut contenir des variables qui peuvent prendre différentes valeurs dans les collections et déployables. Des instructions plus détaillées apparaissent dans Définir ou mettre à jour un composant.

    Collections

    Une collection est l’ensemble des composants qui, ensemble, définissent une version. Vous pouvez considérer une collection comme une composition de sortie.

    Une collection peut contenir des paramètres variables ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration d’ordinateur virtuel utilisées dans la version-1 sont différentes de celles utilisées dans la version-2. release-1 peut utiliser la valeur 2Gb pour le paramètre de mémoire (« memory » : « 2Gb ») et release-2 peut spécifier une valeur différente (« memory » : « 4Gb »). En outre, une collection peut inclure des paramètres de configuration qui n’apparaissent pas dans ses composants. Vous pourriez considérer ces valeurs comme des « superpositions ».

    Déployables

    A déployable est un jeu de données de configuration (pour un environnement de développement, de test ou de production) qui peut être déployé dans votre pipeline CI/CD en tant que service. Chacun déployable dans une application configure un service dans le CMDBfichier . Par exemple, vous pouvez créer trois déployables, un pour chaque type d’environnement : Développement, Test et Production.

    A déployable est constitué de la collection ou de l’ensemble des collections qui définissent la mise en production pour un environnement particulier. La combinaison collections + environnement est liée à un service d’application dans le ou un service d’infrastructure CMDB .

    A déployable peut contenir des paramètres variables ou de remplacement spécifiques à l’environnement. Par exemple, la variable de base de données a une valeur dans l’environnement de développement et une valeur différente dans l’environnement de production. Une valeur de remplacement dans la production déployable peut spécifier un paramètre de conteneur requis qui n’est pas nécessaire dans l’environnement de développement.

    Ensembles de changements et instantanés
    Lorsque vous validez les changements apportés à une CDM application, le système conserve les changements en tant qu’ensemble de changements de l’application. Le système génère également un instantané de tous ceux déployable qui sont affectés par les changements. Un instantané représente un ensemble de données de configuration potentiellement exportable. Le système valide les données de configuration en exécutant des politiques sur chaque instantané et en renvoyant les résultats de validation. Les instantanés qui passent la validation et qui sont publiés peuvent être exportés vers le pipeline de mise en production en tant que données de configuration.
    Composants partagés et bibliothèques de composants
    Composants partagés dans Gestion des données de configuration vous permet d’utiliser un composant dans plusieurs applications.

    Pour une meilleure organisation, ces composants partagés sont gérés dans des bibliothèques de composants. Ces bibliothèques de composants améliorent la cohérence et la maintenabilité en garantissant une source unique de vérité pour les données de configuration d’un composant dans toutes les applications.