I Container

La gestione "a processi" e' stata la base dell'infrastruttura Unbit fin dal 2005. Dopo 7 anni e' giunto il momento di evolvere la piattaforma per venire incontro ai nuovi prodotti software e le loro esigenze in termini di risorse e accesso alle funzionalita' del sistema operativo.

Una sola memoria, tanti processi

La logica alla base di un container e' semplice: si alloca un quantitativo fisico di memoria e vi si fanno girare all'interno tutti i processi (e i thread) che si riesce. In un unico container possono convivere processi generati via ssh, cron, da web o un demone collegato al proprio account.

A differenza della gestione a processi, stavolta si parla di memoria fisica, quindi applicativi che fanno uso della virtual memory potranno girare senza problemi

Meno limiti

Diversi domini (ma non diversi account) possono utilizzare le risorse dello stesso container. Questo permette un considerevole risparmio economico e una maggiore versatilita'.

Tanti container, un solo account

In un unico account possono convinvere diversi container. Un buon modo di aumentare l'affidabilita' delle proprie applicazioni e' separare i vari componenti e assegnarli ad un container diverso. Ad esempio una applicazione Django potrebbe vivere tranquillamente in un container da 80 MB e il suo database postgres in uno da 40 MB. Nessuna delle due influenzera' l'altra, e visto che un crash di un database (sopratuttto per mancanza di memoria) puo' essere noioso (se non peggio), il vantaggio di questo approccio e' innegabile.

Scalabilita'

I container possono essere replicati su più server per garantire alta affidabilità e bilanciare il carico sui diversi nodi. Questo permette agli account di sganciarsi dalla singola macchina fisica e di scalare orizzontalmente per far fronte anche ai carichi più alti e ridurre al minimo il downtime. Per la comunicazione tra i nodi e' disponibile un network dedicato sulla classe 192.168.254.0/24

I database condivisi fanno schifo

Di default ogni piano Unbit comprendeva uno o piu' database sui server sql di sistema. Per quanto un amministratore sia bravo, o un server efficiente, questo approccio (a livello di performance, ma soprattutto di versatilita') e' davvero castrante. In un container e' possibile far girare il proprio database server facilmente e personalizzarlo come si preferisce (a patto di avere sufficiente memoria). Allo stesso modo i server NoSQL possono essere istallati ed eseguiti spesso senza costi aggiuntivi (se non l'acquisto della porta TCP necessaria per alcuni, i socket unix invece sono sempre gratuiti)

Supporto multiprotocollo su un'unica piattaforma

La piattaforma Upstream e' stata estesa per supportare oltre ai protocolli uwsgi ed HTTP, anche fastcgi (in varie modalita'), scgi e biferno. E' stata inoltre aggiunta una modalita' HTTP/1.1 per supportare tecnologie come i websocket.

Niente piu' CGI, o si ?

L'ambiente CGI non sara' piu' collegato direttamente al webserver, ma si potra' sfuttare l'implementazione CGI di uWSGI http://projects.unbit.it/uwsgi/wiki/CGI, che oltre ad avere una versatilita' senza pari offre diverse tecniche di ottimizzazione.

Monitoraggio costante e in tempo reale

Ogni container puo' essere monitorato in tempo reale dal pannello di controllo. I suoi consumi di memoria e i processi in esecuzione sono facilmente accessibili e misurabili.

Il Costo

Calcolare il costo di un container e' estremamente facile: ogni MB di memoria costa 1 euro l'anno. Un container da 80MB costera' 80 euro e cosi' via. Questo e' il caso standard. Sui container piu' grandi vengono applicate varie formule di scontistica. Chiedi sempre allo staff un preventivo aggiornato, ma sappi comunque che il costo massimo non superera' mai quello di 1 euro a MB.