Archivi tag: openstack

RESTIC il backup funzionale e cross platform

INTRODUZIONE

– Restic è un’applicazione per la gestione di backup sia in locale che in cloud, che supporta la crittografazione (AES-256) e la deduplicazione dei dati, riducendo dunque in modo significativo lo spazio necessario per conservare i file bekappati.

Restic è già ad oggi compatibile con la maggior parte dei servizi cloud quali : “OpenStack Swift, bucket Amazon S3, Backblaze B2, Microsoft Azure Blob Storage, Google Cloud”, e sono presenti anche immagini Docker.

Restic è sviluppato in linguaggio GO, cosa che lo rende molto leggero ed efficiente, risolvendo anche molti problemi di gestione di dipendenze.

– INSTALLAZIONE

Esistono molti pacchetti di installazione per la maggior parte dei sistemi operativi, coprendo un range che va da Arch Linux a MacOS, fino ai sistemi *BSD/*NIX……

Per i sistemi più “standard” l’installazione è banale:

– Debian

apt-get install restic

– Fedora

dnf install restic

– MacOS

brew install restic

….. per tutti gli altri sistemi si possono trovare tutte le specifiche sul sito ufficiale di Restic (https://restic.readthedocs.io/en/latest/020_installation.html#stable-releases)

Una volta installato il pacchetto i comandi per l’utilizzo di Restic sono davvero semplici ed immediati.

Prima di tutto va inizializzato lo spazio che si decide di stanziare, dedicare, al backup, ricordandosi che Restic chiama la destinazione per i backup “repository” ( –repo oppure -r ).

Quindi per inizializzare la Directory prescelta per la gestione dei backup possiamo agire in 3 modi diversi:

  • spostarci all’interno della DIR prescelta e dare il comando # restic init
  • indicare il PATH dei backup # restic init –repo /mnt/data/<nome_utente>/backup/
  • indicare un percorso di rete # restic -r sftp:<utente>@<indirizzo_IP>:/mnt/data/<nome_utente>/backup init

– COMANDI PRINCIPALI

  • init
  • backup
  • ls
  • restore
  • snapshots
  • tag
  • copy
  • stats

…….. e molti altri ancora che potete trovare sulla documentazione ufficiale, al sito restic-official-docu

Per poter automatizzare gli accessi ad aree esterne come, altri server, servizi cloud o altro, possiamo usare due metodi diversi;

1) creiamo un file .restic.env nel quale possiamo inserire i dati di accesso (es. ad AWS S3) , aggiungendo la password creata durante la fase di inizializzazione [“init“]

oppure

2) creiamo un file .rest_pass in cui inseriamo soltanto la password 

– ESEMPI

Es. file di tipo ENV ( .restic.env )

#!/bin/bash

export RESTIC_REPOSITORY=” s3:https://s3.amazonaws.com/restic-backup-test “

export AWS_SECRET_ACCESS_KEY=”IVZ6GSBXEaZ1DeXzhN1gr4eCWcxD7hhMOt1RWMdn”

export RESTIC_PASSWORD=”<PASSWD>”

– Prima di lanciare i comandi per restic, in ambiente Cloud, eseguo il comando:

source .restic.env

per caricare le variabili d’ambiente indicate nel file .restic.env

Es. file di tipo PASSWD ( .rest_pass )

< password >

….quando si decide di usare il file .rest_pass basta indicarlo alla fine della stringa di comando, come ad esempio:

restic -r sftp:<utente>@<indirizzo_IP>:/home/<utente>/backup/database snapshots -p .rest_pass

– Esempi Pratici

INIZIALIZZO UNA DIRECTORY LOCALE

.\restic.exe init –repo C:\Users\User\Desktop\restic-repo

enter password for new repository:

enter password again:

created restic repository 80ee4591fd at C:\Users\User\Desktop\restic-repo

Please note that knowledge of your password is required to access the repository. Losing your password means that your data is irrecoverably lost.

Esegui il BACKUP

.\restic.exe backup -r C:\Users\User\Desktop\restic-repo E:\TEST1.txt
enter password for repository:
repository 80ee4591 opened successfully, password is correct
created new cache in C:\Users\User\AppData\Local\restic

Files: 1 new, 0 changed, 0 unmodified
Dirs: 1 new, 0 changed, 0 unmodified
Added to the repo: 467 B

processed 1 files, 0 B in 0:00
snapshot 0161a85c saved

Vedere la lista degli snapshot effettuati

.\restic.exe snapshots -r C:\Users\User\Desktop\restic-repo
enter password for repository:
repository 80ee4591 opened successfully, password is correct

ID Time Host Tags Paths

0161a85c 2021-08-05 13:08:45 Windows10 E:\TEST1.txt

1 snapshots

Vedere la lista dei files di una snapshot:

.\restic.exe ls -l -r C:\Users\User\Desktop\restic-repo 0161a85c
enter password for repository:
repository 80ee4591 opened successfully, password is correct
snapshot 0161a85c of [E:\TEST1.txt] filtered by [] at 2021-08-05 13:08:45.8317433 +0200 CEST):
drwxrwxrwx 0 0 0 1979-12-31 23:00:00 /E
-rw-rw-rw- 0 0 0 2021-08-05 13:07:20 /E/TEST1.txt

Esegui il Restore

Per effettuare un test reale, ho cancellato il file E:\TEST1.txt

.\restic.exe restore 0161a85c -r C:\Users\User\Desktop\restic-repo –target E:\restore
enter password for repository:
repository 80ee4591 opened successfully, password is correct
restoring to E:\restore

….così facendo ho recuperato la copia di backup facendone il restore sul disco E:\restore

$ ls -l E:\restore

Directory: E:\restore

Mode LastWrite Time Length Name
—- ————- —— —-
d—– 31/12/1979 23:00 0 TEST1.txt

Elimina gli snapshot

.\restic.exe forget –prune 0161a85c -r C:\Users\User\Desktop\restic-repo
enter password for repository:
repository 80ee4591 opened successfully, password is correct
[0:00] 100.00% 1 / 1 files deleted
1 snapshots have been removed, running prune
loading indexes…
loading all snapshots…
finding data that is still in use for 0 snapshots
[0:00] 0 snapshots
searching used packs…
collecting packs for deletion and repacking
[0:00] 100.00% 1 / 1 packs processed

to repack: 0 blobs / 0 B
this removes 0 blobs / 0 B
to delete: 2 blobs / 531 B
total prune: 2 blobs / 531 B
remaining: 0 blobs / 0 B
unused size after prune: 0 B ( of remaining size)

rebuilding index
[0:00] 0 packs processed
deleting obsolete index files
[0:00] 100.00% 1 / 1 files deleted
removing 1 old packs
[0:00] 100.00% 1 / 1 files deleted
done

N.B.: bisogna ricordarsi che, nel caso stessimo agendo sull’eliminazione di un backup/snapshot in ambiente cloud, tipo Amazon Bucket S3, prima del comando di forget –prune bisognerà dare un “restic unlock <ID dello snapshot>“

Auto Pulizia

.\restic.exe forget –prune –keep-daily 7 –keep-monthly 12 –keep-yearly 3 -r C:\Users\User\Desktop\restic-repo
enter password for repository:
repository 80ee4591 opened successfully, password is correct
Applying Policy: keep 7 daily, 12 monthly, 3 yearly snapshots

Aggiorna la versione

Prima di tutto verifichiamo quale versione abbiamo al momento:

.\restic.exe version
restic 0.12.0 compiled with go1.15.8 on windows/amd64

oppure

$ restic version
restic 0.12.0 compiled with go1.15.8 on linux/amd64

Sulla macchina ArchLinux la versione è già l’ultima disponibile al momento (5 Agosto 2021) quindi non eseguiremo l’aggiornamento ma, ricordate che in caso di macchine nascoste da un Firewall a cui è vietato fare download di pacchetti si può comunque scaricare su di un’altra macchina l’ultima versione del software dal repository ufficiale su github , scompattarlo e sostituire il nuovo “restic” direttamente in /usr/bin

RESTIC Last Version Binaries Page

Es. :

bunzip2 restic_0.12.0_linux_amd64.bz2

mv restic_0.12.0_linux_amd64.bz2 restic

chmod +x restic

mv restic /usr/bin/

restic self-update

L’invito è quello di leggere la documentazione ufficiale poichè è davvero ricca di esempi, spiegazioni e modi di utilizzare questo fantastico strumento, ultra flessibile e davvero performante.

OpenStack – Introduzione

OpenStack Cloud Software

OPENSTACK – PARTE PRIMA

Si parla molto di OpenStack e delle sue applicazioni. Ma che cos’è davvero, perché è stato sviluppato e quali sono i suoi vantaggi?

Che cos’è?
OpenStack è un sistema operativo per il cloud computing in grado di controllare componenti di storage, networking e computing. È open source e gratuito, di solito è installato sotto forma di soluzione IaaS. OpenStack fornisce un insieme di strumenti che servono a costruire e gestire piattaforme cloud sia pubbliche sia private. Permette agli utenti di installare macchine virtuali e si può accedere al codice sorgente per modificarlo in qualsiasi modo sia utile per gli scopi specifici del progetto.

Chi lo ha sviluppato?
Nel 2010 Rackspace e la NASA hanno collaborato a un progetto congiunto che è poi diventato OpenStack. Il codice iniziale è stato usato per Nebula, la piattaforma cloud della NASA, poi il progetto si è dato l’obiettivo più ampio di aiutare le aziende a far girare software cloud su hardware standard.

Chi lo usa?
Tra i vendor, alcuni dei nomi più importanti che attualmente supportano e distribuiscono OpenStack sono Canonical, Cisco, EMC, HP, Huawei, IBM, Oracle, Google e Red Hat. Tra gli utenti attuali ci sono Bloomberg, Comcast, PayPal e Wells Fargo. Ci sono incontri internazionali periodici su OpenStack – gli OpenStack Summit – in tutto il mondo, che raccolgono programmatori e utenti della piattaforma.

E’ quindi ormai innegabile l’interesse che tutto il mondo IT ha riservato in questi ultimi anni ad OpenStack.

Qual’è la ragione di tutto questo?

L’ormai tradizionale paradigma client-server, in progetti in cui la scalabilità e le finestre di picchi di carico sono variabili essenziali all’interno dell’equazione della produttività, presenta oggi giorno evidenti limiti di gestione dei carichi e della velocita’ di evoluzione dei progetti. Ecco quindi nascere l’esigenza di uno strumento che fosse flessibile ed allo stesso momento affidabile.

Questo concetto spiega quindi le motivazioni che possono spingere ad adottare una piattaforma cloud, ma perché fra tutte le piattaforme esistenti si parla sempre di OpenStack?

OpenStack è un progetto aperto
La sua natura aperta ha fatto sì che tutti i vendor interessati all’introduzione di specifiche funzionalità o determinati ambiti potessero contribuire in maniera attiva e funzionale al progetto, innescando un circolo virtuoso in cui ogni miglioramento apportato per favorire se stessi va a beneficio della comunità.

La sua natura aperta fa sì che chi adotta OpenStack per il proprio ambiente cloud è di fatto esente dal cosiddetto vendor lock-in, ossia l’essere vincolato ad un rivenditore specifico per le proprie tecnologie. Infatti se lo standard OpenStack è garantito, ogni venditore potrà essere valutato in modo paritetico a tutti gli altri, rendendo così il mercato più competitivo e conveniente per il cliente finale.

I presupposti di un progetto OpenStack

Bisogna subito tenere presente che “non tutti i progetti sono adatti al cloud“, nonostante cio che viene erroneamente interpretato leggendo in giro per il web, infatti questo principio sfugge a molti che guardano verso le nuvole vedono unicamente un posto differente da cui erogare i propri servizi. Esistono dei requisiti da tenere presente per capire se un progetto è adatto al cloud.

Un progetto OpenStack quindi deve essere:

** Non persistente: non deve basarsi sulla persistenza dei dati all’interno delle macchine coinvolte. Questo aspetto non va confuso con l’esigenza di avere uno storage solido e sicuro, si tratta invece di non giudicare le istanze che concorrono al progetto come perenni, ma come componenti utili al loro scopo e liberamente sacrificabili;

** Scalabile: deve supportare applicazioni che nativamente siano in grado di scalare. L’applicazione nasce già dallo sviluppo come pensata per il cloud;

** Dinamico: a fronte di un innalzamento delle richieste ricevute il progetto deve essere in grado in maniera autonoma di gestire le nuove componenti. Gli interventi manuali successivi all’implementazione sulle istanze coinvolte devono essere inesistenti;

** Rapido: deve essere passibile di provisioning, favorendo la velocità di creazione (e distruzione) di nuove istanze;

Se il vostro progetto risponde a questi requisiti messi in evidenza qui sopra, allora potete pensare ad integrare OpenStack ed è giunto quindi il momento di capire in cosa consiste.

Le componenti di OpenStack

La parola stack descrive un insieme di entità che concorrono ad uno scopo comune. OpenStack è composto da numerose elementi che devono comunicare fra loro, lo strato di comunicazione passa attraverso due filoni fondamentali: la memorizzazione delle informazioni e la coda delle azioni da svolgere. Queste due azioni sono coperte ciascuna da un elemento specifico:

MySQL

Il database MySQL è necessario per la memorizzazione delle informazioni di configurazione generali del sistema, per la memorizzazione delle informazioni di autenticazione relative a ciascun componente e per il mantenimento dinamico dello stato del sistema.
Ogni azione eseguita all’interno dell’infrastruttura OpenStack è tracciata all’interno del database. L’importanza di questa componente è evidentemente capitale.

RabbitMQ

RabbitMQ è uno scheduler, un software didicato alla gestione delle code ed all’organizzazione delle sequenze di operazioni. Tutti i nodi facenti parte dell’infrastruttura OpenStack comunicano con lo scheduler, ed anche in questo caso è presto spiegato come questa componente ricopra enorme importanza per il regolare funzionamento dell’ambiente.

Determinato quindi il sistema di circolazione e reperimento delle informazioni si può focalizzare l’attenzione sugli elementi peculiari di OpenStack, riassunti in questo diagramma che si trova sul sito ufficiale del progetto:

OpenStack Diagramma Software

                                                     OpenStack Diagramma Software

Keystone

Keystone è il software che gestisce il sistema di autenticazione di OpenStack. Il principio su cui si fonda è quello classico degli utenti e dei gruppi, ma di fatto si occupa di gestire le tre tipologie di utenti configurabili in OpenStack:

  • Cloud Provider Admins: ossia gli amministratori del sistema OpenStack;
  • Tenants: ossia i profili delle compagnie fruitrici dei servizi;
  • Users: ossia gli utenti delle compagnie fruitrici dei servizi;

Il concetto di “compagnia” si riferisce ad un sotto-ambiente interno alla stessa installazione di OpenStack. Applicato ad un provider esso potrebbe essere rappresentato dai clienti, mentre all’interno di un cloud privato potrebbe essere associato ad un dipartimento interno.

Glance

Glance si occupa del provisioning (ossia di fornire) delle immagini all’interno dell’ambiente. Questa componente fornisce un bacino di istanze gia preconfigurate, disponibili ai fruitori dei servizi, per effettuare il deploy (ossia la messa in produzione) dell’istanza desiderata all’interno del proprio ambiente.
Le immagini sono supportate nei formati KVM qcow, Aws, VMWare purché esista su queste un Master Boot Record.

Nova

Nova è il compute service, un servizio che permette di gestire i sistemi virtuali erogati all’interno dell’ambiente. All’interno della macchina definita controller il servizio nova-api guiderà l’avvio e la terminazione delle istanze comandando la sua controparte nova-compute, attiva su tutte le macchine hypervisor facenti parte della struttura OpenStack.
Le decisioni su dove e come le istanze dovranno essere avviata saranno gestite dal servizio nova-compute-service (basato su libvirt).

Horizon

Horizon è l’interfaccia web dalla quale è possibile controllare agevolmente le istanze in modalità point-and-click oltre che le immagini gestite da Glance. Il software Horizon è basato sul modulo wsgi del webserver Apache.

C’è ancora un’ultimo aspetto da tenere presente, come è deducibile dallo schema, lo storage.
In un setup base le macchine possono essere erogate direttamente dai dischi degli hypervisor, ma in ambienti di larga scala ciò potrebbe non essere auspicabile. In questi casi fare riferimento ad un gestore dello spazio centralizzato permetterebbe di utilizzare gli hypervisor come semplici erogatori, valorizzando la scalabilità generale del progetto, ed ecco dunque venirci in aiuto questo componente per la gestione dei volumi, Cinder.

Cinder

In origine parte del progetto Nova (chiamato nova-volume) e dal 2012 progetto a se stante, Cinder è il servizio che fornisce il block storage per le istanze, uno storage gestito e centralizzato che funziona da dispositivo a blocchi per le virtual machines. Le macchine virtuali risiedono quindi su un device dedicato, definito sulla base di quello che è la modalità con cui l’hypervisor ha accesso allo storage.
Cinder supporta diverse modalità per essere visto dagli hypervisors: è possibile infatti utilizzare dischi locali o sistemi storage esterni, quali NFS, FibreChannel, DRBD o iSCSI.

Swift

A differenza di Cinder, Swift è un servizio di storage online che si occupa di rendere disponibile spazio all’interno dell’ambiente OpenStack mediante la modalità object storage. I dati non vengono registrati direttamente su dispositivi a blocchi, ma preventivamente convertiti in oggetti binari, distribuiti all’interno di più device in modo da garantirne la massima accessibilità oltre che la replica.
Swift è compatibile con il servizio di storage Amazon S3 e funziona con lo stesso principio: fornire uno storage web accessibile e scalabile.

Conclusioni

In questa lunga introduzione sono stati illustrati filosofia, componenti e soprattutto potenzialità di OpenStack, ma sebbene la lettura possa essere apparsa lunga, questa tocca appena la superficie dell’universo relativo a questo grande progetto.
Nel prossimo articolo verrà avviato un piccolo studio di fattibilità vero e proprio con lo scopo di mettere su strada tutti i vari software che lo compongono ed iniziare cosi ad adoperare OpenStack.

Mesosphere e la scalabilità dei Data Center

Mesos(sphere) Data Center scalabili

Mesos(sphere) Data Center scalabili

Mesosphere , per chi ancora non la conoscesse, è una startup con sede a San Francisco che si è concentrata sullo sviluppo di un sistema operativo per garantire la scalabilità di un Data Center attraverso il componente open source Apache Mesos, nato dalle viscere della UC Berkeley e già adottato e riadattato nell’uso da giganti del calibro di Twitter, eBay e Airbnb ed anche Apple, che ha ricostruito il progetto SIRI proprio sulla piattaforma tecnologica di Mesos.

L’obiettivo di Mesosphere è semplice, ossia rendere Mesos e le tecnologie a esso affini adatte all’uso anche nelle piccole enterprise, cioè in tutte quelle realtà che non possono permettersi un esercito di ingegneri pronti a prototipare e mettere in produzione un sistema proprietario. In questo modo, anche le piccole realtà potrebbero godere dei vantaggi di cui gode Google, tanto per citarne uno (a caso), che ha sviluppato la tecnologia proprietaria BORG, ossia un substrato software capace di orchestrare le applicazioni, suddividendone l’esecuzione fra tutte le risorse disponibili nei data center globali dell’azienda.

Per capire meglio come funziona BORG e come funziona Mesosphere, basti pensare a tutti i servizi che Google mette a disposizione della propria utenza, come Google Search, Gmail, Google Maps, YouTube e via discorrendo. Mountain View ha organizzato tutte queste applicazioni in modo che condividessero i workload fra tutte le risorse di tutti i data center della società, evitando di assemblare dei cluster separati di server per ogni servizio. [Elementi fondamentali, i workload, nella progettazione del moderno ambiente IT, infatti un buon design dei workload serve per permettere alle applicazioni di essere eseguite con maggior efficienza].

Cosi come il segreto della scalabilità dei servizi di Google sembra risiedere in BORG, Mesosphere punta alla scalabilita’ dei Data Center e, lavora per offrire un sistema operativo per Data Center anche a chi non ha le opportunità di investimento al pari di Mountain View.

Il nome di questo sistema operativo e’ DCOS, ossia Data Center Operating System, il quale è capace di astrarre CPU, memoria, storage e altre risorse computazionali dai server fisici, per riunirli in una piattaforma di gestione unica e facilmente scalabile. Secondo Mesosphere, questo sistema operativo, attualmente in fase beta, permette agli amministratori IT di scalare i cluster data center aggiungendo fino a 50 mila server.

La base del DCOS è un insieme di strumenti open source di cui molti disponibili via Apache Licenses. Questi tools giacciono su un sistema kernel distribuito, che offre le API necessarie alla gestione e all’organizzazione delle applicazioni distribuite. Fra i componenti del nuovo sistema operativo per il cloud computing ci sono un init system distribuito (Marathon), un pianificatore di attività distribuito (Chronos) e un service discovery (DNS). L’architettura supporta già ed è compatibile con Apache Spark, Apache Cassandra, Kafka, Hadoop, YARN, HDFS e Google Kubernetes.

La flessibilità del nuovo sistema operativo di Mesosphere è comprovatadalla capacità di supportare tutte le versioni Linux più recenti delle distribuzioni CoreOS, CentOS, Ubuntu e Red Hat e, dalla possibilita’ di poter essere eseguito su bare metal o in un ambiente di private cloud virtualizzato su alcuni dei più importanti cloud provider come AWS, Google Compute Engine, Digital Ocean, Microsoft Azure, Rackspace e VMware vCloud Air e, dal supporto ad altri strumenti di gestione data center come OpenStack, Docker, Cloud Stack e VMware vCenter Orchestrator.

La crescita di Mesosphere è garantita da una serie di finanziamenti per startup, di cui l’ultimo ricevuto è pari a 10 milioni di dollari. Il nuovo finanziamento, permetterà quindi a Mesosphere di uscire dalla fase beta e proporre DCOS in due differenti versioni, una a pagamento offerta con supporto tecnico e servizio di consulenza e una gratuita per la community.

 

#MesosilnuvoSystemperDataCeter

CoreOS anche su Big G

CoreOS Cloud System

CoreOS Cloud System

Da meta’ Maggio la piattaforma di cloud IaaS di “Big G” è in grado di ospitare virtualizzazioni del sistema operativo CoreOS; tramite un annuncio sul blog del servizio è stata resa nota la disponibilità alla creazione di infrastrutture basate su questo sistema innovativo e che permetterà di realizzare infrastrutture in maniera semplice ed efficace.

Il progetto CoreOS è nato da due ingegneri di Rackspace, Alex Polvi e Brandon Philips, e da un ex dipendente Google, Michael Marineu: i tre hanno dato vita ad un sistema operativo dedicato alla tecnologia cloud, molto leggero nel consumo di risorse e in grado di attivare un cluster complesso in poco tempo grazie a degli strumenti di orchestrazione unici. I due componenti chiave di CoreOS si chiamano etcd e fleet: entrambi sono scritti nel linguaggio Go e servono ad alimentare rispettivamente le configurazioni del cluster e il deploy delle applicazioni tramite dei container Docker.

Google si allinea quindi a Amazon EC2, Rackspace Cloud e altri provider di infrastrutture cloud dove CoreOS è già selezionabile, il sistema operativo è già compatibile con OpenStack e KVM, aspettiamoci di vedere presto crescere le quote di mercato di questo prodotto possiamo ritenere che riempa il buco dei sistemi operativi dedicati al clouding.

 

#Coreoscloudcomputingsystem

Docker – cosi’ cambia la virtualizzazione

docker_logoPREMESSA

Docker, inizialmente sviluppato per la piattaforma PaaS (Platform as a Service) di dotCloud, e’ oggi disponibile su Red Hat Fedora e sulla soluzione enterprise OpenShift. Grazie a questa tecnologia, la virtualizzazione passerà al livello applicativo, impacchettando quanto necessario per eseguire le applicazioni su differenti tipologie d’infrastrutture. Ecco quindi come si estendera’ il concetto del Linux Containers LXC , di cui abbiamo trattato in un prededente articolo (vedi link LXC).Docker è il nome di un nuovo ed impotante esempio di progetto, e di start-up, che ha stupito il mondo dell’open source ed ha attirato l’interesse finanziario, e non solo, di grandi gruppi del settore come Red Hat, e non solo.

Per chi non lo conoscesse, Docker è un progetto che automatizza il deployment delle applicazioni fra differenti piattaforme Linux based. L’obiettivo della piattaforma è quello di consentire la distribuzione e l’esecuzione agevole di un app su differenti tipologie di macchine, dotate di differenti sistemi operativi Linux, dai server virtuali, ai cloud-server presenti fra le nuvole private e pubbliche, fino ai bare-metal server, e fin’anche alle macchine fisiche.

Docker è stato inizialmente sviluppato per DotCloud la startup proprietaria di un’infrastruttura PaaS (Platform as a Service) multilingua.

Docker: ecco come funziona

Il funzionamento di base di Docker è alquanto semplice: il tool è capace di impacchettare un’applicazione e le sue dipendenze in un contenitore virtuale che può essere mandato in esecuzione su qualsiasi versione di Linux.Il risultato di questo processo è una maggiore flessibilità e portabilità delle applicazioni e l’opportunità di eseguirle ovunque senza alcuna problematica, dal proprio laptop, ai cloud server privati e pubblici, ai server virtuali fino ai server fisici.

Dockers non effettua la portabilità delle macchine virtuali o dei sistemi operativi, ma rende portabile il codice con cui l’applicazione è scritta, permettendo così una maggiore mobilità fra le macchine virtuali, anche nelle infrastrutture di cloud computing.

Dockers estende un formato comune di package già presente in Linux e noto come Linux Containers o LXC e Dockers per l’appunto utilizza il formato LXC, e le funzionalità kernel di Linux stesso, mentre lascia all’infrastruttura sottostante il compito di provvedere alle funzionalità del sistema operativo.

Docker sembra sposarsi perfettamente con OpenShift, con cui condivide alcuni aspetti tecnologici e architetturali fondamentali, come i namespace del kernel Linux e la gestione delle risorse tramite cGroups. Lo stesso Openshift, infatti, è costruito su Red Hat Enterprise Linux a già offre un sistema di “cartridge” basato sul formato LXC attraverso l’utilizzo delle Red Hat Enterprise Gears, che sara’ in grado di aumentarne l’usabilità e portabilità.

Il progetto Docker sta riscuotendo un alto livello d’ interesse anche fra i colossi del Web e dell’IT a tal punto che aziende del calibro di Microsoft, Red Hat (gia citata), IBM, Mesosphere, CoreOS, SaltStack e Google hanno iniziato a collaborare su un progetto open source pensato a Mountain View e conosciuto con il nome in codice Kubernets.

In pratica, Google e gli altri attori citati vogliono agevolare la gestione e l’uso dei contenitori Docker e Mountain View è fra le prime a sfruttare in modo massivo la tecnologia pensata da Docker all’interno dei suoi data center.

Insomma, per concludere, grazie ai signori di Docker passeremo presto ad un nuovo concetto di virtualizzazione, tutto ancora da scoprire, ma a vedere i nomi delle aziende che vogliono scommeterci , non resta che iniziare a prepararsi.

Bye