Modèle de données CDM

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 11 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é et CSDM. CDM importe des données de configuration existantes, les valide à l’aide de politiques que vous définissez et exporte des données de configuration valides vers le pipeline existant DevOps de votre organisation pour implémenter des applications, des services et une infrastructure.

    Important :
    DevOps Config est désormais obsolète et n’est plus pris en charge ni disponible pour une nouvelle activation.

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

    Le CDM modèle de données ne change pas votre façon de penser à la configuration. Au lieu de cela, vous utilisez l’API REST et l’interface CDM utilisateur pour mapper vos données JSON, YAML, INI, XML et autres données de configuration 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 des 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.
    • Vous permet de réutiliser les structures de données de configuration à l’aide de variables, y compris de valeurs, et en superposant des valeurs.

    Structure du modèle de CDM données

    Une application dans CDM est la collection complète de données de configuration pour un service d’application, un modèle d’application ou groupe de CI dynamique 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 combinez les collections dans un déployable - un ensemble 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 du dossier d’une nouvelle CDM application

    Composants
    Les composants sont les blocs de construction qui représentent généralement les données de configuration d’un élément logique d’une application ou d’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 des 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 de 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 Variables de composants
    Le dossier 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 .
    Collectes

    Une collection est l’ensemble des composants qui, ensemble, définissent une mise en production : vous pouvez considérer une collection comme une composition de mise en production.

    Une collection peut inclure des paramètres variables ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration de machine virtuelle utilisées dans la version 1 sont différentes des données utilisées dans la version 2. release-1 peut utiliser la valeur 2 Go 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. Ces 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 de composants ou de versions de composants qui représentent la fonctionnalité de la version 2.0 de l’application. En revanche, une collection nommée collection-3 qui représente la fonctionnalité Release 3.0 peut inclure le même ensemble de composants ou de versions de composants, de composants ou de versions de composants supplémentaires et d’autres paramètres de variables, de remplacement et de superposition.

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

    Vous ajoutez et configurez des déployables dans la structure des 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. Chacune déployable dans une application représente la configuration d’un service dans le CMDB.

    Un déployable est constitué d’une collection ou d’un ensemble de collections qui définissent la mise en production d’un environnement particulier. La combinaison collections+environnement lien vers un service d’application dans le ou vers un service d’infrastructure CMDB .

    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éployable nom PROD-2 inclurait également la collection collection-2 mais, à la place, spécifierait des paramètres spécifiques à l’environnement de production pour la version 2.0.

    Lorsqu’un ensemble de changements vous convient, vous pouvez enregistrer et valider les changements. Le système recherche les conflits avec les ensembles de changements validés d’autres utilisateurs. S’il n’y a pas de conflit, le système conserve les changements et génère ensuite 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 exportable potentiel. 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 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 collecte.

    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 collections 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 2 de Core de l’application qui est actuellement en cours de développement et de test. FS1, en revanche, contient l’ancienne version Core 1 qui a été testée de manière approfondie 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 .VM template Les collections FS1 et FS2 héritent donc de ces deux composantes. É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 collection de données de configuration qui avaient été validées 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). Le déployable TEST, cependant, spécifie l’une des bases de données utilisées par l’équipe de test, test3.

    Ce diagramme est simplifié. Dans votre implémentation, déployables peut inclure plusieurs collections, paramètres de variables et de remplacement, et 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 un simple 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 (feuilles)
    • Les CDI et les variables sont des éléments de valeur clé. 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.
    Remarque :

    Gestion des données de configuration À partir de la version 4.2, vous pouvez définir un nœud à l’aide de n’importe quel caractère UTF-8, y compris la barre oblique (/).

    Chemin d’accès au nom
    Le chemin du nom est le chemin du dossier complet du nœud sélectionné dans la liste. Dans l’API REST, vous pouvez fournir un chemin d’accès au nom dans un tableau aux formats suivants :
    • Format de barre oblique inverse : par exemple : testApp/deployables/Development1/cdi1
      Remarque :
      Si le nom de votre nœud contient une barre oblique inverse (« / »), vous ne pouvez pas utiliser ce format.
    • Chemin d’accès du nom du back-end avec des caractères de remplacement : Par exemple : testApp deployables Development1 cdi1
    • Tableau : par exemple : ['testApp','deployables','Development1','cdi1']
    Composants
    Les composants sont les blocs de construction qui représentent généralement les données de configuration d’un élément logique d’une application ou d’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 des collections et déployables. Des instructions plus détaillées apparaissent dans .Définir ou mettre à jour un composant

    Collectes

    Une collection est l’ensemble des composants qui, ensemble, définissent une mise en production : vous pouvez considérer une collection comme une composition de mise en production.

    Une collection peut contenir des paramètres variables ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration de machine virtuelle utilisées dans la version 1 sont différentes des données utilisées dans la version 2. release-1 peut utiliser la valeur 2 Go 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 ensemble 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. Chaque déployable élément d’une application configure un service dans le CMDB. 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 de collections qui définissent la mise en production d’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 des modifications dans une CDM application, le système les conserve en tant qu’ensemble de modifications de l’application. Le système génère également un instantané de chaque élément déployable affecté par les changements. Un instantané représente un ensemble de données de configuration exportable potentiel. 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.

    Nœuds de fichiers
    Un nœud de fichier est créé lorsque vous attachez un fichier au modèle de données de configuration d’une CDM application ou d’une bibliothèque de composants. Il contient un lien vers le fichier joint. À l’aide des nœuds de fichier, vous pouvez joindre des fichiers de n’importe quel type MIME pris en charge dans ServiceNow AI Platform.