Penso di essere d’accordo con il 101% di questo post:
Blogging is not just for “thought leaders” or “internet marketers” anymore. It’s becoming an essential tool for everyone — particularly engineers — to survive in the new talent economy.
E ancora:
It forces you to think. When you write about something, you’ll think hard about it. So overtime you’ll become a better thinker. More importantly, over time you’ll think clearly. Clarity of thought is an essential ingredient for leadership.
Ho sempre considerato il mio blog un modo molto furbo per mettermi nero su bianco e fare del mio pensiero un condensato strutturato. Col tempo mi sono accorto di quanto questo fosse importante per la mia vita (posso dirlo? Non solo professionale), e come mi aiutasse. Sinceramente, ho ricevuto complimenti da vari recruiter per l’adozione di un mezzo simile.
Ultimamente ho iniziato a guardare con un certo interesse Budgie Desktop, che da essere semplicemente la shell grafica di Solus ha iniziato un percorso che l’ha portata ad essere prima un progetto ben scritto ed autoconsistente, poi ad avere una variante di Ubuntu dedicata, e ad essere persino inclusa nei repository di Arch Linux.
Nel loro ultimo post sullo stato dell’arte del progetto, gli sviluppatori spiegano così quello che loro chiamano “deGNOMEing”:
Originally, Budgie intended to integrate with GNOME applications. What actually happened is that it then fully integrated into the GNOME stack. We got our integration, but at a heavy cost. Over time, as GNOME has evolved, every single major release of GNOME has caused issues for Budgie.
E ancora:
It didn’t start out like this of course, but as the GNOME platform evolves, so must derived desktops to maintain the integration. As such, our roadmap for Budgie 11 set the priority of undoing this deep coupling to the GNOME stack, and moving away from Vala, to regain control over the experience, feature-set, and stability, of the Budgie Desktop.
Secondo me è una scelta sensata. Ora come ora, va molto bene salire sulle spalle dei giganti per consegnare un prodotto a una community; Unity su Ubuntu fa questo da anni, e anche Budgie ha circa lo stesso atteggiamento.
Una volta identificate le prospettive di miglioramento però, GNOME non si dimostra in grado di offrire a chi sfrutta questo lavoro una prospettiva di affidabilità a lungo termine. Va bene così, perché rendere i componenti base anche di altri desktop non fa parte dei traguardi che il progetto si pone; tuttavia questo significa che una volta implementato il prodotto, terze parti sono costrette a riscrivere tutto da zero per uscire dai binari.
11 Feb 2017
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.
05 Feb 2017
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 😁
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. 😬
