11 - Onboarding Farm

Guida · Aggiornamento del 10 novembre 2026

Farm riusa la pipeline di Access con un backend e un migratore reali. Codice e registrazione sono su main, le immagini sono pubblicate, il DNS privato è applicato e la baseline SQL è verificata. Il primo rollout è riuscito: migrazione prima del backend e separazione SQL verificata con entrambe le identità. Sono riusciti anche i cinque casi S2S e il cleanup. Finestra IAM chiusa, metriche e una traccia ricevute; il migratore rieseguito non ha applicato nuove versioni. Il prossimo servizio può riusare questo profilo e la stessa procedura.

Cosa abbiamo fatto

Parte	Risultato verificato
Codice Farm	Skeleton di Lorenzo e adattamenti stage integrati; commit del publisher fc5d06e
Registrazione	Progetto moonitoring-farm-stage, database farm su sql-stage, identità sa-farm-api / sa-farm-migrate; nessun nuovo progetto o database
Build	Repository Farm autorizzata in Developer Connect; publisher comune riuscito, due immagini fissate per digest
Delivery	Profilo comune service-with-migration, pipeline farm e target farm-stage; kit verificato e primo rollout approvato riuscito; migrazione prima del backend
Rete	DNS privato run.app sulla Shared VPC applicato e riletto; Access invariato. La lettura DNS non è la prova S2S
Baseline SQL	Ruoli farm_owner / farm_runtime, ACL e default verificati; vecchia fixture conservata, catalogo Access invariato
Enrollment SQL	Entrambe le identità verificate prima/dopo migrazione; sei altri database negati a ciascuna, runtime senza DDL né accesso al ledger
Pulizia SQL	Amministratore, secret, service account, Job e binding temporanei rimossi e assenza riletta; anche i Job di verifica SQL sono rimossi
Runtime	farm-backend-mw9ygxlx Ready con 100% traffico; migratore farm-migrate-lbjrc riuscito. Access invariato
Chiusura IAM	Finestra di prima creazione rimossa, grant applicati sui soli farm-backend e farm-migrate esistenti

Il backend usa i dati autorizzati senza DDL. Soltanto il migratore assume farm_owner per applicare le migrazioni mancanti prima del backend. La baseline infrastrutturale prepara i privilegi; le migrazioni applicative creano lo schema del prodotto. Sono due passaggi distinti.

La vecchia fixture stage_check non è stata adottata o cancellata. Ne sono stati confrontati struttura, proprietà, ACL e dipendenze; le righe non sono state lette né certificate. Il controllo Access ha ritrovato le stesse 141 relazioni e lo stesso fingerprint. Dettaglio SQL.

Codice online e sviluppo successivo

Il servizio online di questo collaudo usa fc5d06e e due migrazioni. Il main Farm successivo di Lorenzo, 7f386d8, contiene otto migrazioni: non è diventato online perché abbiamo aggiornato documentazione e test. I test sul database più avanti del codice verificano il guard SeaORM già presente; una nuova versione applicativa continuerà a richiedere la normale release approvata.

Nuove dipendenze del backend

Il codice successivo al primo rollout richiede FARM_ACCESS_ISSUER, FARM_RAW_BUCKET, FARM_DATASETS_BUCKET e FARM_SECRETS_PROJECT. Mancavano nel manifest stage: il precedente successo di Compose o del primo rollout non dimostrava che questa nuova versione potesse avviarsi nel cloud.

La correzione allinea il manifest al contratto approvato: issuer logico di Access, URL/JWKS privati con identità Google, archivi e progetto dei segreti. Terraform registra i permessi del solo sa-farm-api: invocazione Access, lettura/creazione raw, firma con la propria identità, creazione dei segreti dei feed e aggiunta versioni, pubblicazione sui quattro topic usati dal backend. Nessun ruolo amministrativo generico e nessuna lettura dei segreti sono richiesti dal codice attuale. Il nome del bucket dataset è configurato, ma il backend non riceve permessi dataset finché non li usa.

La capacità di creazione scelta concede la creazione dei contenitori nel progetto Farm senza un vincolo sul loro nome. Il vincolo feed- è applicato e collaudato sull'aggiunta di versioni. La firma è limitata alla propria identità, ma IAM non limita il contenuto firmato ai soli URL GCS. Questi limiti sono documentati nel dettaglio infrastrutturale.

Il backend pubblica dopo il commit SQL; sono previsti farm.events.v1, farm.parse-jobs.v1, platform.audit.v1 e platform.external.v1 nel progetto Farm, come richiesto dal publisher corrente. La retention topic di sette giorni evita la perdita immediata in assenza di sottoscrizioni, ma non conserva gli eventi indefinitamente. I nomi platform.* non dimostrano già un bus condiviso tra progetti. Relay, consumer, worker e sottoscrizioni non vengono attivati da questa correzione e richiederanno la propria registrazione e collaudo.

Aggiornamento dell'11 novembre. L'audit passa a un topic per sistema: Farm pubblica su farm.audit.v1 nel progetto Farm, al posto di platform.audit.v1, con publisher soltanto backend e relay di Farm; access-consumer si sottoscrive al topic di ogni sistema e ricava il sistema dalla sottoscrizione, perché Pub/Sub non porta l'identità di chi pubblica. Il topic va reso configurabile nel codice. I segreti portano il prefisso del sistema: quelli dei feed diventano farm-feed-<id> al posto di feed-<id>, quindi la condizione IAM sull'aggiunta di versioni passa dal prefisso feed- a farm-feed-. Grant e condizione restano da aggiornare in Terraform.

Il controllo riutilizzabile confronta manifest e requisiti versionati, vincola i valori infrastrutturali approvati e ripete il controllo sul render. La prova offline --check-config usa il binario vero, senza connettersi al database o ai servizi. Non certifica IAM, gli RPC di Access o l'intero prodotto Farm. L'enrollment delle installazioni richiede ancora l'integrazione con Releases: dalla PR Farm #17, senza FARM_RELEASES_URL, il codice rifiuta le installazioni fuori dall'ambiente locale (NoInstallations). Il precedente fallback senza verifica resta solo per Compose; non aggiungiamo URL fittizi per aggirarlo. Il gRPC Farm rimane chiuso e le autorizzazioni applicative di Access restano distinte da run.invoker.

La nuova versione applicativa passa dalla normale release approvata; né un merge né l'apply dei permessi aggiorna automaticamente il backend già online.

Esito dell'allineamento del 10 novembre

• Infra #36 e #37 unite e applicate: dieci trigger aggiornati, diciotto aggiunte stage e la correzione mirata di una condizione IAM. I piani successivi non mostrano differenze.
• Farm #20 allinea manifest e controllo del binario, conservando le nuove regole di Lorenzo. Controlli di pipeline e Terraform superati; test Rust e prova offline del backend riusciti. Il rebuild integrale dei Dockerfile originali è stato fermato per spazio disco; Compose è stato verificato con i binari di test e non viene presentato come prova delle future immagini release.
• Undici verifiche cloud riuscite: firma; aggiunta versione feed-; diniego su altro prefisso e lettura segreti; creazione/lettura raw; diniego dataset; permesso di sola pubblicazione sui quattro topic; JWKS Access via DNS privato e token Google. La prova dei topic usa testIamPermissions: non dimostra una consegna Pub/Sub a un consumer. Le risorse sintetiche sono rimosse a fine prova.
• Il primo test ha trovato una condizione IAM errata: AddSecretVersion valuta SecretVersion, non Secret. La correzione mantiene identità, progetto e prefisso; un test basato sugli attributi dell'audit evita la regressione.
• Una richiesta JWKS ha ricevuto 500 da Cloud Run durante l'avvio da zero, prima che il backend fosse disponibile. La prova finale ha ricevuto 200 al primo tentativo. La sonda permette retry limitati solo sul GET per errori transitori; questo non dimostra che il client applicativo abbia già quella resilienza. Va verificata prima dell'uso reale dei flussi autenticati, senza attivare istanze minime permanenti per mascherare il problema.

Nessun rollout applicativo eseguito in questo allineamento. Il nuovo kit Farm contiene i contratti applicati e i controlli aggiornati. Il prossimo publisher deve ancora costruire le immagini release e provare il nuovo controllo nel cloud; approvare il rollout rimane un passo successivo. Il collaudo qui registrato non certifica enrollment, consumer o tutte le autorizzazioni business.

Come riusiamo la base comune

• Cataloghi e moduli Terraform registrano il sistema; non abbiamo creato una seconda implementazione della pipeline per Farm.
• Il Job migratore gira nel progetto Farm, verifica bundle, immagine e identità, serializza le migrazioni e termina il proxy SQL anche in caso di errore.
• Il backend ha minimo zero, massimo due istanze e due connessioni SQL per istanza.
• Il profilo stage comprende backend e migratore. Relay e altri scrittori restano esclusi; Common è fissato alla versione già collaudata con Access.
• Gli eventi automatici dei trigger rimangono spenti. Publisher, preparazione release e rollout usano la procedura manuale approvata.

Dopo il primo onboarding, gli aggiornamenti ordinari riusano il kit senza apply Terraform, salvo nuove risorse o autorizzazioni. Non occorre completare Farm, Console o tutte le schede dei futuri sistemi per lavorare in parallelo.

Cosa abbiamo verificato

1. SQL prima e dopo il rilascio: riuscito. Login privato e membership di entrambe le identità verificati; sei altri database negati a ciascuna. Dopo la migrazione il runtime non può fare DDL né leggere il ledger. Job di verifica rimossi.
2. Kit e rollout: riusciti. Il kit ha adottato la build pubblicata. Il migratore ha applicato le due versioni mancanti e terminato il proxy; il backend è diventato Ready successivamente. La finestra IAM è chiusa con i grant nominali.
3. Platform → Farm: cinque casi riusciti. Rete private-ranges-only, DNS privato e token Google: prima del grant 403, autorizzato 200, senza token 403, audience errata 401, dopo revoca 403. Ogni caso ha provato /health e /ready; il positivo è correlato con i log Farm. Cinque Job e grant rimossi.
4. Telemetria e no-op: verificati entro un perimetro preciso. Ricevute metriche HTTP dei due percorsi e metriche SQL proxy; una traccia applicativa /health correlata; la traccia della richiesta /ready non risultava presente nell’ultima lettura. La richiesta è provata da HTTP 200, log e metriche. La riesecuzione del migratore ha riportato nessuna migrazione mancante, lasciando Job e backend invariati. L'ha avviata l'identità operatore stage, senza nuovi grant: non prova un secondo rollout Cloud Deploy né l'uso effettivo dei permessi del deployer dopo la chiusura IAM.

Il verified=false della ricevuta telemetria indica la seconda traccia mancante, non l'assenza di tutti i segnali: traccia e metriche osservate restano prove dell'arrivo effettivo.

Il kit per i prossimi rilasci usa i contratti successivi alla chiusura IAM. Il kit iniziale e il registro del primo rollout restano immutati. Non occorre un apply per ogni modifica al codice. I piani finali bootstrap e stage, sul commit pulito 1de3800, non mostrano differenze.

Il Catalog gRPC resta chiuso finché non definiamo audience e chiamante esplicito. Aggiornamento del 12 novembre: l'audience è decisa ed è l'URL fisso del backend chiamato (gRPC tra i servizi); il gRPC si apre con il rilascio in cui i chiamanti passano a quell'URL. Questa prova riguarda rete privata e IAM sui percorsi health/readiness; non certifica le autorizzazioni business. DNS pubblico, bilanciatore, IAP e produzione sono consegne separate.

Evidenze essenziali

Le PR Farm #9, Infra #30, #31, #32 e Docs #94 sono unite. Gli esiti finali sono pubblicati anche tramite Infra #34 e Docs #95, entrambe unite a main. La #32 è applicata: 35 modifiche bootstrap e 10 stage, senza cancellazioni o modifiche ad Access. La #33 chiude la finestra IAM: dieci risorse IAM aggiunte e rimozione del ruolo e del binding temporanei di prima creazione. L'uso effettivo dei permessi SQL è provato separatamente. Le altre PR Farm di Lorenzo restano distinte.

Evidenza	Cosa dimostra
Test applicazione	Formato/Clippy, 7 test Rust, 14 test hook/render, 21 contratti; Compose con migrazioni, no-op e blocco intenzionale del backend dopo errore SQL
Pubblicazione	Build 9f1de53b riuscita sul commit fc5d06e, immagini backend/migratore pubblicate; nessun deployment creato dalla build
DNS e S2S/cleanup	Rete privata verificata, cinque casi riusciti, sonde e grant assenti; Access invariato
Baseline e cleanup SQL	Apply confermato, metadati fixture e catalogo Access preservati, risorse amministrative temporanee assenti
Kit Farm e rollout	Kit verificato; release farm-b8c3e911… e rollout farm-stage-0001 riusciti
Migrazione, SQL, no-op	Due migrazioni applicate; privilegi e dinieghi verificati; una riesecuzione senza versioni mancanti
Telemetria	Metriche HTTP/proxy ricevute e una delle due tracce precise osservata; la ricevuta mantiene esplicitamente il limite

Le ricevute tecniche complete restano nell’archivio degli operatori. Questa scheda riporta il risultato e i limiti, senza sostituire ricevute, contratti e procedura comune.