Cette page a été traduite par l'API Cloud Translation.

Étape 6 : Exécuter le déploiement

Cette page décrit la sixième étape du déploiement de Cortex Framework Data Foundation, le cœur de Cortex Framework. Dans cette étape, vous allez exécuter le déploiement de la base de données Cortex Framework.

Processus de compilation

Après avoir configuré le fichier config.json comme décrit dans Étape 5 : Configurer le déploiement, suivez ces instructions pour créer votre processus.

Exécutez la commande suivante pour vous placer dans le dépôt cloné :
```
cd cortex-data-foundation
```
Exécutez la commande de compilation avec le bucket de journaux cible :
```
 gcloud builds submit \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET,\
 _BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/SERVICE_ACCOUNT@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Remplacez les éléments suivants :
- LOGS_BUCKET par le nom du bucket pour le stockage des journaux. Le compte de service Cloud Build doit être autorisé à les écrire ici.
- SOURCE_PROJECT avec le projet source.
- SERVICE_ACCOUNT par l'ID du compte de service.
Suivez le processus de compilation principal en examinant les journaux dans le terminal ou dans la console Cloud Build, si vous disposez des autorisations suffisantes. Pour plus d'informations, consultez les images suivantes.

Figure 1. Exemple de progression des journaux dans le terminal.

Figure 2. Exemple de progression de l'affichage des journaux dans la console.
Suivez les étapes de compilation enfant déclenchées depuis la console Cloud Build ou dans les journaux créés à partir des étapes. Pour plus d'informations, consultez les images ci-dessous.

Figure 3. Exemple de suivi des étapes de compilation enfant dans la console.

Figure 4. Exemple de suivi des étapes de compilation enfant dans les journaux.
Identifiez les problèmes liés à chaque compilation. Corrigez les éventuelles erreurs. Nous vous recommandons de coller le code SQL généré dans BigQuery pour identifier et corriger les erreurs. La plupart des erreurs sont liées à des champs sélectionnés, mais qui ne sont pas présents dans la source répliquée. L'UI BigQuery permet d'identifier ces requêtes et de les commenter.

Figure 5. Exemple d'identification des problèmes à l'aide des journaux Cloud Build.

Déplacer des fichiers vers le bucket DAG Cloud Composer (Airflow)

Si vous avez choisi de générer des fichiers d'intégration ou CDC et que vous disposez d'une instance Cloud Composer (Airflow), vous pouvez les déplacer vers leur bucket final à l'aide de la commande suivante :

  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/

Remplacez les éléments suivants :

OUTPUT_BUCKET par le bucket de sortie.
COMPOSER_DAG_BUCKET avec le bucket de DAG Cloud Composer (Airflow).

Personnaliser et préparer la mise à niveau

De nombreux clients professionnels personnalisent leurs systèmes de manière spécifique, par exemple en ajoutant des documents à un flux ou en utilisant des types d'enregistrements spécifiques. Elles sont spécifiques à chaque client et configurées par des analystes fonctionnels en fonction des besoins de l'entreprise.

Cortex utilise des balises ## CORTEX-CUSTOMER dans le code pour indiquer les endroits où de telles personnalisations sont probablement nécessaires. Utilisez la commande grep -R CORTEX-CUSTOMER pour vérifier tous les commentaires ## CORTEX-CUSTOMER que vous devez personnaliser.

En plus des balises CORTEX-CUSTOMER, vous devrez peut-être personnaliser davantage les éléments suivants en validant toutes ces modifications avec une balise claire dans le code de votre propre dépôt forké ou cloné :

Ajout de règles métier.
Ajouter d'autres ensembles de données et les joindre à des vues ou des tables existantes
Réutiliser les modèles fournis pour appeler des API supplémentaires.
Modifier les scripts de déploiement.
Appliquer d'autres concepts de maillage de données.
Adapter certaines tables ou API de destination pour inclure des champs supplémentaires non inclus dans la norme.

Adoptez un pipeline CI/CD adapté à votre organisation pour tester ces améliorations et maintenir votre solution globale dans un état fiable et robuste. Un pipeline peut réutiliser les scripts cloudbuild.yaml pour déclencher un déploiement de bout en bout de manière périodique ou en fonction des opérations Git, selon le dépôt de votre choix, en automatisant les builds.

Utilisez le fichier config.json pour définir différents ensembles de projets et d'ensembles de données pour les environnements de développement, de préproduction et de production. Utilisez des tests automatisés avec vos propres exemples de données pour vous assurer que les modèles produisent toujours les résultats attendus.

Le fait de marquer vos propres modifications de manière visible dans votre fork ou clone d'un dépôt, ainsi que d'automatiser le déploiement et les tests, vous aide à effectuer des mises à niveau.

Assistance

Si vous rencontrez des problèmes ou si vous avez des demandes de fonctionnalités concernant ces modèles ou ces déployeurs, créez un problème dans le dépôt Cortex Framework Data Foundation. Pour vous aider à collecter les informations nécessaires, exécutez support.sh à partir du répertoire cloné. Ce script vous guide à travers une série d'étapes de dépannage.

Pour toute demande ou tout problème concernant Cortex Framework, accédez à la section Assistance de la page "Présentation".

Blocs et tableaux de bord Looker

Profitez des blocs et tableaux de bord Looker disponibles. Il s'agit essentiellement de modèles de données réutilisables pour les modèles analytiques et les sources de données courants pour Cortex Framework. Pour en savoir plus, consultez Présentation des blocs et des tableaux de bord Looker.