このページは Cloud Translation API によって翻訳されました。

ステップ 6: デプロイを実行する

このページでは、Cortex Framework のコアである Cortex Framework Data Foundation をデプロイする 6 番目のステップについて説明します。このステップでは、Cortex Framework Data Foundation のデプロイを実行します。

ビルドプロセス

ステップ 5: デプロイを構成するで説明されているように config.json ファイルを構成したら、次の手順に沿ってプロセスをビルドします。

次のコマンドを実行して、クローンを作成したリポジトリに移動します。
```
cd cortex-data-foundation
```
ターゲットログバケットを指定してビルドコマンドを実行します。
```
gcloud builds submit --project EXECUTION_PROJECT\
    --substitutions=_GCS_BUCKET=LOGS_BUCKET
```
次のように置き換えます。
- EXECUTION_PROJECT は、実行プロジェクト（通常はソースプロジェクト）に置き換えます。
- LOGS_BUCKET は、ログストレージのバケット名に置き換えます。Cloud Build サービスアカウントには、ここに書き込むためのアクセス権が必要です。
十分な権限がある場合は、ターミナルまたは Cloud Build コンソールでログを確認して、メインのビルドプロセスに沿って操作します。以下の画像を参照してください。

図 1ターミナルでログの進行状況を確認する例。

図 2コンソールでログの進行状況を確認する例。
Cloud Build コンソールからトリガーされた子ビルドステップ、またはステップから作成されたログ内で子ビルドステップを追跡します。詳しくは、次の画像を参照してください。

図 3コンソールで子ビルドステップを追跡する例。

図 4. ログ内で子ビルドステップをトラッキングする例。
個々のビルドの問題を特定します。エラーがある場合は修正します。生成された SQL を BigQuery に貼り付けて、エラーを特定して修正することをおすすめします。ほとんどのエラーは、選択されているが複製元に存在しないフィールドに関連しています。BigQuery UI を使用すると、それらを特定してコメント化できます。

図 5. Cloud Build ログを使用して問題を特定する例。

ファイルを Cloud Composer（Airflow）DAG バケットに移動する

統合ファイルまたは CDC ファイルを生成し、Cloud Composer（Airflow）のインスタンスが存在する場合は、次のコマンドを使用して最終バケットに移動できます。

  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/

次のように置き換えます。

OUTPUT_BUCKET は、出力バケットに置き換えます。
COMPOSER_DAG_BUCKET は、Cloud Composer（Airflow）DAG バケットに置き換えます。

カスタマイズしてアップグレードの準備を行う

多くの企業のお客様は、フロー内の追加ドキュメントや特定の種類のレコードなど、システムをカスタマイズしています。これらはお客様ごとに固有のものであり、ビジネスニーズに応じて機能アナリストによって構成されます。

Cortex は、コード内の ## CORTEX-CUSTOMER タグを使用して、このようなカスタマイズが必要になる可能性が高い場所を示します。grep -R CORTEX-CUSTOMER コマンドを使用して、カスタマイズする必要があるすべての ## CORTEX-CUSTOMER コメントを確認します。

CORTEX-CUSTOMER タグに加えて、コード内の明確なタグを使用して、これらの変更をすべて独自のフォークまたはクローンを作成したリポジトリに commit することで、以下をさらにカスタマイズすることが必要になる場合があります。

ビジネスルールの追加。
他のデータセットを追加して、既存のビューまたはテーブルと結合する
提供されたテンプレートを再利用して、追加の API を呼び出す。
デプロイスクリプトの変更。
データメッシュのその他のコンセプトの適用。
一部のテーブルまたはリリース済みの API を調整して、標準に含まれていない追加フィールドを含める。

組織に適した CI/CD パイプラインを採用して、これらの機能強化をテストし、ソリューション全体を信頼性が高く堅牢な状態に保ちます。パイプラインは、cloudbuild.yaml スクリプトを再利用して、エンドツーエンドのデプロイを定期的にトリガーできます。また、ビルドを自動化して、選択したリポジトリに応じて git オペレーションに基づいてトリガーすることもできます。

config.json ファイルを使用して、開発環境、ステージング環境、本番環境に異なるプロジェクトとデータセットのセットを定義します。独自のサンプルデータを使用して自動テストを行い、モデルが常に期待どおりの結果を生成するようにします。

リポジトリのフォークまたはクローン内で、独自の変更を明示的にタグ付けし、デプロイとテストの自動化を組み合わせると、アップグレードを実行できます。

サポート

これらのモデルまたはデプロイツールに関連する問題が発生した場合や、機能のリクエストがある場合は、Cortex Framework Data Foundation リポジトリで問題を作成してください。必要な情報を収集するには、クローンを作成したディレクトリから support.sh を実行します。このスクリプトでは、トラブルシューティングに役立つ一連の手順をご案内します。

Cortex Framework のリクエストや問題については、概要ページの [サポート] セクションに移動します。

Looker Blocks とダッシュボード

利用可能な Looker Block とダッシュボードを活用します。これらは基本的に、Cortex Framework の一般的な分析パターンとデータソースに再利用可能なデータモデルです。詳細については、Looker ブロックとダッシュボードの概要をご覧ください。