È la chiave per industrializzare i processi, assumendo che tutto funzioni correttamente…

Pensate a cosa accade se un robot che vernicia un’autovettura fa male il suo lavoro (finisce la vernice)… stessa cosa se distribuisci un’applicazione su un’infrastruttura “iperconvergente” e poi scopri che non ci sono le risorse o che devi bilanciare a mano i dischi perché le performance non sono soddisfacenti oppure c’è contesa di risorse e devi fare le acrobazie per sistemare la questione.

Per fortuna l’assunzione sulla piattaforma Nutanix (ovvero che tutto funzioni), grazie alla scalabilità ed alle innumerevoli funzionalità che la rendono sostanzialmente invisibile, è valida e possiamo concentrarci sull’automatizzare le operazioni.

Come diciamo spesso (o forse poco spesso) l’intera piattaforma è gestibile via API, ma che sono le API, non sono le Api del miele (che purtroppo sono sempre meno…) bensì è uno dei tanti acronimi che ci rendono la vita difficile (chi non ha mai avuto vergogna di chiedere che significa un acronimo, alzi la mano o commenti l’articolo…) Application Programming Interface:

https://en.wikipedia.org/wiki/Application_programming_interface

Wow ma che significa, semplicemente che puoi “pilotare” un oggetto programmabile da fuori, ormai lo troviamo sul termostato del termosifone oppure sulla cosiddetta “domotica”, bene anche Nutanix è assimilabile ad un oggetto del genere, ma nel datacenter (o nel cloud, come tanto di moda), Nutanix non è il termosifone del datacenter, infatti consuma anche poca energia se paragonato ai vecchi storage…

Da sempre la piattaforma Nutanix espone delle API, dal piccolo Prism Element al Prism Central. Sul Prism Element locale siamo partiti dalla versione 0.8 a quella odierna 3.1:

Nella 3.1 sono state inserite sempre più funzionalità ed informazioni utili a prendere decisioni (il termostato aveva solo la temperatura, adesso hanno inserito umidità e previsioni del tempo… per cui puoi prendere decisioni più oculate sulla temperatura casalinga… ammesso che le previsioni siano attendibili).

Ad oggi il centro nevralgico del comando dei cluster Nutanix è sicuramente Prism Central che, oltre a gestire cluster multipli e distribuiti geograficamente, ha funzionalità di gestione delle applicazioni in modalità DevOps (wow un altro termine molto gettonato) e multicloud (anche qui parola magica).

Anche il Prism Central ovviamente è programmabile via API e possiamo chiedere per esempio la lista delle VM, su quale nodo stanno girando, quali sono le immagini attive, quali sono i blueprint di Calm e magari lanciarne uno… possiamo creare un progetto con un tenant nuovo, assegnare delle risorse, delle vLAN, chiedere all’SDN di implementare regole di routing etc etc etc…

Come possiamo far vedere tutto ciò con un esempio? Bene, utilizziamo un sistema di comunicazione “umano” ovvero Slack (umano di fa per dire, sempre meglio parlarsi), anche quest’ultimo, guarda caso ha delle API e si presta ad essere programmato.

In particolare ha un sistema che si chiama bot (slackbot) che permette di, incredibile ma vero, automatizzare delle operazioni ripetitive… (diffidate da chi risponde immediatamente ai canali slack… potrebbe essere un bot 🙂 ).

Prism Central già può interagire con Slack nativamente mediante xPlay (da qui l’idea di utilizzare tale metodo), in questo caso, mediante uno slack client installato su una VM che da un lato riesce a parlare con Slack e dall’altro con il Prism Central mediante le ormai celeberrime API…

In questo modo si riesce a far fare al Prism Central delle operazioni semplicemente interagendo con un bot…

Un video di tutto ciò è pubblicato al seguente link:

mentre su github è pubblicato l’esempio con gli script in python che implementano il tutto: https://github.com/ntnxcrex/Prism_API_example

Ma perché abbiamo parlato di automazione e ci ritroviamo a giocare con un bot Slack… l’esempio di interazione è per comprendere che mediante API è possibile inviare comandi al Prism Central in funzione di eventi esterni, di on-boarding di un nuovo “tenant” sull’ambiente con la creazione di un progetto assegnando delle risorse in funzione di quanto ha pagato… come anticipato sopra.

Si potrebbe creare un altro WebServer se le risorse di quelli attivi sono esaurite, oppure al contrario, spegnerne uno se sono troppi a lavorare ed è finito il picco di richiesta.

Tutto questo può avvenire automaticamente, e, come detto all’inizio, dimenticandosi dell’infrastruttura che autonomamente si gestiste e fornisce le migliori performance possibili evitando il più possibile hot-spot sulle risorse… e scusate se è poco 🙂

Categorie: API

0 commenti

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *