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

Cisco Academy nuovo corso NDG Linux Essentials

Back to School Cisco Academy

Back to School Cisco Academy

Oggi vi segnalo il nuovo corso “NDG Linux Essentials” realizzato dal Programma Cisco Networking Academy e proposto da Linux Professional Institute (LPI).

NDG Linux Essentials
Un nuovo percorso formativo arricchisce il Programma Cisco Networking Academy, promosso dall’azienda in tutto il mondo per consentire di acquisire le competenze professionali ICT più richieste nel mercato del lavoro: si tratta di NDG Linux Essentials, dedicato alla conoscenza dei principi fondamentali del sistema operativo Linux.
Il corso NDG Linux Essentials è stato ideato dal gruppo di sviluppo della NDG (Network Development Group), è conforme alle linee guida proposte da Linux Professional Institute (LPI) ed insegna i fondamenti di un sistema la cui adozione è in costante crescita, generando una importante domanda di personale qualificato.

Il corso NDG Linux Essentials è disponibile in tutto il mondo sulla piattaforma Cisco NetSpace Learning, dedicata ai corsi del programma Cisco Networking Academy, ed è erogato secondo l’approccio pratico tipico del programma: si offre una piattaforma operativa che consente agli studenti una continua interazione con il materiale formativo a loro disposizione, aumentando il loro coinvolgimento e le loro conoscenze.

Il Cisco NetSpace Learning è una piattaforma cloud e questo costituisce un ulteriore valore aggiunto, perché l’integrazione al suo interno di un vero ambiente di laboratorio Linux consentirà a università, scuole, enti formativi di inserire l’istruzione open source nella propria offerta senza dovere sviluppare in proprio una struttura dedicata.

Per maggiori informazioni consultare la sezione dedicata a NDG Linux Essentials dal portale Cisco.

 

#CiscoAcademyCorsoLinuxEssentials