Differences

This shows you the differences between two versions of the page.

--- sysadmin:labs [2015/01/23 16:09] – kobe
+++ sysadmin:labs [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Labs ======
-In questa sezione faremo un brainstorming sul mondo Docker e sui [[https://en.wikipedia.org/wiki/Microservices|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 [[https://en.wikipedia.org/wiki/DevOps|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.
-===== 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, [[https://en.wikipedia.org/wiki/High_availability|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.
-[[http://www.jagom.org/|Jagom]], primo progetto di beFair, e' un fork di Trac con dovuti potenziamenti.
-[[https://taiga.io/|Taiga]], metodologia agile (scrum) e/o snella (kanban), applicazione Django e Angular.  Taiga si puo' interfacciare con GitLab (vedi sezione dopo).
-[[https://github.com/feroda/django-exercises-timetracker|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.
-[[https://about.gitlab.com/|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 =====
-[[https://drone.io/|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 [[https://about.gitlab.com/gitlab-ci/|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 [[paas|qui]].
-====== IaaS abstraction level ======
-A titolo di completezza, aggiungiamo questa sezione per fare una panoramica sulla soluzioni libere attualmente disponibili per fornire un livello IaaS, mentre nella sezione prima partivamo da questo livello per fornire un'astrazione maggiore piu' vicina allo sviluppatore.  In linea di massima non dovrebbe essere necessario ricorrere a queste soluzioni a meno che vogliamo fare concorrenza a qualche colosso, possiamo accontentarci di qualche VPS gia' pronto..  :)
-Vedi la pagina dedicata alle [[IaaS]].
-===== Stack di esempio =====
-In linea di massima l'unico limite per combinare tra loro queste tecnologie e' data dalla propria fantasia, comunque l'unico limite dovrebbe essere che Docker non puo' girare dentro Docker (almeno fino a prova contraria), quindi i container sono lo stack piu' alto (sopra al quale non ci puo' stare niente).  Di seguito alcuni esempi di stack IaaS/PaaS che possono avere senso:
-  * Deis:  layer 0 + CoreOS + Deis --> stateless Docker-based PaaS
-  * OpenStack/Deis:  layer 0 + OpenStack (+ CoreOS + Deis) --> Hybrid stateful Docker-based PaaS + normal apps
-  * OpenStack/OpenShift:  layer 0 + OpenStack (+ Kubernetes + OpenShift) --> Hybrid stateful Docker-based PaaS + normal apps
-  * OpenShift:  layer 0 + Kubernetes + OpenShift --> stateful Docker-based PaaS
-  * Mesosphere:  layer 0 + Mesos (+ Kubernetes/Mesos + OpenShift?) --> Hybrid (stateful?) Docker-based PaaS + Mesos-based apps
-Come layer 0 s'intende:
-  * bare metal
-  * [[https://code.google.com/p/ganeti/|Ganeti]] si basa su Xen (o KVM) e LVM, scritto in Python.
-  * [[https://xen-orchestra.com/|Xen Orchestra Basic]] e' un'interfaccia web a Xen Server che permette di orchestrare un cluster di macchine Xen.
-  * affitto di un server virtuale su GCE, AWS, Linode, Digital Ocean...
-==== Kubernetes/OpenShift ====
-[[https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md|Kubernetes Design]]
-Plugins (se cosi' possiamo chiamarli):
-  * [[https://github.com/google/cadvisor|cAdvisor]], monitora i container ed esporta in InfluxDB
-  * [[https://github.com/GoogleCloudPlatform/heapster|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?**
-{{:sysadmin: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:
-  * [[http://nixos.org/nix/|Nix]] e' un gestore pacchetti funzionale
-  * [[http://nixos.org/|NixOS]] e' un sistema operativo dichiarativo e stateless che usa Nix
-  * [[http://nixos.org/nixops/|NixOps]] e' il deployment tool per NixOS (tipo Ansible)
-  * [[http://nixos.org/hydra/|Hydra]] e' il CI per NixOS
-[[http://gfxmonk.net/2015/01/03/nixos-and-stateless-deployment.html|Qui]] viene spiegato perche' e come usare NixOS in un contesto di produzione.
-Inoltre da Nix e' nato un altro progetto:
-  * [[https://www.gnu.org/software/guix/|Guix]] e' un gestore pacchetti costruito sopra Nix
-  * [[http://alpha.gnu.org/gnu/guix/|Qui]] e' possibile scaricare un sistema GNU/Linux con Guix