Just add new special input key for KubeInvaders. Press ‘n’ to jump between namespaces!
https://www.reddit.com/r/kubernetes/comments/d3n50f/just_pushed_new_version_of_kubeinvaders_with_a/
I am very proud to announce that my not useful but fun project has been added to a curated list of tools for Kubernetes!
Non so perché ma il tekno viking ci stava bene…
Just add new special input key for KubeInvaders. Press ‘n’ to jump between namespaces!
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
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.
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"
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
Scale pods of foobar namespace to 20 replicas.
oc scale dc testapp --replicas=20 -n foobar
I deployed also https://github.com/hjacobs/kube-ops-view because I find it very cool for watching pods distributed across node workers.
This is how KubeInvaders works with Openshift 4.1.
Bye!
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).
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.
Il nome utente indicava la distribuzione Linux desiderata.
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
Piccola utility scritta in Go per configurare server in modo dichiarativo.
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.
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:
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.
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.
sh-3.2# cat > index.html < foo > EOF sh-3.2#
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.
Oppure, per chi è curioso di sapere da cosa è composta un’applicazione su Openshift/Kubernetes invio un json contenente tutti gli oggetti creati.
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.
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.
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.
Ci provo svariate cose come diverse versioni di Openshift e la piattaforma che racconterò in questo post.
La configurazione del nodo fisico è molto semplice:
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:
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.
Assolutamente KubeSpray!
È andata più o meno così
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[@]}
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
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…
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
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
