Implementazione a livello tecnico del sistema sul cloud

Siamo arrivati alla fase dellŠimplementazione vera e propria del sistema su AWS.

Per realizzare i nostri obiettivi implementativi gli step che sono stati percorsi sono i seguenti:

1. ‘E stata creata una macchina virtuale (in locale) attraverso lŠutilizzo del software Virtualbox. Su questa VM ‘e stato installato tutto lŠecosistema di ODC, com-preso dei vari database, di Jupyter Notebook e dellŠinterfaccia graĄca. Si noti che questa ‘e la conĄgurazione base di ODC consigliata dagli sviluppatori della piattaforma. Tutti i servizi girano sulla stessa VM ed il sistema ‘e completo.

Una soluzione ŞnaiveŤ, a questo punto, sarebbe stata quella di portare su AWS questa macchina virtuale sviluppata in locale. Ovviamente, non ci siamo voluti fermare ad unŠimplementazione basica e semplicistica, ma lŠobiettivo ‘e sempre stato quello di voler puntare verso una soluzione professionale!

2. Partendo dal disegno architetturale e dai servizi che sono stati individuati per il funzionamento di ODC, sono state create tre macchine virtuali (sempre grazie allŠutilizzo di Virtualbox) che comunicavano attraverso la rete; descriviamo le tre VM implementate:

• ODC UI, comprensiva della componente graĄca del sistema. I servizi che sono stati implementati allŠinterno di essa sono: Redis, Celery e Django (dove per Django non si intende la componente della relativa base di dati, che verr‘a implementata in una VM differente).

• PostgreSQL, contenente la base di dati di ODC e la base di dati di Django.

In particolare, come ampiamente spiegato in precedenza, per il database di ODC ‘e stata utilizzata lŠestensione di PostgreSQL denominata PostGIS.

• Jupyter Notebook, contenente il servizio JupyterLab che ci ha permesso di eseguire gli script in linguaggio Python.

Una volta tirate su le tre istanze, il passaggio pi‘u delicato ‘e stato quello di riuscire a far comunicare le VM attraverso la rete. Ogni VM aveva un suo indirizzo IP e si connetteva alle altre VM (e, in generale, allŠesterno) mediante una determinata porta. Per la conĄgurazione di questa rete abbiamo analizzato il codice sorgente di ODC e abbiamo modiĄcato i riferimenti ai vari servizi della piattaforma (deĄnendo gli indirizzi IP e le porte di comunicazione dove necessario).

Le macchine virtuali in questione si basano tutte su una distribuzione Linux Ubuntu Server 20.04. Ciascuna ‘e stata personalizzata mediante lŠinstallazione e/o la conĄgurazione di pacchetti speciĄci per poter assolvere al proprio compito.

3. Arrivati a questo punto, dopo aver implementato il sistema in locale sfruttando Virtualbox, ‘e stato ricreato lo stesso ambiente di esecuzione facendo il deploy delle tre macchine virtuali su cloud.

Anche qui, come in precedenza, una soluzione banale che poteva essere imple-mentata era quella di migrare direttamente su cloud le tre VM conĄgurate in locale nello step precedente. Tuttavia, una soluzione pi‘u efficiente, che ‘e sta-ta implemensta-tasta-ta, consisteva nello sfrutsta-tare le risorse e, nello speciĄco, i servizi offerti da AWS; Amazon Web Services, infatti, offre agli utenti un servizio de-nominato ŞAmazon RDSŤ¹che contiene sia PostgreSQL che PostGIS. Dunque, per sfruttare questa funzionalit‘a offerta da Amazon RDS, ‘e stato implementa-to il servizio PostGIS e lo stesso ‘e staimplementa-to conĄguraimplementa-to adeguatamente per poter comunicare con le altre due entit‘a in questione (ODC UI e Jupyter Notebook).

Per quanto riguarda le altre due componenti (cio‘e ODC UI e Jupyter Notebook), al Ąne di poter sfruttare il pi‘u possibile le componenti gi‘a pronte di Open Data Cube, sono state prese le immagini .ova derivanti dalle corrispondenti VM sviluppate in locale e sono state importate come AMI (Amazon Machine Images) per permettere di replicare, modiĄcare e/o estendere lŠambiente pi‘u comodamente. Una componente molto importante della soluzione implementata

‘e lŠobject storage S3, che viene utilizzato sia per la persistenza dei dati satellitari estratti dalle sorgenti, sia per il mantenimento delle AMI relative alle istanze in esecuzione.

E stata necessaria, inoltre, una minima conĄgurazione e personalizzazione delle‘ macchine virtuali, una volta eseguito il deploy in cloud, per permettere il loro corretto funzionamento nel nuovo ambiente.

Scendendo ad un livello implementativo pi‘u tecnico, alle macchine virtuali po-sizionate su sotto-reti pubbliche ‘e stato assegnato un Elastic IP a testa che le rende raggiungibili dai vari client (su rete internet). Dunque, ognuna ha un

in-1 Amazon RDS (dove RDS ‘e lŠacronimo di Relational Database Service) ‘e un servizio di database relazionale distribuito di Amazon Web Services. Si tratta, quindi, di un servizio Web in esecuzione sul cloud e progettato per sempliĄcare la conĄgurazione, il funzionamento e il ridimensionamento di un database relazionale da utilizzare nelle applicazioni.

dirizzo IP pubblico raggiungibile da internet ed accettano soltanto connessioni in entrata su porta 22 (utilizzando il protocollo SSH) e 8000 (per lŠapp Django e per Jupyter). La terza macchina ‘e quella di PostgreSQL ‘e su una terza sotto-rete privata (cio‘e che non ha accesso a internet) come ampiamente spiegato durante la progettazione dellŠarchitettura. Ciascuna delle macchine virtuali, inoltre, ha un Elastic Block Storage che garantisce la persistenza dei dati scritti su disco una volta che la macchina viene riavviata o spenta per lunghi periodi di tempo.

Parlando della VPC, invece, essa ‘e collocata presso la Region AWS Eu-Central-1 (Frankfurt).

CŠ‘e da notare che, installando i pacchetti essenziali per la VM contenente il servizio Jupyter, essa necessita anche di avere installata la libreria datacube per svolgere efficacemente i suoi compiti.

Al termine dellŠimplementazione, dopo aver effettuato il deploy delle tre entit‘a su AWS ed aver conĄgurato le modalit‘a di comunicazione tra i vari servizi, sia-mo riusciti nellŠintento di tirar su un sistema ODC funzionante che presupponga unŠinterfaccia graĄca e un Jupyter notebook come unici punti di accesso al sistema, riuscendo a rispettare sia i requisiti stabiliti che le speciĄche di progettazione. In Figura 4.4 ‘e possibile visualizzare la home page della Web UI.

Figura 4.4.Home page della UI di Open Data Cube

Dalla Figura 4.4 possiamo osservare che lŠindirizzo IP della macchina virtuale della UI ‘e 18.159.98.100, mentre la porta attraverso la quale esso comunica con lŠesterno ‘e la 8000.

Riferendoci ai requisiti del sistema delineati nelle fasi iniziali del progetto, non

‘e stata deĄnita alcuna speciĄca riguardante la registrazione autonoma da parte di un utente nel sistema; questa funzionalit‘a, infatti, non ‘e prevista dal nostro sistema perch´e lŠaccesso ad esso ‘e permesso attraverso un meccanismo di autenticazione, ed i vari utenti possono essere creati soltanto dagli amministratori. A tal proposi-to, uno dei problemi che sono stati affrontati riguardava il fatto che la Web UI di

ODC prevedeva nativamente un sistema di registrazione attraverso una form, che divergeva con i requisiti riguardanti il nostro sistema. Per tale motivo, ‘e stato neces-sario rimuovere questa funzionalit‘a agendo direttamente sul codice Python relativo allŠinterfaccia Web di Django.

Analogamente a quanto appena fatto per la Web UI di ODC, in Figura 4.5 verr‘a mostrata la pagina di avvio del servizio Jupyter (raggiungibile allŠindirizzo Ş18.159.98.100Ť attraverso la porta 8000).

Figura 4.5.Pagina di avvio del servizio JupyterLab