Distribuisci Microsoft Discovery con lo strumento di onboarding

Esegui la Fase 4 per creare la piattaforma principale di Discovery in ordine di dipendenze. Questa fase scrive le risorse Azure e può creare assegnazioni di ruolo Foundry per utenti o idoneità. Può comportare costi di calcolo, archiviazione e modello.

Per il deployment di portale o Bicep standalone, usa invece il quickstart dell'infrastruttura.

Prerequisites

• Una zona di atterraggio preparata e revisionata config.json contenente resourceGroup, managedIdentity.id, e le impostazioni di stoccaggio.
• Report aggiornati per supercomputer e workspacedi Fase 3 più evidenze indipendenti di connettività per le subnet necessarie.
• Il set completo di ruoli dell'utente tipo Amministratore della piattaforma è impostato negli ambiti documentati, incluse le risorse UAMI/di rete a cui si fa riferimento. Un ruolo di Discovery non è l'insieme completo.
• Ulteriore autorizzazione dell'assegnazione se questo strumento di esecuzione deve concedere l'accesso a Foundry nel nuovo gruppo di risorse gestite dell'area di lavoro. Vedi permessi della Fase 4.
• Ruoli JIT attivi dove applicabile, interfaccia della riga di comando di Azure con accesso effettuato alla sottoscrizione prevista e un prompt di PowerShell 7 in utilities\onboarding-tool\scripts.

Esaminare le risorse e l'idoneità

La fase 4 implementa il supercomputer e il pool di nodi, poi lo spazio di lavoro, il modello di chat, il container di archiviazione del progetto e il progetto. La revisione esaminata dello strumento utilizza discovery-platform.bicep e la versione 2026-06-01 dell'API Discovery. Mantieni gli script e il template nella stessa revisione.

Non crea l'account di archiviazione UAMI o di proprietà del cliente, non distribuisce librerie né ne acquisisce i contenuti, non pubblica uno strumento né crea un registro clienti.

1. Verificare che i gruppi di sottoscrizioni e risorse corrispondano alla configurazione esaminata.
2. Esaminare sia i report di idoneità che le evidenze indipendenti della rete. Risolvi controlli non riusciti e azioni esterne richieste.
3. Confermare che i report siano stati generati per la configurazione e lo stato di rete da distribuire.

Il percorso di distribuzione normale si blocca se un report fornito è mancante, illeggibile o non GO. Tuttavia, omettere -ReadinessReport genera solo un avviso; anche la copertura del profilo mancante può generare un avviso. Lo strumento non applica l'aggiornamento o il binding di configurazione. Questa procedura fornisce entrambi i profili come salvaguardia operativa, non come affermazione che lo script richieda entrambi.

Confermare il posizionamento dell'area

L'impostazione controlPlaneRegion posiziona le risorse del piano di controllo Discovery. L'impostazione workloadRegion colloca il VNet, le sottoreti e tutte le risorse nei gruppi di risorse gestiti. Queste due regioni possono differire. Il template passa workloadRegion attraverso il discovery.overridemrgregion tag.

Prima che la distribuzione normale invii una richiesta Bicep o ARM, la Fase 4 verifica le aree VNet per le subnet configurate del nodo di sistema, del nodo del carico di lavoro, dell'app contenitore e dell'endpoint privato. Controlla inoltre la subnet di gestione UDR separata quando applicabile. Un VNet illeggibile o una discrepanza di regione fa fallire il controllo deploy-network-region prima dell'invio.

Tieni tutte quelle sottoreti in workloadRegion. Non cambiare controlPlaneRegion solo per farlo corrispondere al VNet. Risolvere una mancata corrispondenza tra carico di lavoro e area e aggiornare le evidenze di idoneità prima di riprovare.

Esegui la fase 4

.\stage4-deployment\stage4_deploy.ps1 `
  -ConfigPath .\config.json `
  -ReadinessReport .\out\stage3-supercomputer.json,.\out\stage3-workspace.json `
  -JsonPath .\out\stage4.json

Mantieni la sessione disponibile mentre le operazioni sulle risorse sono in corso. Il provisioning comprende AKS e servizi gestiti dall'area di lavoro; una console silenziosa non dimostra che un'operazione sia bloccata. Lo strumento interroga lo stato delle risorse e segnala i timeout. Ispeziona la cronologia delle operazioni di Azure prima di riprovare un'operazione andata in timeout che potrebbe ancora essere in esecuzione.

Verificare la distribuzione e l'accesso

1. Rivedi .\out\stage4.md e il rapporto JSON. Ispezionare gli errori ARM e qualsiasi ID di correlazione invece di affidarsi solo al verdetto.
2. Conferma che il supercomputer, il pool di nodi, lo spazio di lavoro, il modello di chat, il container di storage Discovery e il progetto siano in stati di provisioning riusciti e abbiano gli ID risorsa previsti.
3. Verifica che l'archiviazione del progetto punti all'account previsto. names.storageContainer seleziona un nome esplicito. Quando è vuoto, lo strumento ricava automaticamente <workspace-prefix>-storage, troncando il prefisso per mantenere il nome entro 24 caratteri. Le ripetizioni delle esecuzioni possono riutilizzare un nome legacy <workspace>-bookshelf valido; quel nome non significa che la libreria sia stata distribuita.
4. Esaminare i risultati dell'accesso Foundry. Dopo aver creato il progetto, lo strumento mira a Foundry Owner nel gruppo di risorse gestite dallo spazio di lavoro per le entità Platform Administrator, oppure all'identità di distribuzione quando non vengono fornite tali entità; mira a Foundry User per le entità Platform Contributor.
5. Risolvi gli avvisi di Foundry prima che gli utenti dipendano da quell'accesso. In modalità JIT, attiva la nuova idoneità prima di utilizzare lo spazio di lavoro. Un fallimento dell'assegnazione può essere un avvertimento piuttosto che un fallimento nel dispiegamento della piattaforma.

Usa rapporti e artefatti per l'interpretazione dell'output.

Riprendi dopo l'interruzione

La fase 4 ispeziona lo stato effettivo delle risorse e riprende il lavoro incompleto. Dopo un'interruzione:

1. Leggere la cronologia operativa e identificare se l'ultima risorsa è ancora in fase di provisioning, riuscita o non riuscita.
2. Risolvi la causa principale diagnosticata. Aggiornare i report sullo stato di preparazione dopo le modifiche pertinenti.
3. Riesegui lo stesso comando normale con la configurazione revisionata e entrambi i rapporti.

Non cancellare le risorse solo perché il processo è stato interrotto. Un'operazione fallita non implica un rollback.

Usa il recupero dello spazio di lavoro solo quando applicabile

-Recovery è un percorso re-PUT dell'area di lavoro di destinazione, non un'opzione di correzione generale. Usalo solo dopo aver diagnosticato uno spazio di lavoro bloccato e aver confermato che il supercomputer collegato è Succeeded.

Il percorso di recupero viene eseguito prima della normale fase di controllo del report di idoneità. Esaminare esplicitamente evidenze aggiornate relative a idoneità e rete prima di eseguire qualsiasi scrittura di ripristino. Usa il comando mirato emesso dallo strumento per l'abbonamento previsto, il gruppo di risorse e lo spazio di lavoro; non adattarlo a una risorsa diversa senza aver prima effettuato una diagnosi.

Per guasti topologici, ruoli UAMI mancanti, fallimenti AKS in uscita e criteri di ricreazione/escalation sicura, vedi Troubleshoot onboarding. Conservare la cronologia operativa e l'ID di correlazione prima di qualsiasi eliminazione approvata di una risorsa.

Passaggio successivo

Verifica il deployment di onboarding