Blueprint del servizio containerizzato

Il blueprint è il template di repository da cui parte ogni nuovo servizio o

migrazione. È il prodotto finale del corso: l'app Pratiche completata (Modulo 12/13)

ne è l'esemplare di riferimento funzionante; il Modulo 15 lo applica al servizio

legacy Albo Avvisi; il Modulo 16 lo usa come verifica finale.

Come si usa

1. Copiare il template (modules/module-15/lab/final/blueprint/) in un nuovo repository.
2. Cercare e sostituire NOME-SERVIZIO in tutti i file.
3. Compilare la checklist di adozione qui sotto, in ordine.
4. Al termine, il servizio è conforme alle linee guida (doc. 02) e la RACI (doc. 03)

è compilata: il servizio è pronto per il collaudo.

Contenuto del template

NOME-SERVIZIO/
├── README.md                 # da compilare: scopo, avvio locale, release
├── .gitlab-ci.yml            # pipeline standard completa: adattare solo i nomi
├── .env.example              # elencare qui OGNI variabile del servizio
├── compose.yaml              # stack base: definire i servizi reali
├── compose.override.yaml     # sviluppo locale
├── compose.prod.yaml         # staging/produzione
├── docs/
│   ├── runbook.md            # template guidato con sezioni obbligatorie
│   ├── architettura.md       # schema componenti (template con esempio)
│   └── raci.md               # matrice ruoli con tabella nominativi da compilare
└── api/                      # esempio di componente: rinominare/duplicare
    ├── Dockerfile            # multi-stage, non-root, healthcheck: già impostato
    └── .dockerignore

Checklist di adozione (collaudo tecnico)

A. Repository e build

• [ ] Repository creato dal blueprint, NOME-SERVIZIO sostituito ovunque
• [ ] Un Dockerfile per componente, base image dall'elenco approvato, versione pinnata
• [ ] Multi-stage dove esiste una fase di build; utente non-root; .dockerignore
• [ ] docker compose up locale funziona seguendo solo il README

B. Pipeline

• [ ] Stage lint, test, build, scan verdi nel GitLab dell'Ente
• [ ] Immagini pubblicate su registry.ente.it/<area>/<servizio>/<componente>
• [ ] Tag Git vX.Y.Z produce immagini X.Y.Z; ogni build produce sha-<commit>
• [ ] Nessuna vulnerabilità CRITICAL aperta (o piano di rientro approvato da SEC)

C. Configurazione e dati

• [ ] .env.example completo; nessun segreto in repo/immagini (verificato)
• [ ] Stato solo su volumi nominati o servizi esterni; container ricreabile senza perdite
• [ ] Backup definito nel runbook e provato almeno una volta (restore incluso)

D. Esercizio

• [ ] /health risponde; healthcheck attivi in compose
• [ ] Log su stdout, rotazione configurata; (se critico) raccolta centralizzata
• [ ] docs/runbook.md compilato: avvio, stop, deploy, rollback, backup, incidenti
• [ ] Deploy in staging automatico da main verificato; deploy prod manuale provato
• [ ] Rollback provato davvero almeno una volta in staging

E. Ruoli

• [ ] docs/raci.md compilata con i nominativi
• [ ] Se fornitore: requisiti sez. 9 delle linee guida verificati in collaudo

Percorso tipo di una migrazione VM → container