L’importanza ed il valore del Web3

Durante la preparazione del secondo articolo su #Bitcoin 1 anno di studio, ho riflettuto su alcune considerazioni che spesso si fanno al volo nel momento in cui si sentono determinate notizie su prossimi fenomeni sociali e/o sconvolgimenti degli assunti modelli di Status quo.

Quasi come una profezia sul futuro, o forse come un monito al cambiamento sociale verso cui ci stanno spingendo, uno dei nuovi mantra più rilevanti lo ha da tempo messo in agenda il World Economic Forum, che già dal lontano 2017 ha iniziato a proporre un messaggio che potremmo tradurre in questa immagine:

Letto velocemente e senza riflettere su quali siano le evidenze della nostra vita quotidiana di Occidentali privilegiati, sembra una forzatura, ma se provassimo ad analizzare insieme ciò che abbiamo attorno, potremo vedere che i semi di questo frutto avvelenato stanno gi crescendo nell’humus della nostra società, una società che, rispetto a quella dei nostri nonni o anche solo dei nostri genitori (intendendo perlomeno i baby boomers, dunque persone nate tra il 1945 ed il 1965), è stata spinta ad un sostanziale distacco dalla condivisione dei problemi della comunità, creando una sorta di noncuranza apatica, che negli ultimi 2 anni si è trasformata in “distanziamento”.

Un cambiamento sociale che nel dopo guerra era sinonimo di mutuo soccorso tra le persone, e che invece oggi ha assunto il ben più lugubre significato di : “…tutto è stato trasformato in intrattenimento e le persone non hanno più voluto preoccuparsi di problemi difficili”, ossia di quei problemi, politici, industriali, economici che sembrano così complicati al punto che finiamo col pensare che “non sono affar nostro” e che, per organizzare e gestire i quali, si debba delegare tutto agli esperti, ai tecnici, agli scienziati (i virologi), gli amministratori delegati, i grandi finanzieri, i media mainstrem, i moralizzatori… “…sapranno ben loro occuparsi di tutto per noi, assicurandoci la felicità”.

Io ho trascorso infanzia e giovinezza tra gli anni 70-80 e le case erano piene di dischi in vinile, musicassette, video cassette, cartucce di video giochi, album fotografici etc……; quindi possedevamo fisicamente le nostre collezioni di arte nelle sue differenti forme.
Ma OGGI ??

  • la Musica la “paghiamo” (non la compriamo) su Spotify;
  • i Film li vediamo in streaming da Netflix, Disney channel etc…..;
  • i Video giochi si stanno spostando su piattaforme di streaming online e a breve sui Metaversi;
  • le Fotografie sono tutte nel cloud tra servizi Social come FB o Instagram che usiamo come store (magazzino) della nostra vita
  • i Documenti li scriviamo, li condividiamo su piattaforme come GoogleDocs;
  • i Progetti sono parcheggiati su piattaforme cloud come Github
  • i Server aziendali sono quasi tutti nel cloud di AWS e simili, tra macchine virtuali senza alcuna identità

e potrei continuare ancora a lungo. Dunque che cosa succede se e quando uno di questi servizi ha problemi di connessione di qualunque genere, e negli ultimissimi anni è capitato un pò a tutti i Big del Cloud di avere delle cadute di servizio improvvise, a volte anche di diverse ore. Abbiamo così visto uffici impossibilitati a gestire i documenti, le fatture, le spedizioni o solo a mandare email , riunioni annullate, disservizi di ogni genere in ambito lavorativo/professionale. E nella vita personale ??, cosa succede se Netflix non funziona o non riesci a rinnovare l’abbonamento? come la ascolti la musica se Spotify ti chiude l’utenza, magari per sbaglio, magari per altri motivi, che fine fa tutto il lavoro di creazione delle tue splendide Playlist?, perso in un attimo, e le foto di una vita ?, le vacanze, il primo giorno di scuola dei figli etc…. cosa accade se Facebook cambia il regolamento delle politiche aziendali e magari!! a causa di quel post in cui hai criticato l’ultima iniziativa del governo vieni segnalato ed il tuo account viene sospeso o cancellato?

Questa lunga premessa era d’obbligo per cercare di farvi entrare nel ragionamento per cui personalmente penso che il Web 2, quello che viviamo ancora oggi, si sia strasformato in un sistema ultra centralizzato in cui pochi attori decidono le sorti dei loro utenti, altro che il motto “il cliente ha sempre ragione”, qui il cliente può solo fare ACCETTA ad ogni aggiornamento di regolamento del Social di turno, oppure finire estromesso dalla sua esistenza virtuale, SI perchè siamo noi, tuenti e creator che creiamo i contenuti dei loro Social ma i padroni di quei contenuti, stranamente, non siamo noi ma sono loro.

Ma come siamo arrivati a questo e perchè nutro la speranza che il web3 possa riportarci ai fasti del web1 ma con in più l’innovazione e l’accento sulla proprietà personale delle informazioni.

L’evoluzione di Internet

WEB 1.

Il web1 , che possiamo inquadrare nel periodo che va, all’incirca, tra il 1990 ed il 2005, riguardava fondamentalmente la nascita e la prolificazione dei protocolli del web aperti, decentralizzati e governati dalle community, certo la comunicazione era unidirezionale ma chiunque poteva aprirsi un sito, un blog e condividere i propri interessi senza censura.

Tutto ciò significava che, inizialmente, le persone o le aziende potevano aumentare la loro presenza su Internet sapendo che le regole del gioco non sarebbero cambiate in seguito. In questa prima fase sono così nati i più importanti soggetti del web quali Yahoo, Google e Amazon.

WEB 2.

Con il web2 (all’incirca 2005-2020) si sono successivamente sviluppati tutta una serie di servizi centralizzati gestiti da società che si sono trasformate in Monopolio del web. La maggior parte del valore è stato acquisito da una manciata di aziende come Google, Apple, Amazon e Facebook, avvantaggiate dalla crescita esplosiva degli smartphone che ha generato la tendenza all’uso delle app, che sono diventate ad oggi la maggior parte dell’uso quotidiano di Internet. Questo ha fatto si che alla fine gli utenti sono migrati dai servizi aperti a questi servizi centralizzati, inizialmente più sofisticati.

Bene ma non BENISSIMO; certamente questo ha fatto si che miliardi di persone abbiano avuto accesso a tecnologie straordinarie, molte delle quali erano gratuite ma, la cattiva notizia è che è diventato molto più difficile per startup, senza appoggio di Venture Capitalist, riuscire ad aumentare la propria presenza su Internet senza preoccuparsi che le piattaforme centralizzate cambiassero le regole su di loro in corso d’opera, portandogli via pubblico e profitti. Di riflesso, anche se potrebbe non sembrare, questo ha soffocato l’innovazione, rendendo Internet meno interessante e dinamico. La CENTRALIZZAZIONE ha anche, in seconda battuta, creato tensioni sociali più ampie, generando un sistema di controllo e censura del web che ritroviamo in concetti come fake news, fact checker , privazione della privacy degli utenti per un bene più alto e tanto altro.

Ci troviamo in questo momento storico all’inizio di un nuovo paradigma, poichè stiamo vivendo la nascita dell’era web3, che combina l’etica decentralizzata e governata dalla community del web1 con le funzionalità avanzate e moderne del web2.

WEB 3.

Il web3 è l’Internet della proprietà e degli utenti, non più delle multi nazionali della Silicon Valley, dove il tutto viene orchestrato attraverso i #token. Innanzitutto, diamo un’occhiata ai problemi delle piattaforme centralizzate.

Le piattaforme centralizzate seguono un ciclo di vita prevedibile e, all’inizio, fanno tutto il possibile per reclutare utenti per formare una community e creatori di contenuti da eleggere ad influencer, cercano il sostegno di grandi Brand così da poter rafforzare il loro effetto e la loro presenza in rete.

Man mano che le piattaforme aumentano la curva di adozione, il loro potere sugli utenti e sulle terze parti cresce costantemente, a tal punto che una volta raggiunta la vetta della curva di crescita/adozione, le loro relazioni con i partecipanti alla rete si azzerano, trasformando i propri partner in competitor: esempi famosi di questo sono Microsoft contro Netscape, Google contro Yelp, Facebook contro Zynga etc, e gli utenti che hanno formato la massa di adozione vengono controllati con sempre più aggiornamenti dei regolamenti della community, che di community a questo punto hanno ben poco visto che non esiste una votazione per la decisione delle modifiche e se vuoi rimanere nel Social puoi solo che cliccare sul campo “accetta”, altrimenti verrai buttato fuori in tempo zero.

Dunque una forma di controllo delle masse basato sul consenso forzato delle “regole della community” ; si arriva così, solo dopo, a capire che che i Social sono solo aziende private con le loro policy aziendali ed i loro interessi commerciali, non sono centri sociali di scambio e divulgazione del pensiero libero democratico.

La Speranza nasce dal fatto che nel web3, la proprietà e il controllo sono decentralizzati, ciò significa che gli utenti possono partecipare attivamente nei progetti, insieme ai costruttori delle nuove piattaforme, possedendo pezzi di servizi Internet tramite il possesso di token, sia non fungibili (NFT) che fungibili (come le criptovalute). I token conferiscono agli utenti dei diritti di proprietà: questi diritti possono riguardare arte, foto, codice, musica, testi, oggetti da gioco, credenziali, diritti di governance, pass di accesso, e, in linea generale, tutto ciò che la gente può immaginare.

BENVENUTI NELLA RIVOLUZIONE DEL WEB 3

Nel prossimo articolo continueremo su questa traccia iniziando a descrivere il mondo del Branding e degli NFT.

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.

Breve corso di Vagrant – Puntata 1

Vagrant Stack-LAMP

Vagrant Stack-LAMP

Dopo aver gia scritto in precedenti articoli di Vagrant ho sentito l’esigenza di metter, come si suol dire, nero su bianco un piccolo corso/progetto da portare avanti su queste pagine in cui verra’ spiegato non solo l’uso piu’ avanzato di Vagrant ma anche alcuni concetti fondamentali inerenti la creazione di un servizio WEB moderno, introducendo i concetti di “scalabilita’” e di “high availability“.

Iniziamo con un breve elenco dei comandi di vagrant usati più comunemente :
vagrant init [nome-box] [url-box] = inizializza la directory corrente come ambiente per Vagrant e crea il file di configurazione Vagrantfile
vagrant up = crea, configura e avvia la macchina virtuale definita in Vagrantfile . Se la macchina virtuale già esiste, la fa solo partire
vagrant halt <nome macchina> = ferma una macchina virtuale
vagrant destroy = elimina la macchina virtuale
vagrant ssh <nome macchina> = si collega alla macchina virtuale via ssh

Nel seguente esempio verra’ creata una directory che conterra’ il progetto di Vagrant, poi, inizializzemo il progetto, configureremo una macchina virtuale, la lanceremo e infine ci collegheròemo. I seguenti comandi creeranno una macchina virtuale con Ubuntu 14.04 (64bit). Notate che la prima volta che eseguirete questa serie di comandi, verrà scaricata dalla rete un’immagine del sistema operativo Ubuntu. Per farlo ci potranno volere svariati minuti, a seconda anche del tipo di connessione ADSL di cui disponete. Le volte successive, il processo sara’ molto più rapido, perché l’immagine usata per creare la macchina virtuale sarà già stata memorizzata nel vostro sistema.

PARTIAMO
Questi sono i primi comandi che useremo: vagrant init ubuntu/trusty64  &  vagrant up

<> vagrant init ubuntu/trusty64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

<> vagrant up
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Box ‘ubuntu/trusty64’ could not be found. Attempting to find and install…
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Loading metadata for box ‘ubuntu/trusty64’
default: URL: https://atlas.hashicorp.com/ubuntu/trusty64
==> default: Adding box ‘ubuntu/trusty64’ (v20151214.0.0) for provider: virtualbox
default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20151214.0.0/providers/virtualbox.box
default: Progress: 6% (Rate: 115k/s, Estimated time remaining: 0:43:23)))
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
==> default: Forwarding ports…
default: 22 => 2222 (adapter 1)
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
…………..etc etc !!

> vagrant ssh
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-73-generic x86_64)

* Documentation: https://help.ubuntu.com/

System information disabled due to load higher than 1.0

Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:6b:55:0f
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe6b:550f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:544 errors:0 dropped:0 overruns:0 frame:0
TX packets:392 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69053 (69.0 KB) TX bytes:53324 (53.3 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vagrant@vagrant-ubuntu-trusty-64:~$ exit

Dato che il nostro obiettivo è arrivare ad avere uno Stack LAMP, sappiamo che dovremo tenere conto di dover ancora installare e configurare gli altri software necessari ossia,  Apache, MySQL e PHP. Ci sono però anche altri componenti meno ovvi di cui va tenuto conto. Iniziamo studiando lo stack LAMP su di un modello di web application 2.0. Vediamo quindi di spiegare alcuni concetti fondamentali per questo tipo di architetture che vanno decisi prima d’iniziare a creare fisicamente le macchine/server che ci servono.

Scalabilità VS Disponibilità

Scalabilità verticale
Si può scalare un sistema senza aumentarne la disponibilità o il tempo di uptime. Esemplifichiamo, diciamo che vogliate gestire più utenti, più traffico e più carico per l’applicazione web, se si tratta di un server fisico, potreste spegnerlo, installare più memoria e potenziare la CPU, ad esempio. Potreste anche copiare tutti i dati da un solo piccolo server ad un server più grande che abbia più memoria, una CPU più potente e dischi più veloci. Se invece state usando un server virtuale, potreste fermarlo, allocare maggiori risorse e riavviarlo. Se il server è posizionato nel cloud, potrete cambiare il tipo di istanza ad uno che abbia più risorse. Questo si chiama scalare verticalmente. Non c’è niente di male in questo tipo di scalabilità, soprattutto se avete applicazioni in cui il tempo di fermo e’ accettabile.

Scalabilità orizzontale
Un’ altro modo per scalare è di aggiungere altri server, che a volte vengono indicati con il termine di nodi. Questo si chiama scalabilità orizzontale. Per scalare orizzontalmente, si deve fare prima un po’ di lavoro in anticipo, e progettare bene la transizione. Per andare ad esempio da un server web a due, dovrete trovare un modo per instradare il traffico al nodo aggiuntivo, e preferibilmente suddividere il carico tra i due server. Se vi servono più risorse, aggiungete un terzo server,  un quarto, un quinto e cosi’ via. Quando invece avete un solo server, e questo va giù, il servizio si interrompe, ma se avete più di un server che fanno gestiscono la stessa funzione, e uno di loro ha un malfunzionamento, lo scenario peggiore è che il servizio è degradato e non altrettanto prestante come di solito. Lo scenario migliore avviene quando un singolo malfunzionamento non viene nemmeno notato.

Il meglio di entrambi i mondi
In molti casi ha senso scalare il server web in modo orizzontale, e il server di database in modo verticale. Vedremo piu’ avanti, nei prossimi articoli, come prendere il meglio di entrambi i mondi, eliminando, o almeno riducendo moltissimo, il tempo di fermo per il servizio.

Nel secondo capitolo inizieremo la configurazione del file Vagrant per la preparazione delle 5 macchine necessarie al nostro progetto.

Stay Tuned !

Le novita’ di Debian 8

Debian 8 Jessie

Debian 8 Jessie

Il 25 aprile 2015 è stato annunciato il rilascio di Debian 8 (alias Jessie), che e’ l’ultima versione di uno dei più noti ed apprezzati sistemi operativi basati su Linux. Questo rilascio, atteso da moltissimi utenti e da altrettante aziende, porta con sè alcune novità significative, frutto di un lavoro di sviluppo durato circa due anni, e culminato in un sistema operativo che sarà supportato fino al 2020.

In questo articolo vedremo le principali novità introdotte su Debian 8, di cui è possibile effettuare il download direttamente dal sito ufficiale del progetto.

Una distribuzione universale
Debian, ad oggi vanta una vasta gamma di pacchetti software (circa 43 mila), che consentono a chiunque di personalizzarla a proprio piacimento, in base al tipo di applicazione per cui questo sistema sarà utilizzato: dai server alle workstation, passando per il cloud, i mainframe o le board che implentano l’Internet of Things.

L’idea della distribuzione universale, adatta a tanti contesti, ha spinto negli anni la comunità open source a creare un gran numero di derivate (ed il caso più noto risponde al nome di Ubuntu). Il fatto che molti sistemi Linux si basino su Debian aumenta quindi l’importanza di ogni aggiornamento apportato a questa distribuzione in ogni rilascio, dal momento che ciò si ripercuote su tutte le sue derivate (ufficiali e non).

Il passaggio a systemd
La novità più significativa, che ha creato molti dibattiti accesi, introdotta con Debian 8, riguarda il passaggio definitivo a systemd quale sistema di init principale, sebbene sia possibile utilizzare sysvinit come alternativa. Tale scelta trova le sue motivazioni nella riduzione dei tempi di avvio ed arresto del sistema, sebbene non tutti gli utenti sembrano convinti di ciò. Inoltre, systemd non si occupa solo della fase di boot: in quanto gestore di sistema, esso incorpora anche la gestione di diverse altre funzioni (alimentazione, dispositivi, login, eccetera), con conseguenze che potrebbero comportare, ad esempio, la necessità di riavviare il sistema in caso di aggiornamento. Un problema significativo per una distribuzione server, dovuto proprio a systemd. Il problema piu’ grande sorge per via del fatto che oggettivamente, l’attuale sistema usato, SysVInit, è oggettivamente un sistema antiquato, con un elenco di noti difetti, il principale dei quali è sicuramente la grande lentezza derivante dall’approccio seriale all’avvio dei servizi. L’idea di sostituirlo con un prodotto più moderno e meglio ingegnerizzato è, quindi, tutt’altro che sbagliata.

Il problema reale è che systemd sta andando ben oltre questo encomiabile tentativo, ma sta fagocitando al suo interno tutta una serie di servizi che con la gestione dei processi e la creazione dello ‘spazio utente’ poco hanno a che fare. Approccio, questo, che viola radicalmente le logiche della filosofia Unix, che sono alla base non solo dei Linux che usiamo oggi, ma in larga parte di quella che è l’informatica moderna.

Va detto, però, che il passaggio a systemd era già in atto da tempo, e non soltanto sulle distribuzioni basate su Debian: anche Red Hat, Fedora e SUSE (per citare alcune grandi distribuzioni Linux) sono già passate a questo nuovo gestore.

Desktop e applicazioni
Dal punto di vista dell’interfaccia utente, il grande grado di personalizzazione offerto da Debian si traduce nella possibilità di scegliere il proprio desktop environment preferito tra un gran numero di possibilità. L’ultimo rilascio è infatti compatibile con GNOME 3.14, KDE Plasma 4.11.13, Xfce 4.10, MATE 1.8 e Cinnamon 2.2.16.

Ai sopra citati desktop environment si aggiungono anche diverse applicazioni, tra cui Iceweasel 31.6, GIMP 2.8.14 e LibreOffice 4.3.3 per la sfera desktop, Apache 2.4.10, Tomcat 7.0.56 e 8.0.14, MariaDB 10.0.16 e MySQL 5.5.42 per quella server, nonchè OpenJDK 7u75, PHP 5.6.7 e Python 2.7.9 e 3.4.2 per gli sviluppatori.

Altre novità
Per concludere ricordiamo che Debian 8 è basato sul kernel Linux 3.16.7, che garantisce la compatibilità con le più recenti tecnologie disponibili. È altresì interessante notare che, con il nuovo rilascio, viene garantito il supporto a ben dieci architetture diverse, tra cui x86, PowerPC, MIPS, ARM e diverse altre.

 

#DebianottoJessie