PaaS

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 (Milestone 5)

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

scritto in Go

OpenShift supporta l'autoscaling delle applicazioni

repository

Technical Architecture Presentation, System Architecture

200+ GitHub stars

Flynn

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

in alpha

scritto in Go

repository

3000+ GitHub stars

Tsuru

Tsuru

scritto in Go

repository)

1000+ GitHub stars

Appendix: Microservices vs Lightweight VMs

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

Appendix: Orchestration

Kubernetes

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

Appendix: Host OS

CoreOS

In CoreOS sono stati sviluppati numerosi tool:

Rocket

Etcd

Fleet

Flannel

Altri

Atomic (Red Hat)

Ubuntu Core

Appendix: PaaS for stateless-only apps

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

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

Altri

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

Micro PaaS

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

OctoHost (Shell, repository)