Migrazione delle applicazioni
Dopo aver eseguito la migrazione del database dall'ambiente locale ad Azure, è necessario aggiornare le applicazioni esistenti in modo che possano accedere a PostgreSQL nella nuova posizione.
Il server e il database locali originali conterranno i ruoli che definiscono i privilegi associati agli utenti, le operazioni che possono eseguire e gli oggetti su cui eseguono tali operazioni. Database di Azure per PostgreSQL adotta gli stessi meccanismi di autenticazione e autorizzazione di PostgreSQL in esecuzione in locale.
In questa unità si esamineranno gli aggiornamenti che è necessario apportare per consentire alle applicazioni di connettersi alla nuova istanza di Database di Azure per PostgreSQL.
Creare i ruoli utente manualmente
Quando si trasferisce un database PostgreSQL in un'istanza di Database di Azure per PostgreSQL usando il Servizio Migrazione del database di Azure, i ruoli e le relative assegnazioni non vengono copiati. È necessario creare di nuovo manualmente i ruoli e gli account utente necessari per l'amministratore e per gli utenti delle tabelle nel database di destinazione. Per eseguire queste attività, usare l'utilità psql o pgAdmin. Eseguire il comando CREATE ROLE. Per assegnare i privilegi necessari a un ruolo, usare il comando GRANT. Ad esempio:
CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;
Nota
Per creare ruoli PostgreSQL è possibile usare anche il comando createuser dal prompt di Bash.
Per visualizzare i ruoli esistenti nel database locale, eseguire l'istruzione SQL seguente:
SELECT rolname
FROM pg_roles;
Per visualizzare i privilegi assegnati ai ruoli, è possibile usare il comando \du nell'utilità psql.
List of roles
Role name | Attributes | Member of
---------------+------------------------------------------------------------+-----------
azureuser | Superuser, Create DB | {}
myuseraccount | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Nota
Si noti che Database di Azure per PostgreSQL aggiunge alcuni ruoli specifici, tra cui azure_pg_admin, azure_superuser e l'utente amministratore specificato durante la creazione del servizio. L'accesso viene eseguito con gli account amministrativi, ma gli altri due ruoli sono riservati per l'uso da parte di Azure. Non è consigliabile provare a usarli.
Riconfigurare le applicazioni
La riconfigurazione di un'applicazione per la connessione a Database di Azure per PostgreSQL è un processo semplice. È più importante determinare una strategia per le applicazioni di migrazione.
Considerazioni sulla riconfigurazione delle applicazioni PostgreSQL
In un ambiente aziendale è possibile che molte applicazioni vengano eseguite sugli stessi database PostgreSQL da un numero elevato di utenti. È opportuno assicurarsi che, quando si passa dal sistema esistente a Database di Azure per PostgreSQL, i sistemi continuino a funzionare, gli utenti possano continuare a svolgere il proprio lavoro e lo stato delle operazioni business critical per l'azienda rimanga attivo. Nella lezione 2 del modulo 1, Considerazioni sulla migrazione, sono stati descritti a grandi linee molti dei problemi. Quando si esegue la migrazione di un database PostgreSQL in Azure, è necessario tenere presenti alcuni aspetti specifici:
- Se si esegue una migrazione offline, è possibile che i dati nel database PostgreSQL originale e quelli nei nuovi database in esecuzione in Azure inizino a divergere rapidamente se il database precedente rimane in uso. Una migrazione offline è adatta quando un sistema viene messo completamente fuori servizio per un breve periodo di tempo e quindi tutte le applicazioni vengono trasferite nel nuovo sistema prima del riavvio. Questo approccio può tuttavia non essere possibile per un sistema business critical. Se si esegue la migrazione a PostgreSQL in esecuzione in una macchina virtuale di Azure, si configura la replica di PostgreSQL tra il sistema locale e quello in esecuzione in Azure. La replica nativa di PostgreSQL funziona in una sola direzione, ma sono disponibili soluzioni di terze parti che supportano la replica bidirezionale tra i server PostgreSQL (queste soluzioni non funzionano con Database di Azure per PostgreSQL).
- Se si esegue una migrazione online, il servizio Database di Azure per PostgreSQL configura la replica dal database locale al database in esecuzione in Azure. Dopo il trasferimento iniziale dei dati, la replica garantisce che tutte le modifiche apportate al database locale vengano copiate nel database di Azure, ma non viceversa.
In entrambi i casi, è necessario assicurarsi di non perdere i dati attivi sovrascrivendoli accidentalmente. Nello scenario online, ad esempio, le modifiche ai dati di un'applicazione connessa al database in esecuzione nel servizio Database di Azure per PostgreSQL potrebbero essere sovrascritte da un'applicazione che usa ancora il database locale. Tenendo presente questo aspetto, è opportuno valutare gli approcci seguenti:
- Eseguire la migrazione delle applicazioni in base al tipo di carico di lavoro. Un'applicazione che accede ai dati solo per la lettura può essere spostata in modo sicuro nel database in esecuzione nel servizio Database di Azure per PostgreSQL e vedrà tutte le modifiche apportate dalle applicazioni che usano ancora il database locale. È anche possibile adottare la strategia opposta se le applicazioni di sola lettura non richiedono dati completamente aggiornati.
- Eseguire la migrazione degli utenti in base al tipo di carico di lavoro. Questa strategia è simile alla precedente, ad eccezione del fatto che alcuni utenti potrebbero generare solo report mentre altri modificano i dati. In questo caso, si potrebbe configurare la stessa applicazione per la connessione al database appropriato in base ai requisiti degli utenti.
- Eseguire la migrazione delle applicazioni in base ai set di dati che usano. Se applicazioni diverse usano subset di dati differenti, è possibile eseguire la migrazione di queste applicazioni in modo indipendente l'una dall'altra.
Riconfigurazione di un'applicazione
Per riconfigurare un'applicazione, è necessario indirizzarla al nuovo database. La maggior parte delle applicazioni scritte in modo coretto isola la logica di connessione e quindi questa dovrebbe essere l'unica parte del codice da modificare. In molti casi, è possibile che le informazioni di connessione siano archiviate come informazioni di configurazione ed è quindi sufficiente aggiornare tali informazioni.
Le informazioni di connessione per il servizio Database di Azure per PostgreSQL sono disponibili nel portale di Azure nella pagina Stringhe di connessione relativa al servizio. Azure fornisce le informazioni per molti framework e linguaggi di programmazione comuni.
Aprire le porte di rete
Come indicato nella lezione 1 di questo modulo, Database di Azure per PostgreSQL è un servizio protetto che viene eseguito dietro un firewall. I client possono connettersi solo se il relativo indirizzo IP viene riconosciuto dal servizio. È necessario aggiungere gli indirizzi IP, o gli intervalli di blocchi di indirizzi, per i client in cui vengono eseguite applicazioni che devono connettersi ai database.
Testare e verificare le applicazioni
Prima di effettuare il passaggio di applicazioni e utenti al nuovo database, è importante assicurarsi di aver configurato tutto correttamente.
Iniziare con un "dry run test", ovvero un test statico delle applicazioni, e connettere ogni ruolo per assicurarsi che sia disponibile la funzionalità corretta.
Eseguire quindi una serie di "soak test", di verifica della stabilità, per simulare il numero tipico di utenti che eseguono simultaneamente carichi di lavoro rappresentativi per un certo periodo di tempo. Monitorare il sistema e verificare di avere allocato risorse sufficienti al servizio Database di Azure per PostgreSQL.
A questo punto, è possibile iniziare a distribuire il sistema agli utenti. Può essere utile implementare una sorta di "canary test", un test selettivo in cui un piccolo subset di utenti viene trasferito al sistema senza che questi ne siano consapevoli. In questo modo si ottiene un'opinione imparziale sul fatto che gli utenti abbiano la stessa esperienza, oppure un'esperienza migliore o peggiore, con il nuovo database.