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