Agenda

Topic

1
Overview Architetturale

2
Esigenze architetturali per singolo componente

3
Piano di rilasci integrato con le esigenze architetturali

4 Processo di rilascio

5
Team dedicato ai rilasci

© 2023 DXC Technology Company. All rights reserved. 7/12/23 1

Low Sensitivity — DXC Internal Use Only
Architettura Transitoria – Pre Prod Componenti oggetto di analisi

Di seguito vengono rappresentate le componenti tecnologiche previste per il periodo transitorio, che vedrà la coesistenza ON-PREMISES di
nuovi e vecchi componenti.

Nuova
Open Data BI Portale Servizi Layer
installazione
Trasversale
Presentation Layer
IAM
Aggiunta di 2
API Gateway API Manager Nodi RH-SSO
Cooperazione
Interoperability Layer
CI/CD
Message
Service Layer & Microservices
Layer
Legacy Layer
Nuova Container Platform No action
RedHat AMQ installazione App. già in Nuove
esercizio Applicazioni

Process Layer BPMN

No action Business Layer Soluzioni
Custom
Search Engine Monitoring &
Data Lake Data Layer Logging
BDNCP
Object
Documentale
Storage
DB Persistenza
Aggiunta di 1 o 2 MinIO 7/12/23
su 1 VM
© 2023 DXC Technology Company. All rights reserved. 2
Cluster
Low Sensitivity — DXC Internal Use Only
Architettura Transitoria – Prod Componenti oggetto di analisi

Di seguito vengono rappresentate le componenti tecnologiche previste per il periodo transitorio, che vedrà la coesistenza ON-PREMISES di
nuovi e vecchi componenti.

Nuova
Open Data BI Portale Servizi Layer
installazione
Trasversale
Presentation Layer
IAM
Aggiunta di 2
API Gateway API Manager Nodi RH-SSO
Cooperazione
Interoperability Layer
CI/CD
Message
Service Layer & Microservices
Layer
Legacy Layer Ampliamento a 7
Nuova Container Platform
Nodi Licenziati
RedHat AMQ installazione App. già in Nuove
esercizio Applicazioni

Process Layer BPMN

No action Business Layer Soluzioni
Custom
Search Engine Monitoring &
Data Lake Data Layer Logging
BDNCP
Object
Documentale
Storage
DB Persistenza
Aggiunta di 2 MinIO 7/12/23
su 4 VM
© 2023 DXC Technology Company. All rights reserved. 3
Cluster
Low Sensitivity — DXC Internal Use Only
Architettura To-Be

Open Data BI MongoDB Charts Portale Servizi Layer

Trasversale
Presentation Layer IAM

API Manager RH-SSO

API Gateway
Cooperazione
Interoperability Layer CI/CD

Message
Service Layer & Microservices
Layer

Legacy Layer Container Platform

APP. già in esercizio Nuove Applicazioni

Process Layer BPMN Business Layer

Monitoring &
Logging
Data Lake Documentale Data Layer
BDNCP
Tracing
Search Metrics
DB Persistenza Engine
Cloud Event Monitoring © 2023 DXC Technology Company. All rights reserved. 7/12/23 4
Low Sensitivity — DXC Internal Use Only
Esigenze MongoDB
RISORSE AS-IS RISORSE AGGIUNTIVE PER IL TRANSITORIO
Prod Pre-Prod Rilascio Prod Pre-Prod
Entro fine Luglio Entro fine Luglio Entro fine Maggio Entro fine Settembre

BI

Numero NODI : 3 Numero NODI : 3 Numero NODI : 3 Numero NODI : 3

Numero NODI : 3 Numero NODI : 3 + 1 Numero NODI : 1
Risorse per nodo: Risorse per nodo: Risorse per nodo: Risorse per nodo:
Risorse per nodo: Risorse per nodo: Risorse per nodo:
● RAM: 64 (Start) ● RAM: 64 (Start) ● RAM: 32 (start) ● RAM: 64 (start)
● RAM: 32 GB ● RAM: 8 GB ● RAM: x GB ● vCPU: 4 (start) ● vCPU: 4 (start) ● vCPU: 2 (start) ● vCPU: 4 (start)
● vCPU: 4 ● vCPU: 4 ● vCPU: x ● Storage: 300/500 GB ● Storage: 300 GB ● Storage: 150 GB ● Storage: 150 GB
● Storage: 250 GB ● Storage: 200 GB ● Storage: xxx GB ● Versione 6.x ● Versione 6.x ● Versione 6.x ● Versione 6.x
● Versione 4.4 ● Versione 4.4 ● Versione 6.0.6-ent

• Tutti i valori di RAM e vCPU sono da intendersi come il minimo indispensabile in fase di
• ANAC evidenzia che è in possesso di 3 licenze «libere», 2 inizialmente destinate a una avvio. A regime tali valori dovranno essere incrementati a un valore da definire in relazione
soluzione di DR e 1 ad una soluzione di BI alle necessità che si presenteranno in seguito ai rilasci.
• Per traguardare i rilasci in Pre-produzione verrà installato un nuovo cluster di 3 nodi entro
• É in corso l’aggiornamento alla versione 6 dei cluster MongoDB che con l’attuale la fine di Maggio per il collaudo funzionale e un nuovo cluster da 3 nodi entro la fine di
versione 4.4 non consentono l’utilizzo di Strong Authentication Kerberos, Encryption in Settembre per il collaudo delle performance.
Transit and Encryption At Rest necessarie per NPA e FVOE;
• In aggiunta, è opportuno procedere all’installazione e configurazione di due nuovi replica-
• Anche aggiornando il cluster alla versione 6.x non è al momento certificata la set in Produzione che si distinguono per diversi livelli di performance richiesti dalle nuove
compatibilità delle applicazioni legacy con la configurazione necessaria ad NPA e FVOE; applicazioni (es. FVOE ed NPA);
• In ottica di traguardare i primi rilasci in Produzione delle nuove applicazioni verranno
installati i due nuovi cluster da 3 nodi entro fine Luglio;
Esigenze OpenShift
RISORSE AS-IS RISORSE AGGIUNTIVE PER IL TRANSITORIO

Prod Prod
STORAGE
Componente vCPU RAM NODI
(MB) • Al momento non sono necessarie risorse
OpenShift INFRA 4 24 150 3 aggiuntive in ambiente di Produzione;
• In seguito ai prossimi rilasci verrà valutato
OpenShift MASTER 8 32 150 3
l’impatto sull’utilizzo di OpenShift per un
OpenShift OCS 16 64 150 3 eventuale upgrade del numero di nodi/risorse per i
nodi WORKER;
OpenShift Worker 12 48 150 5

Pre-Prod Pre-Prod
STORAGE
Componente vCPU RAM
(MB)
NODI • Al momento non sono necessarie risorse
OpenShift INFRA 4 24 150 3
aggiuntive in ambiente di Pre-Produzione;
• In seguito ai prossimi rilasci verrà valutato
OpenShift MASTER 8 32 150 3
l’impatto sull’utilizzo di OpenShift per un
OpenShift OCS 16 64 150 3 eventuale upgrade del numero di nodi/risorse per i
nodi WORKER;
OpenShift Worker 12 48 150 5

La versione di OpenShift Container Platform attualmente presente è la 4.10

(fonte assessment RedHat)
Esigenze WSO2
AS-IS RISORSE AGGIUNTIVE PER IL TRANSITORIO
Prod Prod
STORAGE • La migrazione alla versione 4.2 dell’attuale WSO2 v.2.6 per le componenti di API
Componente vCPU RAM (MB) NODI
Manager e Developer Portal potrà essere eseguita sui nodi attualmente dedicati,
che rispettano i requisiti di sistema raccomandati dal Vendor incaricato della
Enterprise Integrator 4 16 50 2 migrazione;
• La migrazione potrà comportare un disservizio di massimo due ore;
API Manager 4 8 50 2 • Per effettuare il rilascio in Prod. della componente di API Manager interno è
necessaria la predisposizione di due nodi aggiuntivi:
Identity Server 4 8 50 2
Componente vCPU RAM STORAGE (MB) NODI
Developer Portal 4 8 50 2 API Manager (interno) 4 8 50 2

Pre-Prod
Pre-Prod • La migrazione alla versione 4.2 dell’attuale WSO2 v.2.6 per la componente di API
STORAGE Manager potrà essere eseguita sui nodi attualmente dedicati, che rispettano i
Componente vCPU RAM (MB) NODI requisiti di sistema raccomandati dal Vendor incaricato della migrazione;
• La migrazione non comporterà disservizio in ambiente di Pre-Prod.
Enterprise Integrator 2 8 50 2 • Per effettuare il rilascio in Pre-Prod. della componente di API Manager interno è
necessaria la predisposizione di due nodi aggiuntivi:
API Manager (all-in-one) 4 8 50 2
Componente vCPU RAM STORAGE (MB) NODI
API Manager (interno) 4 8 50 2
Identity Server 4 8 50 2

NOTA BENE
Versioni attuali:
• Le componenti Identity Server ed Enterprise Integrator non sono necessarie nella
• Enterprise Integrator v.6.4
nuova configurazione, dunque a valle della migrazione possono essere liberate le
• API Manager v.2.6
risorse ad esse dedicate;
• APIM Gateway v.2.6
• Per ricevere il supporto alla migrazione e nei successivi 12 mesi in relazione ad
• Identity Server v.5.7.0
aggiornamenti o incidenti su Produzione e Pre-prod è necessario effettuare una
sottoscrizione annuale con il Vendor per i 6 nodi target in produzione;
Esigenze ELK
AS-IS RISORSE AGGIUNTIVE PER IL TRANSITORIO

Prod Prod

STORAGE • Utilizzo degli attuali 3 nodi community per i rilasci in

Componente vCPU RAM NODI
(MB) produzione previsti a Giugno;
ELK 8 16 200 3 • Ampliamento a 7 nodi licenziati per i successivi rilasci in
produzione di Ottobre (es. NPA);
• Tali nodi aggiuntivi sono necessari perché è indispensabile
una maggiore capacità di elaborazione a fronte del maggior
numero di dati collezionati. Verrà valutata la possibilità di
aggiungere gradualmente i nodi aggiuntivi previsti;

Pre-Prod Pre-Prod

STORAGE • Non è previsto l’ampliamento dell’attuale cluster composto

Componente vCPU RAM (MB) NODI
da un singolo nodo ELK;
ELK 8 16 350 1
Esigenze Object Storage
• I dati caldi verranno mantenuti su ELK, mentre per i dati freddi è previsto l’utilizzo di:
‒ MongoDB per la storicizzazione del metadato;
‒ Un Object Storage per la storicizzazione dei dati binari;
RISORSE AGGIUNTIVE
• La soluzione individuata per l'Object Storage è MinIO che per essere installato necessita della
predisposizione di 4 macchine virtuali per ambiente di Produzione e 1 macchina virtuale per
l’ambiente di Pre-produzione;
• Ciascuna macchina virtuale dovrà avere le seguenti caratteristiche: 2 CPU, 4 Giga di RAM, 50 GB di
storage, OS Linux. Il disco dovrà essere di tipo LVM per essere adattato secondo le esigenze;
• Non è necessario procedere all’acquisto di licenze in quanto la soluzione individuata è di tipo open-
source;
• L’installazione di MinIO dovrà essere completata entro i primi di Giugno in pre-produzione ed entro
metà Giugno in produzione;
Esigenze Camunda
• Il componente Camunda verrà installato in modalità
containerizzata;
• Ogni applicativo avrà il suo server Camunda per
evitare blocchi totali nei processi in caso di
problemi al BPMN;
• Negli applicativi che lo richiedono verrà integrato il
Rule Engine Zeebe che è interno nella suite
Camunda e permette di creare le regole per
instradare l’iter del ciclo di vita dell’appalto;

RISORSE AGGIUNTIVE
È opportuno che ANAC proceda all’acquisto delle
subscription di Camunda entro Settembre per poterlo
utilizzare nei rilasci in ambiente di produzione previsti
nell’Obiettivo 2 e per ricevere supporto post-
installazione.
Il modello di licensing del prodotto non è legato al
numero di distribuzioni effettuate sulle singole
applicazioni a micro-servizi ma è customizzato in base
alle esigenze dell’acquirente  Contattare azienda
reseller.
Esigenze Form.IO
Il componente Form.IO verrà containerizzato su OpenShift.
Gli sviluppi eseguiti non prevedono l’utilizzo di funzionalità che necessitano della versione Enterprise.
É opportuno prevedere le seguenti configurazioni aggiuntive per procedere alla sua prima
installazione:

1. Creazione del DB per Form.io;

2. Creazione del name-space su Open-Shift;
3. Abilitazione di "anac-gitlab-readonly-pull-secret" su namespace creato;
4. Creazione gitlab progetto + app-helm;
5. Creazione progetto quay.io per formio;
6. Configurazione app-helm;
7. Configurazione GitLab;
 Ambiente di rilascio Ambiente di qualificazione
*• Necessario provisioning
Piano dei rilasci integrato Dipendenza

2023
Ambiente di pre-produzione Ambiente di produzione

Attività Maggio Giugno Luglio Agosto Settembre Ottobre

Nuovo Cluster MongoDB (PRE-PROD) *

Nuovi Cluster MongoDB (PROD) *

Migrazione WSO2 (PRE-PROD) *

ATTIVITA’ SULLE COMPONENTI

Migrazione WSO2 (PROD) *

Nuovi nodi ELK (PROD) *

Installazione Object Storage (PRE-PROD)

Installazione Object Storage (PROD)

Installazione Camunda (PRE-PROD)

Installazione Camunda (PROD) *

Installazione Form.IO (PRE-PROD)

Installazione Form.IO (PROD)

Portale Servizi
RILASCI APPLICATIVI

IAM (CIE, CNS, EIDAS) *

USER PROVISIONING

Qualificazione SA *

NPA

FVOE

(*) Rilasci che non dipendono da attività sulle componenti descritte nel presente documento
Calendario attività
X  Date confermate
X  Date da confermare

29-May 30-May 31-May 1-Jun 2-Jun 3-Jun 4-Jun 5-Jun 6-Jun 7-Jun 8-Jun 9-Jun 10-Jun 11-Jun 12-Jun 13-Jun 14-Jun 15-Jun 16-Jun 17-Jun 18-Jun
Attività
M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P M P

1° Nuovo Cluster MongoDB (PRE-PROD)

X X                                                                                

Installazione APIM interno WSO2 (PRE-PROD)

    X X  X X                                                                    

Installazione Object Storage (PRE-PROD)

                      X X                                        

Installazione Form.IO (PRE-PROD)

                                    X X                                    

Assessment ELK
                                                        X X                    

Installazione APIM interno WSO2 (PROD)

                                                            X X X X            

Installazione Form.IO (PROD)

                                                                    X X        

Installazione Object Storage (PROD)

                                                                    X X        
                                                                                   
                                                                                   
 Processo di rilascio
Avvio Rilascio Pre-esercizio
progetto Qualificazione
Esercizio
Operation

ARGO
ARGO
Deploy 
Deploy 
ambiente Ambiente
"RILASCIO" OK OK
successivo successivo
…
ANAC

KO
Referente

Evasione
Approvazione Approvazione
ticket ALM

Impostazione
Gitlab

Tag versione OK
Apertura Avvio pipeline (CI)
Merge request Merge request
ticket ALM Generazione
dell’immagine su
RTI

QUAY.IO ANAC
OK

Sviluppo
KO KO
componente Test Test
SW

KO
Processo di rilascio – Dettaglio steps
# Descrizione Steps
1 Impostazione Gitlab: questa fase comprende una serie di attività preliminari legate al progetto nel suo complesso e non al singolo rilascio:
• predisposizione dell’alberatura su Gitlab, sia lato ANAC che lato RTI, tenendo presente che dovranno essere uguali tra loro;
• definizione degli utenti che utilizzeranno il tool e dei permessi che devono essere loro associati;
• impostazione di Quay.IO;
Tutte queste attività vedono la compartecipazione sia del fornitore che delle figure ANAC, e si inseriscono in quella che è la definizione dello scenario all’interno del quale poi avvengono i vari
rilasci; si tratta dunque di attività propedeutiche al rilascio stesso.
2 Definiti tutti gli aspetti preliminari relativi al progetto, l’RTI comincia lo sviluppo dei pacchetti software che saranno poi oggetto del rilascio e prosegue con le attività di tale processo solo nel
momento in cui è terminato lo sviluppo di una componente autoconsistente, che è pronta quindi per il rilascio.
3 L’RTI apre un ticket su ALM indirizzato al referente ANAC di progetto contenente il dettaglio delle attività propedeutiche al rilascio che ANAC dovrà necessariamente svolgere, unitamente al
manuale di installazione e gestione (uno per applicativo); sarà compito del referente ANAC coinvolgere le strutture più idonee allo svolgimento di tali attività. Ogni rilascio applicativo potrebbe
richiedere attività su uno o più componenti dell’architettura; si citano solo a titolo di esempio i seguenti:
• creazione DB;
• abilitazione utenza;
• installazione certificati;
• configurazione dei tool;
4 Dal momento in cui ANAC comunica il completamento delle attività richieste, l’RTI può effettuare il tag della versione della componente oggetto del rilascio e contestualmente avviare la pipeline;
tale processo determina la generazione dell’immagine su Quay.IO (ANAC).
5 In base alla modalità di rilascio definita avviene il deploy nell’ambiente di rilascio: qualora sia stata selezionata la modalità “autosync” il deploy sarà automatico (successivo alla generazione
dell’immagine su Quay.IO), in caso contrario sarà l’operatore ANAC ad avviare manualmente tale operazione.
6 Una volta concluso il rilascio l’RTI esegue i test necessari, i quali ovviamente possono avere sia un esito positivo che un esito negativo:
• Esito dei test negativo (KO): adeguamento e successivo deploy in ambiente di rilascio da parte dell’RTI (2);
• Esito dei test positivo (OK): ANAC può procedere alla validazione della componente sviluppata (7);
7 ANAC valida lo sviluppo ripetendo i test che ritiene più opportuni e comunica l’esito all’RTI. Anche in questo caso l’esito può essere positivo o negativo:
• Esito della validazione negativo (KO): vengono effettuati nuovamente dei test (6) mirati ed eventualmente segue un adeguamento e successivo deploy in ambiente di rilascio da parte
dell’RTI (2);
• Esito della validazione positivo (OK): apertura della Merge Request su Gitlab da parte dell’RTI (l’apertura di tale richiesta viene notificata sul tool e solitamente anche via mail dall’RTI).
8 ANAC dispone l’accettazione su Gitlab della Merge Request e tramite il “sync” su ARGO avvia il deploy nell’ambiente successivo, determinando la promotion, ovvero il rilascio nell’ambiente
successivo; per ogni promotion si ripetono i punti elenco dal 6 in poi (Test, Validazione, Merge Request e Accettazione).
Piano dei rilasci integrato
Ambiente di rilascio Ambiente di qualificazione
*• Necessario provisioning
Dipendenza Ambiente di pre-produzione Ambiente di produzione

2023
Attività Maggio Giugno Luglio Agosto Settembre Ottobre
1° Nuovo Cluster MongoDB (PRE-PROD) *
24-29
1° Nuovo Cluster MongoDB (PROD) *

Migrazione WSO2 (PRE-PROD) * Date indicative

ATTIVITA’ SULLE COMPONENTI

30
Migrazione WSO2 (PROD) *
15-16
Nuovi nodi ELK (PROD) *

Installazione Object Storage (PRE-PROD)

31
Installazione Object Storage (PROD)
10
Installazione Camunda (PRE-PROD)

Installazione Camunda (PROD) *

Installazione Form.IO (PRE-PROD)

07
Installazione Form.IO (PROD)
14
Portale Servizi
RILASCI APPLICATIVI

IAM (CIE, CNS, EIDAS) *

USER PROVISIONING

Qualificazione SA *

NPA

FVOE

(*) Rilasci che non dipendono da attività sulle componenti descritte nel presente documento Attività schedulate