Déployer des schémas convertis avec Setup Experience

L'assistant de configuration de conversion de schéma génère automatiquement des instructions et des scripts à la fin du flux de travail de conversion. Utilisez ces fichiers pour déployer des schémas convertis en Azure Database pour PostgreSQL. La génération des fichiers ne déploie pas les schémas vers votre destination. Vous les passez en revue et exécutez le script PowerShell ou Bash généré dans votre environnement de déploiement.

Pour obtenir des instructions sur l’ouverture des fichiers d’installation à partir d’une conversion terminée, consultez Préparer le déploiement avec l’expérience d’installation dans le didacticiel.

Passer en revue les fichiers générés

Le répertoire d’installation dépend du nombre de schémas Oracle que vous sélectionnez pour la conversion. Utilisez le chemin d’accès applicable par rapport à la racine de l’espace de travail :

Sélection du schéma Oracle Répertoire d’installation
Un schéma sélectionné .github\postgres-migrations\<migration-project>\artifacts\oracle\<schema-name>\setup
Plusieurs schémas sélectionnés .github\postgres-migrations\<migration-project>\artifacts\oracle\_migration\setup

Remplacez <migration-project> par le nom du dossier du projet de migration, tel que Mig001. Si vous sélectionnez un schéma, remplacez <schema-name> par le nom du dossier de schéma Oracle sélectionné, par exemple HR. Si vous sélectionnez plusieurs schémas, _migration il s’agit du nom réel du dossier, et non d’un espace réservé.

L’emplacement reflète les schémas Oracle sélectionnés, et non le nombre de schémas PostgreSQL inclus dans le package. Passez en revue setup_instructions.md pour la portée de déploiement du package.

Fichier ou répertoire Purpose
setup_instructions.md Conditions préalables spécifiques au déploiement, commandes, paramètres facultatifs et conseils de résolution des problèmes.
setup.ps1 Programme d’exécution du déploiement pour Windows PowerShell.
setup.sh Outil de déploiement pour Bash sur Linux ou macOS.
sql Prise en charge des vérifications de préparation, des scripts d’extension, des requêtes de vérification et des manifestes utilisés par les runners.
reports et logs Sorties écrites lorsque vous exécutez les scripts d’installation.

Conservez le répertoire d’installation dans le projet de migration complet. Les runners font référence à la session de conversion deploy.sql dans le répertoire frère convert ; la copie uniquement du répertoire d’installation n’est pas suffisante.

Passez en revue les instructions générées et sql de déploiement avant de les exécuter. Vérifiez que le sql inclut les corrections d’objet que vous envisagez de déployer. Si vous transférez le projet vers un autre environnement, conservez sa structure d’annuaires et suivez les exigences de gestion des données de votre organisation. Supprimez les identifiants et d'autres secrets des fichiers que vous partagez.

Préparer la destination

Utilisez les exigences de votre setup_instructions.md généré, plutôt que de copier les exigences d'une autre conversion :

  • Versions du serveur et du client. Préparez un serveur flexible Azure Database pour PostgreSQL avec la version postgreSQL requise. La psql version principale du client doit correspondre à la version principale du serveur de conversion enregistrée dans le package d’installation généré. Installez ce client sur l’ordinateur qui exécute le programme d’installation et mettez-le à disposition sur PATH. Le programme d'installation peut créer une base de données sur votre serveur, mais ne provisionne pas le serveur Azure.
  • Accès à l’interpréteur de commandes et aux fichiers. Utilisez PowerShell 5.1 ou version ultérieure sur Windows, ou Bash sur Linux ou macOS. L'exécuteur a besoin d'un accès en écriture à ses répertoires logs et reports.
  • Accès au réseau. Autoriser l’ordinateur d’installation à se connecter au serveur de destination Azure Database pour PostgreSQL et au port PostgreSQL.
  • Extensions. Passez en revue les extensions requises et ajoutez des extensions prises en charge à la liste d’autorisation du serveur de destination Azure Database pour PostgreSQL avant le déploiement. Consultez Autoriser les extensions dans Azure Database pour PostgreSQL.
  • Autorisations. Utilisez un compte disposant des autorisations de base de données, de schéma, de création d'objets et d'installation d'extension spécifiées dans les instructions générées. Le mode Nouvelle base de données nécessite également l’autorisation de créer la base de données.
  • Authentification. Utilisez l’invite de mot de passe masquée du script, un fichier de mot de passe PostgreSQL ou le processus de gestion des secrets approuvé de votre organisation. N’incorporez pas de mots de passe dans des scripts de déploiement.

Vérifiez que le client est disponible :

psql --version

Les instructions générées reflètent l’environnement de conversion, y compris sa version de PostgreSQL et ses exigences en matière d’extensions PostgreSQL. Passez en revue les différences de destination avant le déploiement.

Choisir un mode de base de données

Les deux exécuteurs prennent en charge ces modes :

Mode Behavior
Nouvelle base de données Mode par défaut. Crée une base de données sur le serveur de destination Azure Database pour PostgreSQL lors du déploiement. Le nom de la base de données demandée ne doit pas déjà exister.
Base de données existante Utilise la base de données que vous spécifiez. Si les schémas cibles contiennent des objets, le programme d’installation nécessite une confirmation explicite avant de continuer.

Pour une exécution interactive, le script demande les valeurs d’hôte, d’utilisateur et de base de données manquantes. Passez en revue la destination affichée, le mode de base de données affiché, les schémas affichés et l’opération affichée avant de confirmer.

Vérifier la préparation sans déployer

Ouvrez un terminal dans le répertoire d’installation généré. Choisissez la commande pour votre système d’exploitation et le mode de base de données prévu :

Mode de base de données Windows PowerShell Linux ou macOS
Nouvelle base de données .\setup.ps1 -ValidateOnly bash setup.sh --validate-only
Base de données existante .\setup.ps1 -DatabaseMode existing -ValidateOnly bash setup.sh --database-mode existing --validate-only

Le mode validation seule se connecte au serveur et écrit des rapports et des journaux locaux. Il ne crée pas la base de données cible, n’installe pas les extensions et ne déploie pas les objets convertis.

Les vérifications de préparation couvrent la connectivité, la version PostgreSQL, l’encodage de base de données et les paramètres régionaux, les autorisations, l’occupation du schéma cible et la disponibilité des extensions. Passez en revue les avertissements ainsi que les échecs bloquants.

En mode nouvelle base de données, la validation utilise la base de données de maintenance, car la base de données de destination n’existe pas encore. Les vérifications qui nécessitent la base de données de destination sont marquées comme ignorées. Une exécution de validation seule réussie n’est pas la confirmation que ces vérifications ignorées ont réussi.

Une fois la validation terminée, passez en revue validation_report_<timestamp>.md dans le répertoire reports. Résolvez les problèmes signalés avant le déploiement. Si la validation s’arrête tôt, vérifiez d’abord la sortie de la console, puis tout journal ou rapport créé.

Déployer les schémas convertis

Utilisez la même destination et le même mode de base de données que vous avez vérifiés. À partir du répertoire d’installation, exécutez la commande appropriée sans -ValidateOnly (PowerShell) ou --validate-only (Bash) :

Mode de base de données Windows PowerShell Linux ou macOS
Nouvelle base de données .\setup.ps1 bash setup.sh
Base de données existante .\setup.ps1 -DatabaseMode existing bash setup.sh --database-mode existing

Le runner prépare la base de données, vérifie l’état de préparation, installe les extensions prises en charge requises, exécute le sql de déploiement converti et vérifie les objets et extensions résultants.

Passez en revue le sql de déploiement avant d’approuver une destination non vide, car il peut modifier les objets existants.

Important

Les deux modes de base de données peuvent laisser subsister des modifications après une défaillance. En mode nouvelle base de données, le programme d’installation crée la base de données avant les vérifications de préparation de destination, de sorte qu’une vérification ayant échoué puisse laisser cette base de données en place. Le déploiement SQL peut également appliquer des modifications dans des transactions distinctes. Passez en revue l'état de destination avant de réessayer. Ne partez pas du principe qu'un déploiement ayant échoué n'a pas annulé les modifications précédentes.

Utiliser setup_instructions.md pour les paramètres facultatifs de port, tls, paramètres régionaux et automatisation. Pour une exécution non interactive, fournissez les détails de l’hôte, de l’utilisateur, de la base de données et de l’authentification à l’avance. Une cible existante non vide nécessite également un accusé de réception explicite via -AllowNonEmptyExisting sous Windows ou --allow-nonempty-existing sous Linux ou macOS.

Passer en revue les résultats du déploiement

Lisez les résultats du déploiement avant de passer à la validation des données ou de l’application. Un état de conversion seul ne confirme pas le déploiement vers cette destination.

Répertoire Output Éléments à vérifier
reports deployment_report_<timestamp>.md Les totaux déployés et non déployés, les résultats de l’extension, les résultats par type d’objet et les raisons pour lesquelles les objets n’ont pas été déployés.
reports verification_<timestamp>.csv Résultats détaillés de la vérification des objets.
reports extensions_<timestamp>.csv Résultats détaillés de l’extension.
reports preflight_<timestamp>.csv Résultats du contrôle de préparation.
logs setup_<timestamp>.log Messages d’exécution et erreurs.

Les exécutions de validation uniquement produisent un rapport de validation au lieu d’un rapport de déploiement. Un échec précoce, tel qu’un problème d’accès aux fichiers ou de version shell, peut laisser uniquement la sortie de la console.

Utilisez le code de sortie du runner avec ces sorties :

Code de sortie Meaning
0 L’opération demandée a réussi. En mode validation seule, la validation de préparation a réussi sans déploiement.
1 Erreur de saisie, côté client ou due à l’annulation par l’utilisateur.
2 Échec du package d'installation/de la configuration, de la connexion, de la base de données, de la vérification de l'état de préparation ou de l'installation de l'extension.
3 Erreur de déploiement, de vérification, de création de rapports ou erreur inattendue de l'exécuteur.
4 La vérification a identifié des objets ou des extensions qui n’ont pas été déployés.

Continuez l'automatisation uniquement pour le code de sortie 0. Pour tout autre code, passez en revue les sorties disponibles et résolvez les problèmes signalés avant de continuer.

Valider le schéma déployé

La configuration réussie n’établit pas d’équivalence comportementale avec Oracle ni l’état de préparation pour la production. Testez indépendamment la gestion des données, les dépendances, la logique métier et le comportement de l’application dans l’environnement de destination.

Passez en revue les objets ou extensions qui n’ont pas été déployés et terminez leur correction. Appliquez une configuration de sécurité gérée séparément et révoquez les privilèges d’installation temporaires lorsqu’ils ne sont plus nécessaires.

Contenu connexe

  • Dernière mise à jour :