AWS RDS e S3

Il titolo di questo post è senz’altro bizzarro, sono tre sigle che a molti potrebbero dire ben poco. AWS sta per Amazon Web Services, si tratta della piattaforma dei servizi cloud fornita da Amazon che è stata la prima a fornire questo tipo di servizi su larga scala, credo che sia ancora la più importante e sicuramente ha una offerta ampia e completa e per quel che è la mia esperienza servizi di alta qualità e affidabilità. Tutti i servizi cloud forniti da AWS sono identificati da sigle, RDS e S3 sono due di questi. RDS sta per Relational Database Service, è un servizio cosiddetto SaaS (per alcuni PaaS, il confine è labile e la stessa Amazon non sembra sbilanciarsi troppo), altra sigla Software As A Service. In pratica RDS è un database server già configurato e gestito automaticamente da AWS per cui l’utente deve solo fare le configurazioni “applicative”, creazione schemi/utenti e poco altro. Sotto c’è sempre una macchina ma non si ha accesso al sistema operativo e questo in rari casi è una limitazione. Non c’è accesso allo storage della macchina, però per le istanze RDS Oracle è predisposta una directory e il corrispondente oggetto Oracle Directory per gestire import/export con Data Pump ed external tables. La modalità di default per accedere a questo filesystem è il package PL/SQL DBMS_FILE_TRANSFER con le procedure GET_FILE e PUT_FILE che permettono di trasferire file da una istanza Oracle all’altra tramite DB LINK. Questa modalità funziona bene per i dump creati da DataPump, non funziona con i file di testo come i log a causa della limitazione che i file devono avere dimensione multipla di 512 byte (poi si parla solo di binary file e non ho capito se anche questo è un vincolo). Per accedere ai file di testo sulle istanze RDS Oracle è a disposizione un package PL/SQL RDSADMIN.RDS_FILE_UTIL con delle procedure o funzioni per mostrare il contenuto di file di testo, elencare i file presenti nella directory e per cancellarli.

S3 è un altro dei servizi AWS, Simple Storage Service, una sorta di filesystem, con diverse funzionalità accessorie. Tramite la “AWS CLI” è facile copiare da e verso “bucket” S3 file. Sulle istanze Oracle RDS è possibile attivare una opzione chiamata S3_INTEGRATION che aggiunge l’accesso a un package PL/SQL RDSADMIN.RDSADMIN_S3_TASKS che fornisce due funzioni per copiare dall’istanza RDS a un bucket S3 e viceversa dei file. Questo rappresenta quindi un modo più comodo per trasferire file da e verso istanze RDS, seppur sempre dovendo “triangolare”. Si tratta poi di gestire con attenzione le “policy” e i permessi vari. Uno dei vincoli da tenere presente nel modulo S3_INTEGRATION è che funziona solo se l’istanza RDS e il bucket S3 sono nella stessa Region, mentre poi, sempre gestendo in modo opportuno le policy dei bucket S3 è possibile copiare file tra bucket in region diverse e anche fra bucket in account diversi tramite CLI ad esempio. Occorre fare attenzione alle “ACL” ovvero ai permessi associati a file copiati nei bucket. Per default se copio da un account un file in un bucket in un altro account (dopo che a questo bucket ho associato una policy che mi permetta di copiarci file) il file mantiene i permessi di chi ha scritto il file, quindi, un po’ sorprendentemente e paradossalmente per me, il proprietario del bucket non può accedere in alcun modo al file. Per cambiare questo comportamento se si copia il file tramite CLI basta aggiungere l’opzione “–acl bucket-owner-full-control” che dice appunto che l’owner del bucket avrà pieno accesso al file copiato. Si può anche associare una policy al bucket che forzi l’uso dell’opzione, nel senso che se qualcuno cerca di copiare un file senza specificarla viene restituito un errore. Non mi risulta esista un modo per renderlo un default del bucket, ovvero fare si che qualunque file copiato nel bucket sia pienamente accessibile al proprietario del bucket.

Nelle funzioni di copia di S3_INTEGRATION non c’è la possibilità di specificare il parametro “–acl bucket-owner-full-control” per cui per copiare i file su bucket S3 di altri account occorre fare ulteriori passaggi. Ad esempio è possibile, una volta trasferito il file nel bucket usare il comando “aws s3api put-object-acl ….–acl bucket-owner-full-control“

Vi è poi un’altra casistica con cui mi sono scontrato e per la quale credo di aver trovato la soluzione ma non ho capito perfettamente la motivazione. Copiando file da un bucket S3 in una regione a un bucket in un’altra regione tramite CLI (aws s3 cp) ricevo un errore del tipo “The eu-south-1 location constraint is incompatible for the region specific endpoint this request was sent to.” Questo mi è capitato con file sopra una certa dimensione e non con file piccoli (mi pare sotto gli 8 MB). Sembra che oltre gli 8 MB per default venga cambiata la modalità di caricamento del file utilizzando una modalità “multipart”, ma poi perché questo scateni l’errore non l’ho capito.

In un primo momento ho trovato (dopo estenuanti ricerche) come soluzione l’aggiunta del parametro “–metadata-directory REPLACE”, poi andando sulla documentazione di AWS CLI V2 ho trovato il suggerimento di usare il parametro “–copy-props”, ho provato con “metadata-directive” e funziona (dovrebbe funzionare anche con “none” ma non sono sicuro di aver provato)

Riporto un esempio di policy che ho utilizzato su un bucket S3 per poterci copiare (e leggere) file da un altro account:

Una delle cose belle, fra tutto il casino e la complessità che c’è dietro è che AWS fornisce fra le altre anche delle librerie per poter fare tutto tramite script in python