Modèle de données CDM

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 11 minutes de lecture

    • Le modèle de données CDM est une structure de données standardisée qui prend en charge le cycle de vie plus global de la livraison de logiciels : automatisation, validation de la qualité et CSDM. 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 DevOps existant de votre entreprise 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.

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

    Le modèle de données CDM ne change pas votre façon de concevoir la configuration. Vous utilisez plutôt l'API REST CDM et l'interface 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.
    • 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 données CDM

    Une 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 d'une groupe de CI dynamique [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 élément 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 élément déployable est un nœud dans la structure.

    Structure de dossiers pour une nouvelle application CDM

    Composants
    Les composants sont les blocs de base 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 dans 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 éléments 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. Le développement utilise la valeur de variable de base de données par défaut. Le test, en revanche, utilise une valeur différente qui convient à l'environnement de test.
    Dossier des variables de composants
    Le dossier des variables de 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 version. Vous pouvez considérer une collection comme une composition de version.

    Une collection peut inclure des paramètres de variable ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration de VM utilisées dans la version-1 sont différentes de celles utilisées dans la version-2. La version-1 peut utiliser la valeur 2Gb pour le paramètre de mémoire (« memory » : « 2Gb ») et la version-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 des 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 composants qui représentent la fonctionnalité version 2.0 pour l'application. En revanche, une collection nommée collection-3 qui représente la fonctionnalité version 3.0 peut inclure le même ensemble de composants ou de versions de composants, des composants ou des versions de composants supplémentaires, ainsi que d'autres paramètres de variable, de remplacement et de superposition.

    Dossier des variables de collections
    Le dossier des 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é supérieure à celle d'une variable de composant.
    Déployables

    Vous ajoutez et configurez des éléments déployables dans la structure de données. Un 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. Chaque déployable dans une application représente la configuration d'un service dans le CMDB.

    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.

    Un déployable peut inclure des paramètres de variable 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 l'déployable de production 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 nommé PROD-2 inclurait également la collection collection-2 mais spécifierait plutôt 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 changements, puis génère un instantané de tous les déployable affectés par ceux-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'éléments déployables
    Le dossier des variables d'éléments déployables peut contenir des variables que n'importe quel CDI du dossier Éléments déployables peut utiliser. Chaque élément déployable dispose d'un dossier de variables d'éléments déployables. Une variable d'élément déployable a une priorité plus élevée qu'une variable de collection.

    Exemple

    Dans le diagramme suivant de l'exemple d'application Librairie, 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 Core 2 de l'application qui est actuellement en cours de développement et de test. FS1, en revanche, contient la version antérieure 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 tests) 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 particulier. 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 élément déployable comprend la collection adaptée à son environnement (développement, test ou production). Dans l'exemple, l'élément 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 tests. L'élément déployable PROD, en revanche, utilise FS1 dans l'environnement de production. FS1 est la version antérieure de la collection des données de configuration qui avait été validée pour la production.

      Dans chaque élément déployable, les variables sont définies sur des valeurs adapté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 peut inclure plusieurs collections, des paramètres de variable et de remplacement, ainsi que des paramètres de superposition (paramètres qui n'apparaissent pas dans les composants et collections qui composent l'élément déployable). En outre, vous pouvez avoir plusieurs éléments déployables pour chaque type d'environnement.

    Comment les composants et les collections fournissent du contenu que vous pouvez intégrer dans des éléments 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.
    Remarque :

    À partir de Gestion des données de configuration 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 du nom
    Le chemin d'accès du nom est le chemin d'accès complet au dossier du nœud sélectionné dans la liste. Dans l'API REST, vous pouvez fournir le chemin d'accès au nom sous forme de tableau dans les formats suivants :
    • Format avec 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 au nom du back-end avec caractères de remplacement : par exemple : testApp�deployables�Development1�cdi1
    • Tableau : par exemple :['testApp','deployables','Development1','cdi1']
    Composants
    Les composants sont les blocs de base 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 dans déployables. Pour des instructions plus détaillées, consultez Définir ou mettre à jour un composant.

    Collectes

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

    Une collection peut contenir des paramètres de variable ou de remplacement spécifiques à une version particulière. Par exemple, les données de configuration de VM utilisées dans la version-1 sont différentes de celles utilisées dans la version-2. La version-1 peut utiliser la valeur 2Gb pour le paramètre de mémoire (« memory » : « 2Gb ») et la version-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

    Un 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. Chaque déployable dans une application configure un service dans le CMDB. Par exemple, vous pouvez créer trois éléments déployables, un pour chaque type d'environnement : Développement, Test et Production.

    Un 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.

    Un déployable peut contenir des paramètres de variable 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 l'déployable de production 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 application CDM, 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 chaque déployable affecté 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
    Les composants partagés dans Gestion des données de configuration vous permettent 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 joignez un fichier au modèle de données de configuration d'une application CDM ou d'une bibliothèque de composants. Il contient un lien vers le fichier joint. À l'aide de nœuds de fichiers, vous pouvez joindre des fichiers de n'importe quel type MIME pris en charge sur ServiceNow AI Platform.