L'invio di Email con OCI ADB e AWS SES

Come si vedrà tra poco, il contesto prevede un database applicativo su un OCI ADB che deve,  tra le sue funzionalità, inviare email. Senza dover gestire infrastrutture email multiple sia in AWS che in OCI, e per garantire una gestione centralizzata e efficiente delle utenze di posta si voleva utilizzare un sistema unificato.

Il Contesto

Un cliente con un OCI Database Autonomous in modalità serverless, gestito quasi interamente dal cloud di Oracle, per ragioni di familiarità, competenza preesistente e per evitare la proliferazione di configurazioni e competenze separate, preferiva instradare le mail con origine dall’applicativo basato su Oracle, attraverso AWS SES anziché OCI Email Delivery.

 

Il Problema

 

La sfida iniziale: l'errore ORA-29278

Dopo aver impostato le configurazioni iniziali, inclusa l'assegnazione di una ACL (Access Control List) all'utente designato per l'invio di email e seguendo la documentazione Oracle, ogni tentativo di inviare una email risultava in un errore:

Questo errore si rivela essere estremamente generico, rendendo difficile identificare la causa principale del problema. Nonostante l'aumento del livello di tracciamento, non è facile ottenere informazioni più dettagliate che identifichino la vera natura del problema.

Indagini Approfondite e Ipotesi di Network

Dopo una serie di verifiche iniziale viene naturale verificare il Network Security Group (NSG) associato al database comprensivo di analisi sulla porta necessaria per l'accesso al servizio AWS SES ( ovviamente aperta e configurata correttamente). Anche successivi test eseguiti da istanze di Compute (server virtuali) nella stessa rete dimostrarono la connettività verso AWS SES, escludendo un problema di firewall o routing. Ma concentrarsi solo sulle uscite dal database non è sufficiente, in quanto vanno analizzati anche gli accessi in entrata. Si poteva notare infatti che nonostante il database fosse replicato su diverse infrastrutture, l'indirizzo di accesso rimaneva costante. Questo suggeriva che la comunicazione non avveniva direttamente con il database, ma era gestita tramite un CMAN (Connection Manager).

Il Ruolo del CMAN e il Private Endpoint

La presenza del CMAN implicava che il Private Endpoint del database fosse definito a livello del Connection Manager e non direttamente sul server del database. Questa rivelazione sollevò una domanda cruciale: come venivano gestite le richieste in uscita dal database e quale rete utilizzavano?

Test e Scoperta della Rete Pubblica

Per indagare, abbiamo configurato un endpoint pubblico sulla porta 587 su un server remoto e implementato una procedura sul database in grado di eseguire una richiesta TCP. Tracciando le richieste in arrivo sul server remoto, abbiamo trovato che l'indirizzo sorgente era attestato su una rete pubblica di Oracle, e non sulla rete privata configurata per la procedura.

La Soluzione

Identificato il problema, abbiamo identificato anche la soluzione: modificare una proprietà del database per forzare le richieste in uscita ad utilizzare il Private Endpoint del database. La proprietà da modificare era:

A questa proprietà venne assegnato il valore:

I Risultati

La risoluzione di questo problema ha permesso al cliente di evitare la gestione di due diverse infrastrutture di posta, con conseguente riduzione della duplicazione di informazioni, dei costi e della complessità operativa.
Il cloud, con la sua potenza e complessità, richiede un nuovo paradigma tecnico. Non più una competenza verticale o settoriale, ma una competenza orizzontale, basata su conoscenze condivise. Un linguaggio comune facilita il dialogo tra le parti interessate e porta a soluzioni innovative.

Miriade si distingue in questo contesto, grazie a tecnici in grado di fornire supporto avanzato nelle loro specializzazioni e di offrire supporto orizzontale su tutta la piattaforma. Questa capacità aumenta notevolmente il loro Problem Solving e li rende in grado di risolvere problemi complessi su più livelli tecnologici in diverse infrastrutture cloud.