Ansible: primi passi

Durante il mio periodo in Sourcesense ho imparato parecchio su un software di configuration management di cui non ero molto pratico all’inizio, ovvero Chef: Eugenio mi ha insegnato veramente di tutto su quello che considero uno dei sistemi più completi per l’orchestrazione della propria infrastruttura, tuttavia proprio in questi giorni mi sono trovato per le mani qualcosa di meraviglioso, ovvero (finalmente) qualcosa che infrastrutturalmente era un green-field project.

Da Wikipedia:

In many disciplines a greenfield project is one that lacks constraints imposed by prior work. The analogy is to that of construction on greenfield land where there is no need to work within the constraints of existing buildings or infrastructure.

Dovendo fare una scelta e avendo del tempo per stare dietro all’infrastruttura senza fretta, ho preferito privilegiare la conoscenza di un nuovo strumento, e ho deciso di dare una chance ad Ansible, di cui in parecchi mi avevano parlato bene durante le chiacchierate ai meetup.

Primo impatto

Il primo impatto con Ansible non è malaccio, alla fine fornisce un’infrastruttura di configuration management completamente agentless in cui abbiamo una Ansible Control Machine (ovvero anche il nostro computer) e i vari host, che sono banalmente IP associati a delle label che li raggruppano. Successivamente abbiamo i playbook, dei file con descrittori scritti in YAML che vanno a specificare cosa fare su un determinato host o altro. Il range di cose che possiamo specificare è infinito, dato che possiamo installare pacchetti ma anche installare file tramite template e così via, fino all’installazione di software tramite le gemme Ruby o Python Pip, o addirittura l’istanziazione/orchestrazione di container Docker.

Questo è possibile perché Ansible è ben ingegnerizzato, e oltre ai playbook permette di scrivere dei moduli (in Python) che consentono di specificare comportamenti personalizzati invocando delle action precise. Alcuni di questi moduli sono parte di Ansible stesso out-of-the-box, come il modulo relativo a docker, che permette di fare cose simili:

- name: Create a data container
  docker_container:
    name: mydata
    image: busybox
    volumes:
      - /data

E questi sono solo i primi esempi di cosa possiamo fare. Il fatto che in tutto questo non ci siano agent di mezzo, ma basti solo un ssh-copy-id e qualche riga di YAML per aggiungere un nodo all’infrastruttura e configurarlo è veramente fantastico, anche perché dal punto di vista di gestione è praticamente a sforzo zero, e non dipende da barbatrucchi assurdi.

Imparate le basi, mi è rimasto solo da misurarmi con qualche piccolo trucchetto per far quadrare la situazione come piaceva a me.

Trucchetti

Tra Puppet, Chef, Ansible e Saltstack non ho mai visto un sistema di configuration management privo di trucchetti per semplificarsi la vita. Mi spiego: su Chef per esempio la configurazione di knife e della workstation dello sviluppatore secondo me rimane un po’ macchinosa. Oltre questo, ci sono una serie di piccoli inganni tipo i symlink per gestire più configurazioni insieme ed altro che non vengono molto (anzi, per niente) pubblicizzati dal manuale. Essendo però gli unici modi per ovviare a queste (secondo me) falle di design, la community è arrivata persino a sviluppare dei piccoli programmi Ruby per fare proprio queste cose qui.

Ansible non sfugge a questa regola, grossomodo: io ho da subito avuto un problema col fatto che avrei voluto memorizzare in un unico repository Git tutte le informazioni riguardo i miei playbook e riguardo i server, ma la manualistica di base consiglia di mantenere la lista degli host nel file di configurazione /etc/ansible/hosts.

È una cazzata.

Ansible stesso, ho scoperto dopo un po’, permette di dargli in pasto un altro file in cui vengono descritti gli host (detto inventory file), da un path arbitrario, residente anche nella directory in cui ci troviamo (ovvero il workspace in cui manteniamo i playbook). In questo modo possiamo avere file multipli che descrivono gli host di infrastrutture separate, condividendo comunque i playbook da lanciare sulle macchine, e consentendoci di memorizzare tutto all’interno di un unico repository Git che fungerà da singola fonte di verità per il nostro pattern di Infrastructure As Code.

Quello che basterà fare successivamente sarà puntare al nostro file chiamato infrastructure invocando Ansible e dandogli in pasto il playbook da eseguire:

$ ansible-playbook -i infrastructure playbook-number-one.yml

Rubo dalla documentazione ufficiale anche un albero di come è indicato tenere il workspace del repository dei playbook. Come si può vedere, nessuno ci dice di tenere gli host in un file lì dentro, ma come per magia nelle best practice il file compare da solo. Nice job 😁

production
staging

group_vars/
   group1
   group2
host_vars/
   hostname1
   hostname2

library/
filter_plugins/

site.yml
webservers.yml
dbservers.yml

roles/
    common/
        tasks/
            main.yml
        handlers/
            main.yml
        templates/
            ntp.conf.j2
        files/
            bar.txt
            foo.sh
        vars/
            main.yml
        defaults/
            main.yml
        meta/
            main.yml
        library/
        lookup_plugins/

    webtier/
    monitoring/
    fooapp/

Tutto molto molto carino.

Business as usual: i ruoli e tutto il resto

Il resto della roba che Ansible mette a disposizione è molto simile a Chef, ma senza la complicazione di avere un agent che gira sulle macchine. Abbiamo i ruoli, che possono essere scaricati anche da Ansible Galaxy installandoli nel proprio repository, e che permettono di partire da una base già solida per quanto riguarda il riuso dei playbook dato che fungono da “moduli” in cui organizzare lo stato desiderato delle macchine. Abbiamo il templating, come ho già scritto, e un linguaggio che anche se non è simile a Ruby e non è potente allo stesso modo, fa decisamente quello che serve permettendoci persino di iterare attraverso oggetti multipli (esempio: la copia di più file, o l’installazione di più pacchetti nella stessa action).

Personalmente ho trovato Ansible molto comodo rispetto ad altre soluzioni di configuration management. Non ho nemmeno provato Ansible Tower, che Red Hat tenta di appizzarci appena diamo un’occhiata al sito. Sembra una figata, ma semplicemente non ne ho ancora avuto bisogno e mi sento di dire che sto bene così. Non so cosa possa fornire in più rispetto al sistema manuale, forse qualche chicca di eyecandy. Chef di solito lo gestivo in combo con la web console anche per motivi di usabilità, con Ansible non mi sento in pericolo sotto questo aspetto.

Conclusioni

Prima di questa piccola esperienza, continuavo a chiedermi come mai nessuno avesse la mia stessa opinione sui tool di configuration management. Dopo aver provato Puppet e Ansible, credevo semplicemente che nessuno avesse pensato a risolvere i problemi in una maniera molto più terra-terra, sicuramente meno adatta alle infrastrutture giganti formato Facebook, ma molto più alla portata di chiunque non voglia stare ad impazzire appresso alle sue macchine.

Chef nello specifico è fantastico, ma trovo che non avendo io un milione di macchine non sia esattamente quello che mi serve. Viceversa a me serve qualcosa che si connetta ad un’altra macchina o ad un altro set di macchine, e faccia da grosso wrapper di SSH, senza il bisogno di un server centrale o di client strani che si eseguono ogni tot minuti.

La risposta alle mie domande è stata Ansible.

Time for a goodbye

Tutto quello che ha un inizio, ha anche una fine. Sembrano le parole dell’Oracolo di Matrix, invece è solo banalmente quello che è successo negli ultimi tempi per me in Sourcesense; ho percepito che fosse arrivato in qualche modo il mio tempo, e che fosse venuto con questo il momento di misurarmi con qualcosa di nuovo.

Nel momento in cui abbozzo questo post sto formattando la mia macchina aziendale, e mi vengono in mente un sacco di esperienze che ho vissuto qui, e soprattutto un sacco di persone a cui dire grazie:

• Paolo Mariotti: quando ero un imberbe fanciullo mi ha insegnato meraviglie frontendistiche e javascriptistiche (ma si dice?) che non avrei mai immaginato;
• Ludovico Cafarelli: il mio sponsor, ha sempre creduto in me, e mi ha fatto sempre sbattere il muso sui lati peggiori del mio carattere;
• Matteo Nobili: perché è pelato;
• Eugenio Marzo: i nostri venerdì in Viale Europa mi hanno insegnato che c’è sempre una soluzione a qualsiasi problema che sarebbe meglio non far sapere troppo in giro perché fa cagare (e ricordati le best practice!);
• Piergiorgio Lucidi: lui e il suo gemello malvagio Piergioegio (che è nato quando gli hanno sbagliato il badge al Devoxx) mi hanno insegnato a conciliare la ricerca continua di novità con un approccio più orientato al mondo enterprise;
• Manuel Felici: il pulcino di tutti che adesso è un bel basilisco;
• Valerio Luzzi: no matter the day, every day is sushi day.

Con Sourcesense ho raggiunto dei traguardi notevoli, come notevoli sono state le persone che mi hanno accompagnato nel mio viaggio.

Chiariamoci: è decisamente una Sourcesense diversa dalla Sourcesense che ha fondato Gianugo Rabellino. Non è una realtà immune dalle arrabbiature, anzi: tuttavia è una compagnia che mi ha fatto crescere in modo esagerato, insegnandomi a lavorare con persone alle quali non ero esattamente affine (che non è banale), dando valore a tutto il ventaglio delle mie capacità, mettendomi alla prova e non facendomi annoiare mai.

A chi applica oggi per una posizione in Sourcesense, dico che fa bene: rispetto alla media delle società di consulenza romane, è un’azienda che spicca e che ha anche delle potenzialità di sbocco interessanti vista la sede a Milano e soprattutto quella a Londra. Chi sa forgiare il proprio cammino nel modo giusto da Sourcesense può ottenere esperienze internazionali e l’expertise di vicini di scrivania veramente preparati e appassionati. Forse tra i più appassionati e preparati che possiate mai trovare a Roma.

fork()

Non ho lasciato Sourcesense per l’ignoto. Presto arriveranno novità. Qualcuno già le sa, ma prima di fare annunci a gran voce vorrei ambientarmi e capire che direzione ho intrapreso (si, non lo so nemmeno io…).

Alle persone che ho incontrato in questi anni, come a quelle che ho menzionato direttamente pocanzi, devo un enorme ringraziamento, perché sono tra quelle responsabili di ciò che sono oggi. E io sono molto fiero di quello che sono oggi, almeno per i tratti positivi del mio carattere 😁

:wq

La Node.js Foundation lancia il Node.js Certification Program

Non c’è molto da dire su questo, ma è una piacevole notizia che la Node.js Foundation abbia deciso di aprire il suo programma di certificazioni su Node.js:

Node.js Foundation is worked closely with The Linux Foundation to create the blueprint and process for administering the program. The Linux Foundation offers a neutral home for running training and certification programs, thanks to its close involvement with the open source community.

Onestamente penso che questo aiuterà Node ad affermarsi sul mercato, e ad essere una piattaforma considerata maggiormente come enterprise-ready, per quanto possa essere considerata enterprise-ready una piattaforma che fa leva su un linguaggio debolmente tipizzato e tradizionalmente ritenuta “da frontendari”.

Nonostante questo, a ognuno le sue pecche, e a me piace. 😬

Il Mac Mini è morto, lunga vita al Mac Mini

Russell Ivanovic ha scritto un pezzo interessante che avevo inspiegabilmente perso, in cui spiega il suo iter da un Mac Mini in salotto ad un Mini PC Intel con Windows 10:

Do I actually need this computer to run macOS? I quickly realised I don’t. I need Chrome, I need a few basic apps and I need my Elgato EyeTV Diversity USB stick to be supported so I can watch TV. It turns out there’s another OS that has all those: Windows. I’ve had Windows 10 on a gaming PC I built over 6 months ago and I’ve not had a single problem with it. It’s never bothered me, needed rebooting because it was flakey or even broken a sweat doing all the things I’ve asked of it.

Quello che continuo a non capire è come mai Apple continui ad inseguire la chimera di una rivoluzione sui propri laptop, senza consegnare alla propria utenza degli attrezzi con cui lavorare fuori da quello specifico fattore di forma. La cosa che per molti anni mi ha affascinato di Apple (a prescindere dai prezzi folli) era questa: hai bisogno di un mini PC? C’è il Mac Mini. Un portatile? A bizzeffe tra MacBook e MacBook Pro (che all’epoca erano veramente Pro). Necessità di lavorare con un hardware super-duper? Ecco il MacPro.

Una variegatura (e non ho parlato degli iMac) che oggi è solo un ricordo, con una linea d’offerta ridotta non dico al lumicino ma, beh, quasi - e soprattutto utenti che delusi si guardano intorno per scoprire che Microsoft può dargli quello che Apple ormai si rifiuta di dare. O addirittura che Linux è un’alternativa possibile.

KDE Slimbook, ultrabook (fichissimo) con il cuore di un draghetto

Ieri sera tra una sessione di terminale e l’altra ho visto spuntare come funghi in giro per l’internet una cosa molto, molto affascinante, ovvero il KDE Slimbook. Mi ha fatto alzare la testa per due ordini di motivi:

• Il primo è che è pensato per la mobilità, con un design che prende a piene mani dal MacBook Air di Apple, la quale però non ha intenzione (pare) di avventurarsi in un revamp di quella specifica linea;
• Il secondo è la realizzazione portata avanti a stretto contatto con la community di KDE, tramite l’interazione con dei membri selezionati molto vicini al progetto. Quello che è venuto fuori è un prodotto a mio parere competitivo, forte di una metodologia di creazione che in pochi possono permettersi di adottare e in ancora meno hanno effettivamente voglia di applicare.

A riguardo, è interessante leggere sicuramente il post ufficiale di KDE ma anche quello di Harald Sitter:

Naturally, as one of the neon developers, I was doing some software work to help this along. Last year already we switched to a more reliable graphics driver. Our installer got a face-lift to make it more visually appealing. The installer gained an actually working OEM installation mode. A hardware integration feature was added to our package pool to make sure the KDE Slimbook works perfectly out of the box. The device looks and feels awesome. Plasma’s stellar look and feel complements it very well making for a perfect overall experience.

Il form factor

Sicuramente guardando al form factor cadiamo nella trappola del “not invented here”, per il semplice fatto che viene sfruttato un concetto di scocca già implementato da altri e rodato fino allo sfinimento, per consegnare all’utente un’esperienza che non porta nulla di nuovo.

Da una parte è vero che questa macchina è una copia spudorata di un MacBook Air, dall’altro lato è vero allo stesso modo che nello specifico il MacBook Air ha un feeling estremamente sexy, e dato che a molti attuali utenti Apple (soprattutto power user) interessa un revamp di qualcosa di simile, potrebbe addirittura far alzare un sopracciglio a chi cerca un buon rimpiazzo per il proprio Mac e vuole passare a Linux.

La spesa

Un KDE Slimbook non viene via a poco, anzi. Però con la combo che ho scelto io viene comunque 300 euro meno di un Macbook, che insomma, buttali via. Quello che mi piacerebbe capire invece è quanto, a fronte della spesa abbastanza elevata, mi venga restituito in qualità costruttiva: il confronto con un MacBook viene spontaneo, e sicuramente pur costando un prodotto Apple un occhio della testa è vero che una volta pagato quel rene che ti viene chiesto, hai un prodotto che dura un sacco di tempo (parlando di computer, eh, beninteso: con i telefoni è tutta un’altra storia) e rimane solido come appena uscito dalla scatola.

Prodotti wannabe-equipollenti, con la stessa scocca, purtroppo all’interno non risultano essere assemblati a dovere, nei casi più eclatanti addirittura messi insieme col nastro adesivo, e alla fine pur pagando sensibilmente meno si rinuncia ad avere un portatile rock-solid.

Siccome a me questo aspetto del mio MacBook Pro piace molto, sarei curioso di sapere come si pone lo SlimBook da questo punto di vista. Ovviamente questa strizzata d’occhio non troppo velata significa che se state leggendo questo post e me ne inviate uno sarà mia cura recensirlo con tutti i crismi.

Tornando al punto iniziale, ho visto che recentemente Apple ha impoverito molto persino le possibilità di configurazione degli Air, mentre questo laptop ha una flessibilità molto alta in fase di build, permettendoci di arrivare fino a 16GB di RAM (dove un MacBook Air arriva a 8GB ed è grasso che cola).

Linux come cittadino di prima classe

Quello che mi ha affascinato enormemente di questo progetto è ciò che hanno fatto gli sviluppatori di KDE/KDE Neon con l’aiuto di un manufacturer che voleva semplicemente offrire un ultrabook con Linux. Quello in cui si è tramutato il tutto è stato un piacevole tentativo (riuscito, poi bisogna vedere se le persone premieranno lo sforzo) di fornire a un bacino di utenza di base non enorme la possibilità di avere un hardware testato e ritestato su cui ottimizzare i comportamenti del software, una sorta di macchina di riferimento su cui eseguire benchmark di qualsiasi tipo da quelli di usabilità a quelli di comportamento.

Questo rende Linux un cittadino di prima classe su questo laptop esattamente come macOS sui Mac, e me lo rende onestamente appetibile, anche perché per un tempo abbastanza lungo dopo essermi allontanato dal fronte GNOME sono stato un vero e proprio fanboy KDE. Date queste premesse, e data la flessibilità che offre la piattaforma di Plasma, penso che un OEM abbia spazio per inserire tante personalizzazioni senza rovinare l’esperienza utente di base di KDE. Allo stesso tempo sono piacevolmente sorpreso di come gli sviluppatori di KDE si stiano preoccupando di come possa apparire la loro software compilation su una macchina e su quella soltando, andando a risolvere problemi che riguardano anche il coupling tra la componente “interattiva” del computer e quella “fisica”.

Detto ciò, sono molto, molto curioso di capire come possa performare un altro sistema Linux su questo hardware, tipo Arch Linux con GNOME Shell. 😬 😬 😬