Blocco C · Il modello per l'Ente — Modulo 14 di 16

Migrare un servizio legacy

da VM a container, con metodo

Obiettivi di oggi

La metodologia in 6 fasi: assessment → cutover → esercizio
Le 5 trasposizioni standard (stato, config, log, cron, supervisione)
Applicarla a un caso realistico: l'Albo Avvisi (path fissi, /etc, log su file, cron)

La metodologia in 6 fasi

Assessment — questionario fisso: processi, porte, stato, config, log, cron, dipendenze, segreti, vincoli
Containerizzazione — a comportamento INVARIATO
Pipeline — blueprint + pipeline standard
Convivenza — container in staging con i dati copiati; confronto con la VM
Cutover — switch del proxy/DNS; VM spenta ma pronta
Esercizio — monitoraggio, backup; VM smantellata dopo 30 giorni

Le 5 trasposizioni standard

Sulla VM	Nel container
dati in path fissi	volume nominato sullo stesso path
config in /etc/*.conf	variabili d'ambiente (fallback ai default)
log su file	stdout → docker logs + rotazione
cron	servizio dedicato nel compose (o scheduler)
systemd Restart	restart: unless-stopped

L'errore classico

"Già che ci siamo, riscriviamo/moderniamo" → due rischi che si mascherano a vicenda
Prima si migra IDENTICO (ogni differenza è un bug della migrazione)
Poi, semmai, si migliora — con la pipeline già a protezione

Laboratorio (2h15)

Assessment compilato sull'Albo Avvisi (codice della "VM" fornito)
Containerizzazione con le 5 trasposizioni; cron → servizio pulizia
Prova di convivenza: dati "della VM" copiati nel volume → identico
Piano di cutover scritto

Riepilogo e prossimo passo

Hai un METODO, non solo un caso riuscito: assessment fisso + 5 trasposizioni + cutover reversibile
Quali servizi dell'Ente somigliano all'Albo? (lista di priorità avviata oggi)
Modulo 15: blueprint e matrice dei ruoli — lo standard nero su bianco

← portale · frecce/click per navigare · F = schermo intero · Ctrl+P = PDF