Se Docker di default puo' avere vantaggi principalmente in fase di sviluppo, per sfruttarlo in fase di ops e' necessario dotarsi di un orchestration engine o, ancora meglio, una PaaS Docker-based che quindi puo' portare a:

• infrastruttura piu' agile basata sui microservizi
• migliorare l'efficienza del deploy di un'applicazione tramite:
  • minimizzazione dei costi di deploy di un'applicazione
  • migliorare la scalabilita' in produzione

Cosa si intende per PaaS e a quale livello di astrazione si pongono questi strumenti? Qui e qui si puo' avere un'idea sui differenti livelli di astrazione.

Qui invece un articolo che introduce la differenza tra PaaS e IaaS+.

OpenShift 3 Origin

• OpenShift 3 e' la riscrittura della PaaS di RedHat in Go (prima era in Ruby) e basato su Docker (prima era su un container engine specifico di RedHat)
• basato su Kubernetes e Atomic
• in beta
• punta a supportare app stateful
• OpenShift supporta l'autoscaling delle applicazioni
• repository
• Technical Architecture Presentation, System Architecture
• 200+ GitHub stars

Flynn e' stato sviluppato a partire dalla ricerca di Google presentata come Omega

• in beta
• Architecture Overview
• Repository
• 3000+ GitHub stars

• Tsuru
• repository)
• 1000+ GitHub stars

Tra tutte e' emersa una proposta alternativa nell'uso di Docker non visto piu' come un container che fornisce microservizi ma una come VM a basso overhead. In questo caso la differenza principale e' data dall'avere (come in un normale OS) un normale demone di init come PID 0, mentre nei microservizi il PID 0 e' il processo che vogliamo lanciare (Nginx, uWSGI, PostgreSQL…). Questo approccio risolve alcuni aspetti nell'uso di Docker in produzione, come la questione del logging. Tuttavia per sfruttare appieno Docker non e' neanche sufficiente dotare ogni container di demoni init nativi, SSH e SysLog, ma bisogna andare un po' oltre e pensare un sistema di orchestrazione che risolve questo e altri problemi come l'HA, l'autoscaling, etc fermorestanto l'approccio dei microservizi.

• Part 1
• Part 2

Kubernetes e' stato presentato da Google all'I/O 2014 come proposta per standardizzare l'orchestrazione di applicazioni dockerizzate stateless (dove un'applicazione e' costituita da vari pod, ogni pod e' un insieme di container). Scritto in Go, puo' girare su bare metal, cosi' come su OpenStack, un VPS generico con Debian, Ubuntu, Fedora, CoreOS.

• 6000+ GitHub stars
• in beta
• scritto in Go
• (per ora) permette solo applicazioni stateless

In CoreOS sono stati sviluppati numerosi tool:

• Rocket
• Etcd
• Fleet
• Flannel

• Atomic (Red Hat)
• Ubuntu Core

Per stateless s'intende che la soluzione proposta non gestisce dati persistenti (che sia su database o su file system), e questo e' dovuto al fatto che i container possono essere costruiti/distrutti in qualsiasi momento (piu' o meno come se fossero in sola lettura).

Quindi eventuali database (relazionali o non) o file caricati dagli utenti dovranno risiedere altrove, ad esempio su un nostro VPS qualsiasi, oppure su un servizio dedicato come Google Persistent Disk, Amazon S3, etc. Tuttavia questo e' un argomento abbastanza complesso su cui siamo in piena fase di R&D, per cui ora non approfondiamo ulteriormente.

• Deis e' la prima PaaS libera costruita su Docker ed evoluta nel tempo (ed attualmente l'unica pronta per la produzione) che implementa i principi di 12factor e rappresenta una sorta di Heroku libero
• basato su CoreOS
• Deis e CoreOS sono entrambi production-ready
• Deis scritto in Python e Go, CoreOS in Go

Requisiti minimi:

• occupa ~2/2.5GB di RAM e 30GB di disco
• almeno 3 server da 4GB di RAM (~120USD/anno) + Storage

• Cloud Foundry (Shell/Ruby/.., repository, supportato dalla Linux Foundation)

• Dokku (Shell, sponsorizzato da Deis per ambienti molto piccoli)
• OctoHost (Shell, repository)