Passaggio 6: esegui il deployment

Questa pagina descrive il sesto passaggio per eseguire il deployment di Cortex Framework Data Foundation, il cuore di Cortex Framework. In questo passaggio, esegui il deployment di Cortex Framework Data Foundation.

Processo di compilazione

Dopo aver configurato il config.json file come descritto nel passaggio 5: configura il deployment, segui queste istruzioni per creare il processo.

Esegui il comando seguente per individuare il repository clonato:
```
cd cortex-data-foundation
```
Esegui il comando di build con il bucket di log di destinazione:
```
 gcloud builds submit \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET_NAME,_BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/CLOUD_BUILD_SA@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Sostituisci quanto segue:
- LOGS_BUCKET_NAME con il nome del bucket per l'archiviazione dei log. Il service account Cloud Build deve avere l'accesso per scriverli qui.
- SOURCE_PROJECT con il progetto di origine.
- CLOUD_BUILD_SA con l'ID account di servizio Cloud Build creato nel passaggio 4 del deployment.
Segui il processo di compilazione principale esaminando i log nel terminale o nella console Cloud Build, se hai autorizzazioni sufficienti. Per ulteriori informazioni, consulta le immagini seguenti.

Figura 1. Esempio di visualizzazione dell'avanzamento dei log nel terminale.

Figura 2. Esempio di visualizzazione dell'avanzamento dei log nella console.
Tieni traccia dei passaggi di build secondari attivati dalla console Cloud Build o all'interno dei log creati dai passaggi. Per ulteriori informazioni, consulta le immagini seguenti.

Figura 3. Esempio di monitoraggio dei passaggi di build secondari nella console.

Figura 4. Esempio di monitoraggio dei passaggi di build secondari all'interno dei log.
Identifica eventuali problemi con le singole build. Correggi gli errori, se presenti. Ti consigliamo di incollare l'SQL generato in BigQuery per identificare e correggere gli errori. La maggior parte degli errori è correlata ai campi selezionati, ma non presenti nell'origine replicata. L'interfaccia utente di BigQuery aiuta a identificarli e a commentarli.

Figura 5. Esempio di identificazione dei problemi tramite i log di Cloud Build.

Sposta i file nel bucket DAG di Managed Service for Apache Airflow (Airflow)

Se hai scelto di generare file di integrazione o CDC e hai un'istanza di Managed Airflow (Airflow), puoi spostarli nel bucket finale con il seguente comando:

  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/dags/ gs://COMPOSER_DAG_BUCKET/
  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/data/ gs://COMPOSER_DAG_BUCKET/

Sostituisci quanto segue:

OUTPUT_BUCKET con il bucket di output.
COMPOSER_DAG_BUCKET con il bucket DAG di Managed Airflow (Airflow).

Personalizza e preparati per l'upgrade

Molti clienti aziendali hanno personalizzazioni specifiche dei propri sistemi, ad esempio documenti aggiuntivi in un flusso o tipi specifici di record. Questi sono specifici per ogni cliente e vengono configurati dagli analisti funzionali in base alle esigenze aziendali.

Cortex utilizza i tag ## CORTEX-CUSTOMER nel codice per indicare i punti in cui è probabile che siano necessarie queste personalizzazioni. Utilizza il comando grep -R CORTEX-CUSTOMER per controllare tutti i commenti ## CORTEX-CUSTOMER che devi personalizzare.

Oltre ai tag CORTEX-CUSTOMER, potresti dover personalizzare ulteriormente quanto segue eseguendo il commit di tutte queste modifiche con un tag chiaro nel codice nel tuo repository con fork o clonato:

Aggiunta di regole aziendali.
Aggiunta di altri set di dati e unione con viste o tabelle esistenti
Riutilizzo dei modelli forniti per chiamare API aggiuntive.
Modifica degli script di deployment.
Adattamento di alcune tabelle o API di destinazione per includere campi aggiuntivi non inclusi nello standard.

Adotta una pipeline CI/CD adatta alla tua organizzazione per mantenere questi miglioramenti testati e la soluzione complessiva in uno stato affidabile e solido. Una pipeline può riutilizzare gli cloudbuild.yaml script per attivare periodicamente il deployment end-to-end o in base alle operazioni Git, a seconda del repository scelto, automatizzando le build.

Utilizza il file config.json per definire diversi set di progetti e set di dati per gli ambienti di sviluppo, gestione temporanea e produzione. Utilizza i test automatici con i tuoi dati di esempio per assicurarti che i modelli producano sempre ciò che ti aspetti.

L'aggiunta di tag visibili alle modifiche nel fork o nella clonazione di un repository, insieme all'automazione del deployment e dei test, facilita l'esecuzione degli upgrade.

Assistenza

Se riscontri problemi o hai richieste di funzionalità relative a questi modelli o deployer, crea un problema nel repository Cortex Framework Data Foundation. Per raccogliere le informazioni necessarie, esegui support.sh dalla directory clonata. Questo script ti guida attraverso una serie di passaggi per aiutarti a risolvere i problemi.

Per qualsiasi richiesta o problema relativo a Cortex Framework, vai alla sezione di assistenza nella pagina di panoramica.

Looker Blocks e dashboard

Sfrutta i Looker Blocks e le dashboard disponibili. Si tratta essenzialmente di modelli di dati riutilizzabili per pattern di analisi e origini dati comuni per Cortex Framework. Per ulteriori informazioni, consulta la panoramica di Looker Blocks e dashboard.