Clonage d’instances avec AES

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 5 minutes de lecture
  • Découvrez comment protéger les données, les tables et les modèles que vous avez créés lorsque App Engine StudioClone système vous utilisez pour copier des instances de production vers non-production.

    Conservation des données et des tables lors du clonage

    Voici la configuration requise pour cloner des instances avec AES:
    1. Assurez-vous que tous vos AES modules d’extension sont installés dans toutes les instances.
    2. Si vous clonez une instance de production, vérifiez que vous avez configuré un conservateur de données sur les instances cibles pour préserver le (ATF) et Instance Scan les Framework de tests automatisés propriétés. Pour plus d’informations sur les conservateurs de données, voir Create a clone preserver et Create a data preserver (legacy).
      Important :
      Par défaut, la propriété système ATF est désactivée pour vous empêcher d’exécuter accidentellement ces tests sur un système de production. L’exécution d’ATF sur une instance de production n’est ni recommandée ni prise en charge en raison du risque de corruption ou de panne des données.
    3. Si vous collectez des données de développement et de déploiement, le module d’extension App Engine Management Center (AEMC) doit être installé sur toutes les instances.
    Le clonage des données et des tables d’une instance de production sur une instance de non-production peut remplacer les données de vos tables de non-production. Pour vous assurer que les données ne sont pas perdues dans les environnements de développement, créez une stratégie de clonage pour la collaboration.
    1. Les tables suivantes disposent d’une préservation des données pour garantir que les tables sont correctement clonées entre les instances :
      Remarque :
      Pour les tableaux suivants, la conservation concerne uniquement le champ d’application global.
      • Tables de descripteurs de collaboration :
        • Descripteurs de collaboration d’applications (sys_appcollab_descriptor)
        • Autorisations du descripteur de collaboration d’applications (sys_appcollab_permission_m2m)
      • Tables Utilisateurs et groupes de collaboration :
        • Utilisateurs de collaboration d’applications (sys_appcollab_user)
        • Groupes de collaboration d’applications (sys_appcollab_group)
      La préservation des données garantit que les données sont conservées sur les tables dans les instances de développement.
    2. Les tables suivantes ont des exclusions de clone :
      • Tables de descripteurs de collaboration :
        • Descripteurs de collaboration d’applications (sys_appcollab_descriptor)
        • Autorisations du descripteur de collaboration d’applications (sys_appcollab_permission_m2m)
      • Tables Utilisateurs et groupes de collaboration :
        • Utilisateurs de collaboration d’applications (sys_appcollab_user)
        • Groupes de collaboration d’applications (sys_appcollab_group)
      Les exclusions de clones garantissent que les données des instances de production ne sont pas copiées vers les instances de développement.
    3. S’il AES s’agit de la seule application utilisant la table Informations d’identification, envisagez de créer des conservateurs de données pour l’alias d’informations d’identification, l’authentification de base et les informations d’identification de découverte. Sinon, vous devez vous assurer que ces tables ne sont pas écrasées lorsque l’instance de production est clonée vers des instances de non-production.
    4. Les rôles des utilisateurs suivants doivent être réaffectés après le clonage :
      • Utilisateurs du groupe Utilisateurs AES
      • Utilisateurs du AES groupe Utilisateurs limités
      • Utilisateurs disposant du rôle sn_app_eng_studio.user dans les instances de non-production
    5. Après le clonage, un script de nettoyage post-clonage ReSync Collaborations Permissions s’exécute automatiquement, de sorte que toutes les applications qui étaient identiques sur les instances de production et de développement ont automatiquement des collaborateurs synchronisés. Les développeurs peuvent reprendre le développement immédiatement.
      Remarque :
      Le module d’extension de collaboration doit être activé sur l’instance clonée.
    6. Si certaines applications ont été sauvegardées avant le clonage et récupérées après le clonage, vous pouvez utiliser le lien connexe Resynchroniser les autorisations de collaboration sur l’enregistrement sys_app pour réaffecter les utilisateurs et les groupes à leurs autorisations de développement déléguées appropriées.
    7. Si un descripteur de collaboration n’est plus associé à un utilisateur ou à un groupe après le clonage (au cas où les applications de développement auraient été effacées pendant le clonage, car elles ne se trouvaient pas dans l’instance source), sélectionnez le lien connexe Nettoyer les enregistrements avec des références vides pour supprimer l’utilisateur ou le groupe non référencé de la table Collaboration. Vous devez exécuter cette action d’interface utilisateur une fois le clonage terminé et toutes les applications conservées récupérées (avec des autorisations de collaboration Resynchroniser déjà exécutées sur elles).
    Les tables suivantes disposent d’une préservation des données pour garantir que les tables sont correctement clonées entre les instances :
    • Instance de pipeline
    • Clé d'autorisation de demande
    • Demande de déploiement
    • Demande d’environnement de déploiement

    Conservation des modèles d’application lors du clonage

    Les administrateurs doivent empêcher les modèles personnalisés d’être écrasés pendant le processus de clonage. Sans protection, les modèles créés ( AES à la fois à partir d’applications existantes et à partir de zéro) risquent de disparaître lors d’un clone.

    Lorsque vous créez un modèle dans , une application incluse dans le périmètre est automatiquement générée dans AESla table Applications personnalisées [sys_app.list] de votre instance. Bien qu’elles aient des contenus différents, les applications de modèle et les applications personnalisées standard sont traitées de la même manière sur le ServiceNow AI Platform. Ainsi, la conservation des modèles d’application lors d’un clone système fonctionne de la même manière que la préservation d’une application.

    Pour protéger les modèles d’application sur vos instances de non-production, suivez le processus dans Create a clone preserver ou Create a data preserver (legacy).

    Plus d’informations sur le clonage et la conservation des données

    Consultez les rubriques suivantes pour plus d’informations sur le clonage et la préservation des données :
    • Pour plus d’informations sur l’utilisation de cet Clone système outil, reportez-vous à la section Instance Clone.
    • Pour plus d’informations sur la conservation des données, reportez-vous à la section Create a clone preserver.
    • Pour en savoir plus sur le clonage d’instances avec AES, consultez le Guide de l’administrateur App Engine Studio système sur ServiceNow University.
    En savoir plus sur le clonage d’instances avec AES Ressources supplémentaires ServiceNow
    ServiceNow fournit plusieurs ressources supplémentaires sur le clonage d’instances avec App Engine Studio.

    Clonage de l’article de base de la base de connaissances

    Clonage des instances : conseils et astuces Article de la base de connaissances

    FAQ complète : article de la base de connaissances sur le clonage des instances

    Livre blanc App Engine Enterprise : conservation des données lors du clonage système
    Remarque :
    Vous devez vous connecter pour accéder à ServiceNow University cette ressource.