Recentemente sono rientrato in un periodo di trasferte perpetue e ciò significa che ogni settimana passo almeno sette ore in treno cercando di dormire o di lavorare in totale tranquillità. A volte penso che ci vorrebbe un post su come sopravvivere in trasferta e che raccolga un po’ di dritte utili. Ad esempio, se ordinate del cibo in camera, chiedete sempre le posate.
Nella galassia di progetti personali interrotti per via della mia scarsezza nella progettazione di interfacce utente ho spesso ipotizzato di costruire cose che offrissero servizi alla community.
Riporto qualche esempio di progetti tristemente deceduti, ma non per questo meritevoli di una damnatio memoriae, e alcuni in via di sviluppo (tipo il bot Telegram per Openshift).
Olinuxc
Era figo ma dispendioso e poco comprensibile. Praticamente un cloud-linux-shell-provider libero solo per amanti e/o bisognosi di una shell effimera istantanea. Si inviava la propria chiave pubblica a OlinuxC per poter richiedere un container tramite ssh debian@olinuxc.org .
C’era la possibilità di scegliere tra “un botto” di distro Linux.
Il nome utente indicava la distribuzione Linux desiderata.
Ziopinguino.it
Un clone di nip.io fatto con PowerDNS. Praticamente un wildcard dns per mappare qualsiasi ip.
Tipo, foobar.33.33.33.33.ziopinguino.it veniva risolto su internet con 33.33.33.33. Quindi per esperimenti vari, senza comprare alcun dominio si poteva usare ziopinguino.it
Congruit – Il configuration management tool che ama Bash
Piccola utility scritta in Go per configurare server in modo dichiarativo.
Funziona tipo così:
[
{
"places": ["debian","screen_is_not_installed"],
"works": ["screen_package_apt"]
},
{
"places": ["centos7","screen_is_not_installed"],
"works": ["screen_package_yum"]
}
]
Tutti gli oggetti all’interno della configurazione scritta in json richiamano alla fine degli utilissimi “bashoni” o per meglio dire script bash.
Se i place sono veri (quindi ritornano un exit code pari a 0) vengono eseguiti i works.
Openshift-Bot
Visto che ultimamente lavoro parecchio con Openshift ho deciso di scrivere un bot per Telegram e la cosa mi ha entusiasmato molto! Presto pubblicherò il codice su Github.
Cosa fa il bot nello specifico
Allo /starts ciò che il bot ci dice è questo:
Il connubio tra “devo studiarmi come funzionano le API di Openshift” e il fatto che mi è sempre piaciuto offrire servizi alla community mi ha portato a implementare queste tre funzionalità di molto basilari.
Dockerize yourself!
La prima, “Build and expose a pod – picture version”, prende una foto scattata e la manda al bot che produce una build di tipo “strategy Docker”.
Praticamente inserisce la foto in un’immagine Docker molto semplice che espone un web-server Python minimale.
FROM ubuntu USER root RUN apt-get update RUN apt-get -y install python RUN apt-get clean EXPOSE 8080 WORKDIR / COPY index.html index.html COPY server.py server.py COPY from_telegram.jpg from_telegram.jpg CMD [ "python","server.py" ]
Una volta terminata la build e ottenuto un pod running viene creata una route su Openshift e tramite nip.io l’url può essere risolta, e quindi raggiunta, ovunque.
Si, come indicato sopra, il bot cancella tutto in 30 secondi. Non dispongo di molte risorse computazionali per cui devo liberare spazio per evitare che il mio server prenda fuoco.
Send index.html
Questa è stata un feature molto semplice che fa più o meno le stesse cose della prima, ma al posto di iniettare una foto in un’immagine Docker traporta un index.html inviato come file da Telegram.
- creo un file index.html
sh-3.2# cat > index.html < foo > EOF sh-3.2#
- lo invio al bot
- curl verso il sito esposto
sh-3.2# curl http://sample-app-i50b6v.94.23.211.122.nip.io foo
La comodità è con poche righe di codice posso inviare file di log agli utenti. Tipo questo, che serve per far vedere come è andata la build.
Oppure, per chi è curioso di sapere da cosa è composta un’applicazione su Openshift/Kubernetes invio un json contenente tutti gli oggetti creati.
Link ad un progetto Docker su GitHub
L’ultima feature è ancora in beta per cui non la sponsorizzo più di tanto. Di base prende in input un link ad un progetto Docker su Github e lo compila. È ovvio che manca ancora molto su questo fronte. Ci sarebbero da aggiungere tutte le build strategy che Openshift offre e la possibilità di passare al bot le variabili d’ambiente del proprio container.
Lo scopo di questo post qual’è?
Lato tecnico per parlare di quando è figo fare bot e di quanto sono comode le API di Openshift.
Molte delle operazioni svolte le ho applicate nell’implementazione di alcune catene di CI/CD nell’ambito di vari progetti enterprise. Sono fortemente convinto che fare esperimenti in ambiti non lavorativi sia la base per ritrovarsi allenati e pronti alle sfide che ci si propongono nel lavoro di tutti i giorni.
Lo scopo di questo post è ribadire che nel nostro lavoro è fondamentale “smanettare” e non perchè ci sia dietro un profondo discorso filosofico, ma perchè se si fa parte di quella categoria di persone che sui libri non ci sa stare, l’unico modo per apprendere è sperimentare.