Préparation d'une application pour le chargement des données de configuration

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 5 minutes de lecture
  • 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. Une fois que vous avez chargé vos données de configuration source, l'application peut prendre en charge toutes les éventuelles déployables qui composent chaque version des environnements de développement, de test et de production du service.

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

    Vue d'ensemble : préparation d'une application pour accepter les données de configuration chargées

    Vous suivez ce processus général pour préparer une application afin d'accepter le chargement des données de configuration :
    1. Dans l'onglet Applications, vous, un utilisateur disposant du rôle Administrateur CDM [sn_cdm.cdm_admin], créez un enregistrement d'application.

      Le système génère une application qui comprend plusieurs dossiers standard dans une structure hiérarchique. Vous allez mapper vos données de configuration existantes dans cette structure des données pour activer les avantages décrits dans Modèle de données CDM.

      Structure des données pour une nouvelle application. Vous allez ajouter vos données de configuration en tant que nœuds dans le dossier approprié

      L'application prend en charge la création de plusieurs déployables. Par exemple, vous pouvez créer un déployable pour chaque environnement type : Développement, Test et Production. Vous pouvez également créer plusieurs versions de chaque déployable pour chaque type d'environnement.

    2. En travaillant dans l'éditeur de code CDM, vous créez maintenant un ensemble de changements, c'est-à-dire une copie brouillon de l'application que vous pouvez modifier.
    3. Tout en travaillant dans l'ensemble de changements, vous créez les types de nœuds suivants dans les dossiers appropriés. Ce processus modélise les données de configuration, c'est-à-dire qu'il prépare l'application à mapper vos données de configuration sources dans la structure des données CDM.
      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 (/).

    4. Maintenant que la structure est en place, vous utilisez les API REST ou le panneau d'édition de code CDM pour charger vos données de configuration existantes dans l'ensemble de changements. Le processus est décrit dans Chargement de vos données de configuration. Pour plus d'informations, consultez CdmApplicationsAPI, CdmChangesetsAPI et CdmSnapshoAPI.
      Remarque :
      Si vous chargez un fichier XML ou CSV pour importer vos données de configuration existantes dans CDM, l'analyseur CDM analyse les données d'une manière spécifique. Pour plus d'informations, consultez Analyse des fichiers XML dans CDM et Analyse de fichiers CSV dans CDM.
      Vous pouvez charger les types de jeux de données suivants : variables de composants, composants, collections et éléments déployables.
      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.

    5. Une fois les données chargées, vous revenez à CDM. Vous mettez à jour les valeurs de variable et de remplacement afin que l'ensemble relativement restreint de composants et de collections puisse fournir des données de configuration pour les trois environnements déployable. 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.
    6. Maintenant, enregistrez et validez l'ensemble de changements. Le système effectue les actions suivantes :
      • Déterminer s'il existe des conflits avec d'autres validations antérieures. Si le système signale un conflit, vous devez le résoudre et valider à nouveau ou créer un ensemble de changements et effectuer à nouveau vos changements. Pour plus d'informations sur la résolution des conflits, consultez Conflits entre les validations de l'ensemble de changements.
      • Pousser tous les changements dans le modèle de données de l'application (les données de configuration sont conservées).
      • Générer un instantané de chaque déployable affecté par les changements apportés à l'ensemble de changements. Le système valide les données de configuration en exécutant des politiques spécifiées par rapport à un instantané. Au moment où l'instantané est créé, il peut être publié et utilisé pour exporter les données de configuration. Les instantanés sont des enregistrements permanents qui ne peuvent pas être modifiés.
    Les données de configuration source sont maintenant conservées dans des tables CDM. Vous pouvez maintenant gérer les données selon vos besoins : mapper des politiques à chaque déployable afin que les instantanés puissent être validés, valider les données dans un instantané (appliquer les politiques), exporter des données de configuration, etc.
    Remarque :
    Vous pouvez mapper des politiques à un déployable vide, mais ce n'est pas une procédure classique.