Il 19 settembre 2022, nell’Aula Magna del DIAG della Sapienza di Roma, si è tenuto il convegno finale del progetto PON “Smart Cities and Communities” SMARTOUR, con una quindicina di partner — nove PMI, quattro università e tre istituti del CNR. Il finanziamento arriva dal PON “Ricerca e Competitività” 2007–2013, avviso “Smart Cities and Communities” — area Cultural Heritage; l’obiettivo dichiarato era una piattaforma per la fruizione turistica e culturale, con sperimentazioni sul territorio in più sedi. Ora che il progetto si chiude, restano alcune note tecniche su cosa significhi consegnare infrastruttura cloud-native come deliverable di ricerca e non come prodotto tenuto in produzione.

Contesto

Un progetto di ricerca finanziato consegna due cose: documenti — un deliverable per Obiettivo Realizzativo — e codice. Il vincolo amministrativo è la verificabilità: ogni componente dichiarato deve esistere, essere descritto e, nel caso migliore, riproducibile da un revisore esterno mesi dopo la fine dei lavori. Questo stride con la pratica corrente dell’infrastruttura, dove gran parte dello stato vive in cluster effimeri, registry privati e segreti che nessuno versiona.

La durata del progetto copre una fetta importante della maturazione dell’ecosistema Kubernetes. SMARTOUR è stato impostato quando orchestrare container era ancora una scelta architetturale discutibile, e si chiude quando l’orchestrazione è il default implicito di qualunque sistema multi-componente. Nel mezzo, l’API del progetto di riferimento ha spostato più volte il confine tra stabile, deprecato e rimosso. Da qui parte il primo problema concreto.

Lo standard che si sposta

La versione corrente alla chiusura è Kubernetes 1.25, uscita il 23 agosto 2022. Rimuove per sempre PodSecurityPolicy, deprecata dalla 1.21, e la rimpiazza con il Pod Security Admission controller, diventato stabile nella stessa release. Per un sistema scritto contro API di due o tre anni prima questo non è un dettaglio: i manifest che descrivevano il profilo di sicurezza dei pod su un cluster aggiornato non si applicano più. La stessa 1.25 elimina i plugin di volume in-tree Flocker, Quobyte e StorageOS, completando il passaggio al Container Storage Interface.

Il problema non è la singola deprecazione. È che un deliverable di infrastruttura ha una data di scadenza implicita molto più corta di quella di un documento. Un PDF di architettura scritto nel 2020 nel 2022 si legge ancora; un set di manifest scritto contro un’API che nel frattempo ha tolto tre risorse no. Per un progetto la cui rendicontazione si estende oltre la fine dei lavori, nasce così un debito di standard: il sistema consegnato è corretto rispetto alla versione contro cui l’hanno scritto, e via via scorretto rispetto a quella che un revisore installerebbe oggi.

La risposta pragmatica è inchiodare le versioni. Quella del control plane, quelle delle CLI, i digest delle immagini base — niente tag mobili. Un deliverable di infrastruttura si riproduce solo se dichiara la versione esatta di tutto ciò che dà per scontato, control plane compreso. Un manifest che chiede image: nginx:latest non è un artefatto di ricerca riproducibile; lo è quello che chiede un digest sha256.

Architettura dei portali

I portali web del progetto seguono un’impostazione headless: il livello di contenuto e dati è separato da quello di presentazione tramite API, e il front-end nasce come insieme di asset statici più chiamate a runtime, invece di essere reso da un’applicazione monolitica server-side. La scelta ha una ragione concreta: i partner che producono dati territoriali — sicurezza urbana, infomobilità, monitoraggio conservativo, fruizione culturale — non condividono un unico back-end, e un livello di presentazione che consuma API è l’unico modo per comporre fonti eterogenee senza legare i loro rilasci.

Questa architettura costa in numero di superfici da versionare. Un monolite ha un solo artefatto di deploy; un sistema headless multi-portale ha il back-end di contenuto, lo strato API, i build statici di ogni portale e i contratti fra di loro. Ognuno è un punto in cui la riproducibilità si rompe se non lo inchiodi. La separazione che rende il sistema componibile è la stessa che moltiplica le cose da documentare per renderlo consegnabile.

Multi-tenancy come requisito amministrativo

Le sperimentazioni territoriali — fra le altre, sicurezza urbana, fruizione culturale in realtà aumentata, monitoraggio conservativo, infomobilità — sono di fatto tenant separati su un’infrastruttura condivisa. Non per scelta di design: è la conseguenza di un progetto con sedi e responsabili distinti che pescano da un unico budget infrastrutturale. Su Kubernetes il confine naturale è il namespace, con quote di risorse e policy di rete per l’isolamento. Tolta PodSecurityPolicy, alla chiusura del progetto la via prevista per imporre profili di sicurezza per tenant è etichettare i namespace secondo i Pod Security Standards — restricted, baseline, privileged — applicati dal nuovo admission controller.

L’isolamento per namespace costa poco ma non è un confine di sicurezza forte: condivide kernel e nodi, e un tenant che riesce a evadere dal proprio container si ritrova sullo stesso host degli altri. Per un sistema di ricerca con dati territoriali non sensibili è un compromesso difendibile; nel deliverable va però dichiarato chiaro, perché chi desumesse un isolamento forte dalla parola “multi-tenant” leggerebbe nel sistema una garanzia che non c’è.

Limiti

Tutto questo riguarda la consegnabilità, non l’esercizio continuativo, che è un’altra storia: un deliverable verificabile a una certa data e un servizio mantenuto nel tempo hanno requisiti diversi e in parte opposti. Il primo premia il pinning esatto e la fotografia immutabile; il secondo chiede aggiornamenti continui che, per definizione, allontanano il sistema in esercizio dall’artefatto consegnato. Un progetto di ricerca che finisce consegna il primo; chi raccoglie il codice dopo eredita il secondo, e con esso il debito di standard accumulato fra la versione contro cui il sistema fu scritto e quella corrente.

Non ho metriche di esercizio post-progetto da riportare, perché la fase finanziata si chiude qui. Le note valgono per quello che sono: osservazioni sul punto di consegna, dove un sistema cloud-native smette di essere un ambiente vivo e diventa un artefatto che qualcun altro dovrà rimettere in piedi leggendo i manifest.

Il resoconto di chiusura dal lato di noze, con i deliverable consegnati, è nell’insight dedicato al progetto: https://www.noze.it/insights/smartour-conclusione/.

https://www.iac.cnr.it/convegno-finale-del-progetto-pon-smart-cities-and-communities-smartour https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/ https://kubernetes.io/blog/2022/08/25/pod-security-admission-stable/ https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/ https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md

Immagine di copertina: Interno di un data center con file di rack di server illuminati in una sala macchine — foto di BalticServers.com, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:BalticServers_data_center.jpg