Eseguire la migrazione di carichi di lavoro Linux e PostgreSQL

  • 45 minuti

Questo modulo illustra la migrazione di un carico di lavoro esistente da un ambiente locale o sul cloud ad Azure. Riguarda la migrazione dell'ambiente di calcolo a una macchina virtuale di Azure e dei dati a Database di Azure per PostgreSQL. L'applicazione è un esempio indipendente dal cloud che supporta qualsiasi applicazione reale preparata per la migrazione sul cloud.

In questa unità si esaminerà il valore delle transizioni seguenti con il vantaggio di una famiglia di prodotti completa di controlli di sicurezza e identità forniti da Azure:

  • Passaggio da un ambiente self-hosted (ad esempio un database autogestito) a un'offerta di database completamente gestita
  • Passaggio dal calcolo bare metal alle macchine virtuali ospitate nel cloud

Si esplorano inoltre i vantaggi della gestione delle risorse nel cloud dal punto di vista dei costi e delle prestazioni. Verrà illustrato come calcolare e gestire con precisione i costi prima e dopo la distribuzione, nonché come ottimizzare le prestazioni sia dal punto di vista del calcolo che dal punto di vista dei dati.

Carico di lavoro e dati

Il carico di lavoro è un'applicazione scritta in linguaggio Go che funziona con i dati all'interno di PostgreSQL. I dati costituiscono un set di dati aperto che consente di esplorare la potenza della piattaforma Postgres e delle relative estensioni.

Anche se questa applicazione può essere eseguita facilmente all'interno di un contenitore, gli stakeholder hanno scelto di non farlo in questa fase. La compilazione di un contenitore, la distribuzione in una piattaforma del contenitore o l'uso dell'orchestrazione dei contenitori non rientra nell'ambito. Tuttavia la migrazione ai contenitori potrebbe essere un passaggio logico in futuro.

Il repository GitHub associato a questo modulo fornisce un'applicazione e i dati correlati. Verrà illustrato come preparare l'applicazione ed esportare i dati per raggiungere uno stato simile a quello di questa applicazione di esempio. È anche possibile usare l'applicazione di esempio come modello per una distribuzione greenfield.

Qual è il valore della migrazione di questo carico di lavoro?

Ci si potrebbe chiedere quali sono i vantaggi della migrazione di questo carico di lavoro nel cloud. Ecco alcune delle proposte di valore.

Sicurezza e conformità

Quando si trasferiscono sul cloud carichi di lavoro di calcolo e dati, essi possono trarre vantaggio da funzionalità di sicurezza maggiori.

Le macchine virtuali in Azure traggono vantaggio da un'ampia gamma di funzionalità di sicurezza e conformità, tra cui firewall, reti virtuali, accesso just-in-time alle macchine virtuali, crittografia, controllo degli accessi in base al ruolo e computing riservato. Database di Azure per PostgreSQL supporta molte funzionalità simili, ad esempio la crittografia con chiavi gestite dal cliente, certificazioni di conformità e supporto per Microsoft Defender for Cloud.

Protezione delle connessioni tra le macchine virtuali e i database

Man mano che si integra una macchina virtuale con Database di Azure per PostgreSQL, è essenziale che possano connettersi tra loro in modo sicuro, in modo da ridurre il rischio di perdita dei dati.

L'autenticazione di Microsoft Entra consente di connettersi a Database di Azure per PostgreSQL senza password tradizionali. È invece possibile usare le identità di Microsoft Entra per il carico di lavoro dell'applicazione, ovvero identità gestite, utenti e amministratori tramite gli account utente Microsoft Entra. Questo approccio riduce il rischio che le credenziali di lunga durata vengano compromesse e che attori malintenzionati possano accedere ai dati.

Microsoft Entra ID, le identità gestite e il controllo degli accessi in base al ruolo (RBAC) con granularità fine possono consentire al carico di lavoro dell'applicazione di accedere ai dati e gestire le risorse di Azure in modo sicuro, seguendo il principio dei privilegi minimi.

Accesso a risorse di calcolo a prestazioni elevate e a costi convenienti tra più aree

Sia che sia necessario un calcolo conveniente per sviluppo/test o per i tipi di calcolo più recenti, con prestazioni più elevate o più grandi disponibili nel cloud, Azure offre una vasta gamma di opzioni di calcolo sia per le macchine virtuali che per Database di Azure per PostgreSQL. È possibile aumentare e ridurre le prestazioni di queste opzioni in base alle esigenze e sono disponibili in più di 60 aree in Azure.

È possibile ridimensionare le risorse di calcolo sia verticalmente che orizzontalmente, incluse le repliche di database e le opzioni distribuite , ad esempio Azure Cosmos DB per PostgreSQL. Azure Cosmos DB for PostgreSQL è un servizio gestito per PostgreSQL esteso con la superpotenza open source Citus delle tabelle distribuite. Questo calcolo è associato ad alcune delle opzioni di archiviazione cloud più veloci per adattare i requisiti di I/O di calcolo e archiviazione al carico di lavoro.

Gestione ed efficienza dei costi

È possibile ottimizzare la gestione dei costi e l'efficienza economica sia lato Linux che PostgreSQL. Rispetto alle soluzioni locali, il costo può spesso essere maggiormente personalizzato e adatto alla propria situazione. È possibile ridimensionare correttamente le risorse di calcolo rispetto a una soluzione locale. È inoltre possibile gestire facilmente l'intera flotta per ottimizzare solo le risorse di calcolo e archiviazione necessarie e pagare solo per ciò che si usa, in un modello di fatturazione dell'utilità.

La fatturazione dell'utilità consente ai clienti di gestire periodi di domanda elevata senza dover pagare il costo del provisioning eccessivo. Consente la migrazione a generazioni di calcolo più veloci ed efficienti man mano che diventano disponibili.

I clienti possono inoltre sfruttare il Vantaggio Azure Hybrid per risparmiare sui costi di licenza per distribuzioni Linux specifiche. Per altre informazioni, vedere Vantaggio Azure Hybrid per le macchine virtuali Red Hat Enterprise Linux (RHEL) e SUSE Linux Enterprise Server (SLES).

I clienti possono inoltre ridurre i costi, fino al 72% rispetto ai prezzi con pagamento in base al consumo, con condizioni di un anno o tre anni per le macchine virtuali e le istanze di macchina virtuale riservate di Azure. Per altre informazioni, vedere Come viene applicato lo sconto per la prenotazione di Azure alle macchine virtuali. I prezzi di Azure sono trasparenti e prevedibili ed è possibile usare il calcolatore prezzi di Azure per stimare i costi prima della distribuzione.

Operazioni del giorno 2

Le operazioni del giorno 2 per le applicazioni distribuite (ad esempio valutazione, monitoraggio, applicazione di patch di sicurezza, backup e ripristino di emergenza) diventano più efficienti tramite l'automazione e la possibilità di eseguire l'aggiornamento con tempi di inattività potenzialmente zero. Inoltre, è possibile gestire l'infrastruttura end-to-end con toolchain standard di settore.

Prima di iniziare

Questo modulo è ideato per facilitare la migrazione di un carico di lavoro Linux e PostgreSQL esistente ad Azure. Tuttavia, non è incentrato su come esportare i dati dal database di origine o su come preparare l'applicazione per la migrazione. Un motivo per tale approccio è che esistono molti tipi di database di origine e applicazioni di cui è possibile eseguire la migrazione, e il processo per ogni tipo è univoco.

Questo modulo offre un'applicazione di esempio, dati Postgres, file binari e infrastruttura come codice che è possibile usare per simulare il processo di migrazione. Dopo aver completato la migrazione simulata, è possibile usare le conoscenze acquisite per applicare gli stessi principi al proprio carico di lavoro.

Si usa l'applicazione di esempio Azure-Samples/tailwind-traders-go, come supporto per la migrazione del codice dell'applicazione. L'infrastruttura Bicep come codice, esempi di dati Postgres e binari e altre risorse per supportare la parte pratica di questo modulo sono disponibili nel repository GitHub Azure-Samples/linux-postgres-migration .

Per applicare questo approccio al proprio carico di lavoro, è necessario eseguire il mapping dei dati e dell'applicazione di origine alla struttura seguente.

Codice applicazione

È consigliabile archiviare il codice dell'applicazione nel controllo del codice sorgente, preferibilmente in un repository di GitHub.

La migrazione in questo modulo illustra lo scenario più semplice di clonazione del repository direttamente nella macchina virtuale di Azure. In uno scenario reale, è probabile che si disponga di una pipeline di distribuzione più complessa, ad esempio GitHub Actions, che compila e distribuisce il codice dell'applicazione nelle risorse di calcolo.

Dati Postgres

È consigliabile archiviare i dati Postgres in un file .sql che può essere usato per creare lo schema del database e inserire i dati. In questa migrazione simulata si usa un file di dati di esempio, tailwind.sql, all'interno del repository Azure-Samples/linux-postgres-migration. Copiare il file in Archiviazione BLOB di Azure e importarlo quindi in Database di Azure per PostgreSQL.

Quando si tratta di eseguire la migrazione dei propri dati, esportare i dati dal database di origine e salvarli in un file .sql. Copiare quindi il file nell'archivio BLOB come descritto in questo modulo.

File binari

La maggior parte delle applicazioni dispone di altri file binari, ad esempio file multimediali, di cui è necessario eseguire la migrazione. Per l'applicazione di esempio, verrà illustrato come eseguire la migrazione delle immagini copiandole da Azure-Samples/linux-postgres-migration all'archiviazione BLOB.

Analogamente, è necessario copiare i file binari in Archiviazione BLOB quando si esegue la migrazione del proprio carico di lavoro. In questo caso, il calcolo è senza stato e l'applicazione dispone dell'autorizzazione per accedere ai dati binari direttamente nell'archiviazione BLOB.

Infrastruttura come codice (Bicep)

L'infrastruttura come codice per questo modulo viene archiviata anche in Azure-Samples/linux-postgres-migration. È progettata per essere un'architettura di riferimento da usare così come è, con modifiche minime, se è possibile rendere i dati di origine e l'applicazione conformi alla struttura descritta in precedenza.

La sicurezza è un tema importante di questa migrazione ed è stata scelta una certa impostazione di sicurezza per semplificare il completamento della parte pratica di questo modulo. Ad esempio, Archiviazione BLOB usa un metodo di autenticazione più sicuro, senza chiave, ma sono consentite le connessioni di rete da qualsiasi indirizzo IP. In un ambiente di produzione si potrebbe voler bloccare l'accesso di rete ai soli indirizzi IP che devono accedere all'account di archiviazione.

Analogamente, si lascia l'opzione per aggiungere una regola del firewall al server PostgreSQL per consentire un indirizzo IP specifico. In un ambiente di produzione, è possibile disabilitare completamente l'accesso pubblico al server.

Differenze tra gli ambienti di origine e Azure

Una delle principali differenze durante la migrazione da un altro ambiente ad Azure è che si utilizzano completamente i controlli di sicurezza e identità forniti da Azure:

  • È possibile usare le identità gestite per le macchine virtuali e Database di Azure per PostgreSQL.
  • Usare Microsoft Entra ID per l'autenticazione. nel database.
  • Per accedere alle macchine virtuali si usa l'ID Microsoft Entra, anziché le chiavi SSH (Secure Shell).

Anziché eseguire una migrazione in modalità lift-and-shift, è possibile modernizzare l'applicazione in modo da sfruttare al meglio le funzionalità di sicurezza e conformità fornite da Azure.

In locale, è possibile usare un nome utente e una password per l'autenticazione al database. In Azure, viene illustrato come usare l'identità gestita della macchina virtuale per l'autenticazione nel database. Questo metodo di autenticazione è più sicuro e riduce il rischio che le credenziali di lunga durata vengano compromesse.

L'uso di un'identità gestita per l'autenticazione spesso richiede modifiche al codice nell'applicazione. In questo modulo, viene illustrato come usare la libreria azidentity in Go per ottenere un token per l'identità gestita. La stessa libreria è disponibile negli SDK Microsoft.

Creare un account Azure e installare l'interfaccia della riga di comando di Azure

Se non si ha un account Azure, è possibile creare un account gratuito oggi. Si ottengono crediti che è possibile usare per provare i servizi di Azure a pagamento. Anche dopo aver usato i crediti, è possibile mantenere l'account e continuare a usare i servizi di Azure gratuiti.

Per eseguire i comandi nelle unità seguenti, è necessario accedere a una shell bash. Tale shell può trovarsi in una di queste aree:

  • Nel computer locale. Ad esempio, usare macOS, Linux, sottosistema Windows per Linux (WSL) o Docker.
  • In una macchina virtuale. Ad esempio, usare Multipass o Azure.
  • Nel cloud. Ad esempio, usare Azure Cloud Shell o GitHub Codespaces.

Per completare questo modulo, è necessaria l'interfaccia della riga di comando di Azure. È possibile installare l'interfaccia della riga di comando di Azure nel computer locale seguendo le istruzioni nell'articolo Installare l'interfaccia della riga di comando di Azure. È anche necessario installare Git.

Risorse