Archivi tag: docker

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.

Il miracoloso NodeJS

piattaforma Open Source event-driven

NodeJS – una piattaforma Open Source event-driven

Ok, ammetto che fino a non molto tempo fa mi ero quasi scordato di Javascript, nonostante fosse stato uno dei primi linguaggi da me studiati, nel lontano 1997, quando mi approcciai al mondo del web; negli anni successivi pero’, non essendo io uno sviluppatore, le tecnologie di gestione e deploy dei server web che dovevo gestire si erano spostate verso un grande quantitativo di linguaggi, in particolare per la parte back-end , passando cosi dal php, perl, python, java, ruby, lua etc……

Come stavo dicendo, per me javascript era rimasto in sordina come un linguaggio di scripting che intercorreva tra l’hmtl ed il css, nella composizione piu’ o meno dinamica di una pagina web ,prima che i pesi massimi sopra citati entrassero in campo per svolgere il duro lavoro.

Poi, un giorno, a ciel sereno……BOOOOOOOMMMM ! scopro l’esistenza di NodeJS, ed iniziai a chiedermi a cosa si dovesse tutto l’interesse di cui stavo leggendo; scopro quindi che NodeJS e’ una piattaforma Open Source event-driven per l’esecuzione di codice JavaScript Server-side, costruita sul motore V8 di Google Chrome. Mmmmhhhh, ok bene, ma quindi? cosa fa?

Ebbene questa piccola rivoluzione creata da Google consente agli sviluppatori di realizzare web application con JavaScript non più solo lato client, ma anche sfruttandolo come linguaggio di programmazione lato server.

E gli sviluppi sono davvero moltissimi, cosi tanti che mettere un’elenco sarebbe noioso e stancante ma, tanto per farne uno molto odierno, con NodeJS possiamo, ad esempio, realizzare dei ChatBot.

Ma qual’e’ dunque il funzionamento che lo rende cosi appetitoso? Innanzitutto partiamo dal dire che Node funziona con una logica a eventi: quando un evento viene generato, allora viene eseguita un’azione. Grazie a questa tecnica non bisogna attendere che le istruzioni precedenti siano terminate, rendendo cosi il tutto molto veloce.

Nella pratica, non c’e’ bisogno di sapere come funziona il V8 per poter utilizzare NodeJS, basti sapere che e’ l’interprete javascript piu’ veloce al mondo, poiche’ e’ stato altamente ottimizzato utilizzando un tipo di programmazione JIT (Just In Time), che trasforma rapidamente il codice javascript in linguaggio macchina.

Ma la cosa che, almeno a parere personale, mi ha maggiormente colpito, e’ stato quello che possiamo chiamare come “Modello non bloccante” , questo si basa sul concetto degli eventi, ma per meglio chiarire dovremmo spiegare un minimo la differenza tra modello bloccante e NON bloccante.

Immaginiamo di dover creare un programma che ci permetta di scaricare un file da internet e che alla fine dell’esecuzione del download ci mostri un messaggio.

Bene, con il modello classico (bloccante) basato sulla programmazione sincrona potremmo schematizzare il processo nel seguente modo:

  • Scarica il file
  • Mostra il messaggio
  • Fai qualcos’altro

Ci aspetteremmo quindi che le azione vengano eseguite in ordine, leggendo le operazioni da eseguire dall’alto verso il basso.

Nel sistema asincrono di NodeJS invece le operazioni verranno svolte nel seguente modo:

  • Scarica file
  • Fai qualcos’altro
  • Mostra il messaggio

Perche’ questa diversita’ nell’esecuzione rende il tutto piu’ veloce e performante? Beh perche’ mentre il sistema effettua il download del file, il programma non rimane in attesa che il processo venga portato a termine ma anzi nell’attesa il programma esegue altre operazioni.

Il codice in oggetto avra’un aspetto tipo questo:

request(‘http://www.site.com/file.zip&#8217;, function (error, response, body) {
console.log(“Download completato!”);
});

console.log(“Mentre aspetto eseguo il resto del codice…”);

Quello appena descritto qui sopra e’ un’esempio di procedura di callback 

Ok ma se non fosse ancora del tutto chiaro, proviamo ancora a spiegare perche’ le callback sono cosi importanti, procediamo con l’esempio di prima ed aggiungiamo una difficolta’; adesso i file da scaricare sono diventati due, dunque nel sistema sincrono il programma procederebbe nel seguente modo:

  • Scarico primo file
  • Attendo che finisca
  • Scarico secondo file
  • Attendo che finisca
  • Mando messaggio

La grande differenza in questo esempio sarebbe che con NodeJS verrebbero lanciati entrambi i download, nello stesso momento, permettendo gia cosi un piu’ veloce download e, nel frattempo il programma e’ in grado di svolgere eventuali altri compiti. Ma questo come dicevo e’ soltanto un esempio, invece di un download multiplo, potrebbero essere delle query ad un DB, o la richiesta di dati a servizi esterni tramite API (Facebook, Twitter).

Pensiamo quindi ad un sistema come Facebook, che riceve X richieste di Like ogni tot secondi e vengono cosi aperti N operatori che devono attendere il loro turno per fare la modifica (del like) consumando comunque energie anche mentre sono fermi in attesa; invece NodeJS nella stessa situazione di richiesta di “reaction” sul sisto di FB (like o altro) si comporterebbe nel seguente modo:

metterebbe tutte le richieste in ordine di arrivo, prenderebbe la prima e, vedendo che si tratta di una sfilza di input le inserirebbe all’interno del sistema e, una volta capito che si tratta di stesse azioni (ad esempio che aggiungono un Like) che devono contattare un DB, NodeJS contatta il DB e invece di attendere per effettuare ogni singola modifica, aggancia alla richiesta una callback, per ogni richiesta di modifica, tutti uno dietro l’altro. Quando il DB finisce la prima modifica scatta la callback e NodeJS restituisce all’utente l’avvenuta modifica della pagina e cosi via, gestendo quindi con un solo operatore le N richieste di modifica del Like invece di crearne uno per ogni richiesta e parcheggiandoli tutti in attesa della loro singola modifica. Quindi con un server (magari anche un container con Docker) e con poche risorse possiamo gestire un’enorme quantita’ di richieste al secondo.

Inoltre NodeJS usa come sistema di pacchetti e librerie l’NPM, ma di questo fantastico sistema di librerie parleremo in un’altro articolo.

Nel prossimo articolo su NodeJS parleremo anche di 5 nuovi framework ottimi per chi si occupa di sviluppare.

#NodeJS

 

Docker i Container ed i Microservices

Docker ed i Microservices

Docker ed i Microservices

Su questo portale abbiamo gia piu’ volte scritto e descritto la tecnologia che sta dietro al progetto Docker, sicuramente una delle nuove scoperte informatiche degli ultimi anni, a livello dell’uscita della Virtualizzazione; ma nonostante tutto, non sempre e’ facile capire in poche righe concetti nuovi non sempre semplici da comprendere, quindi eccovi un nuovo articolo, che fara’ parte di una piccola serie di episodi, in cui cercheremo di fare ulteriormente luce su cos’e’ e come funziona questo fantastico progetto.

Dagli script PHP ai microservice
Alla fine degli anni ’90 i siti erano per lo più ancora statici, con qualche script CGI , o altre soluzioni oggi considerate poco eleganti. Poi arrivarono ASP JAVA e PHP. Da li in avanti un progetto Web era prettamente fondato, ad esempio, su file PHP, CSS e immagini; in queste soluzioni tecnologiche era sufficiente copiare tutti questi file su uno spazio hosting e al più modificare qualche file di configurazione, per ricreare un nuovo ambiente web e ricominciare su di un nuovo sito.

Venti anni dopo gli scenari sono drasticamente diversi, le architetture SOA hanno preso piede, si è iniziato a parlare di microservice e tutto è diventato più complesso. Un’applicazione web, soprattutto in ambito enterprise, non è più la directory di cui parlavamo prima, ma un’ insieme di componenti autonomi, ognuno col suo ciclo di vita indipendente, rilasciati su macchine diverse e a ritmi sempre crescenti.

Una complessità così grande non può piu’ essere amministrata con il vecchio copia e incolla, diventa cosi’ necessario uno strumento affidabile che consenta di manipolare o spostare intere applicazioni limitando errori umani, checklist lunghissime da controllare e tutti i passaggi snervanti e carichi di rischi necessari per il deployment.

I container
Cosi’ come nell’industria dei trasporti nacque l’esigenza di una soluzione unica intercambiabile, vennero cosi creati i container: contenitori multiuso, realizzati in formati standard che possono essere passati con facilità da un camion a una nave, poi magari su un treno merci e così via.

Anche nel campo informatico abbiamo bisogno di qualcosa che “contenga” la nostra applicazione, che ci consenta di manovrarla con facilità senza sapere nulla, o quasi, riguardo il suo contenuto. In pratica, abbiamo bisogno anche noi del nostro container!

Docker
L’intuizione del team di Docker è stata quella di prendere il concetto di container e costruirvi attorno un’ ecosistema che ne semplificasse l’impiego. Di questo ecosistema fanno parte una serie di tool: Docker engine, Docker Toolbox, Swarm, Kitematic e tant’ altro ancora per rendere i container qualcosa di accessibile anche a chiunque, sfruttando anche il fatto che la community di sviluppatori che utilizza Docker è davvero molto vasta. Ad esempio, Docker Hub è un repository di container pubblici pronti per l’uso, mentre il codice sorgente del Docker engine è liberamente disponibile su GitHub e vanta quasi 1500 contributor.

Container VS Virtual Machine
Apparentemente i container e le virtual machine sembrano due concetti molto simili ma, sebbene queste due soluzioni abbiano delle caratteristiche in comune, si tratta di tecnologie profondamente diverse tra loro, così come diverso è anche il modo in cui dobbiamo iniziare a pensare all’architettura delle nostre applicazioni. Possiamo creare un container con la nostra applicazione monolitica all’interno, ma così non sfrutteremmo a pieno la forza dei container e quindi di Docker.

Una possibile architettura software adatta per un’infrastruttura a container è la classica architettura a microservizi. L’idea, in pratica, è quella di scomporre l’applicazione in tante piccole componenti ognuna col suo compito specifico ma capaci di scambiarsi messaggi e di cooperare tra loro, cio’ che e’ alla base dei sistemi SOA. Il deploy di tali componenti avverrà poi effettuato singolarmente, come tanti container.

Uno scenario come quello ipotizzato è assolutamente poco pratico con una macchina virtuale, in quanto ogni nuova macchina virtuale istanziata richiederebbe un bel dispendio di energia per la macchina host. I container, al contrario, sono molto leggeri, poiché effettuano una virtualizzazione completamente diversa da quella praticata dalle macchine virtuali.
Nelle macchine virtuali, lo strumento detto hypervisor si preoccupa di riservare (staticamente o dinamicamente) un certo quantitativo di risorse dal sistema operativo host da dedicare poi ad uno o più sistemi operativi, detti guest o ospiti, inoltre ogni sistema operativo guest sarà completamente isolato dal sistema operativo host. Questo meccanismo è molto dispendioso in termini di risorse, per cui l’idea di associare un micro-servizio ad una macchina virtuale è del tutto irrealizzabile.

I container, d’altro canto, apportano un contributo completamente diverso alla questione, l’isolamento è molto più blando e tutti i container in esecuzione condividono lo stesso kernel del sistema operativo sottostante, host. Scompare completamente l’overhead dell’hypervisor, e un singolo host può arrivare a ospitare centinaia di container.

Docker VS VirtualMachine

Docker VS VirtualMachine

Nel prossimo articolo rivedremo come installare Docker tramite i Docker-ToolBox, e come interagire con i container.
Alla prossima

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 nuova rivoluzione nel Cloud

CoreOS new Cloud System

CoreOS new Cloud System

Poco tempo fa ho pubblicato un breve articolo introduttivo riguardante CoreOS ed il suo uso nei DataCenter, ma in pratica cos’ha di così interessante CoreOS ? Lo sviluppatore di CoreOS, Alex Polvi, è partito da ChromeOS, il sistema operativo sviluppato da Google intorno al browser Chrome, per ottenerne molto di più.

Dunque, partendo da questo presupposto si potrebbe affermare che CoreOS e’ in definitava una distribuzione Linux pensata per gli ambienti server, ma a differenza dei prodotti Linux-based già riservati al settore server ed enterprise, CoreOS prevede solo il kernel di Linux ed il systemd, ossia il gestore dei processi per avviare i servizi essenziali all’inizializzazione del sistema.

In pratica questo sistema operativo è pensato per i clienti che devono avviare e gestire cluster di centinaia di server e si inserisce quindi come un server Linux per le distribuzioni ad alto volume di dati e di traffico (IaaS, PaaS, SaaS). In maniera molto semplicistica, potremmo dire che CoreOS impacchetta Internet in una singola postazione, permettendo di ospitare infrastrutture simili a quelle di Amazon e Google sul proprio computer, grazie alla potenza di questo sistema operativo altamente scalabile che portera’ non poco risparmio alle startup del mondo cloud computing.
CoreOS offre quindi l’infrastruttura necessaria a ospitare i componenti di qualsiasi applicazione Web e non è dotato di null’altro, se non dei bit sufficienti per eseguire i contenitori. A tale riguardo, come gestore dei contenitori, CoreOS utilizza Docker e, come già spiegato in precedenza, la scelta dei contenitori, a differenza della virtualizzazione, permette di gestire meglio le performance della macchina e di distribuire la medesima configurazione su differenti hardware.

CoreOS, inoltre, si rifà a ChromeOS per quanto riguarda la questione degli aggiornamenti, infatti il sistema operativo supporta gli aggiornamenti automatici in background e non crea problemi d’inconsistenza dati, in quanto funziona su due partizioni disco, attivate alternativamente uno alla volta, in questo caso la partizione inattiva potra’ essere aggiornata offline effettuado uno swap dei dischi seguito da un riavvio, in modo da poter procedere con gli aggiornamenti. Il riavvio potra’ richiedere da mezzo secondo a un secondo netto.

Infine, CoreOS utilizza una partizione di sola lettura per il filesystem e include il componente etcd come servizio distribuito di configurazione.

Nel prossimo articolo vedremo come funziona nella pratica, nel frattempo vi invito a dare un’occhiata al video qui riportato dal titolo parlante : “PlayStation: Developing Apps on CoreOS”