このページは 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 \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET,\
 _BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/SERVICE_ACCOUNT@SOURCE_PROJECT.iam.gserviceaccount.com'
```
次のように置き換えます。
- LOGS_BUCKET は、ログの保存に使用するバケット名に置き換えます。Cloud Build サービスアカウントには、ここに書き込むためのアクセス権が必要です。
- SOURCE_PROJECT: ソースプロジェクト。
- SERVICE_ACCOUNT は、サービスアカウント ID に置き換えます。
十分な権限がある場合は、ターミナルまたは 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 ブロックとダッシュボードの概要をご覧ください。