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 usa gli stessi meccanismi di autenticazione e autorizzazione di PostgreSQL in esecuzione in locale.
In questa unità verranno esaminati gli aggiornamenti che è necessario apportare alle applicazioni per connettersi al database di Azure appena migrato per PostgreSQL.
Creare manualmente i ruoli utente
Quando si trasferisce un database PostgreSQL in Database di Azure per PostgreSQL usando il Servizio Migrazione del database di Azure, i ruoli e le assegnazioni di ruolo non vengono copiati. È necessario ricreare manualmente i ruoli e gli account utente necessari per l'amministratore e gli utenti delle tabelle nel database di destinazione. Per eseguire queste attività, usare le utilità psql o pgAdmin. Eseguire il comando CREATE ROLE. Usi il comando GRANT per assegnare i privilegi necessari a un ruolo. Per esempio:
CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;
Annotazioni
È anche possibile usare il createuser comando dal prompt di bash per creare ruoli PostgreSQL.
Per visualizzare i ruoli esistenti nel database locale, eseguire l'istruzione SQL seguente:
SELECT rolname
FROM pg_roles;
È possibile usare il comando \du nell'utilità psql per visualizzare i privilegi assegnati ai ruoli.
List of roles
Role name | Attributes | Member of
---------------+------------------------------------------------------------+-----------
azureuser | Superuser, Create DB | {}
myuseraccount | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Annotazioni
Si noti che Database di Azure per PostgreSQL aggiunge alcuni ruoli propri. Questi ruoli includono azure_pg_admin, azure_superusere l'utente amministratore specificato al momento della creazione del servizio. È possibile accedere usando gli account amministrativi, ma gli altri due ruoli sono riservati per l'uso da parte di Azure. Non è consigliabile tentare di usarli.
Riconfigurare le applicazioni
La riconfigurazione di un'applicazione per la connessione a Database di Azure per PostgreSQL è un processo semplice. Tuttavia, è più importante determinare una strategia per le applicazioni di migrazione.
Considerazioni sulla riconfigurazione delle applicazioni PostgreSQL
In un ambiente aziendale potrebbero essere in esecuzione molte applicazioni con gli stessi database PostgreSQL. da un numero elevato di utenti. Si vuole essere certi che, quando si passa dal sistema esistente a Database di Azure per PostgreSQL, i sistemi continueranno a funzionare, gli utenti possono continuare a svolgere i propri lavori e le operazioni critiche per l'azienda rimangono operative. Modulo 1, Lezione 2, Considerazioni sulla migrazione, sono stati illustrati molti dei problemi in termini generali. Quando si esegue la migrazione di un database PostgreSQL ad Azure, è necessario tenere presenti alcune specifiche:
- Se si esegue una migrazione offline, i dati nel database PostgreSQL originale e i nuovi database in esecuzione in Azure possono iniziare a divergere rapidamente se il database precedente è ancora in uso. Una migrazione offline è adatta quando si sospende completamente il funzionamento di un sistema per un breve periodo di tempo e quindi si trasferiscono tutte le applicazioni al nuovo sistema prima di riavviare il sistema. Questo approccio può tuttavia non essere possibile per un sistema business critical. Se stai migrando a PostgreSQL in esecuzione su una macchina virtuale di Azure, configuri la replica PostgreSQL tra il sistema on-premises e quello su Azure. La replica di PostgreSQL nativa funziona solo in una sola direzione, ma sono disponibili soluzioni di terze parti che supportano la replica bidirezionale tra i server PostgreSQL (queste soluzioni non funzioneranno 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, un'applicazione connessa al database in esecuzione in Database di Azure per PostgreSQL potrebbe avere le modifiche sovrascritte in modo cieco da un'applicazione che usa ancora il database locale. Tenendo presente questo aspetto, è consigliabile considerare gli approcci seguenti:
- Eseguire la migrazione delle applicazioni in base al tipo di carico di lavoro. Un'applicazione che accede ai dati per la lettura può essere spostata in modo sicuro nel database in esecuzione in Database di Azure per PostgreSQL e visualizzerà 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 up-to-date.
- Eseguire la migrazione degli utenti in base al tipo di carico di lavoro. Questa strategia è simile a quella precedente, ad eccezione del fatto che potrebbero essere presenti utenti che generano solo report mentre altri modificano i dati. È possibile che la stessa applicazione sia configurata per connettersi al database appropriato in base ai requisiti utente.
- Eseguire la migrazione delle applicazioni in base ai set di dati che usano. Se applicazioni diverse utilizzano subset diversi dei dati, è possibile eseguire la migrazione di queste applicazioni indipendentemente l'una dall'altra.
Riconfigurazione di un'applicazione
Per riconfigurare un'applicazione, è necessario indirizzarla al nuovo database. La maggior parte delle applicazioni ben scritte isolerà la logica di connessione, rendendo questa l'unica parte del codice che richiede modifiche. In molti casi, le informazioni di connessione potrebbero essere archiviate come informazioni di configurazione, ma è 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 per il 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 passare le applicazioni e gli utenti al nuovo database, è importante assicurarsi di aver configurato tutto correttamente.
Iniziare dalle applicazioni "in esecuzione asciutta" e connettere ogni ruolo per assicurarsi che sia disponibile la funzionalità corretta.
Eseguire quindi "test di immersione" per simulare il numero tipico di utenti che eseguono carichi di lavoro rappresentativi simultaneamente per un periodo di tempo. Monitorare il sistema e verificare di aver allocato risorse sufficienti al servizio Database di Azure per PostgreSQL.
A questo punto, è possibile iniziare a implementare 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.