Luca Cabibbo Architettura dei Sistemi...

Architettura dei Sistemi

Software

Luca Cabibbo

Luca Cabibbo ASWLuca Cabibbo ASW

Gestione di ambienti

dispensa asw640

marzo 2019

Gestione di ambienti1

Provisioning new servers is a manual, repetitive, resource-intensive,

and error-prone process. Exactly the kind of problem

that can be solved with automation. Jez Humble and David Farley

Luca Cabibbo ASW

- Fonti

Humble, J. and Farley, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.

Chapter 11, Managing Infrastructure and Environments

Bass, L., Weber, I., and Zhu, L. DevOps: A Software Architect’s Perspective. Addison-Wesley, 2015.

Chapter 2, The Cloud as a Platform


Luca Cabibbo ASW

- Obiettivi e argomenti

Obiettivi

presentare gli ambienti di esecuzione e le attività legate alla loro gestione

introdurre la gestione automatizzata delle configurazioni software e degli ambienti

Argomenti

introduzione

ambienti

deployment e provisioning

gestione automatizzata di ambienti

gestione di server e ambienti fisici

gestione di server e ambienti virtuali

monitoraggio di ambienti e applicazioni

discussione Gestione di ambienti3

Luca Cabibbo ASW

* Introduzione

In una precedente dispensa abbiamo già introdotto, in modo preliminare, la delivery del software e gli ambienti di esecuzione

la delivery di un sistema software ha lo scopo di rilasciare/consegnare il software (o una sua nuova versione) ai suoi utenti finali

la delivery del software comprende diverse attività, tra cui il deployment (installazione) del sistema software nel suo ambiente di esecuzione

a sua volta, il deployment comprende il provisioning(preparazione) dell’ambiente di esecuzione

un ambiente di esecuzione, intuitivamente, comprende le risorse di calcolo (hardware e software) necessarie per poter eseguire il sistema software

questa dispensa approfondisce la gestione degli ambienti di esecuzione


Luca Cabibbo ASW

* Ambienti

Un ambiente (environment) per un sistema software comprende tutte le risorse di calcolo (hardware e software) di cui il sistema software ha bisogno per poter essere eseguito, insieme alla loro configurazione

le risorse hardware (fisiche e/o virtuali) comprendono i nodi, con le loro configurazioni (ad es., tipo e numero di CPU, memoria, …), lo storage e l’infrastruttura di rete

le risorse software comprendono, per ciascun nodo, l’OS, il middleware (ad es., database server, message broker, …) e tutto il software di supporto e i dati (data set) che sono richiesti dal sistema software – con le loro configurazioni

in pratica, un ambiente per un sistema software deve essere in grado di eseguire il software in modo auto-contenuto

tranne l’eventuale dipendenza da specifiche entità esterne –ad es., servizi esterni come Google Maps


Luca Cabibbo ASW

Ambiente: un esempio

Un esempio di ambiente per un’applicazione web


web server web server

application server

application server

application server

database server

database server

load balancer

Luca Cabibbo ASW

Ambiente: un esempio

In un ambiente, ogni nodo richiede un’opportuna configurazione –sia dell’hardware che del software

le configurazioni sono in genere diverse per tipi di nodi differenti (ovvero, server che erogano servizi differenti)

inoltre, ciascun package software installato in un nodo richiede una propria configurazione


hardware

OSOS

configuration

middlewaremiddleware

configuration

applications/services

app/serviceconfiguration

application server

hardware

OSOS

configuration

databasedatabase

configuration

database server

Luca Cabibbo ASW

Un sistema software, tanti ambienti

Un sistema software richiede in genere più ambienti, tra cui

l’ambiente di produzione – ovvero, l’ambiente di esecuzione in cui il sistema viene effettivamente fruito dai suoi utenti finali

l’ambiente di sviluppo

uno o più ambienti di test – per test unitari, di accettazione, di carico – e per ulteriori test manuali


Luca Cabibbo ASW


L’ambiente di produzione Un ambiente di test


web server web server

application server

application server

application server

database server

database server

web server

application server

database server

Luca Cabibbo ASW


I diversi ambienti per un sistema software (ad eccezione dell’ambiente di sviluppo) sono di solito simili tra loro – ma non necessariamente identici – ed hanno la struttura richiesta dall’ambiente di produzione

in questa dispensa non consideriamo l’ambiente di sviluppo del software – in cui di solito non è necessario eseguire l’intero sistema software

inoltre discuteremo qui la definizione e la gestione di un solo ambiente – poiché la definizione e la gestione di ogni altro ambiente può avvenire in modo simile


Luca Cabibbo ASW


I diversi ambienti per un sistema software vanno in genere tenuti separati

l’ambiente di produzione deve sicuramente essere isolato rispetto agli ambienti di sviluppo e test

in particolare, l’esecuzione dei test non dovrebbe mai modificare i dati in produzione – e nemmeno sovraccaricare l’ambiente di produzione

in genere, l’isolamento tra ambienti può essere garantito dall’assenza di risorse condivise modificabili – la presenza di eventuali risorse condivise non modificabili (accessibili in sola lettura) potrebbe non costituire un problema (se non per l’eventuale incremento del carico di lavoro)

inoltre, eventuali entità esterne modificabili vanno accedute solo dall’ambiente di produzione – mentre gli altri ambienti devono poter accedere a dei cloni di test di queste entità


Luca Cabibbo ASW

Infrastruttura

L’infrastruttura (infrastructure) di un’organizzazione comprende invece tutti gli ambienti gestiti dall’organizzazione, nonché i servizi infrastrutturali per sostenerli – ad es., server DNS, firewall, repository per il controllo delle versioni, …

questa dispensa si concentra soprattutto sulla gestione degli ambienti – ma quanto viene detto può anche essere esteso alla gestione delle infrastrutture


Luca Cabibbo ASW

* Deployment e provisioning

La gestione degli ambienti è rilevante soprattutto nel contesto della delivery (in particolare, del deployment) di un sistema software

il deployment (installazione) di un sistema software – o, più comunemente, di una nuova versione di un sistema software –riguarda l’installazione del software in un opportuno ambiente di esecuzione

avviene (logicamente) dopo la scrittura, la compilazione e l’assemblaggio del software

prima di poter installare ed eseguire il sistema software, è necessario preparare il suo ambiente (provisioning)

il provisioning di un ambiente è la sua acquisizione e configurazione – in cui viene acquisito l’hardware (fisico o virtuale), su ciascun server viene installato e configurato lo stack software richiesto (OS e middleware), viene configurata la rete, ecc.


Luca Cabibbo ASW

Provisioning

In generale, il termine provisioning (approvvigionamento, fornitura) indica il processo di preparazione ed equipaggiamento di un insieme di risorse o di un intero sistema per consentirne l’accesso da parte dei suoi utenti

Questo termine viene spesso usato in modi più specifici

hardware provisioning – acquisizione e configurazione dell’hardware (può comprendere la sua ordinazione dal fornitore)

software provisioning – acquisizione, installazione e configurazione del software – che può essere di terze parti o sviluppato internamente

server provisioning – preparare un server (un nodo) per un uso in rete – installando e configurando l’OS e il middleware – ma non necessariamente le applicazioni o i servizi

environment provisioning – il provisioning di un intero ambiente Gestione di ambienti14

Luca Cabibbo ASW

- Deployment manuale

Il processo di deployment – compresa l’attività di provisioning –viene (purtroppo) svolto spesso in modo manuale

nel deployment manuale, i nodi o server che costituiscono l’ambiente di esecuzione vengono preparati individualmente e “a mano”

la preparazione avviene installando “a mano” su ciascun server l’OS e tutto il software di supporto richiesto, copiando o creando i relativi file di configurazione – tramite console, GUI o console web – e copiando eventuali dati di riferimento

questo può richiedere decine o centinaia di passi da eseguire per ciascun server, magari descritti informalmente in qualche documento (anche questo scritto “a mano”)


Luca Cabibbo ASW

Il deployment manuale è un antipattern

Il deployment manuale del software è un antipattern

il deployment manuale è un’attività di solito lunga, complessa e soggetta ad errori – infatti, ci sono molte cose che possono andare male

se qualche passo viene omesso o eseguito in modo sbagliato, oppure se la versione scelta per un software di supporto è incompatibile con il sistema software o altri software di supporto, oppure se … – allora il sistema software non funzionerà

a questo punto sarà difficile capire dov’è l’errore o quale passo è stato eseguito male


Luca Cabibbo ASW

Il deployment manuale è un antipattern

Alcuni segni (e svantaggi) del deployment manuale del software

richiede la produzione di documentazione dettagliata per descrivere i passi da eseguire – spesso difficile da comprendere anche da chi l’ha scritta

si basa su test manuali (spesso insufficienti) per confermare che l’applicazione è in esecuzione

non scala con molti server

difficile la diagnosi in caso di problemi

il rilascio di una nuova versione richiede più di pochi minuti –anzi può protrarsi per tutta la notte o per l’intero fine settimana

è difficile ripristinare una versione precedente funzionante del sistema – ad es., a seguito di un rilascio errato o della rottura di un server

il rilascio di nuove versioni del software viene vissuto come un incubo – e per questo viene effettuato il meno possibile


Luca Cabibbo ASW

- Deployment automatizzato

Per superare questi problemi, il rilascio del software viene sempre più comunemente svolto in modo automatizzato – anche grazie al supporto fornito da opportuni strumenti software

è possibile automatizzare sia il provisioning e la configurazione degli ambienti di esecuzione che il deployment del software – e, più in generale, l’intero processo di delivery del software

l’automazione è basata su un approccio di tipo infrastructure-as-code – che adotta alcune pratiche dello sviluppo del software, come l’uso di linguaggi specializzati per le configurazioni e il versionamento

l’automazione è possibile sia per server e ambienti fisici che – e ancor di più – per server e ambienti virtuali, nonché sul cloud

in pratica, il deployment del software viene effettuato selezionando la versione del software da utilizzare e l’ambiente di esecuzione richiesto – e premendo un pulsante “deploy”


Luca Cabibbo ASW

Deployment automatizzato

In questo modo, il deployment automatizzato del software non è più un’arte – ma diviene un’attività ingegneristica

il deployment del software diviene un processo ripetibile – se il processo di deployment non è automatizzato allora non è nemmeno ripetibile

la ripetibilità sostiene la consistenza e l’affidabilità – ad es., in caso di problemi, è facile ripristinare una versione precedente funzionante del sistema (rifacendone il deployment)

di solito può essere svolto in pochi minuti

il rilascio di nuove versioni del software non viene più vissuto come un incubo

sono possibili rilasci frequenti – alcuni sistemi rilasciano anche migliaia di nuove versioni del software ogni giorno

il rilascio automatizzato del software dovrebbe essere l’unico modo con cui rilasciare sistemi software complessi e/o critici


Luca Cabibbo ASW

* Gestione automatizzata di ambienti

La gestione di un ambiente (o di un’intera infrastruttura di un’organizzazione) comprende sia la sua creazione (provisioning) iniziale che la sua successiva manutenzione ed evoluzione

la gestione automatizzata degli ambienti può risolvere molti problemi della gestione manuale


Luca Cabibbo ASW

Principi

La gestione automatizzata degli ambienti si basa su tre principi

lo stato desiderato di un ambiente deve essere specificato usando configurazioni eseguibili (infrastructure-as-code) e soggette a versionamento

l’ambiente deve essere autonomico (autonomic) – ovvero deve aggiornarsi automaticamente e da solo al suo stato desiderato

autonomico vuol dire che “agisce da solo”

deve essere sempre possibile conoscere lo stato attuale dell’ambiente – tramite monitoraggio e strumentazione


Luca Cabibbo ASW

Benefici

Alcuni benefici della gestione automatizzata degli ambienti

la combinazione della creazione automatizzata degli ambienti e della loro manutenzione autonomica assicura, ad es., che in caso di problemi sia possibile ricostruire un ambiente di produzione funzionante in una quantità di tempo prevedibile

consente di generare degli ambienti di test la cui struttura corrisponde, in modo fedele, a quella dell’ambiente desiderato di produzione (nuovo o modifica di quello attuale)

per verificare che tutti i servizi o le applicazioni funzionino in quell’ambiente (possibilmente sulla base di test automatizzati) – non solo prima di rilasciare una nuova versione dei servizi o delle applicazioni, ma anche prima di creare o di modificare l’ambiente di produzione

una “configurazione eseguibile” di un ambiente è preferibile a qualunque altra forma di documentazione dell’ambiente

rende più semplice ricostruire un ambiente che non “ripararlo”Gestione di ambienti22

Luca Cabibbo ASW

Aspetti nella gestione di un ambiente

La gestione di un ambiente (e di ciascun suo nodo) richiede di considerare molti aspetti

il sistema operativo e la sua configurazione

lo stack software del middleware – che comprende librerie, application server, database server, message broker, … – e la loro configurazione

software di supporto dell’infrastruttura – come un sistema per il controllo delle versioni, altri repository per gli elaborati, servizi di directory e sistemi di monitoraggio

punti esterni di integrazione – come sistemi e servizi esterni

infrastruttura di rete – come router, switch, firewall, DNS, DHCP


Luca Cabibbo ASW

Modellazione di ambienti

Una caratteristica fondamentale della gestione automatizzata degli ambienti è la modellazione e specifica, completa e dettagliata, di tutte le informazioni di configurazione dell’ambiente e dei suoi elementi

ad es., due installazione di uno stesso OS (o di un servizio di middleware) possono differire in migliaia di modi – le impostazioni e i parametri scelti possono influenzare in modo significativo il modo in cui il sistema software viene eseguito

alcune applicazioni o componenti sono tolleranti a cambiamenti in molti parametri

tuttavia, alcuni servizi possono essere sensibili anche a piccoli cambiamenti in alcuni parametri – sia in termini di corretto funzionamento che di qualità

ad es., le prestazioni di un servizio potrebbero dipendere nella dimensione dei pacchetti o nella configurazione del file system


Luca Cabibbo ASW


In generale, la scelta delle impostazioni di default (per un OS o un middleware) è di solito inappropriata – ad esempio

l’OS richiede la configurazione dei servizi abilitati, degli utenti e del controllo degli accessi

le basi di dati devono essere configurate, così come i loro utenti e i permessi d’accesso

in un message broker devono essere configurati i canali per messaggi e le sottoscrizioni

gli application server devono essere configurati – e devono anche avere le librerie e i componenti applicativi rilasciati


Luca Cabibbo ASW


In pratica, le informazioni di interesse per sostenere la gestione automatizzata di un ambiente comprendono almeno

le definizione dei parametri di installazione dell’OS

per ogni software aggiuntivo, la versione scelta e la sua configurazione

configurazioni per servizi infrastrutturali – come i file di configurazione del firewall o di un application server

ogni script usato per gestire l’ambiente

Tutte queste informazioni non vanno solo specificate con precisione – ma vanno anche gestite in un sistema di controllo delle versioni


Luca Cabibbo ASW

* Gestione di server e ambienti fisici

Il provisioning e la configurazione di server (nodi) e ambienti può essere svolta in diversi modi

in modo completamente manuale

metto un “box” nel data center, lo collego, lo avvio, ci installo e configuro l’OS, installo e configuro lo stack software necessario, installo e configuro i servizi e le applicazioni di interesse

installazione remota automatizzata di ambienti fisici

installazione automatizzata di ambienti virtuali e sul cloud

Non consideriamo ulteriormente il provisioning manuale

questa sezione discute il provisioning automatizzato di server e ambienti fisici – il caso virtuale è discusso nella sezione successiva

in pratica, questi due casi presentano molti aspetti in comune –ma anche alcuni aspetti distintivi


Luca Cabibbo ASW

- Installazione remota di macchine fisiche

L’installazione remota automatizzata è il modo migliore per mettere in uso una nuova macchina fisica – da usare poi come server fisico o come host da virtualizzare

un modo comune per iniziare è con un boot remoto

ad es., PXE (Preboot eXecution Environment) è uno standard per il boot remoto di computer (di solito il client è disponibile nel BIOS) – un’alternativa è Windows Deployment Services (anch’esso basato su PXE)

il boot ha inizio da una immagine di installazione di un OS, che viene scaricata, caricata in memoria e avviata

l’immagine viene selezionata da un repository di immagini (gestito da un server PXE in rete)

le immagini nel repository possono essere “predefinite” (da terzi) oppure essere state create in precedenza in modo personalizzato


Luca Cabibbo ASW

Installazione e configurazione dell’OS

Dopo questo avvio iniziale di un nodo, va in genere completata l’installazione e configurato l’OS

un modo comune è usare un processo di installazione “unattended” (“senza sorveglianza”)

ad es., Kickstart (RedHat), Preseed (Debian) e UnattendedWindows Setup (Windows)

si tratta di un modo per installare o aggiornare un OS con un intervento minimo dell’operatore – di solito sulla base di uno o più file di configurazione predefiniti, che descrivono le attività da eseguire automaticamente durante l’installazione dell’OS

ad es., cambiare le impostazioni (selezionare la lingua, configurare la rete, definire gli utenti ed i loro diritti d’accesso, ecc.), selezionare quali pacchetti installare e quali servizi/demoni avviare, installare service pack e aggiornamenti dell’OS


Luca Cabibbo ASW

Ulteriore configurazione del server

Il passo ancora successivo riguarda l’installazione e la configurazione del middleware e dello stack software necessario sul nodo

questa attività può essere svolta in modo automatizzato mediante l’uso di opportuni strumenti software per la gestione delle configurazioni (configuration management software) – ad es., Puppet, Chef o Ansible

questi strumenti operano in modo simile tra loro

l’amministratore specifica lo stato desiderato dell’ambiente/ infrastruttura e dei suoi nodi

lo strumento garantisce che l’ambiente/infrastruttura e i suoi nodi siano nello stato specificato


Luca Cabibbo ASW

- Gestione delle configurazioni

In un sistema per la gestione delle configurazioni

lo stato desiderato dell’ambiente o dell’infrastruttura è specificato mediante un proprio linguaggio di configurazione –per configurare ambienti, nodi (server) e altre risorse (ad es., uno specifico package o middleware o servizio)

Una possibile architettura per questi sistemi è quella master-agent

il nodo master gestisce un repository centralizzato delle configurazioni dei nodi e degli ambienti

su ciascun nodo dell’ambiente gira un agente che

preleva dal master la configurazione desiderata del nodo e delle sue risorse

applica la configurazione, eseguendo tutte le attività necessarie – come installare software e fare cambiamenti nelle configurazioni locali – per portare il nodo nel suo stato desiderato


Luca Cabibbo ASW

Gestione delle configurazioni

Esempio di architettura master-agent per la gestione delle configurazioni


PuppetServer

Host1configconfig

Puppet Master ServerHost 1

PuppetAgent

Host 2

PuppetAgent

Host 3

PuppetAgent

Host2configconfig

Host3configconfigconfig

Luca Cabibbo ASW


I sistemi per la gestione delle configurazioni sostengono l’autonomicità (ovvero, la capacità di autoripararsi) di un server, di un ambiente o dell’infrastruttura

i sistemi per la gestione delle configurazioni garantiscono che le configurazioni vengano applicate in modo idempotente

se l’agente in esecuzione in un nodo applica più volte una stessa configurazione a quel nodo, allora il nodo arriva comunque nello stato desiderato finale

inoltre, se nel repository viene modificata una configurazione, allora il sistema provvede ad aggiornare tutti i nodi che adottano quella configurazione, aggiustando opportunamente il loro stato (e riavviandoli se necessario)


Luca Cabibbo ASW

Linguaggi di configurazione

Le configurazioni (di ambienti, nodi e risorse) sono specificate mediante degli opportuni linguaggi di configurazione

un linguaggio di configurazione è di solito un Domain-SpecificLanguage (DSL) specifico per informazioni di configurazione

in pratica, ciascuna configurazione è costituita da uno o più file di testo (infrastructure-as-code) – la sintassi è in genere basata su linguaggi come YAML, JSON o Ruby

la configurazione di un ambiente può comprendere

la descrizione dei suoi nodi

per ciascun nodo, la specifica dei package (software) da installare su quel nodo (ciascuno con i propri parametri di configurazione) e la definizione delle variabili d’ambiente

altri file e template (ad es., file di configurazione pre-definiti, ovvero predisposti in precedenza), nonché eventuali script da eseguire sui diversi nodi


Luca Cabibbo ASW

Linguaggi di configurazione

Le configurazioni (di ambienti, nodi e risorse) sono specificate mediante degli opportuni linguaggi di configurazione

i linguaggi di configurazione sono di solito dichiarativi (e non imperativi) – ovvero, specificano la configurazione desiderata indipendentemente dal modo in cui verrà ottenuta

ad es., l’installazione di un package viene specificata in modo indipendente dai possibili package manager (come Yum, Aptitude e RPM)

è compito dell’agente interpretare una configurazione e svolgere le attività necessarie per applicarla in termini dello specifico OS del nodo


Luca Cabibbo ASW

- Gestione e configurazione del middleware

Ogni servizio di middleware (come un server web o un messagebroker) è di solito composto da tre parti – (i) file binari, (ii) configurazioni e (iii) dati

queste parti hanno un ciclo di vita differente, che spesso va gestito separatamente

Ad esempio

le basi di dati devono essere configurate, così come i loro utenti e permessi d’accesso

in un message broker devono essere configurati i canali per messaggi e le sottoscrizioni

gli application server devono essere configurati – e bisogna installarvi anche le librerie e i componenti applicativi di interesse


Luca Cabibbo ASW

Gestione e configurazione del middleware

Nei casi più semplici, un servizio di middleware può essere gestito con uno degli strumenti di gestione delle configurazioni discussi in precedenza (ad es., Puppet, Chef o Ansible)

per installare i package giusti e aggiornare le loro configurazioni mediante dei template pre-definiti (ovvero, definiti prima di iniziare il provisioning)

ci sono però anche casi meno semplici da automatizzare – la loro gestione potrebbe richiedere la predisposizione di un proprio package per il servizio di middleware di interesse

ad es., se non è disponibile nel formato del package manager in uso nell’OS di destinazione

se il middleware non è stato pensato per un’installazione silenziosa


Luca Cabibbo ASW

Configurazione del middleware

I diversi middleware offrono modalità di configurazione differenti –l’automatizzazione delle loro configurazioni è più o meno semplice

molti middleware prevedono un certo numero di file di configurazione (spesso in XML)

la configurazione di default può essere sovrascritta mediante dei template pre-definiti

molti middleware sono configurabili mediante CLI (comandi da una console testuale), operazioni REST o API

la configurazione può essere aggiornata mediante script

purtroppo, alcuni middleware (spesso proprio quelli industriali) sono configurabili solo mediante una console grafica – magari anche perché mantengono i propri dati di configurazione in una base di dati o in forma binaria anziché testuale

questo può richiedere soluzioni ad-hoc – oppure può portare a preferire servizi di middleware diversi


Luca Cabibbo ASW

- Gestione di servizi infrastrutturali

Anche i servizi infrastrutturali – come reti, router, DNS e servizi di directory – vanno configurati (e monitorati) opportunamente

le configurazioni di rete possono essere complesse – ad es., più reti isolate per diversi tipi di traffico (ad es., public e admin)

i problemi relativi a queste configurazioni sono di solito difficili da diagnosticare – ad es., se un’applicazione funziona nell’ambiente di test ma non in quello di produzione

alcuni suggerimenti

fare il versionamento di tutte le configurazioni dei servizi di rete o infrastrutturali

usare un buon sistema di monitoraggio della rete

usare il logging per sostenere la diagnosi

usare nell’ambiente di test una topologia della rete quanto più possibile simile a quella dell’ambiente di produzione


Luca Cabibbo ASW

- Deployment di applicazioni e servizi

Il deployment (installazione e configurazione) di applicazioni, componenti e servizi applicativi può essere di solito effettuato in modo automatizzato con tecniche analoghe a quelle di installazione e configurazione del middleware

i servizi applicativi devono essere stati compilati ed assemblati in unità di rilascio – ad es., file jar oppure war – che comprendono sia i file binari che file di configurazione

questa unità possono di solito essere installate mediante CLI, operazioni REST o API – oppure copiandole in opportune cartelle

di solito è possibile anche il deployment mediante console GUI o web – ma spesso questo non si può automatizzare


Luca Cabibbo ASW

* Gestione di server e ambienti virtuali

Il provisioning automatizzato di server (nodi) e ambienti virtuali (oppure sul cloud) presenta molti aspetti in comune con il caso fisico – ma anche alcuni aspetti distintivi


Luca Cabibbo ASW

Provisioning iniziale

Nel caso virtuale, il provisioning ha inizio dalla creazione delle VM di interesse

per ciascuna VM va specificato il tipo di hardware virtuale (ad es., numero di vCPU, memoria e storage) nonché il cablaggio di rete virtuale (ad es., schede di rete e modalità di collegamento in rete)

la VM viene in genere avviata da un’immagine di VM pre-definita – selezionata da un repository di immagini, pubblico oppure privato (ovvero, gestito dall’organizzazione)

in questo caso, dunque, le VM non vengono di solito avviate da un’immagine di installazione di un OS (come nel caso di PXE) – anche se talvolta è possibile (ad es., per iniziare la creazione di una nuova immagine di VM)

questa attività può richiedere pochi secondi


Luca Cabibbo ASW

Un repository di immagini di VM

Le immagini di VM (o template o baseline o box) vengono in genere gestite in un repository di immagini (pubblico o privato)

ciascuna immagine contiene sicuramente un OS pre-installato e pre-configurato – ma può contenere anche altro software aggiuntivo – come middleware, servizi e/o applicazioni

queste immagini possono essere state pre-personalizzate

la creazione di immagini pre-definite è sostenuta dalla facilità con cui è possibile creare immagini di VM (virtual appliance)

ci si riferisce alla creazione di un’immagine anche con il termine baking (cottura) – che può essere di diversi “gradi”

un’immagine può essere molto generale (light baking) – ad es., un’installazione di default di Ubuntu – o anche più specifica – ad es., Ubuntu con Tomcat – oppure ottimizzata per un caso particolare (heavy baking) – ad es., anche con una specifica applicazione web


Luca Cabibbo ASW


L’installazione di solito prosegue con l’uso di un sistema per la gestione delle configurazioni – come Puppet, Ansible o Chef – per installare e configurare su ciascun nodo tutto il software desiderato

questo può richiedere, a seconda dei casi, da pochi secondi a diversi minuti

Il risultato di una post-installazione di questo tipo può essere poi salvato come nuova immagine di VM e aggiunto al proprio repository di immagini

questo consente di ridurre ulteriormente il tempo di configurazione di nuove VM


Luca Cabibbo ASW

Gestione di ambienti virtuali

Esistono anche strumenti per la configurazione e la gestione automatizzata di ambienti virtuali o sul cloud – come VMware vRealize, Terraform, Vagrant e AWS CloudFormation

sono basati su un approccio di tipo infrastructure-as-code

la configurazione di un ambiente comprende

la descrizione dei nodi dell’ambiente – compresa la configurazione dell’hardware virtuale e dell’immagine di VM su cui basare la rimanente configurazione

la descrizione delle configurazioni software di ciascun nodo – basata anche sull’uso di strumenti per la gestione delle configurazioni software

la descrizione e la configurazione dell’infrastruttura – ad es., delle reti virtuali e dello storage

consentono di creare facilmente (ad es., in modo parametrico) ambienti di esecuzione strutturalmente simili o identici tra loro


Luca Cabibbo ASW

Gestione di ambienti virtuali multipli

Se ci sono sufficienti risorse di calcolo (ad es., sul cloud) ciascun nuovo ambiente può essere creato separatamente dagli altri

ad es., si supponga di voler aggiornare un sistema software in esecuzione in un ambiente di produzione A

per minimizzare il tempo di fuori servizio, anziché aggiornare il sistema nell’ambiente A, è possibile creare un nuovo ambiente B e installarvi il sistema aggiornato, per poi sostituire A con B al termine di questo deployment – e infine deallocare il vecchio ambiente A

anche gli ambienti di test possono essere facilmente tenuti separati da quello di produzione

i test più lunghi possono essere partizionati e svolti in parallelo in ambienti separati – riducendo il tempo di test, in genere senza aumentare i costi


Luca Cabibbo ASW

* Monitoraggio di ambienti e applicazioni

In generale è importante monitorare i propri ambienti, le proprie applicazioni e l’intera infrastruttura

per conoscere lo stato di salute dei sistemi informatici della propria organizzazione – ma ancor di più quello dei processi di business dell’organizzazione

affinché, quando qualcosa va male, gli amministratori del sistema possano essere informato dell’incidente ed avere le informazioni necessarie a trovare le radici dell’incidente e risolverlo

inoltre, perché i dati storici sono essenziali ai fini della pianificazione – ad es., in termini di carico e capacità


Luca Cabibbo ASW

Monitoraggio di ambienti e applicazioni

Gli aspetti principali del monitoraggio

la strumentazione dell’infrastruttura e delle applicazioni

per raccogliere dati (tecnici) dall’hardware, dall’OS e dal middleware, nonché dati (di business) dalle applicazioni

la memorizzazione dei dati – per una successiva analisi

la creazione di dashboard – per aggregare i dati raccolti e presentarli in un formato adatto al business e all’amministrazione del sistema

notifiche automatiche di eventi – in modo tale che le persone possano conoscere ciò che gli interessa – o per consentire una loro gestione automatizzata


Luca Cabibbo ASW

* Discussione

La gestione automatizzata di ambienti offre numerosi vantaggi –sia nel caso di server e ambienti fisici – che, ancora di più, nel caso di server e ambienti virtuali o su cloud

nel caso fisico, il provisioning automatizzato è supportato dagli strumenti di installazione remota e per la gestione delle configurazioni software – con un approccio di tipo infrastructure-as-code


Luca Cabibbo ASW

Discussione

La virtualizzazione amplifica i benefici delle tecniche di provisioning, di configurazione e di gestione automatizzata di server e ambienti

la virtualizzazione consente un processo di provisioning e rilascio controllato, completamente automatizzato e ripetibile –con una riduzione dei tempi, dei costi e dei rischi

il provisioning è favorito dalla possibilità di creare e gestire in modo semplice una libreria di immagini di VM personalizzate

l’acquisizione di un ambiente virtuale o su cloud richiede minuti e un costo iniziale nullo – anziché giorni o settimane, e un costo iniziale alto, come nel caso fisico

è possibile e semplice gestire ambienti multipli e separati simili o identici – ad es., di produzione e di ambienti multipli di test

abilita il rilascio o l’aggiornamento di un sistema software nel suo ambiente di esecuzione con un singolo click


Luca Cabibbo ASW

Discussione

Il modello “pets vs cattle” (“animali da compagnia vs bestiame”) è rappresentativo della dicotomia tra gestione manuale (“pets”) e gestione (completamente) automatizzata (“cattle”) degli ambienti di esecuzione

nel modello “pets”, l’amministratore dà ai nodi dei nomi carini (ad es., “zeus” e “minerva”), e su di essi installa e aggiorna il software manualmente (con ssh – ad es., per installare una nuova versione di Tomcat)

in caso di problemi, l’amministratore fa di tutto per “riparare” manualmente questi nodi

nel modello “cattle”, l’amministratore dà ai nodi dei nomi seguiti da numeri di identificazione (ad es., “web-01” e “web-02”), e su di essi il software viene installato ed aggiornato automaticamente (non si collega mai ai nodi con ssh)

in caso di problemi, l’amministratore distrugge e ricostruisce i nodi anziché provare a “ripararli” manualmente


Luca Cabibbo Architettura dei Sistemi...

Documents

Transcript of Luca Cabibbo Architettura dei Sistemi...