Cloud ibrido tra Kubernetes e IBM i

smeup webup: l’applicazione smeup di cui è stato eseguito il porting su cloud

smeup webup è un’applicazione web che permette ai clienti smeup di comunicare con smeup erp da un qualsiasi browser web e si compone di 3 elementi:

• webup front-end, l’applicazione principale visibile dagli utenti;
• AS400 Proxy: un middleware che permette a webup front-end e IBM i di comunicare tra loro;
• H53 service: un microservice che, comunicando direttamente con webup front-end, offre funzioni di stampa pdf. 

Per la parte architetturale dell’installazione che gestisce la struttura dell’applicazione e che mette in comunicazione tra loro i 3 elementi, le tecnologie utilizzate per questo porting sono state:

• Cloud Kubernetes
• Helm (il Package Manager di Kubernetes)

Per la parte di monitoraggio dell’installazione e per i sistemi di allerta del cluster, alla base ci sono invece:

• Prometheus
• Grafana

Nel cloud non è banale poter essere a conoscenza dello stato dell’applicazione soprattutto quando questa è distribuita su più nodi e su diverse macchine.

Cloud Kubernetes: cos’è un cloud pubblico

Kubernetes è un sistema open source di orchestrazione e gestione di container.

Si basa sul concetto di container, ovvero l’evoluzione di una virtual machine in grado di risolvere i problemi di utilizzo di memoria sfruttando il sistema operativo della macchina sottostante per l’applicazione interna al container stesso.

Kubernetes orchestra e gestisce un numero elevato di container (da 4-5 fino a centinaia) comunicando tramite strumenti e oggetti creati in base al concetto di “codice come infrastruttura” e letti da file di configurazione a codice markup YAML, che viene scansionato da Kubernetes per la creazione di tali oggetti.

Il Pod, una sorta di wrapper che racchiude al suo interno un container e altri strumenti aggiuntivi, è il concetto alla base di Kubernetes. All’interno dei container dei tre Pod di webup si trova Payara, un application server utilizzato per eseguire applicazioni java.

Come è possibile che due container diversi comunichino?

Essendo i Pod Kubernetes (e quindi anche i container posti al loro interno) ambienti chiusi, sterili e separati, garantiscono la replicabilità di un certo ambiente per l’esecuzione delle applicazioni.
Allo stesso modo sono anche strutture effimere spesso avviate, distrutte e ricreate più volte nel ciclo di vita di un’applicazione, rendendo impensabile che i dati all’interno non possano sopravvivere.

La comunicazione avviene tramite i volumi, ossia strumenti Kubernetes che consentono la permanenza e la persistenza dei dati nel tempo.

L’application server – il container Payara – esegue automaticamente webup e condivide il file attraverso Il volume. 

Webup a questo punto diventerà disponibile per il cliente, garantendo la persistenza di dati di configurazione anche in caso di riavvii di containers, Pods, o addirittura nodi del cluster Kubernetes.

Obiettivo raggiunto!

Ecco il deployment più avanzato all’interno del progetto di smeup.

Il check up periodico sull’applicazione, chiamato health check, è a carico degli oggetti Kubernetes detti “probes”, che riescono a rilevare guasti in un’applicazione grazie a controlli periodici come chiamate HTTP o esecuzione di script.

Nel caso di webup le probes eseguono chiamate HTTP sugli endpoint dell’applicazione webup. 

Se le chiamate restituiranno un codice “200” (OK) , il sistema starà funzionando correttamente, mentre con codici di errore 400-500 persistenti per tre controlli consecutivi, le probes scateneranno un riavvio del container per risolvere eventuali problemi.

Come avviene la lettura di tutti gli elementi Kubernetes?

Helm è uno strumento di creazione di package chiamati Charts rappresentanti un semplice microservice o un’intera applicazione (come nel caso di webup). Oltre ad occuparsi dell’installazione delle Charts, Helm aiuta anche con upgrade e rollback.

Vantaggi:

• permette di installare webup e tutti e tre i suoi componenti con un semplice comando “helm install webup”
• tramite appositi file di configurazione è possibile inserire variabili e flow control all’interno della chart per cambiare, ad esempio, la versione dell’applicazione. Se un tecnico avesse necessità di cambiare la versione del front end di webup, helm gli permetterà di separare dal codice le variabili e le informazioni in un paio di semplici configurazioni chiave-valore.
• helm permette di eseguire upgrade e rollback senza downtime creando una nuova versione dell’applicazione con un upgrade di webup, online in pochi minuti e mantenendo a disposizione degli utenti la versione precedente fino a che quella nuova sarà disponibile;

Le installazioni di cui abbiamo parlato finora sono state eseguite in un ambiente Cloud pubblico. 

Cloud pubblico

Un cloud pubblico è una piattaforma che utilizza il modello di cloud computing standard per rendere le risorse, le applicazioni, lo storage o le virtual machine disponibili agli utenti in remoto. 

smeup ha usato tre servizi:

• elastic Kubernetes service (EKS), il servizio completamente gestito e integrato con altri servizi per monitorare, scalare e bilanciare il carico del cluster;
• elastic file system (EFS) che offre un file system interamente gestito e completamente integrato con EKS, tramite il quale è possibile garantire la persistenza di file di configurazione e di log, aggregando questi dati e rendendoli disponibili per la visualizzazione su una qualsiasi macchina che monti il file system EFS.
• Route 53: un semplice servizio di DNS utilizzato per la pubblicazione su webup.smeup.cloud di webup EKS.

Prometheus e Grafana

Monitorare un’applicazione o un cluster Kubernetes non è per nulla semplice: molti nodi, molti più Pod creati e distrutti alcuni dei quali senza neppure un sistema operativo in cui entrare per eseguire controlli.

Prometheus è un’applicazione per il monitoraggio dotata di un sistema di avvertimento ed è la soluzione adottata da smeup.

Si tratta di un sistema di monitoraggio che periodicamente rileva lo stato di webup e del cluster Kubernetes interrogando diversi endpoint, per poi salvare i dati ottenuti su un database time series che mostra l’andamento nel tempo dei dati raccolti.

Di per sé questi dati non sono utili se non si trova il modo di trasformarli in informazioni comprensibili. 

Grafana è invece una soluzione open-source che consente di visualizzare graficamente dati da diverse sorgenti e che ha permesso a smeup di interrogare il database time series e creare dashboard con i dati ricavati da Prometheus che indicassero il numero di thread attivi, il carico medio del sistema, l’utilizzo di CPU, le informazioni su networking, l’uptime,… 

Tutte informazioni utili a mostrarci cosa stesse realmente accadendo all’interno del cluster.

Con Grafana è stato inoltre possibile creare dei sistemi di allerta che, attraverso un messaggio su telegram, una mail o un sms avvisassero del malfunzionamento di un componente dell’installazione, e permettessero un intervento tempestivo.

Ricapitolando, la struttura webup di puro deployment cloud vedrà utenti che tramite HTTPs si collegano a webup front end il quale (su cloud aws) comunicherà con i due componenti H53 service e AS400 proxy.
Per accedere al back end, AS400 proxy (anch’esso su cloud aws) comunicherà con IBM i tramite TCP su data center .

Dal Cloud pubblico al Cloud ibrido

Il porting del deployment dal cloud pubblico al cloud ibrido con IBM i.

Come siamo passati da un’architettura completamente cloud ad un’architettura ibrida?

Installando direttamente su IBM i il microservice AS400 proxy, il middleware del nostro sistema distribuito che mette in comunicazione il frontend di webup e il backend di IBM i.

Questo microservice comunica con webup tramite il protocollo HTTPs, mentre la comunicazione con IBM i avviene tramite TCP.

Per lo sviluppo di questo microservice abbiamo utilizzato diverse tecnologie: 

• delle API rest, necessarie per interfacciarsi ai servizi esposti da AS400 proxy;
• la comunicazione HTTPs per il dialogo tra il frontend e il nostro middleware;
• l’interfaccia swagger per testare gli endpoint.

Per il porting di AS400 proxy in IBM i abbiamo utilizzato Quarkus, il framework java sviluppato da RedHat e ottimizzato in ottica cloud.

Quarkus, un framework di sviluppo Java utilizzato per creare un microservice  AS400 su IBM i 

Quarkus è un framework per l’ottimizzazione in ottica Cloud che offre diversi vantaggi:

• è sviluppato da RedHat (IBM);
• le applicazioni Quarkus non richiedono un Application Server, come per esempio Payara, visto nel deployment originale;
• riduce i tempi di avvio dell’applicazione avendo eliminato completamente il tempo di start up dell’application server;
• riduce anche i tempi di deploy dell’applicazione, in pochi secondi infatti si ha l’avvio del microservice;
• crea applicazioni che consentono la riduzione del consumo di memoria di un decimo rispetto a java tradizionale.

La differenza tra i due deployment:

• AS400 proxy su cloud comunica in TCP con l’IBM i.
• AS400 proxy installato direttamente su IBM i comunica in localhost direttamente sulle data queues.

smeup webup Cloud Ibrido con IBM i AS400 Proxy

Con questo deployment diversi sono i vantaggi sia in termini di performance che di utilizzo delle risorse:

• maggiore sicurezza tramite comunicazione su localhost;
• minore overhead avendo eliminato l’application server Payara, le macchina extra e VPN;
• ottimizzazioni fornite dal toolbox java su trasferimento di grandi quantità di dati specificando l’utente di collegamento con IBM i usando la parola chiave  *CURRENT;
• AS400 Proxy trasformato in un vero e proprio microservice portandolo su IBM i.

Utilizzando il toolbox java, attraverso la parola chiave *CURRENT, si dovrà impostare l’utente di collegamento con il server solo al primo avvio.

Il concetto di utente applicativo, per le diverse funzioni applicative, ci permette poi di astrarsi a un livello superiore.

Questo il procedimento per far partire l’applicazione tramite Qshell e vedere se è funzionante:

• creare uno script bash dove si fanno le seguenti operazioni:
  • settare le variabili d’ambiente, ossia le configurazioni per la nostra applicazione;
  • specificare il server, ossia “localhost” perché comunica con la stessa macchina su cui viene installato;
  • inserire l’utente e la password con *CURRENT;
  • lanciare il jar dell’applicazione con il comando java -jar;
• lanciare lo script bash; 
• un file catturerà l’output;
• vedremo i log contenuti nel file e se l’applicazione è partita correttamente;
• il server Quarkus dovrà partire correttamente e trovare le configurazioni precedentemente settate;
• l’applicazione inizierà a girare.

Impressionante la velocità di avvio ottenuta con l’utilizzo di Quarkus e la possibilità di provare gli endpoint con l’interfaccia swagger.

Portando il microservice direttamente su IBM i e lanciando l’applicazione da Qshell, in pochi istanti questa sarà online e pronta per essere utilizzata.

In conclusione, qual è la principale differenza tra i due deployment?

Deployment Cloud: tre microservice tutti sul cloud pubblico AWS e con AS400 Proxy che comunica con IBM i in data center tramite TCP.

Deployment Ibrido: utilizza un’architettura ibrida con i due microservice webup e H53 sul cloud pubblico AWS mentre AS400 proxy Quarkus è installato direttamente su IBM i in data center e i due microservice comunicano in HTTPs con l’AS400 proxy e la AS400 proxy in localhost direttamente su IBM i.