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

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 5 minutes de lecture
  • 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. Une fois que vous avez chargé vos données de configuration source, l’application peut prendre en charge tout le potentiel déployables qui compose 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 téléchargées

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

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

      Structure des données d’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 typique : Développement, Test et Production. Vous pouvez également créer plusieurs versions de chacun déployable pour chaque type d’environnement.

    2. Dans l’éditeur de CDM code, vous créez maintenant un ensemble de modifications, une copie brouillon de l’application que vous pouvez modifier.
    3. Lorsque vous travaillez 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 de CDM données.
      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 (/).

    4. Maintenant que la structure est en place, vous utilisez les API REST ou le panneau d’édition de CDM code 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 des fichiers CSV dans CDM.
      Vous pouvez charger les types d’ensembles de données suivants : variables de composant, composants, collections et déployables.
      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émoirememory » : « 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.

    5. Une fois les données chargées, vous revenez à .CDM Vous mettez à jour les valeurs variables et de remplacement afin que l’ensemble relativement petit de composants et de collections puisse fournir des données de configuration pour les trois déployable environnements. 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.
    6. Maintenant, enregistrez et validez l’ensemble de changements. Le système effectue les actions suivantes :
      • Déterminez 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 en savoir plus sur la résolution des conflits, reportez-vous à la section Conflits entre les validations d’ensemble de changements.
      • Transmettre par push tous les changements dans le modèle de données de l’application (les données de configuration sont conservées).
      • Générez un instantané de chaque élément déployable affecté par les changements apportés à l’ensemble de changements. Le système valide les données de configuration en exécutant les 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 CDM tables. Vous pouvez maintenant gérer les données selon vos besoins : mapper les stratégies à chacune déployable afin que les instantanés puissent être validés, valider les données dans un instantané (appliquer les stratégies), exporter les données de configuration, etc.
    Remarque :
    Vous pouvez mapper des stratégies à un vide déployable, mais ce n’est pas une procédure classique.