Come dare fastidio a chi ascolta la radio in spiaggia ( a volume molto alto ) e interrompe il vostro momento zen

Un saluto estivo a tutti i lettori di devopsrecipes.info 😉

Le mie vacanze si avvicinano e presto potrò finalmente allontanarmi dal caos cittadino… Nel mio zaino, oltre ad set di birre ricercatissime ( una paio di Peroni da 66 ) quest’anno ci sarà anche un trasmettitore radio FM pirata, nel caso qualcuno disturbi il mio sonno sentendo la radio ad alto volume… Se vi siete drogati, è molto probabile che la musica che sentite non è trasmessa da alcun vicino, per cui andate a prendervi un Calippo.

listening-to-old-time-radio-on-the-beach

Procuratevi più o meno le seguenti cose, oppure compratevi un trasmettitore radio su Amazon ( però sappiate che è poco fico comprarlo già fatto o scaricare app )

  1. Un Raspberry PI
  2. Un alimentatore portatile per smartphone ( meglio se ad energia solare)
  3. Una pennetta wireless
  4. Uno script in php per la gestione tramite interfaccia web (https://github.com/lucky-sideburn/piratepiwave.git)
  5. Il software https://github.com/rm-hull/pifm per l’erogazione del segnale FM
  6. Il vostro smartphone

Perchè il punto 4?

Non mi andava assolutamente di smanettare troppo con le GPIO per collegare uno schermo LCD e un regolatore di frequenza, per cui ho preferito controllare il trasmettitore tramite il mio telefono.

  1. Per prima cosa installiamo un web-server Apache + Php sulla nostra Raspbian Jessie Lite ( naturalmente ognuno è libero di usare il sistema operativo e/o web-server che preferisce )
  2. Se siete pigri potete anche prendere il mio script php https://github.com/lucky-sideburn/piratepiwave.git ( non sono un web-developer quindi si, l’interfaccia grafica non è cool )
  3. Installate https://github.com/rm-hull/pifm in /usr/local/pifm ( nella documentazione trovate a quale GPIO agganciare un’antenna fatta con un filo )
  4. configurate scheda di rete di Wifi per collegarsi all’hotspot del vostro smartphone ( dal pannello di amministrazione ricaverete l’ip assegnato )
  5. mettete tutto in autostart al boot, agganciate batteria esterna al raspino e dal vostro smartphone date un http://$ipdelraspberry

Cosa facciamo suonare sulla radio del “disturbatore momento zen”?

Copiate le vostre tracce audio preferite ( pure teknone spinto ) in /usr/local/pifm/sounds e modificate il puntamento al file audio che troverete nello script php.

Come seleziono le frequenze FM?

Potete usare la comodissima barra in alto

Screen Shot 2016-08-15 at 11.25.27.png

Oppure farvi dei tastini tipo questi con le frequenze radio già impostate

Screen Shot 2016-08-15 at 11.28.20.png

Questo è il risultato finale

IMG_20160815_113020

buone vacanze!

Cos’è che fa di un Devops un Devops, signor Lebowski?

Vorrei parlare dei principi base del Devops che negli ultimi 5 anni ho potuto assimilare lungo il cammino.
Questo perchè dovevo preparare delle noiosissime slide. Mi serviva uno scopo, e un post sul blog ci sta tutto.

Inoltre, ho preso il dominio ziopinguino.it e sto pensando di migrare tutto il blog lì…

Quali sono i caratteri distintivi dell’area Devops?
Quali sono gli stereotipi e le considerazioni ricorrenti tipiche degli ambiti innovativi a cavallo tra buzzword e vera innovazione?

Cos’è che fa di un devops un devops, signor Lebowski?

Essere una BaaS? Buzzword as a service?

Lo era sicuramente all’inizio una buzzword, ma ora non più.
Lo è se si legge solo nei blog di Devops, se non si è potuto toccarne con mano i benefici e i risultati.

Nei contesti dove c’è stata una vera rivoluzione, la parola “Devops” descrive perfettamente figure professionali che svolgono attività di collegamento tra i gruppi di sviluppo e le operation. Queste attività si individuano nella forma di integrazioni di sistemi, sviluppo di piccoli tool e pubbliche relazioni (quando dai supporto…).

I Devops seguono tutta la catena di montaggio partendo dal codice fino al delivery e monitoring delle applicazioni.

Sono sistemisti che scrivono del buon codice, o programmatori che si muovono agili sulla shell.
Giocano con molte tecnologie e spesso trovano la parola chiave corretta su Google che gli risolve la giornata.

Stare attento a quando dici “alla vecchia maniera”?

Nell’IT non è previsto l’utilizzo di espressioni come “ai tempi miei” o “come si faceva un tempo”.

Un paio di scarpe fatto alla vecchia maniera è resistente e di qualità, ma un sistema fatto così, pur essendo stabile, verrebbe inevitabilmente visto come “anziano”.

Saggio in quanto anziano, ma con la barba bianca e lunga al posto dei baffetti hipster.
Non entro in merito sulla correttezza di tale giudizio, ma è innegabile dire che in molti contesti ciò accade.

Molte delle cose fatte un tempo funzionano egregiamente anche oggi e comunque le usiamo volentieri.

Dirò solo una cosa “Bash Rocks!”.

bash-logo-web

A volte però il cambiamento è fortemente consigliato.

Ad esempio, non è possibile sostituire un configuration management tool come Chef o Puppet con dello shell scripting. Concetti come idempotenza e auto-discovery richiedono comunque un effort nella loro realizzazione. E’ meglio quindi usare strumenti supportati da una community, piuttosto che scrivere componenti di cui poche persone mantengono la memoria storica.

Essere preparato su GIT?

Non può mancare una conoscenza approfondita di Git.
Servirà quando uno sviluppatore ti chiederà aiuto o quando prenderai in giro il tuo amico perchè lavora dove ancora distribuiscono il codice e le nuove release su aeroplanini di carta. Sull’ala destra c’è il messaggio di commit e su quella sinistra la versione. Se l’aeroplanino ritorna indietro per via di forti correnti contrarie hai fatto rollback.

Il pattern di “infrastructure as code” non può mancare e quindi serve “versionare”.

E’ importante sapere che lavoriamo in un ambiente deterministico e che possiamo pilotare piattaforme tramite codice.

Così “ciao ciao” documentazione, si legga il playbook di Ansible o il cookbook Chef (tutto questo in mondo immaginario…il “documentone” verrà sempre chiesto, però ultimamente sono sceso a compromessi per cui anche un bel markdown fatto bene può andare)

Ho imparato che tutto il lavoro svolto deve essere portabile. Un modulo Puppet o un cookbook Chef deve essere chiaro e leggibile. Sembra scontato ma non lo è.
Spesso automatismi e meccanismi agili all’interno delle nostre infrastrutture risiedono solo nella nostra conoscenza perchè le abbiamo sviluppate noi. Questo è poco Devops, perchè diventa comunque un silos. Un “agile silos”.

Scegliere i tool con senso critico?

Il landscape dei tool Devops è enorme.
E’ costellato di programmi che fanno a volte la stessa cosa e che competono a suon di stellette su github e loghi accattivanti.

Alcuni di essi sono veramente utili ed è divertente contribuire alle loro community. Altri vengono proposti “a cazzo di cane” in conversazioni di gruppo dove il tema parrebbe essere “spariamo a nomi a caso”.

Una specie di cyber flusso di coscienza << kubernetes! Prometheus!! Openshift!! Spark!! Mesos! Puppy Linux!! >>

Comunque… un Devops, come sceglie i tool da usare nell’opensource?

Evitare sicuramente di giudicare solo in base alla popolarità.

Se tale software viene utilizzato e contemporaneamente lo si reputa mediocre, si dovrebbe contribuire con quello che pensiamo possa portare un miglioramento.

L’opensource del resto è un qualcosa di tutti, potrebbe in un futuro prossimo diventare un bene di tutti. Forse il paragone è esagerato, ma migliorare il software contruibuendo è come pulire una strada per il bene della comunità, perchè hai necessità di percorrerla e se la percorri imprecando sembri un predicatore matto.

Condividere il knowledge, abbattere i silos e fare team?

Assolutamente si. Senza questi tre elementi probabilmente il mio lavoro sarebbe molto noioso. Sono punti fondamentali.

Mi viene in mente un modo di dire che ho coniato qualche minuto fa per cui non ne certifico la concretezza e neanche un senso logico: se detieni l’ownership di una procedura noiosa, non detieni l’ownership del tempo lavorativo mentre la fai.

Intendo che se ci è richiesto di intervenire solo perchè conosciamo una procedura che noi e solo pochi eletti siamo in grado di eseguire siamo distanti anni luce dalle metodologie Devops.

Non siamo owner di quel tempo che impieghiamo a concludere il task perchè qualcuno prima di noi ha deciso quanto sarebbe dovuto durare scrivendo passo passo un documento procedurale.

E’ compito di un Devops, a mio parere, arrivare al risultato scegliendo la soluzione più smart possibile.

Ecco tutto questo però dimenticatelo il venerdì pomeriggio… ben venga il noioso, il ripetivo e pure il “se funziona non lo toccare”.

E pure il “eh vecchio mio, mi ricordo quando mettevamo il notepad in cluster…”.

unnamed high-availabilityunnamed.png

Un giro su OKD 4 (parte 1)

L’impatto del ritorno dopo le vacanze è stato tragico. Avendo dimenticato tutto in merito a cosa fa un DevOps ho iniziato con un’attività molto leggera. Giocare con OKD 4, la versione community da cui deriva Openshift.

Già da un po’ di tempo è stato annunciato OKD 4 https://www.openshift.com/blog/okd4-is-now-generally-available e messo a disposizione della community un installer per provare il prodotto in locale. Mi ero abituato con Minishift o a farmi un cluster a due nodi (un master e un worker, 2 vm Vagrant e via con i playbook di installazione) ma devo dire che crc (Code Ready Containers) è molto comodo.

All’interno del repo GitHub del progetto (https://github.com/code-ready/crc) si trova un link a https://cloud.redhat.com/openshift/install/crc/installer-provisioned per scaricare ed installare il tool.

Una volta installato (fate in modo che sia in PATH, ho optato per un classico link simbolico /usr/local/bin/crc -> /Users/foobar/WORK/Openshift4/crc/crc) basta dare semplicemente crc setup e crc start. Non ha molto senso entrare in ssh nell’istanza di CoreOS di OKD 4 installata con crc ma per curiosità vi scrivo che si può fare così:

~$ ssh -i /Users/foobar/.crc/machines/crc/id_rsa core@"$(crc ip)"
Red Hat Enterprise Linux CoreOS 45.82.202007240629-0
  Part of OpenShift 4.5, RHCOS is a Kubernetes native operating system
  managed by the Machine Config Operator (`clusteroperator/machine-config`).

WARNING: Direct SSH access to machines is not recommended; instead,
make configuration changes via `machineconfig` objects:
  https://docs.openshift.com/container-platform/4.5/architecture/architecture-rhcos.html

---
Last login: Sat Aug 22 17:50:00 2020 from 192.168.64.1
[core@crc-fd5nx-master-0 ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.5

Una volta partita la vm, in output verrà mostrato come accedere da riga di comando tramite oc. Con oc console si può comunque reperire la password in qualsiasi momento

~$ crc console --credentials
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p DhjTx-8gIJC-2h2tK-eksGY https://api.crc.testing:6443'

Tramite crc console secco, invece, si aprirà magicamente la console di Openshift sul browser. A prima vista ci sono un sacco di cose che mi piacciono in confronto alla versione 3.11.

Feature interessanti da un primo sguardo alla web-console

  • La view divisa tra administrator e developer
  • La search bar per le resource e gli event. Molto utile anche se era più divertente fare dei bashoni con oc
  • La sezione OperatorHub
  • La sezione workloads per administrator è cross-namespace. Non c’è più bisogno di entrare nel namespace per vederne le risorse (questo è molto comodo, si fa troubleshooting più in fretta)
  • Nella sezione storage ci sono i PV. Da paura. Ci sono anche le storage-class. Mi spiace che tra i provisioner non ci sia quello per OpenEBS (https://openebs.io/)
  • Ok la parte compute è veramente utile (devo provarla però). La feature più interessante di questa sezione è il MachineAutoscaler per cui ciao ciao scale-up manuale (peccato era la cosa più facile lo scale-up tramite Ansible, su OKD. L’aggiornamento invece, su OKD e non su Openshift, era un cosiddetto bagno di sangue.
  • Sezione OAuths in Cluster Settings. È possibile configurare vari identity provider direttamente da web console

Aggiunta identity provider HTPasswd

# Creazione password file con htpasswd 
htpasswd -b -c fooobar foo bar

Upload del file tramite web console

Prova di login

$ oc login -u foo -p bar https://api.crc.testing:6443
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

Direi che OKD4, da un primo sguardo, ci piace parecchio ma ci sono molti aspetti da verificare e funzionalità da provare.

crc è sicuramente utilissimo per gli sviluppatori ma anche per i DevOps in caso vogliano dare uno sguardo.

Bella.

KubeInvaders on Openshift 4.1

Just add new special input key for KubeInvaders. Press ‘n’ to jump between namespaces!

ezgif-1-e88ad3f7a1e0

Recently I released a gamified chaos engineering tool for Kubernetes (it has been added in https://github.com/dastergon/awesome-chaos-engineering some days ago) and I would like deploy it on Openshift 4.1.

First of all, follow these two guides:

Openshift 4 Install Experience

Cluster Install

A today,  for trying Openshift 4 the best choise is by using AWS.  The openshift-install-linux utility installs a ready to use cluster through Terraform.

Screenshot 2019-05-02 at 21.01.55

The installation is very easy and after the execution of openshift-install-linux-amd64 I had just to follow instructions for connecting to my new Openshift cluster.

time="2019-05-02T10:58:45Z" level=debug msg="OpenShift console route is created"
time="2019-05-02T10:58:45Z" level=info msg="Install complete!"
time="2019-05-02T10:58:45Z" level=info msg="Run 'export KUBECONFIG=/root/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI."
time="2019-05-02T10:58:45Z" level=info msg="The cluster is ready when 'oc login -u kubeadmin -p xxxx succeeds (wait a few minutes)."
time="2019-05-02T10:58:45Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.kubeclu.kubeinvaders.io"
time="2019-05-02T10:58:45Z" level=info msg="Login to the console with user: kubeadmin, password: xxxx"

Screenshot 2019-05-02 at 21.06.28

Before to deploy KubeInvaders create a sample namespace in which run, for example, NodeJS applications. You can deploy it directly from the Openshift catalog.

Let’s install KubeInvaders.

# Clone KubeInvaders
git clone https://github.com/lucky-sideburn/KubeInvaders.git
# Do the following commands. 
# Same and updated guide on https://github.com/lucky-sideburn/KubeInvaders#install-kubeinvaders-on-openshift

# The namespace you want to stress
TARGET_NAMESPACE=foobar

# Choose route host for your kubeinvaders instance.
ROUTE_HOST=kubeinvaders.apps.kubeclu.kubeinvaders.io

# Please add your source ip IP_WHITELIST. This will add haproxy.router.openshift.io/ip_whitelist in KubeInvaders route
# https://docs.openshift.com/container-platform/3.9/architecture/networking/routes.html#whitelist
IP_WHITELIST="10.10.10.10"

oc new-project kubeinvaders --display-name='KubeInvaders'
oc create sa kubeinvaders -n kubeinvaders
oc create sa kubeinvaders -n $TARGET_NAMESPACE
oc adm policy add-role-to-user edit -z kubeinvaders -n $TARGET_NAMESPACE

TOKEN=$(oc describe secret -n $TARGET_NAMESPACE $(oc describe sa kubeinvaders -n $TARGET_NAMESPACE | grep Tokens | awk '{ print $2}') | grep 'token:'| awk '{ print $2}')
oc process -f openshift/KubeInvaders.yaml -p ROUTE_HOST=$ROUTE_HOST -p TARGET_NAMESPACE=$TARGET_NAMESPACE -p TOKEN=$TOKEN | oc create -f -

Open routes and go to KubeInvaders location

Screenshot 2019-05-02 at 21.11.53Screenshot 2019-05-02 at 21.12.12

Scale pods of foobar namespace to 20 replicas.

oc scale dc testapp --replicas=20 -n foobar

Screenshot 2019-05-02 at 21.18.58

I deployed also https://github.com/hjacobs/kube-ops-view because I find it very cool for watching pods distributed across node workers.

Screenshot 2019-05-02 at 21.31.26

This is how KubeInvaders works with Openshift 4.1.

 

Bye!

L’apologia dei progetti personali incompleti

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

Link al repo Github

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.

Screenshot 2018-11-22 at 21.24.29

Screenshot 2018-11-22 at 21.24.36

Il nome utente indicava la distribuzione Linux desiderata.

Screenshot 2018-11-22 at 21.11.32

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.

Link al repo GitHub

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.

congruit

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:

Screenshot 2018-11-10 at 17.42.22

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.

Screenshot 2018-11-10 at 17.54.54

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

Screenshot 2018-11-10 at 18.02.44

  • 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.

Screenshot 2018-11-10 at 18.07.35

Screenshot 2018-11-10 at 18.05.54

Oppure, per chi è curioso di sapere da cosa è composta un’applicazione su Openshift/Kubernetes invio un json contenente tutti gli oggetti creati.

Screenshot 2018-11-10 at 18.09.46

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.

Un laboratorio per Rancher, K8s, GlusterFS e la soluzione “del ferro economico” al quesito “dove provo tutta sta roba” #1

Ieri, per delle robe un po’ urgenti, mi occorreva avere uno stack ben definito intorno a Kubernetes.

Siccome siamo DevOps Engineer fighi ho scritto un po’ di moduli Terraform e in due minuti ho fatto tutto…

Non è vero c’ho messo tipo mezza giornata e l’ho fatto anche un po’ “a manella”.

Mi piace molto Kubernetes ma, da ormai svariato tempo, preferisco usarlo tramite Openshift soprattutto nell’ambito enterprise. Tuttavia, Rancher mi è piaciuto e lo vedo come una valida soluzione da proporre in determinati casi (magari produrrò un post del tipo Openshift Vs Rancher).

Non è comunque un’alternativa ad Openshift perchè sono due prodotti diversi.

Giuro che non ho abbandonato l’utilizzo sfrenato di Vagrant in locale sulla mia workstation ma, questa volta, ho adottato la soluzione “del ferro economico” al quesito “dove provo tutta sta roba”.

Si, alla fine ho preso in affitto una macchina su Kimsufi con Proxmox 5 che uso come laboratorio da molto tempo.

Screen Shot 2018-09-08 at 10.44.38.png

Ci provo svariate cose come diverse versioni di Openshift e la piattaforma che racconterò in questo post.

La configurazione del nodo fisico è molto semplice:

  1. Proxmox 5 (già installato da Kimsufi).
  2. Una rete locale 10.10.10.0/24 su cui attesto le virtual machine e le faccio uscire su internet.
  3. Un HaProxy installato direttamente sul nodo fisico in modo da inoltrare il traffico sulla 10.10.10.0/24 e farmi accedere da fuori.
  4. Spengo e accendo le diverse “sub-platforms” (me lo sono inventato al volo questo termine…) a seconda delle risorse che mi servono e le raggiungo tranquillamente tramite il reverse proxy.
  5. No, non è come in cloud che spengo e accendo come mi pare con la confortevole sensazione del risparmio pay as you go. Spendo sempre gli stessi soldi.
  6.  Per entrare direttamente sulle vm dal mio computer naturalmente ho impostato gli Host nella configurazione ssh.
Host gluster01
HostName 10.10.10.16
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster02
HostName 10.10.10.17
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster03
HostName 10.10.10.18
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Tutto questo anche visto che il mio mac MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) quando faccio cose DevOps si scalda e accende la ventola che è abbastanza fastidiosa. Inoltre ti esponi al rischio “collega simpatico” che ti fa battute tipo << che fa decolla? >>.

Mi serviva avere questo stack in poco tempo per testare cose:

  1. Un cluster Kubernetes.
  2. Un’istanza Rancher per gestirlo.
  3. Un cluster GlusterFS in replica 3.

Screen Shot 2018-09-08 at 10.55.41

Per creare le VMs?

Volevo provare un plugin di Vagrant per Proxmox, ma non avevo tempo cui ho svolto “a manella” l’installazione di un nodo CentOS Linux release 7.5.1804 (Core) con cloning per le altre 2 virtual machine.

  • gluster01 (10.10.10.16)
  • gluster02 (10.10.10.17)
  • gluster03 (10.10.10.18)

Per installare velocemente Kubernetes?

Assolutamente KubeSpray!

È andata più o meno così

    1. Come installare Python3 su Centos 7.5 visto qui
    2. yum install git ansible
      git clone https://github.com/kubernetes-incubator/kubespray.git
      mkdir inventory/mycluster
      cp -rfp inventory/sample/* inventory/mycluster
      declare -a IPS=(10.10.10.16 10.10.10.17 10.10.10.18)
      CONFIG_FILE=inventory/mycluster/hosts.ini python3.6 contrib/inventory_builder/inventory.py ${IPS[@]}
      
    3. Prova di connessione ai nodi con ‘ansible all -i inventory/mycluster/hosts.ini -m shell -a “whoami”‘
    4. Inizio installazione
      ansible-playbook -i inventory/mycluster/hosts.ini cluster.yml

Devo dire che è andato tutto bene senza troppi intoppi.

Kubernetes cluster up and running!

[root@gluster01 kubespray]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready master,node 4m v1.11.2
node2 Ready master,node 4m v1.11.2
node3 Ready node 3m v1.11.2

 

Installazione di Rancher

Rancher si installa facilmente e basta dargli in pasto un cluster Kubernetes per vederlo all’opera. Nel mio caso gira come container Docker con persistenza.

 docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /host/rancher:/var/lib/rancher rancher/rancher:latest

#creazione di un service account con diritti per amministrare il cluster k8s
[root@gluster01 ~]# kubectl create -f admin-user.yaml
serviceaccount/admin-user created
[root@gluster01 ~]# kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user admin-user
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created

Dopo un po’ di “smanettamenti” lato reverse proxy e DNS finalmente il cluster è in stato waiting…

Screen Shot 2018-09-08 at 15.51.53

Dopo altri “smanettamenti ” il cluster si è “joinato” correttamente a Rancher. Anzi più che “joinato” forse è meglio dire che Rancher ha eseguito un takeover su k8s.

Però ho dovuto importare un certificato nel container di Rancher con:

 docker cp /etc/pki/ca-trust/source/anchors/kube-ca.crt $idcontainerdirencher:/etc/ssl/certs/

È una cosa temporanea eh… dopo metto apposto…

Questi sono i pod attivi sul cluster nel namespace creato per Rancher

[root@node1 ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
cattle-system cattle-cluster-agent-6b8df4755-8tfxg 1/1 Running 0 2m
cattle-system cattle-node-agent-48bcq 1/1 Running 0 2m
cattle-system cattle-node-agent-928wl 1/1 Running 0 1m
cattle-system cattle-node-agent-t6cs6 1/1 Running 0 2m

Screen Shot 2018-09-08 at 16.48.38Screen Shot 2018-09-08 at 16.48.44

Installazione di GlusterFS

Sui tre nodi Gluster01,02,03 dove avevo installato Kubernetes controllato da Rancher dovevo aggiungere anche GlusterFS.

Per l’installazione niente di più semplice di questa guida

[root@node1 ~]# gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: 2a111687-5d26-4051-b0a8-8d4a67efc87f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gluster02:/bricks/brick1/gv0
Brick2: gluster03:/bricks/brick1/gv0
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet

#Lista nodi dei peer dal node1
[root@node1 ~]# gluster peer status
Number of Peers: 2

Hostname: gluster02
Uuid: 2cb83c74-ebc3-4dca-a62f-799433d198ae
State: Peer in Cluster (Connected)

Hostname: gluster03
Uuid: 6918282f-23f8-4627-b9b4-e7b9d521b32d
State: Peer in Cluster (Connected)

 

Una volta completato tutto ho potuto eseguire delle simulazioni utili per alcuni problemi su un’altra piattaforma.

Al momento sto girando dei pod con GlusterFS come persistent volume e nei prossimi articoli scenderò più nel dettaglio sull’utilizzo di Rancher.

Bella

Autenticazione con Ansible. Esempi di vari casi (ssh key, sudo, su, password,…)

Spesso, a seconda dell’environment in cui ci troviamo e delle restrizioni che dobbiamo affrontare lato sicurezza, dobbiamo effettuare un tuning del nostro inventory file.

Riporto in questo post un po’ di casi diversi che possono essere utili come esempi di configurazione base.

Sono casi molto semplici ma uniti insieme possono essere una visione d’insieme rapida sui parametri disponibili da usare nell’inventory.

Scambio chiavi ssh

Il default user per le connessioni ssh è root. La chiave pubblica dell’utente da cui sto lanciando Ansible è stata inserita in /root/.ssh/authorized_keys di root in ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35
ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Autenticazione con password

Definisco la password di root di ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_ssh_pass=supersecret_password
ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Utilizzo utente operatore con password

Definisco un utente operatore con relativa password.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
operatore

become_method sudo

L’utente operatore diventa root tramite sudo

[root@ocslave35 ~]# cat /etc/sudoers.d/operatore
operatore ALL=(ALL) ALL
#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=sudo ansible_become_pass=foobar.123
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

become_method su

L’utente operatore diventa root tramite il comando su con password definita nell’inventory.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=su ansible_become_pass=supersecret_password
[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

 

Accesso locale

Il nodo da cui lanciamo Ansible è lo stesso a cui vogliamo connetterci. Non c’è bisogno di ssh quindi.

[nodes]
ocmaster35 ansible_connection=local

ciao!

DNS Server Master/Slave tramite Ansible

Devo mettere in piedi un DNS server master/slave e mi trovo davanti al solito quesito sulle opzioni per l’implementazione. Come lo faccio?

  1. a manina
  2. Chef
  3. Ansible

L’opzione numero uno (ogni tanto e soprattutto per i miei ambienti di laboratorio) inizia a sembrarmi quella più rapida, ma per tenersi allenati su IaC è bene usare la 2 o la 3.

Siccome il DNS mi serve per un cluster Openshift direi di procedere con la 3, così farò tutto con Ansible.

1_hdwjXl1x4Q3VXmL7UG1XrQ

Ho preso in affitto una macchina fisica su Kimsufi con sopra Proxmox come hypervisor.

Screen Shot 2018-07-15 at 11.27.50

La rete è configurata così.

ocmaster39 (eth0: 10.10.10.10/24, eth1: 192.168.56.10/16)

ocslave39 (eth0: 10.10.10.11/24, eth1: 192.168.56.11/16)

Il nostro DNS ascolterà sulla 192.168.0.0 mentre sulla 10.10.10.0 attesterò i servizi di OC.

Una volta completato l’inventory file che è veramente molto scarno in questo caso eseguirò i playbook.

[dns_master]
192.168.56.10 ansible_connection=local

[dns_slave]
192.168.56.11



Eseguiamo qualche comando per vedere che la comunicazione funzioni…

[root@ocmaster39 ansible-role-bind]# ansible all -a 'whoami' -m shell
192.168.56.10 | SUCCESS | rc=0 >>
root

192.168.56.11 | SUCCESS | rc=0 >>
root

Ok si.. tutti usano il ping e quindi lo userò anche io,

[root@ocmaster39 ansible-role-bind]# ansible all -m ping
192.168.56.10 | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"
}
192.168.56.11 | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"
}

Convergenza del master (sotto è riportato il playbook usato)

ansible-playbook master.yml

Convergenza slave

ansible-playbook slave.yml

A questo punto Bind è installato e configurato, per cui interroghiamo il master…

[root@ocmaster39 ~]# dig @192.168.56.10 google.it | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-google.it. 188 IN A 172.217.18.195
[root@ocmaster39 ~]# dig @192.168.56.10 ocslave39.openshift.local | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-ocslave39.openshift.local. 1209600 IN A 192.168.56.11

… ora lo slave …

[root@ocmaster39 ~]# dig @192.168.56.11 ocslave39.openshift.local | grep -n1 "ANSWER SECTION"
13-
14:;; ANSWER SECTION:
15-ocslave39.openshift.local. 1209600 IN A 192.168.56.11

Ho forkato il playbook originale per una PR dove ho aggiunto i playbook usati e un po’ di doc.

Trovate l’esempio usato qui

Ciao!