Distribuire schemi convertiti con Esperienza di installazione

L'esperienza di configurazione della conversione dello schema genera automaticamente istruzioni e script al termine del flusso di lavoro di conversione. Usare questi file per distribuire schemi convertiti in Database di Azure per PostgreSQL. La generazione dei file non esegue la distribuzione degli schemi nella destinazione. È possibile esaminarli ed eseguire lo script di PowerShell o Bash generato nell'ambiente di distribuzione.

Per istruzioni sull'apertura dei file di installazione da una conversione completata, vedere Preparare la distribuzione con l'esperienza di installazione nell'esercitazione.

Esaminare i file generati

La directory di installazione dipende dal numero di schemi Oracle selezionati per la conversione. Usare il percorso applicabile relativo alla radice dell'area di lavoro:

Selezione dello schema Oracle Directory di installazione
Uno schema selezionato .github\postgres-migrations\<migration-project>\artifacts\oracle\<schema-name>\setup
Più schemi selezionati .github\postgres-migrations\<migration-project>\artifacts\oracle\_migration\setup

Sostituire <migration-project> con il nome della cartella del progetto di migrazione, ad esempio Mig001. Se si seleziona uno schema, sostituire <schema-name> con il nome della cartella dello schema Oracle selezionato, ad esempio HR. Se si selezionano più schemi, _migration è il nome effettivo della cartella, non un segnaposto.

Il percorso riflette gli schemi Oracle selezionati, non il numero di schemi PostgreSQL inclusi nel pacchetto. Esaminare setup_instructions.md l'ambito di distribuzione del pacchetto.

File o directory Purpose
setup_instructions.md Prerequisiti, comandi, parametri facoltativi e indicazioni per la risoluzione dei problemi specifici dell'implementazione.
setup.ps1 Strumento di esecuzione della distribuzione per Windows PowerShell.
setup.sh Runner di distribuzione per Bash in Linux o macOS.
sql Supporto di controlli di preparazione, script di estensione, query di verifica e manifesti usati dai runner.
reports e logs Output scritti quando si eseguono gli script di installazione.

Mantenere la directory di installazione all'interno del progetto di migrazione completo. Gli strumenti di esecuzione fanno riferimento a deploy.sql della sessione di conversione nella directory di pari livello convert; copiare solo la directory di installazione non è sufficiente.

Esaminare le istruzioni generate e sql di distribuzione prima di eseguirle. Verificare che SQL includa le correzioni degli oggetti che si intende distribuire. Se si trasferisce il progetto in un altro ambiente, mantenere la struttura di directory e seguire i requisiti di gestione dei dati dell'organizzazione. Rimuovere le credenziali e altri segreti dai file che condividi.

Preparare la destinazione

Usare i requisiti nel setup_instructions.md generato, anziché copiare i requisiti da un'altra conversione:

  • Versioni server e client. Preparare un server flessibile Database di Azure per PostgreSQL con la versione di PostgreSQL richiesta. La versione principale del client psql deve corrispondere alla versione principale registrata del server di conversione nel pacchetto di installazione generato. Installare il client sul computer che esegue il programma di installazione e renderlo disponibile in PATH. Il programma di installazione può creare un database nel server, ma non effettua il provisioning del server Azure.
  • Accesso alla shell e ai file. Usare PowerShell 5.1 o versione successiva in Windows o Bash in Linux o macOS. Il runner deve avere accesso in scrittura alle directory logs e reports.
  • Accesso alla rete. Consentire al computer di installazione di connettersi al server di destinazione Database di Azure per PostgreSQL e alla porta PostgreSQL.
  • Estensioni. Esaminare le estensioni necessarie e aggiungere estensioni supportate all'elenco di elementi consentiti del server di destinazione Database di Azure per PostgreSQL prima della distribuzione. Vedere Consentire le estensioni in Database di Azure per PostgreSQL.
  • Autorizzazioni. Usare un account con le autorizzazioni di database, schema, creazione di oggetti e installazione dell'estensione specificate nelle istruzioni generate. La modalità nuovo database richiede anche l'autorizzazione per creare il database.
  • Autenticazione. Usare il prompt delle password nascoste dello script, un file di password PostgreSQL o il processo di gestione dei segreti approvato dall'organizzazione. Non incorporare password negli script di distribuzione.

Verificare che il client sia disponibile:

psql --version

Le istruzioni generate riflettono l'ambiente di conversione, inclusi la versione di PostgreSQL e i requisiti delle estensioni. Esaminare eventuali differenze di destinazione prima della distribuzione.

Scegliere una modalità di database

Entrambi gli strumenti di esecuzione supportano queste modalità:

Mode Behavior
Nuovo database Modalità predefinita. Crea un database nel server di destinazione Database di Azure per PostgreSQL durante la distribuzione. Il nome del database richiesto non deve esistere già.
Database esistente Usa il database specificato. Se gli schemi di destinazione contengono oggetti, la configurazione richiede un riconoscimento esplicito prima di continuare.

Per un'esecuzione interattiva, lo script richiede valori di host, utente e database mancanti. Esaminare la destinazione visualizzata, la modalità di database, gli schemi e l'operazione prima di confermare.

Controllare la preparazione senza distribuire

Aprire un terminale nella directory di setup generata. Scegliere il comando per il sistema operativo e la modalità di database desiderata:

Modalità database Windows PowerShell Linux o macOS
Nuovo database .\setup.ps1 -ValidateOnly bash setup.sh --validate-only
Database esistente .\setup.ps1 -DatabaseMode existing -ValidateOnly bash setup.sh --database-mode existing --validate-only

La modalità di sola convalida si connette al server e scrive report e log locali. Non crea il database di destinazione, non installa le estensioni né distribuisce gli oggetti convertiti.

I controlli di preparazione riguardano la connettività, la versione di PostgreSQL, le impostazioni locali e la codifica del database, le autorizzazioni, l'occupazione dello schema di destinazione e la disponibilità dell'estensione. Esaminare gli avvisi e gli errori bloccanti.

In modalità nuovo database, la convalida usa il database di manutenzione perché il database di destinazione non esiste ancora. I controlli che richiedono il database di destinazione vengono contrassegnati come saltati. Un'esecuzione di sola convalida riuscita non conferma che i controlli ignorati siano stati superati.

Al termine della convalida, esaminare validation_report_<timestamp>.md nella reports directory . Risolvere i problemi segnalati prima della distribuzione. Se la convalida viene arrestata in anticipo, controllare prima l'output della console, quindi qualsiasi log o report creato.

Distribuire gli schemi convertiti

Usare la stessa destinazione e la stessa modalità database selezionate. Dalla directory di installazione eseguire il comando appropriato senza -ValidateOnly (PowerShell) o --validate-only (Bash):

Modalità del database Windows PowerShell Linux o macOS
Nuovo database .\setup.ps1 bash setup.sh
Database esistente .\setup.ps1 -DatabaseMode existing bash setup.sh --database-mode existing

Il runner prepara il database, verifica la prontezza, installa le estensioni supportate necessarie, esegue l'SQL di distribuzione convertito e verifica gli oggetti e le estensioni risultanti.

Esaminare lo SQL di distribuzione prima di approvare una destinazione non vuota perché può modificare gli oggetti esistenti.

Important

Entrambe le modalità database possono lasciare modifiche residue dopo un errore. In modalità nuovo database, il programma di installazione crea il database prima dei controlli di preparazione della destinazione, in modo che un controllo non riuscito possa lasciare il database in posizione. Deployment SQL può anche applicare modifiche in transazioni separate. Esaminare lo stato di destinazione prima di riprovare; non presupporre che un'implementazione non riuscita abbia eseguito il rollback delle modifiche precedenti.

Usare setup_instructions.md per i parametri facoltativi di porta, TLS, impostazioni locali e automazione. Per un'esecuzione non interattiva, specificare in anticipo i dettagli host, utente, database e autenticazione. Una destinazione esistente non vuota richiede anche un riconoscimento esplicito tramite -AllowNonEmptyExisting in Windows o --allow-nonempty-existing in Linux o macOS.

Esaminare i risultati della distribuzione

Leggere i risultati del deployment prima di continuare con la convalida dei dati o dell'applicazione. Uno stato di conversione da solo non conferma la distribuzione/pubblicazione in questa destinazione.

Directory Output Cosa rivedere
reports deployment_report_<timestamp>.md Totali distribuiti e non distribuiti, risultati dell'estensione, risultati per tipo di oggetto e motivi per cui gli oggetti non sono stati distribuiti.
reports verification_<timestamp>.csv Risultati dettagliati della verifica degli oggetti.
reports extensions_<timestamp>.csv Risultati dettagliati dell'estensione.
reports preflight_<timestamp>.csv Risultati del controllo di preparazione.
logs setup_<timestamp>.log Messaggi di esecuzione ed errori.

Le esecuzioni di sola convalida producono un report di convalida anziché un report di deployment. Un errore anticipato, ad esempio un problema di accesso ai file o di versione della shell, potrebbe lasciare solo l'output della console.

Usare il codice di uscita del runner insieme a questi output:

Codice di uscita Meaning
0 Operazione richiesta completata. Per la modalità solo convalida, la convalida della preparazione ha avuto esito positivo senza distribuzione.
1 Errore di input, del client o di annullamento da parte dell'utente.
2 Errore di pacchetto di installazione/configurazione, connessione, database, controllo di preparazione o installazione dell'estensione.
3 Distribuzione, verifica, segnalazione o errore imprevisto dello strumento di esecuzione.
4 La verifica ha identificato oggetti o estensioni che non sono stati distribuiti.

Continua l'automazione solo per il codice di uscita 0. Per qualsiasi altro codice, esaminare gli output disponibili e risolvere i problemi segnalati prima di procedere.

Convalidare lo schema distribuito

La configurazione riuscita non stabilisce l'equivalenza comportamentale con Oracle né la prontezza per la produzione. Testa in modo indipendente la gestione dei dati, le dipendenze, la logica di business e il comportamento dell'applicazione nell'ambiente di destinazione.

Esaminare gli oggetti o le estensioni che non sono stati distribuiti e completare le relative azioni correttive. Applicare la configurazione di sicurezza gestita separatamente e revocare i privilegi di installazione temporanea quando non sono più necessari.

Contenuti correlati

  • Ultimo aggiornamento: