Programma del corso
Da VM a Container: Docker e Pipeline CI/CD per i servizi dell'Ente
16 mezze giornate da 4 ore (64 ore totali) — ~50% teoria guidata, ~50% laboratorio pratico.
Obiettivo
Non migrare "un servizio": costruire il modello con cui l'Ente migrerĂ tutti i servizi.
Al termine del corso il partecipante avrĂ prodotto:
- Un esempio end-to-end funzionante e documentato: l'applicazione Pratiche (gestione pratiche dell'Ente) containerizzata, con pipeline CI/CD completa dal commit al deploy in produzione.
- Le linee guida architetturali standard per containerizzare qualunque servizio dell'Ente.
- La matrice dei ruoli (RACI) tra sviluppatori, sistemisti, referenti ICT e fornitori, replicabile su tutti i servizi.
- Un blueprint di repository riusabile come punto di partenza per ogni nuovo servizio o migrazione.
Il filo conduttore: l'app "Pratiche"
Tutti i laboratori lavorano sulla stessa applicazione, che cresce modulo dopo modulo:
un portale di gestione pratiche (frontend web + API Python/Flask + PostgreSQL + Redis).
- Nel Modulo 1 è una semplice pagina statica servita da un container.
- Nel Modulo 8 è uno stack multi-servizio con la sua prima pipeline.
- Nel Modulo 12 viene rilasciata in "produzione" con approvazione manuale e rollback.
- Nel Modulo 16 il partecipante ripete l'intero percorso da zero, da solo, usando il blueprint.
Ogni modulo ha una cartella lab/start (punto di partenza garantito, anche per chi è rimasto
indietro) e lab/final (soluzione completa e funzionante).
Struttura in tre blocchi
Blocco A — Fondamenta Docker (Moduli 1–6)
Dal "funziona sulla mia VM" al "funziona ovunque".
| # | Modulo | Contenuti chiave | Lab |
|---|---|---|---|
| 1 | Perché i container. Setup dell'ambiente | VM vs container; architettura Docker; installazione e verifica ambiente; run, ps, logs, exec | Installare Docker; primo container; servire la home del portale Pratiche con Nginx |
| 2 | Immagini e Dockerfile | Layer e cache; Dockerfile; build e tag; ciclo build→run→test | Containerizzare l'API Pratiche (Flask) |
| 3 | Dockerfile avanzato e hardening | Multi-stage; utente non-root; .dockerignore; HEALTHCHECK; pinning versioni; dimensioni immagine | Ottimizzare l'immagine API: piĂą piccola, piĂą sicura |
| 4 | Reti e persistenza | Bridge network; DNS interno; volumi vs bind mount; backup dei dati | Collegare API e PostgreSQL; dati che sopravvivono al container |
| 5 | Docker Compose | compose.yaml; servizi, dipendenze, ordine di avvio; comandi essenziali | Stack completo: web (Nginx) + API + DB con un solo comando |
| 6 | Compose per ambienti reali | Healthcheck; variabili e .env; profili; override dev/prod; cache Redis | Stesso stack, due configurazioni: sviluppo e produzione |
Blocco B — La filiera automatizzata (Moduli 7–12)
Dalla macchina del singolo alla pipeline dell'Ente.
| # | Modulo | Contenuti chiave | Lab |
|---|---|---|---|
| 7 | Registry e versionamento immagini | Registry privato; naming convention dell'Ente; semver e tag; retention | Push delle immagini Pratiche sul registry con le convenzioni dell'Ente |
| 8 | Git e Pipeline as Code | Branching model; anatomia di .gitlab-ci.yml; runner; artefatti | Prima pipeline: lint + build automatici a ogni push |
| 9 | Pipeline di build e test | Test automatici (pytest); stage e dipendenze; build & push su tag | Pipeline che testa, builda e pubblica l'immagine versionata |
| 10 | QualitĂ e sicurezza in pipeline | Lint (ruff, hadolint); scansione vulnerabilitĂ (Trivy); SBOM; policy di blocco | Aggiungere i "cancelli di qualitĂ " alla pipeline Pratiche |
| 11 | Deploy automatico in staging | Environments; deploy via SSH + compose pull/up; smoke test post-deploy | La pipeline porta Pratiche in staging da sola |
| 12 | Rilascio in produzione e rollback | Approvazione manuale; release versionate; backup pre-deploy; rollback in un comando | Rilascio controllato in "produzione" e rollback simulato |
Blocco C — Il modello per l'Ente (Moduli 13–16)
Da un caso riuscito a uno standard replicabile.
| # | Modulo | Contenuti chiave | Lab |
|---|---|---|---|
| 13 | OsservabilitĂ ed esercizio | Log strutturati; endpoint di health; metriche Prometheus; dashboard Grafana; runbook | Monitorare Pratiche: dashboard e alert di base |
| 14 | Migrare un servizio legacy da VM | Metodologia: assessment → containerizzazione → convivenza → cutover; casi tipici (cron, file, config) | Migrare il servizio legacy "Albo Avvisi" da VM a container |
| 15 | Architettura standard e matrice dei ruoli | Il blueprint di repository; linee guida architetturali; RACI dev/sistemisti/fornitori; governance e handover | Applicare il blueprint all'Albo Avvisi; compilare la RACI |
| 16 | Progetto finale end-to-end | Percorso completo in autonomia: nuovo servizio dal blueprint fino al deploy | Verifica finale: da git init alla "produzione" con checklist di conformitĂ |
Perché proprio 16 mezze giornate
- Un incremento verificabile per modulo. Ogni mezza giornata chiude con l'app Pratiche in uno stato funzionante e dimostrabile. 4 ore = 1 concetto portante + 1 laboratorio completo: meno tempo costringerebbe a tagliare la pratica, piĂą tempo diluirebbe.
- La mezza giornata è sostenibile per un ICT operativo. I partecipanti mantengono i servizi dell'Ente: mezza giornata di corso lascia mezza giornata di esercizio, e il calendario può distribuirsi su 4–8 settimane senza fermare l'operatività .
- Metà corso è laboratorio. L'obiettivo non è "sapere Docker" ma saper ripetere il percorso su altri servizi: servono ore di pratica reale, con progetti di partenza (
start) che permettono a tutti di riallinearsi a ogni modulo. - I tre blocchi rispecchiano i tre obiettivi. 6 moduli per la competenza tecnica individuale (Docker), 6 per la filiera condivisa (CI/CD), 4 per il modello organizzativo (migrazione, architettura standard, ruoli, verifica finale). Togliere moduli al blocco C significherebbe ottenere tecnici capaci ma nessun modello replicabile — l'esatto contrario dell'obiettivo.
- Il modulo 16 è la prova del modello. L'ultima mezza giornata non introduce nulla di nuovo: il partecipante rifà tutto da solo partendo dal blueprint. Se ci riesce in 4 ore, il modello è davvero replicabile — ed è la stessa prova che si chiederà ai fornitori.
Prerequisiti dei partecipanti
- Uso base della riga di comando Linux (cd, ls, editing di file).
- Nozioni base di Git (clone, commit, push) — richiamate comunque nel Modulo 8.
- Non è richiesta esperienza di sviluppo: il codice dell'app è fornito; si scrive
infrastruttura (Dockerfile, compose, pipeline), non applicativo.
Materiali
- Portale del corso (questo sito): documentazione navigabile, slide, pacchetti scaricabili.
- Pacchetto per modulo (
module-NN.zip): README del laboratorio +lab/start+lab/final. - Slide per il trainer: un deck HTML per modulo + il deck di presentazione del programma.
- Documenti trasversali: setup ambiente, linee guida architetturali, matrice dei ruoli, blueprint.