Contratto Quadro SPC Cloud Lotto 1 CaaS - Enterprise Container as a Service Specifiche di Realizzazione
Gestione | Azienda | Riferimento |
REDATTO: | Telecom Italia S.p.A. | |
REDATTO: | DXC Technology | |
APPROVATO: | Telecom Italia S.p.A. (Mandataria), DXC | |
N° allegati: | 0 |
Firmato digitalmente da: XXXXXXXX XXXXXXXXXX
Firmato il 06/12/2017 22:39
Seriale Certificato: 443651
Valido dal 05/12/2016 al 05/12/2019 TI Trust Technologies CA
INDICE
1. REGISTRAZIONE MODIFICHE DOCUMENTO 3
3. REALIZZAZIONE DEL SERVIZIO 5
2.3. System e service management 12
2.3.1. Help Desk e Self-ticketing 13
2.4. Sicurezza della soluzione 13
2.5. Garanzia operativa istanze ECaaS/CCaaS 13
2.5.1. Profilo Business Enterprise 14
2.5.2. Profilo Business Standard 14
2.6. Gestione monitoring e incident management dei servizi ospitati 14
2.6.1. Profilo Business Enterprise 14
2.6.2. Profilo Business Standard 14
2.7. Livelli di erogazione del supporto 14
2.8. Servizi erogati su richiesta 15
2.8.1. Creazione Immagini Docker 15
2.8.2. Progettazione creazione modelli di orchestrazione 16
1. REGISTRAZIONE MODIFICHE DOCUMENTO
N° Rev. | Descrizione | Data emissione |
0 | Prima emissione | 06/07/2017 |
1 | Seconda emissione | 19/09/2017 |
2. GENERALITA’
1.1. Applicabilità
Questo documento è applicabile nell’ambito del Contratto Quadro SPC Cloud Lotto1.
1.2. Assunzioni
Nell’ambito del Contratto Quadro SPC Cloud Lotto 1 viene proposta l’introduzione di un servizio in grado di fornire una piattaforma ECaaS/CCaaS, basata su tecnologia Container Docker. Questo servizio comprende opzioni aggiuntive descritte ampiamente nei paragrafi successivi del documento. Il servizio viene erogato dai centri di servizio del RTI.
1.3. Riferimenti
Identificativo | Titolo/Descrizione |
Gara Cloud Lotto 1 | Gara Cloud Lotto 1_Allegato5B Capitolato Tecnico |
Gara Cloud Lotto 1 | Gara Cloud Lotto 1_Allegato5A Capitolato Tecnico Parte Generale |
Gara Cloud Lotto 1 | Offerta Tecnica del Fornitore Allegato B Relazione Tecnica Lotto 1 |
1.4. Definizioni e acronimi
Definizioni/Acronimi | Descrizione |
IaaS | Infrastructure as a Service |
ECaaS | Enterprise Container as a Service |
CaaS | Container as a Service |
CCaaS | Community CaaS |
RTI | Raggruppamento temporaneo d’Impresa |
3. REALIZZAZIONE DEL SERVIZIO
Il servizio è erogato usando una piattaforma, istanziata per ogni specifico cliente e basata su un’architettura descritta nei seguenti paragrafi.
2.1. Architettura generale
L’architettura ECaaS/CCaaS è funzionalmente suddivisa in tre livelli (planes) che supportano il classico modello Supply/Delivery/Demand delle piattaforme Cloud.
Figure 1 - Architettura logica ECaaS/CCaaS
• Il Back plane fornisce le risorse infrastrutturali (IaaS) necessarie ad ogni istanza ECaaS/CCaaS e di fatto coincide con la piattaforma Cloud SPC, basata su OpenStack.
• Il Core plane implementa le funzionalità fondamentali che erogano i servizi basati su tecnologia Containers (Containers Orchestration), la loro gestione (Delivery Management) e la connessione con funzioni per lo sviluppo di servizi applicativi basati su incapsulamento a Containers (CI/CD pipeline instances).
• Il Front plane permette agli utenti finali di accedere e fruire i servizi offerti dalla piattaforma, tramite una console (dashboard) sia in modalità diretta (utente) che programmatica (a mezzo di funzioni API).
I vari moduli architetturali sono costituiti da diversi prodotti/soluzioni software (pressoché basati su progetti open source) integrati tra loro opportunamente usando chiamate API.
Tutti questi moduli sono incapsulati in Containers per cui la stessa piattaforma ECaaS/CCaaS è di fatto realizzata usando la stessa tecnologia offerta per i servizi erogati.
2.1.1. Il back plane
Come già anticipato la piattaforma OpenStack SPC-Cloud fornisce l’accesso alle risorse IaaS necessarie all’ECaaS/CCaaS. In particolare ogni istanza ECaaS fa uso di due tenant OpenStack.
Figura 2 - Utilizzo dei tenant e VDC nell'ECaaS
Figura 3 - Utilizzo dei tenant e VDC nel CCaaS
Il primo ❶ per ospitare le risorse virtuali contestualizzate in un VDC, utili a istanziare la piattaforma di gestione ❷ e fornire i nodi iniziali del cluster ❸; questi nodi corrispondono a VM le cui dimensioni (numero di virtual CPU e RAM) sono ottimizzate per un impiego in un cluster Docker. Un secondo tenant ❹, sempre basato su VDC, ospita gli eventuali nodi computazionali aggiuntivi necessari, sempre usati dal cluster Docker ❺; le VM hanno la stessa configurazione del primo tenant ma sono destinate ad un uso flessibile (consumo orario) per poter sfruttare in modo efficace le necessità di “flessione” computazionale dei servizi secondo un modello di capacity on demand. I nodi aggiuntivi (del cluster Docker), rispetto a quelli iniziali, sono associati sempre al secondo tenant.
Le risorse XxxX previste per un’istanza CCaaS o ECaaS:
• Macchine virtuali di base:
o ECaaS:
▪ 10 VM per la parte di management
▪ 4 VM per il cluster Docker
o CCaaS:
▪ 7 VM per la parte di management
▪ 2 VM per il cluster Docker
• Macchine virtuali aggiuntive per cluster Docker a consumo: numero variabile in funzione della necessità attivabile e disattivabili su base oraria
Macchine virtuali aggiuntive per cluster Docker, rispetto all 4 iniziali a canone.
• Lo storage di base fornito è pari a 500GB reso disponibile ai nodi del cluster Docker in modalità “shared”. Ulteriore capacità può essere fornita tramite elementi aggiuntivi già presenti nel catalogo SPC-Cloud relativi alle risorse VDC.
La versione ECaaS usa più nodi computazionali rispetto a quella CCaaS a cause dell’uso del prodotto Docker Enterprise Edition.
2.1.2. Il core plane
La piattaforma di gestione comprende un insieme di strumenti e servizi, in parte accessibili anche dall’utente finale (l’amministrazione) per poter ospitare servizi applicativi, in ambienti di test o produzione, in funzione delle necessità.
2.1.2.1. Container Orchestration
È il motore della piattaforma. Si basa su Docker (progetto open source omonimo) e include lo scheduler del cluster Docker - il componente che ospita i servizi applicativi dell’utente finale. È basato su Docker Swarm (in una futura versione sarà possibile usare Kubernetes in alternativa a Swarm). Ad oggi un’istanza ECaaS/CCaaS può avere un solo cluster scheduler configurato.
La versione CCaaS mette a disposizione una console web di amministrazione del cluster Docker e un Docker registry Community Edition mentre la versione ECaaS è basata su Docker Enterprise Edition (DDE), versione commerciale fornita da Docker (azienda omonima del progetto software). DDE include i seguenti componenti:
• Docker Trusted Registry (DTR): è il repository dove sono riposte le immagini Docker. Il DTR garantisce l’integrità delle immagini, grazie alla firma digitale applicata a queste ultime, fornisce la possibilità di effettuare lo scanning al fine di garantire che non vi sia all’interno malware o rootkits
• Universal Control Plane (UCP): è la soluzione enterprise di gestione e monitoraggio del cluster Swarm di Docker. Attraverso l’UCP è possibile controllare lo stato delle risorse Docker, quali ad esempio le immagini, i container, i servizi, le reti, i nodi, ecc. e variare alcuni parametri di esecuzione, come ad esempio il fattore di scaling dei servizi.
2.1.2.2. Infrastructural Services
Si tratta di servizi di base necessari per garantire il funzionamento della piattaforma ECaaS/CCaaS. In questo contesto sono inclusi i seguenti componenti:
• Shared storage: è il servizio che fornisce lo storage condiviso al cluster Docker. Al momento è basato sulla soluzione open source Gluster FS. È un file system di rete client-server, distribuito e scalabile, in grado di gestire diversi petabyte di dati e migliaia di client. All’interno dell’architettura ECaaS/CCaaS è utilizzato per definire spazi storage condivisi tra tutti i nodi del cluster, in maniera
da poter garantire l’alta affidabilità dei servizi in caso di migrazione da un nodo all’altro. La gestione di questo componente è a carico del gestore della piattaforma. In futuro sarà possibile l’integrazione di ulteriori soluzioni di mercato di storage condiviso.
• Service Discovery: permette la riconfigurazione automatica a caldo dei reverse proxy per accedere alle applicazioni di business. Si aggancia al flusso degli eventi del cluster Swarm, e quando un container destinato ad interfacciarsi con l’esterno viene attivato, il servizio di discovery intercetta l’evento, ispeziona il container a run-time e riconfigura il servizio di reverse proxy col nuovo indirizzo del container appena creato. L’utente non deve quindi preoccuparsi di esportare i servizi o di attivare particolari regole di NAT/routing sugli apparati: tutto viene eseguito in maniera completamente automatica.
• Reverse Proxy: sono disponibili tre tipi di reverse proxy applicativi a seconda delle esigenze di business: HAProxy, Nginx e Apache. Il primo permette di eseguire un reverse proxy anche di protocolli non HTTP (ad esempio un sistema RDBMS) mentre gli altri due sono di natura prettamente orientata alle applicazioni web. I reverse proxy hanno solitamente almeno due interfacce: una verso l’esterno ed una verso le reti interne overlay di Docker. In questa maniera l’unico punto di accesso sicuro verso l’esterno è il reverse proxy, mentre tutti i container di business rimangono schermati all’interno di reti overlay (si parla di Software Defined Networking). Il reverse proxy, opportunamente configurato con certificati SSL, funge anche da terminatore HTTPS per tutte le applicazioni di business che necessitano di tale protocollo di sicurezza. Oltre al reverse proxy di business, è presente anche un reverse proxy per i servizi infrastrutturali di base (es. DTR).
• Internet Proxy: utilizzato per connettere i container con Internet. Rappresenta un ulteriore livello di sicurezza in quanto permette di evitare l’esposizione diretta delle applicazioni di business che necessitano di connessioni Internet HTTP/HTTPS (come ad esempio i processi di build delle immagini Docker). È implementato con il software Squid configurato opportunamente per connettersi ad Internet su un nodo dedicato oppure attraverso un’ulteriore proxy esterno ad ECaaS/CCaaS.
• DNS: tiene traccia di tutti gli hostname dell’infrastruttura e degli alias per accedere ai servizi in load balancing (round xxxxx). Opportunamente configurato si integra con il servizio di Service Discovery per il mapping dinamico dei nomi dei container che esportano servizi verso l’esterno.
• SMTP: server SMTP interno per l’invio delle email da parte delle piattaforme applicative che ne hanno bisogno. È configurato come email relay verso un server SMTP esterno all’ECaaS.
• LDAP: realizzato con OpenLDAP, è il sistema di autenticazione ed autorizzazione per tutta la piattaforma ECaaS. È inoltre disponibile per le piattaforme applicative che necessitano di una centralizzazione delle utenze. Qualora si desideri utilizzare un sistema di autenticazione esterno (es. Microsoft Active Directory), il server LDAP interno verrà configurato come LDAP proxy verso il sistema esterno.
2.1.2.3. Continuous Delivery
È l’insieme di funzionalità dedicata alla gestione operativa dei servizi rilasciati in esercizio e comprende:
• Logging Collection and Correlation: è il sistema di logging real time basato sui software open source ELK (ElasticSearch, Logstash, Kibana). È perfettamente integrato nell’architettura ECaaS semplificandone l’utilizzo da parte dei servizi applicativi: basta un semplice parametro nella definizione del servizio Docker per agganciare l’applicazione al sistema ELK, senza nessun altro tipo di intervento infrastrutturale o di configurazione applicativa.
• Monitoring: è il sistema di monitoring e alerting basato sui software open source Grafana e Prometheus. Oltre a raccogliere ed elaborare le informazioni sullo stato delle componenti infrastrutturali, come ad esempio la situazione delle risorse degli engine appartenenti al cluster Docker, il sistema controlla in automatico, senza alcun tipo di configurazione richiesta, tutti i container che vengono attivati sul cluster. Grazie ad una comoda visualizzazione grafica, al superamento di soglie prestabilite dell’utilizzo di risorse il sistema invia automaticamente degli alert attraverso il sistema di collaboration & communication ChatOps (presente nel front plane).
• Auditing: è la funzionalità che permette di ispezionare e rendere noto lo stato di rispondenza dei servizi applicativi rispetto alle politiche di delivery che l’utente finale può predefinre.
• Software forge: è il componente che fornisce le funzionalità prevalentemente dedicate alla creazione del software applicativo, in particolare: una piattaforma di source code control, di documentazione integrata, di automazione delle fasi di testing, di gestione delle issues e features (relative allo sviluppo software). È basato sul software open source Gitlab.
2.1.2.4. Continuous integration
È l’insieme di funzionalità che permette l’automatizzazione dei cicli di sviluppo, build, test e rilascio dei componenti dei servizi applicativi. È basato su questi software:
• Xxxxxxx: strumento di automazione che si integra con il Software Forge per l’esecuzione delle pipeline. L’esito dell’esecuzione delle pipeline viene segnalato in modalità multicanale, sia attraverso sistemi tradizionali di email che attraverso lo strumento di collaborazione e comunicazione ChatOps Mattermost.
• Workflow automation: in questo caso viene usato uno strumento sviluppato in modalità open source appositamente concepito per le necessità della piattaforma ECaaS/CCaaS.
• Altri strumenti a supporto (es. ebot, egit, ecc.): oltre agli strumenti principali appena elencati, sull’ECaaS sono stati implementati, sempre attraverso container, dei moduli che implementano funzionalità minori e di utilità utilizzati dal sistema stesso nel contesto del Continuous Integration.
I seguenti diagrammi mostrano rispettivamente i componenti dell’architettura del CCaaS e ECaaS.
-
Figura 1 - Componenti CCaaS
Figura 2 - Componenti ECaaS
Sono evidenziati con un colore specifico, nel diagramma ECaaS, i nodi computazionali dove sono usati i Docker engine con supporto commerciale.
2.1.3. Front plane
Fornisce l’accesso alla piattaforma e alle sua funzionalità in questo contesto sono integrati i seguenti componenti:
o Collaboration & Communication: implementa un piattaforma di comunicazione e collaborazione in modalità continuativa ChatOps. È realizzato usando il software open source Mattermost ed è utilizzato per qualsiasi tipo di segnalazione di rilievo, come lo stato delle build, ma anche per gli alert infrastrutturali o applicativi provenienti dal sistema di monitoraggio. Grazie all’utilizzo di canali specifici è in grado di ottimizzare la comunicazione nel contesto di team che operano seguendo la pratica DevOps. Inoltre tramite Mattermost è possibile anche integrare l’esecuzione dei passi di workflow di orchestrazione che possono prevedere, ad esempio, delle fasi di approvazione, come l’autorizzazione a rilasci in produzione.
o Service Catalog: implementato attraverso il software Open Service Catalog Manager (OSCM) permette ai fornitori di pubblicare i propri servizi, all’amministrazione di gestirli ed agli utenti di usufruirne. Il software consente una profilazione granulare delle utenze e fornisce una reportistica sul consumo delle risorse a catalogo ai fini della rendicontazione. La soluzione proposta include anche la possibilità di gestire ruoli di brokering dei servizi. Questa funzionalità è ad esclusivo uso del cliente finale (amministrazione) per facilitare l’attivazione/uso di servizi realizzati a mezzo della piattaforma ECaaS/CCaaS, di conseguenza anche la gestione dei contenuti del service catalog è a carico del cliente finale (amministrazione).
o Identity Services: è incluso nella piattaforma ECaaS/CCaaS un servizio LDAP interno che consente di mantenere una gestione consistente e coordinata degli accessi ai vari
componenti, inoltre è possibile federare tale servizio con sorgenti LDAP esterne del cliente finale. Può essere fornito, opzionalmente, un servizio di two-factor authentication.
Il dettaglio e l’architettura di alto livello dei componenti appena descritti è mostrato nelle precedenti figure per la versione ECaaS (che prevede l’uso di una combinazione di software open source e proprietari).
La versione CCaaS, si basa solamente su componenti open source – si nota l’assenza dei componenti DTR (Docker Trusted Registry) e UCP (Universal Control Plane) che essendo software di tipo proprietario sono stati sostituiti con soluzioni funzionalmente equivalenti (sebbene con meno funzionalità operative) quali Portainer (al posto dello UCP) e Docker Registry (al posto del DTR). Questa riduzione di funzionalità non ha impatti in termini di capacità di esecuzione di servizi applicativi rispetto ala versione ECaaS.
Tutti gli strumenti elencati precedentemente, oltre ad essere disponibili per i servizi applicativi, sono usati internamente da ECaaS/CCaaS. Di fatto tutta la piattaforma ECaaS/CCaaS è sviluppata e manutenuta utilizzando metodologie agile CI/CD e DevOps fortemente automatizzate, aumentando la qualità del ciclo di sviluppo e riducendo i tempi per l’installazione e gli aggiornamenti della piattaforma stessa.
La figura seguente illustra un tipico ciclo di sviluppo CI/CD gestibile con ECaaS/CCaaS.
Figure 4 - Ciclo CI/CD attivabile con ECaaS/CCaaS
Ogni volta che uno sviluppatore effettua un push del proprio codice sul repository GIT, viene attivata automaticamente una pipeline CI/CD che effettua la compilazione del codice, la build delle immagini necessarie, il test sul cluster Container (Swarm) e notifica lo sviluppatore tramite messaggistica istantanea Mattermost l’esito del lavoro, con un link diretto all’output della pipeline. Il tutto viene effettuato in maniera completamente automatica e senza alcun intervento manuale esterno.
L’amministrazione può così tenere sotto controllo l’evoluzione ed il bug-fixing del codice quasi in tempo reale, riducendo le attività di collaudi formali in quanto la maggior parte delle funzionalità vengono testate durante il ciclo di sviluppo non appena rilasciate. Questo approccio evita i big-bang di rilascio, parallelizza le attività di sviluppo e testing, aumenta la qualità del prodotto finale e riduce l’incidenza di errori in fase di rilascio.
Per applicazioni non critiche la pipeline può essere estesa anche al rilascio completamente automatico direttamente nell’ambiente di produzione a seguito ad un esito positivo dei test (anch’essi automatici).
È interessante notare che il registry di Docker mantiene comunque uno storico del contenuto delle immagini dei container: è quindi sempre possibile tornare indietro alla situazione precedente ad un rilascio automatico non andato a buon fine.
2.2. Console di gestione
Ogni istanza ECaaS/CCaaS fornisce una console di gestione che consente, all’utente finale, di gestire in modalità “self-service” le funzionalità fornite dalla piattaforma.
La console è realizzata utilizzando il modello responsive UI (web based) il quale ne consente l’uso su diversi dispositivi come PC, Tablet e smartphones. Il pannello principale consente di accedere velocemente ai vari elementi di controllo delle funzioni erogate dalla piattaforma. Queste sono raggruppate in 4 principali aree:
• Dashboard: vista d’insieme dello stato della piattaforma
• Administration: gestione operativa e accesso i componenti
• Metrics: accesso alle informazioni di misurazione su consumi, indici prestazionali e SLA
• CI/CD: software forge, CI automation, Collaboration and communication
• Service Catalog: accesso al catalogo dei servizi
La figura seguente mostra la dashboard principale dove sono visibili le informazioni rilevanti sullo stato corrente dell’utilizzo della piattaforma.
Figure 5 - ECaaS/CaaS dashboard
2.3. System e service management
Le funzionalità di system e service management sono di fatto espletate dal servizio di Continuous Delivery, già descritto al che incorpora le funzioni di monitoring, logging e auditing. Inoltre è prevista la possibilità di
integrare un sistema di “trouble ticketing” – a mezzo di “ticket exchange” – con il componente di collaboration and communication (ChatOps).
Il supporto della piattaforma ECaaS/CCaaS da un punto di vista operativo è veicolato tramite la piattaforma di governance di SPC-Cloud ed il service desk previsto dal contratto.
2.3.1. Help Desk e Self-ticketing
L’Utente dell’Amministrazione accederà alle funzioni di Help Desk e Self Ticketing, utilizzando i canali di comunicazione già in essere nell’attuale convenzione.
Le richieste di supporto per il servizio ECaaS/CCaaS saranno registrate e gestite sul portale di Ticketing come Richieste di Change. La registrazione potrà essere fatta o attraverso la funzionalità di Self Ticketing o tramite Numero Verde dello SPOC.
Nel caso di registrazione della Change tramite Numero Verde dello SPOC, la richiesta sarà comunque visibile e gestibile nella sezione di Self Ticketing dell’Amministrazione.
Il sistema di Gestione Ticketing traccerà tutti gli stati e tempi di lavorazione di una qualsiasi Change
fornendo i dati a:
• Sistemi di produzione della reportistica per il calcolo degli SLA/KPI contrattualizzati;
• Cruscotto sintetico per il monitoraggio dell’andamento degli indicatori contrattuali.
2.4. Sicurezza della soluzione
Poiché la soluzione ECaaS/CCaaS è realizzato sfruttando le risorse infrastrutturali della piattaforma SPC- Cloud OpenStack di fatto ne eredita le caratteristiche intrinseche di sicurezza e affidabilità. Inoltre un’istanza ECaaS/CCaaS e dedicata ad un singolo cliente garantendo quindi un elevato livello di separazione logica dei servizi da essa erogati.
La versione ECaaS incorporando anche il DTR (Docker Trusted Registry) fornisce un ulteriore livello di garanzia in quanto sono presenti ulteriori funzionalità rilevanti dal punto di vista della sicurezza quali:
• Immagini Docker firmate utilizzando certificati digitali: garanzia di integrità assoluta delle immagini stesse
• Controllo stretto delle politiche di deployment: è possibile specificare intervalli temporali entro cui le immagini dei Container possono essere usate, al di fuori di tali intervalli il sistema non consente l’uso di tali immagini.
• Funzionalità RBAC (Role Based Access Control): l’accesso al Registry (archivio delle immagini) e allo UCP (Universal Control Plane) può essere sottoposto a specifiche politiche legate all’utenza.
• Scanning delle immagini dei Container: è una funzionalità attivabile sul DTR opzionalmente.
Le immagini presenti nel registry (DTR) di istanze ECaaS possono essere usate anche nel registry di istanze CCaaS sebbene in questo caso non siano disponibili le funzionalità citate sopra.
2.5. Garanzia operativa istanze ECaaS/CCaaS
La garanzia operativa dell’istanza garantisce la piena funzionalità dei componenti che costituiscono la piattaforma (descritti nelle specifiche di realizzazione – sezione relativa all’architettura). È disponibile in due profili distinti e alternativi descritti di seguito.
2.5.1. Profilo Business Enterprise
Questo profilo prevede un supporto erogato con copertura su 24 ore per 7 giorni settimanali. Eventuali incidenti derivanti da problematiche relative all’istanza saranno soggetto di risoluzione con un tempo minimo di 2 ore in base alla criticità della problematica, tempo condizionato anche dal supporto di secondo e terzo livello fornito dal produttore software (Docker) sui componenti relativi al prodotto Docker Enterprise Edition. Questo profilo è applicabile solo alla versione ECaaS.
2.5.2. Profilo Business Standard
Questo profilo prevede un supporto erogato con copertura Lunedi-Venerdì (dalle 8:30 alle 17:30) e Sabato (dalle 8:30 alle 14:00). Eventuali incidenti derivanti da problematiche relative all’istanza saranno soggetto di risoluzione con un tempo minimo di 4 ore in base alla criticità della problematica. Questo profilo è applicabile sia alla versione ECaaS che CCaaS.
2.6. Gestione monitoring e incident management dei servizi ospitati
Questo servizio opzionale permette al cliente finale (amministrazione) di richiedere il monitoring e l’incident management di un servizio applicativo rilasciato in produzione sull’istanza della piattaforma, versione ECaaS o CCaaS e secondo i consueti due profili: Business Enterprise e Business Standard.
2.6.1. Profilo Business Enterprise
La gestione del monitoring, di uno o più servizi applicativi, fornirà una verifica costante dello stato di funzionamento di tali servizi con copertura 24 ore su 7 giorni settimanali. In caso di problematiche di funzionamento il servizio provvederà ad una possibile risoluzione ma qualora ciò non fosse possibile verrà attivato un processo di incident management con escalation sul secondo livello di gestione a carico del cliente, attraverso email o eventualmente ticket exchange. L’integrazione con il sistema di trouble ticketing del cliente richiede un progetto specifico attuabile a mezzo di uno specifico progetto di Cloud Enabling da prevedere a parte in un piano di fabbisogni.
2.6.2. Profilo Business Standard
In questo caso viene fornito lo stesso servizio descritto al 2.6.1 ma con una copertura Lunedi-Venerdì (dalle 8:30 alle 17:30) e Sabato (dalle 8:30 alle 14:00). Anche in questo caso valgono le stesse considerazioni sull’eventuale possibile integrazione con il sistema di trouble ticketing del cliente descritte al 2.6.1.
2.7. Livelli di erogazione del supporto
La seguente tabella riporta la classificazione dei livelli di impatto usati per definire in tempi di risposta alle richieste di supporto:
Priorità del problema | Descrizione |
Priorità 1 | Qualsiasi incidente che causa il blocco dei servizi erogati con la piattaforma e l’operatività della piattaforma stessa. |
Priorità 2 | Un qualsiasi incidente che causa un impatto rilevante ai servizi in ambiente di produzione o un impatto severo a servizi non critici. In questo caso i servizi sono funzionanti ma operano in uno stato prestazionale degradato e non è chiara la soluzione utile a superare l’impatto. |
Priorità 3 | Qualsiasi incidente che produce un impatto moderato sul fronte operativo. In questo caso i servizi sono in uno stato prestazionale di leggera degradazione ma ci possono essere problematiche relative a necessità di rilasci pianificati. |
2.8. Servizi erogati su richiesta
2.8.1. Creazione Immagini Docker e flusso di orchestrazione
La trasformazione in architettura container di un’applicazione non distribuita nativamente sotto forma di immagine Docker, non si limita alla mera creazione di un certo numero di immagini, ma necessita nel caso più generale di una serie di attività di analisi, progettazione ed implementazione illustrate di seguito:
• verifica delle funzionalità della piattaforma applicativa esistente:
o acquisizione e lettura della documentazione disponibile
o analisi dell’architettura, dei software e delle tecnologie utilizzate
o identificazione delle componenti infrastrutturali utilizzate
o identificazione delle componenti applicative che compongono la piattaforma
o analisi delle dipendenze e dei flussi dati tra le componenti applicative interne alla piattaforma in esame
o analisi delle dipendenze e dei flussi dati tra la piattaforma ed il mondo esterno
• definizione dell’architettura in ottica ECaaS
o analisi e definizione della strategia di trasformazione
o scomposizione in micro servizi ove possibile senza modifiche al codice
o disegno dell’architettura a container
• creazione delle immagini Docker
o creazione delle immagini base ed eventuale personalizzazione in accordo ad eventuali policy esistenti
o creazione delle immagini dei servizi applicativi
o test unitari delle immagini
• definizione dei servizi e della piattaforma applicativa
o definizione e creazione delle reti Docker in accordo all’architettura definita
o definizione dei volumi
o definizione delle interfacce con l’esterno
o configurazione delle policy di deploy
o composizione applicativa dei container
o test di integrazione
• collaudo e rilascio
o collaudo dell’applicazione trasformata
o rilascio in produzione
L’impegno necessario all’esecuzione delle attività appena descritte varia in funzione della complessità della piattaforma da migrare e dalla dimensione della stessa in accordo alla tabella riportata nella sezione 5.1.1.2 del documento “Contratto Quadro SPC Cloud Lotto 1 ECaaS Specifiche del Servizio”.
2.8.2. Progettazione creazione modelli di orchestrazione
Questo servizio opzionale fornisce la possibilità di richiedere la realizzazione di template di orchestrazione basati sul tipo di cluster usato (Swarm o Kubernetes) per la composizione dinamica di servizi basati su componenti applicativi a Containers. Le attività relative a questo servizio prevedono la progettazione, sviluppo e test di orchestrazioni destinate alla menzionata composizione dinamica.
Tipicamente ciò equivale a produrre e testare una service composition o stack composition con Docker Swarm o analoga soluzione con Kubernetes.
In base alla complessità del servizio, determinata da diversi fattori riportati nella tabella 5.1.1.2 del documento “Contratto Quadro SPC Cloud Lotto 1 ECaaS Specifiche del Servizio”, viene determinato l’impegno per l’esecuzione delle attività relative a questo elemento di servizio.