Alessio Biancalana Grab The Blaster di Alessio Biancalana

Cosa fa di un DevOps un DevOps?

Eugenio Marzo, che oltre ad essere un professionista preparatissimo è anche il mio ex capo, scrive su Mokabyte:

Parafrasando uno dei film culto degli anni Novanta (“Cos’è… cos’è; che fa di un uomo un uomo, signor Lebowski?”) vorrei parlare dei principi base per definire i caratteri distintivi dell’area DevOps, le caratteristiche e le competenze che deve possedere un professionista che operi in quest’area. In breve “Cos’è che fa di un DevOps un DevOps, signor Lebowski?”.

A parte la precisazione doverosa per cui DevOps non è un job title ma il nome di una corrente di pensiero e della conseguente metodologia, Eugenio ha la sua bella parte di ragioni e questo post va sicuramente letto.

Ho pensato di annotare qui anche quello che gli ho lasciato come commento su Facebook (sai mai che Zuckerberg impazzisse e cancellasse tutto il DB di produzione stanotte):

Condividere la conoscenza, abbattere i silos e fare team

E sai meglio di me che è questo quello che fa veramente di un devops un devops, e che è la cosa più difficile da raggiungere perché in qualsiasi azienda vai, ti metteranno in mano l’infrastruttura dicendo “questo è il traguardo che vogliamo ottenere, ma non vogliamo muoverci di un millimetro per ottenerlo, tantomeno faticare”.

Comunque grande post :) concordo anche sulla scelta critica dei tool, anzi, aggiungo un punto mio: meno tool ma scelti bene fanno infinitamente meglio di tanti tool messi “tanto per”, solo per far sganciare i soldi di qualche licenza ;)

Marco Pracucci: stepping back from CTO and jumping into operations

Conoscete Marco Pracucci? No? Fate male. È l’ormai ex-CTO di Spreaker, e recentemente ha fatto qualcosa che mi ha veramente colpito rinunciando al suo ruolo di CTO per assumere il ruolo di Tech Operations Lead nella stessa azienda.

Non capita molto spesso di vedere persone che fanno una scelta simile, né di aziende che permettono a qualcuno di farla. Questo indica tre cose:

  • Fiducia di tutta l’azienda nelle persone che compongono la sua leadership;
  • Un atteggiamento incredibile da parte di Marco: è difficile che una persona rinunci al suo ruolo per fare un passo indietro quando vuole fare altro – di solito si tende a mantenere entrambi i ruoli e a fare male tutte e due le cose;
  • Un’azienda in cui è possibile riconfigurare il proprio compito, facilmente o difficilmente che sia.

Applausi! 😎

Writing a GTK Video Player with Haskell

Onestamente, uno dei linguaggi su cui ho sbattuto la testa sempre cavare un ragno fuori dal buco in tempi ragionevoli è proprio Haskell. Ho trovato straordinariamente interessante questo post, più che altro perché mostra un esempio pratico.

Oltre questo, è molto molto fico che venga adottato un linguaggio funzionale per scrivere un’applicazione desktop ❤️

Sviluppare un programma in C con Docker (si, è una figata)

Docker logo in ASCII

In questo periodo non ho scritto moltissimo sul blog, ed il motivo principale è che oltre al lavoro e a qualche progettino personale, sono stato impegnato con il webserver che avevo da scrivere per il mio esame di Reti di Calcolatori (che è uno dei “perk” dell’essere ancora uno studente di triennale a ventisei anni). Trovandomi a sviluppare su parecchie piattaforme ed essendo il target principale un sistema operativo generico Linux, ho avuto il piccolo problema di sviluppare parte del codice sul mio portatile con macOS: ovviamente non potevo testare bene qualsiasi cosa facessi, e non avevo così tanta voglia di portare a Darwin tutto quello che avevo scritto, quindi mi sono ingegnato per trovare una soluzione nel più breve tempo possibile.

All’inizio ho provato con una macchina virtuale e con qualche server sparso in giro per il mondo. È un buon approccio se uno ha voglia di perder tempo. Viceversa dopo un po’ mi sono detto: “E se provassi con Docker costruendo un container per debuggare?”

Docker to the rescue

Dopo aver dato una scorsa al manuale per togliere la ruggine sulla sintassi dei Dockerfile, ho deciso di creare il mio container per Grocery. Sono partito in realtà da quello definitivo che è veramente piccolino, creando una directory docker all’interno del mio repository e andandoci a scrivere questo file Dockerfile:

FROM alpine:3.6

RUN apk update
RUN apk add --no-cache build-base imagemagick

RUN mkdir /grocery
RUN mkdir /grocery/www
RUN mkdir /grocery/cache

ADD . /grocery

WORKDIR /grocery
RUN make clean release

RUN apk del build-base

VOLUME /grocery/www

CMD ["./grocery", "8080"]

Niente di trascendentale: installo le dipendenze dell’applicazione (che consistono in ImageMagick e pochissimo altro), riempio il container dei file sorgenti, li compilo come se fossi in una fakeroot ed espongo un volume per la directory da cui il webserver dovrà leggere i file. Period. Successivamente, avendo a disposizione un Makefile con vari goal ho inserito quello per fare il build della mia immagine.

...

build_docker:
	sudo docker build -t grocery -f docker/Dockerfile .

...

In questo modo attraverso un semplice make build_docker ho potuto costruire ogni volta che ne avevo bisogno un container con una versione “freezata” del programma.

Successivamente, ho visto che non solo questa roba funzionava, ma mi consentiva effettivamente una portabilità del package su qualsiasi sistema operativo senza perdere nulla e senza dover impazzire dietro a cambiamenti infrastrutturali dovuti all’OS che ospita il container. Docker in questo senso essendo un layer di compatibilità ci permette di risparmiare veramente tanto tempo.

Un container per lo sviluppo in C

Dato che il mio container “per la produzione” funzionava, ho deciso di muovermi leggermente oltre, creando un equivalente per lo sviluppo che ad ogni restart prendesse il codice, lo ricompilasse e lo eseguisse senza dover fare repackage. Questo possiamo farlo grazie ai volumi e grazie alle istruzioni per lo start del container.

Ho quindi dotato la directory docker del mio progetto di un file Dockerfile.test, contenente quanto segue:

FROM alpine:3.6

RUN apk update
RUN apk add alpine-sdk imagemagick

RUN mkdir /grocery
WORKDIR /grocery
VOLUME /grocery
EXPOSE 8080

Successivamente ho inserito nel Makefile due goal, uno per costruire l’immagine di test e uno per eseguirla:

...

build_docker_test:
	sudo docker build -t grocery_test -f docker/Dockerfile.test .

docker_test:
	sudo docker run -d -P -p 8080:8080 --name grtest -v $(shell pwd):/grocery grocery_test \
		make debug run

...

Su questo abbiamo un po’ di cose da dire: costruendo il container di test esponiamo un volume, sul quale poi montiamo la nostra directory con i sorgenti. Subito dopo possiamo tramite un make docker_test inizializzare un container che prenda la nostra directory corrente, la monti come volume, e ricompili il codice eseguendo il binario.

Tra l’altro mi sono accorto ora che c’è una inception perché questo è un goal di un Makefile che esegue un altro make, stavolta containerizzato.

In realtà non c’è molto da dire: avremo il container in listen sulla porta 8080 ma possiamo anche rimapparla a nostro piacimento se ci dà fastidio; e questo container ci abilita a fare docker restart grtest (o qualsiasi altro nome voi diate al vostro, di container) per far si che istantaneamente il codice si ricompili e ricominci ad eseguirsi. Il passo ulteriore che potrebbe essere fatto è quello di monitorare per cambiamenti ai file del codice sorgente per l’autorestart del container, ma sinceramente non avevo voglia di arrivare così lontano.

Sono andato rapido, anche un po’ troppo, perché ritengo che questo piccolo lavoro di “ricerca” sia banale e sia ancora meglio guardare un caso di studio reale per poi adattarlo al proprio progetto. In ogni caso, in questo modo ho reso il mio codice C indipendente dal sistema operativo usato per lo sviluppo, quindi da parte mia non posso che consigliarlo a chi fa sviluppo C per processori con architettura i686/x86_64 😸

Il progetto, per chiunque avesse voglia di dargli un occhio, è ovviamente su GitHub.

Image courtesy of Tit Petric, whose post is amazing and full of interesting tips. 😁

XFree KWin, aka KWin senza XWayland

Il buon Martin Graesslin ci aggiorna sullo stato dell’arte di Wayland e KDE. In particolare, adesso si sta concentrando sul far partire KWin senza XWayland, ovvero il layer di compatibilità tra X.org e Wayland.

Gran parte del lavoro è fatta, ma c’è ancora parecchio da sistemare:

[…] my personal main goal is to be able to handle a crashing XWayland. This will also be an interesting task as the X11 code in KWin also depends on other libraries (e.g. KWindowSystem) which do not expect to outlive the X server […]

E da parte mia non posso che augurargli buona fortuna.