Samuele PoiattiIndice articolo
Questo articolo ha lo scopo di mostrare il nuovo approccio alla fornitura di applicazioni Sme.UP ai clienti, basato sulla generazione automatizzata di oggetti hardware virtuali già pronti, con il software installato e configurato. Tutto questo si basa su una metodologia piuttosto recente in generale, ma sicuramente PIONIERISTICA nel panorama informatico italiano, l’Infrastructure as Code.
Infrastructure as code (IaC) è il processo di gestione e approvvigionamento dei computer attraverso file di definizione leggibili dalla macchina, piuttosto che configurazione hardware fisica o strumenti di configurazione interattiva. In altre parole, dei sorgenti software che generano e configurano l’infrastruttura.. I vantaggi sono: riduzione dei costi, incremento della velocità, rimozione di errori e maggiore affidabilità.
Infatti rimuovendo la componente manuale, le persone sono in grado di concentrare i loro sforzi verso altre attività aziendali. L’automazione dell’infrastruttura consente velocità attraverso un’esecuzione più rapida quando si configura la propria infrastruttura. L’automazione rimuove il rischio associato all’errore umano, come l’errata configurazione manuale; la rimozione di questo può ridurre i tempi di fermo e aumentare l’affidabilità.
IaC e Smartkit
Il primo software di Sme.UP che utilizza questo approccio è quello che è stato definito Smartkit.
Si tratta di una macchina virtuale o fisica, su cui è installato un sistema operativo Linux CentOS. In questo è stato installato il software Docker (https://www.docker.com/what-docker), un cosiddetto Container Engine, ossia un sistema per la gestione di macchine virtuali “light”, che contengono tendenzialmente una sola applicazione, dette Container.
I container docker installati possono essere molti, uno portrebbe contenere Sme.UP Provider, uno Web.UP, uno MySQL. Nella prima versione dello Smarkit viene installato solo Sme.UP Provider. Questo nella sostanza un container Sme.UP Provider è a sua volta composta da Payara (application server per far girare applicazioni java) e Sme.UP Provider WAR, versione WAR di Sme.UP Provider (https://www.smeup.com/download/download-sme-erp/versione-roma/).
L’archiettettura finale è rappresentata nella figura seguente
Questa metodologia verrà utilizzata sempre più spesso nei prodotti Sme.UP.
Sme.UP Provider si presta a questo processo, secondo la procedura elencata in questo articolo.
La seguente lettura si comporrà di tre parti:
- La prima riguarda il processo tramite il quale viene creata la macchina virtuale;
- La seconda si comporrà della procedura di avvio della macchina virtuale all’interno di virtual box;
- La terza parte consisterà in un test di utilizzo di questo provider per l’interrogazione di un Web Service tramite l’utility Sme.UP a ciò dedicata, la K11.
Creazione della macchina virtuale.
Il processo di creazione della macchina virtuale avviene attraverso una console, in maniera interattiva oppure in maniera schedulata. A prescindere dal modo scelto, il tutto parte con l’avvio del software di creazione come di seguito.
Una volta creata la macchina virtuale, si avvieranno automaticamente le operazioni di setup del sistema operativo, di installazione del software e così via. Tutta questa procedura è automatizzata e avviene all’interno della macchina virtuale. Al termine del processo di installazione del sistema operativo nella macchina virtuale, potremo procedere al passaggio successivo. Questa fase durerà diversi minuti e, giunti a completamento, si presenterà una schermata come la seguente.
Preparazione del container Sme.UP Provider.
Appena la macchina sarà disponibile, il nostro processo principale riprenderà e darà inizio alle installazioni del caso. Tutta questa procedura è guidata da uno script Terraform il quale installerà il software che, successivamente, consentirà di procedere al setup. All’interno della macchina virtuale il provider verrà installato sotto forma di container Docker. Il risultato della produzione di questa virtual machine è un file in formato Open Virtual Application (.ova) come quello da esempio.
Questo file in formato .ova, potrà essere importato come applicazione virtuale in una piattaforma di virtualizzazione.
Una volta importato, il risultato che otterremo consisterà nell’avere a disposizione una macchina virtuale nella quale sarà pre-installato un container Docker, contenente a sua volta un application server GlassFish (per la precisione Payara), all’interno del quale è stato installato lo Sme.UP Provider sotto forma di Web Application.
Una volta configurata la macchina virtuale che abbiamo importato, con le impostazioni necessarie per la sua pubblicazione, la avvieremo e al suo interno avremo a disposizione una Web Application che svolgerà le funzioni di Sme.UP Provider.
Avviata la macchina, ci connettiamo utilizzando l’utente predefinito e, una volta scoperta la configurazione di rete acquisita (con il comando “ip a”), potremo collegarci con una console ed andremo a verificare lo stato dell’applicazione appena installata.
Una volta avviata la macchina virtuale, all’interno della quale si è avviato il container Docker, contenente GlassFish, dentro di cui si trova Sme.UP Provider, abbiamo una cartella dei log all’interno di cui troviamo i log del provider che indicano il collegamento al sistema.
L’accesso ai file di configurazione dello Sme.UP Provider avviene direttamente dalla macchina virtuale attraverso il percorso
/opt/payara/etc/provider/smeup-provider/configuration.properties
Una volta applicate delle modifiche, bisogna riavviare il provider con i comandi “docker stop smeup-provider” e, successivamente, “docker start smeup-provider”.
docker stop smeup-provider docker start smeup-provider
Anche l’accesso ai file di log del Provider avviene direttamente dalla macchina virtuale tramite il percorso
/home/smeup/container/smeup-provider/log/
Questi passaggi dovrebbero portare ad avere disponibile uno SmeUp Provider e la sua corrispettiva pagina di debug. Quest’ultima può essere statica oppure contenente le informazioni attinte dall’AS400 per verificare lo stato di salute del Provider.
L’indirizzo http alla pagina di debug è il seguente:
{indirizzo ip del provider}:8080/smeup-provider/debug
Ad esempio:
Esempio di utilizzo. Chiamata K11 tramite Sme.UP
Provider.
In questa fase utilizzeremo il provider per effettuare una chiamata attraverso la /copy K11. Si rimanda alla documentazione specifica, che trovate sul nostro blog, relativa a /copy K11 ed al costruttore LOA38 per informazioni riguardanti le configurazioni necessarie.
Per fare questo dobbiamo, attraverso uno dei client (Loocup o WebUP), andare sulla scheda del provider e, tramite l’interfaccia del costruttore A38, prendere uno dei servizi per cui esistono i connettori per questa installazione e andare sulla pagina di simulazione che, attraverso la /copy K11, effettuerà una chiamata di richiesta di token di autenticazione ad un web service di un portale.
Compilando con i parametri previsti, viene effettuata la chiamata e, attraverso il provider che abbiamo installato e avviato nel container Docker sulla macchina virtuale, abbiamo ottenuto la risposta, ovvero, il token di autenticazione del web service.
Se qualcosa non dovesse essere chiaro, questo video mostra passo passo la procedura illustrata precedentemente:
Questo è tutto, ora abbiamo a nostra disposizione uno Sme.UP Provider pienamente funzionante!