Skip to main content
Seleziona lo storage prima in base ai requisiti operativi, poi conferma la dichiarazione di supporto machine-readable della release. CaseBender non tratta ogni backend implementato da un SDK come certificato nella release.

​
Flusso di selezione

  1. Scegli un servizio esterno, gestito dal cliente, raggiungibile sia dal web sia dal worker.
  2. Provisiona località separate quarantine, records ed ephemeral.
  3. Conferma i requisiti di identità, TLS/CA privata, crittografia, versioning, retention, legal hold, audit logging, egress, backup e ripristino.
  4. Confronta il profilo prodotto esatto con scripts/storage/certification-matrix.json.
  5. Esegui la qualificazione live contro il prodotto/versione esatti dalla rete del workload.
  6. Firma e conserva le evidenze sanitizzate insieme al record della release.

​
Interpretazione della matrice attuale

Le evidenze live attuali di ODF/Ceph sono bloccate dalle credenziali del cliente. È configurato e pronto per la qualificazione, non certificato. Aggiorna lo stato rivolto al cliente solo dopo che il validatore della release accetta evidenze firmate di versione esatta.

​
Livelli di evidenza

  • Unit dimostra il comportamento locale dell’adapter in test di codice controllati.
  • Emulator dimostra la compatibilità SDK e di contratto con il sottoinsieme di un emulator.
  • Live dimostra le operazioni richieste contro un prodotto nominato e una versione esatta nel contesto di rete, trust, identità e policy previsto.
I risultati di emulator non possono mai soddisfare una voce della matrice il cui requiredCertification è live. I nomi di famiglia di prodotto come “S3 compatible,” “Ceph” o “Azure Blob” sono insufficienti senza una versione target esatta e un digest delle evidenze. La compatibilità con l’emulator non è certificazione live.

​
Valida la matrice

Parti da scripts/storage/certification-evidence.template.json. Non aggiungere mai credenziali, token, connection string, chiavi private, contenuti degli oggetti, nomi di oggetti del cliente o URL firmati alle evidenze.

​
Esempi di configurazione

Per la produzione, preferisci un STORAGE_CONFIG_FILE montato con modalità 0400 o 0600. Questa forma è illustrativa:
Lo schema completo e rigoroso del profilo è documentato nelle pagine dei provider. Non inserire access key nella documentazione né committare un file di configurazione popolato.

​
Trigger di riqualificazione

Riesegui le evidenze live dopo aver modificato uno qualsiasi di:
  • release CaseBender o SDK di storage;
  • provider, ODF, Ceph, account o versione API;
  • sicurezza, versioning, retention o immutabilità di bucket/container;
  • identità, ruolo, credenziale, endpoint, CA privata o policy di egress;
  • confine scanner/promotion; oppure
  • tooling di backup, migrazione e ripristino.
Guide correlate: