Labs

In questa sezione faremo un brainstorming sul mondo Docker e sui microservizi, non direttamente connesso a 1ring (almeno per ora) ma sempre legato all'automatizzazione dell'infrastruttura IT, nell'ottica di applicarla in futuro. In particolare, le tecnologie presentate di seguito rappresentano lo stato dell'arte di un modello di sviluppo software che riguarda una maggiore integrazione tra il workflow di sviluppatori e sistemisti (dev e ops), cosiddetto DevOps.

Premessa: tutto cio' che andremo a vedere di seguito parte dal presupporto di adottare strumenti rilasciati come software libero e che quindi possiamo usare sulla nostra infrastruttura senza dipendere da servizi esterni. Laddove andiamo ad usare servizi esterni (principalmente l'affitto di server virtuali) e' importante non legarsi ad un venditore specifico per essere flessibili nella scelta dei fornitori.

Fonte: https://twitter.com/CommitStrip/status/562321064575782912

Docker

Introduzione a Docker: https://speakerdeck.com/slok/ship-it-with-docker

Gli obiettivi di usare Docker puo' portare a diversi vantaggi:

avere ambienti riproducibili e standardizzati tra dev e ops

in dev, ridurre l'overhead rispetto ad eventuali VM/Vagrant

in ops, aumentare la sicurezza grazie ad ambienti isolati

L'idea di adottare un set di strumenti basati su Docker che ne estendono le funzionalita' nell'ottica di avere un'infrastruttura IT Docker-based, automatizzata, autoscalabile, HA minimizzando costi e interventi umani, proponendo una standardizzazione del forkflow dev e ops.

Questi strumenti possono essere:

Projects tracker (es: Jagom, Taiga), non e' direttamente legato a Docker ma e' fondamentale per gestire il workflow di dev e ops

Server GIT (es: GitLab), non e' direttamente legato a Docker ma e' la base per lo sviluppo (ma comunque puo' essere deployato tramite Docker)

Server di CI (es: GitLab CI, Drone), infrastruttura che si occupa dei test automatici ad ogni push. Questa prende in ingresso i repository, effettua dei test, ed eventualmente effettua delle operazioni di publish o deployment, o comunque puo' avvisare altri software.

PaaS (es: Deis…) e' il cuore dell'infrastruttura che si occupa di tenere su tutte le applicazioni, in produzione e non, regolando il workflow degli ops. In particolare, si occupa di gestire:

il deploy di tutte le app a partire da un modello dichiarativo

i log delle applicazioni

il carico delle app sui singoli host, il load balancing e l'autoscaling

Projects tracker

Questi strumenti possono fungere anche da wiki e issue tracker e sostituiscono ad esempio JIRA.

Jagom, primo progetto di beFair, e' un fork di Trac con dovuti potenziamenti.

Taiga, metodologia agile (scrum) e/o snella (kanban), applicazione Django e Angular. Taiga si puo' interfacciare con GitLab (vedi sezione dopo).

Timetracker, esercizio di sviluppo per prendere confidenza con Django, punta a fornire un'interfaccia web anche su mobile, per segnare il tempo delle proprie attivita'. Puo' essere integrato con Jagom e/o Taiga.

Repository

Questo strumento puo' fungere anche da wiki e issue tracker e sostituisce GitHub o BitBucket.

GitLab e' un software simile a GitHub ma libero, e quindi puo' essere hostato nella nostra infrastruttura. E' disponibile una versione Dockerizzata non ufficiale.

Docker-based CI

Drone e' un sistema per il CI basato su Docker, nel senso che usa dei container Docker per i test, ed eventualmente puo' essere lui stesso installato con Docker. Sostituisce software come Jenkins (Java, lo standard de facto) e GitLab CI (Ruby). Drone prende come input repository da:

GitHub, Bitbucket, GitLab

E puo' deployare e/o pubblicare su:

Deployment: Git, Bash, OpenShift(TODO), Tsuru …

Publish: S3, Swift (OpenStack), NPM, PyPI, Docker, GitHub

Una volta scelta una PaaS, possiamo capire meglio quale puo' essere l'output piu' adatto per Drone (publish o deployment che sia).

Docker-based PaaS

Vedi qui.

Kubernetes/OpenShift

Kubernetes Design

Plugins (se cosi' possiamo chiamarli):

cAdvisor, monitora i container ed esporta in InfluxDB

Heapster, orchestra il monitoraggio di un cluster usando cAdvisor, InfluxDB e Grafana

Kubernetes Doc Reference:

https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs

https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples

In particular, an overview example can be found here:

https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/walkthrough

The example we usually demo is here:

https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook

For full API details, you can bring up a Kubernetes cluster, and go to http://MASTER_ADDRESS/swaggerui

That documentation is automatically generated from the source:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/v1beta1/types.go

FAQs

Ma non sarebbe utile fare qualche disegnino per capire meglio?

devops.pdf

Cosa ci possiamo fare oggi con tutto questo?

Attualmente (gennaio 2015) c'e' molto fermento e non sembra esserci una soluzione production-ready PaaS-only che permette di gestire sia componenti stateless che stateful, tuttavia avere una visione d'insieme dell'attuale ecosistema e dare un occhio al domani puo' essere utile per arrivare preparati e fare oggi scelte piu' opportune/lungimiranti nel progetto 1ring.

Dov'e' Ansible in tutto questo?

Risposta brevissima: non lo so, ma da qualche parte lo infileremo, no? :D

Risposta breve: Nell'era dei container perde molta della sua importanza, sebbene puo' comunque essere usato, ad esempio per il bootstraping di Kubernetes su un host.

Risposta non breve:

Ansible di base accede via SSH ad 1+ host ed esegue 1+ task, mentre piu' in generale verifica e si assicura che ci siano certi stati in certi host. Nei container, non disponendo di default di un demone SSH, diventa molto difficile lavorarci. C'e' un filone di pensiero (vedi Phusion) che vede i container come VM leggere, e quindi un demone di init + SSH + syslog + cron + processi delle applicazioni, ma come dicevamo all'inizio qui siamo partiti dal pressupposto di avere un'infrastruttura basata su microservizi e quindi questo lo ecludiamo.

Nei container stateless, per logica, non dovrebbe essere necessario applicarci dei playbook di Ansible, ma bisognerebbe (piu' drasticamente) distruggere/ricreare container per assicurare gli stati. Per i container stateful invece potrebbe tornare utile, ad esempio per backup e snapshot (tuttavia non sono certo di questo).

I campi in cui comunque rimane fondamentale sono:

acquisto/gestione delle VM via API

bootstraping di baremetal/VM (a cui si accede via SSH)

“tappare i buchi” laddove non ci sia una funzionalita' nativa gia' implementata

Questo ci permette di attivare funzionalita' molto potenti come:

autoscaling su numero variabile di VM (AWS-like), cioe' aggiungere VM al cluster di container Docker quando questi complessivamente hanno bisogno di maggiori risorse (e' un po' difficile da spiegare)

Alcune cose dovrebbero essere modificate sui repository perche' Ansible non potra' andare a scrivere dati specifici all'interno delle clone dei repository, ad esempio:

i settings.py di Django che oggi vengono gestiti come template in Jinja2 con Ansible, dovrebbero invece essere suddivisi in diversi file, in modo che Django lanci il corretto settings.py in base ad una ipotetica variabile d'ambiente del tipo TYPE=prod oppure TYPE=stage o TYPE=dev (approccio 12factor)

Questa parte magari e' da scrivere un po' meglio..

Post-Docker Era?

In piena era Docker, perche' non spendere due parole per parlare dell'era post-Docker?

Per iniziare un paio di articoli, il primo contro Ansible&Co, l'altro come proposta di OS che vanno oltre i concetti di Docker:

https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/

http://gfxmonk.net/2015/01/04/os-technologies-to-watch.html (interessanti il primo e l'ultimo pezzo su NixOS e Docker)

Nix, NixOS e Guix

In breve:

Nix e' un gestore pacchetti funzionale

NixOS e' un sistema operativo dichiarativo e stateless che usa Nix

NixOps e' il deployment tool per NixOS (tipo Ansible)

Hydra e' il CI per NixOS

Qui viene spiegato perche' e come usare NixOS in un contesto di produzione.

Inoltre da Nix e' nato un altro progetto:

Guix e' un gestore pacchetti costruito sopra Nix

Qui e' possibile scaricare un sistema GNU/Linux con Guix