24 Oct 2017
Onestamente? Sono anni che voglio imparare Kubernetes. Peccato che per qualche motivo finisca sempre per capitolare; il più fallimentare dei miei tentativi è stato quando per far partire un numero spropositato di “minion” in UniquID che simulassero un dato comportamento ho infilato tutto in dei container: pur volendo imparare a installare un cluster Kubernetes, alla fine sono tornato per mancanza di tempo ad una gestione manuale tramite un programma in Python scritto da me.
Stufo della mia ignoranza, da qualche settimana ho deciso di partire con un crash course di Kubernetes. La prima cosa che ho fatto, avendo fallito completamente in passato con il setup di un cluster non capendo nemmeno dove mettere mano, è stata darmi una calmata installando Minikube sul mio computer.
Minikube
Da quando ho fatto tableflip l’ultima volta cercando di capire come funziona il setup di un cluster Kubernetes, è uscito Minikube. Grazie a Minikube possiamo installare un cluster di un singolo nodo master di test all’interno della nostra macchina; la pagina di manuale dedicata è abbastanza estesa.
Una volta installato e configurato kubectl (sulla mia workstation ho usato Homebrew, per Arch Linux come al solito è tutto su AUR, per Debian e CentOS/Red Hat se non lo trovate nei repository ci sono modi alternativi) è toccato all’eseguibile minikube essere installato in /usr/local/bin. La guida spiega come fare con un curl, e io ho semplicemente (una volta controllato che lo script che stavo scaricando non facesse cose strane) installato il binario in questo modo.
Con minikube start poi l’ho lanciato, ed è partita la fase di setup che richiede qualche minuto. Una volta completata la guida del kickstart deployando il container che ha dentro una sorta di applicazione “hello world”, ho fatto qualche altro esperimento deployando Grocery, ovvero il mio webserver scritto in C che ho svolto come progetto universitario qualche settimana fa.
Per deployare il container è necessario un comando simile a questo:
$ kubectl run hello-grocery --image=registry.hub.docker.com/dottorblaster/grocery --port=8080
È importante notare l’URL che abbiamo dato in pasto a kubectl, perché l’unica via per me di reperire come sono fatti i resource locator di immagini presenti su Docker Hub è stato scavare dentro StackOverflow. Quindi, tanto per chiarire, per deployare un container costruito a partire da un’immagine che si trova sul Docker Hub, dobbiamo prependere al nostro solito nome di immagine il dominio registry.hub.docker.com.
Dopodiché per rendere il container accessibile al mondo esterno dobbiamo esporre il deployment tramite la rete interna. Questa cosa mi disturba leggermente, nel senso che già Docker fa da discreto layer di astrazione con il suo mapping di porte esterne al container a porte interne, in più con Kubernetes andiamo ad aggiungere strati su strati di complessità, che ovviamente però per grandi ambienti e infrastrutture ingombranti diventa necessaria.
$ kubectl expose deployment grocery --type=NodePort
Fatto! Abbiamo deployato il nostro container.
Non è che l’inizio
Per una prova al volo, questo era quello che mi interessava, che però non mette in risalto nemmeno un millesimo delle potenzialità di Kubernetes. Volevo iniziare a fare altre cose ma la mia versione locale di kubectl era troppo aggiornata rispetto a quella di Minikube, così invece di risolvere questo problema ho preferito aspettare direttamente un aggiornamento di Minikube studiando altro.
Setup di un cluster Kubernetes
Invece di continuare a pasticciare con Minikube il quale forse è il tool migliore per studiare Kubernetes che io abbia mai visto, sono andato a cercare sul manuale come fare setup di un cluster on premise. Abbastanza sepolto sotto ogni offerta cloud di ‘sto mondo ho trovato effettivamente il modo, con varie alternative.
Nello specifico quelle che ho apprezzato di più sono kubeadm, che è il tool principe per l’amministrazione di un cluster, e Kubespray, che consiste in un insieme di playbook Ansible che non fanno altro che orchestrare l’uso di kubeadm per rendere più semplice il mantenimento del cluster.
Prossimi step
Per ora termino qui, tuttavia il mio “learning path” relativo a Kubernetes credo sia ben lontano dall’essere anche solo cominciato. Tutto quello che ho appena appuntato mi serve, perché trovo che la documentazione di Kubernetes oltre ad essere dispersiva sia molto incentrata sul “compra hosting Kubernetes dai migliori provider” – che è sicuramente quello che ogni azienda con un po’ di sale in zucca dovrebbe fare, ma non è decisamente il miglior modo per un “junior” di imparare come funziona il giocattolone.
I prossimi passi:
- Setup vero di un cluster usando
kubeadm
- Deploy di un’applicazione stateful con uno stack classico webapp + database, per imparare a gestire anche questa grana
👋
20 Oct 2017
Altro giro di Homebrew su macOS, altra storia dell’orrore (sort of: ne ho sentite di molto peggiori) su “cose a caso”: scrivo “cose a caso” perché effettivamente non ho capito che cosa cacchio stesse cercando di fare il mio computer, e cosa diamine sia successo nel frattempo.
Andando con ordine, questa settimana ho trovato un bug su un bot Telegram che ho scritto in Elixir. Provando a compilare il fix in locale, ho trovato un’incompatibilità tra la vecchia versione di Erlang che avevo installata, e macOS High Sierra a cui ho aggiornato da poco. Ho deciso quindi di aggiornare i miei package locali, ma:
Error: Your Xcode (8.3.spicci) is outdated. Please update to Xcode 9.0 (or delete it). Xcode can be updated from the App Store.
Ok. Vado sull’App Store, e vedo che XCode non mi viene segnalato come installato. Strano: ricordo di averlo, ma effettivamente non riesco a vederlo nemmeno dal drawer delle applicazioni. Dopodiché metto ad installare gli svariati giga della versione 9.0, mentre penso “ma vuoi vedere che basta aggiornare solo i command line tools?”; nell’ordine sono successe le seguenti cose:
- Ho usato
xcode-select --install per cercare aggiornamenti nei CLI tools, e ne ho installato uno (che non specificava la versione);
- Nell’App Store mi è comparsa la voce di aggiornamento ai CLI tools 8.3.spicci (che avevo appena portato a termine), e ho aggiornato;
- L’App Store mi ha successivamente proposto l’aggiornamento ai CLI tools 9.0, che ho installato;
- Lanciando
brew upgrade ottengo lo stesso errore.
Ho lanciato il computer nello zaino e me ne sono andato al meetup di Rust che mi attendeva. La mattina dopo mi viene lo sghiribizzo di controllare meglio: il laptop mi accoglie con un popup che mi informa del download di XCode 9.0 fallito (cominciamo bene), e a me viene in mente di lanciare una find su /Applications giusto per capire; infatti scopro che ho una versione di XCode installata, a ‘sto punto non tanto a mia insaputa quanto a insaputa del sistema operativo. Provo a cancellarla, e a rilanciare brew upgrade.
Funziona.
Poi dicono che Linux è difficile.
17 Oct 2017
È già da un sacco di tempo che volevo risolvere questo piccolo problemino ma non trovavo la voglia dato che per lavoro uso sempre qualche altro editor: installando Vim da Homebrew su macOS, il backspace non funziona più come dovrebbe in insert mode.
Per riavere indietro il vecchio comportamento, basta inserire questa riga alla fine del proprio vimrc:
Vim da Homebrew
Giusto come annotazione, installare Vim da Homebrew serve, dato che la versione installata di default con macOS è un po’ vecchiotta, e quello che accade è semplicemente che alcuni plugin, magari facenti uso di feature più recenti, non si comportano come previsto.
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 ;)
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! 😎
