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) 인스턴스가 있는 경우 다음 명령어를 사용하여 최종 버킷으로 이동할 수 있습니다.
Cloud Composer (Airflow) DAG 버킷을 사용합니다.COMPOSER_DAG_BUCKET
맞춤설정 및 업그레이드 준비
많은 엔터프라이즈 고객은 흐름의 추가 문서나 특정 유형의 레코드와 같은 시스템을 맞춤설정합니다. 이는 각 고객에게 고유하며 비즈니스 요구사항이 발생하면 기능 분석가가 구성합니다.
Cortex는 코드에서 ## CORTEX-CUSTOMER 태그를 사용하여 이러한 맞춤설정이 필요할 수 있는 위치를 나타냅니다. grep -R CORTEX-CUSTOMER 명령어를 사용하여 맞춤설정해야 하는 모든 ## CORTEX-CUSTOMER 주석을 확인합니다.
CORTEX-CUSTOMER 태그 외에도 코드에서 명확한 태그를 사용하여 이러한 모든 변경사항을 포크 또는 클론된 저장소에 커밋하여 다음을 추가로 맞춤설정해야 할 수 있습니다.
비즈니스 규칙 추가
다른 데이터 세트를 추가하고 기존 뷰 또는 테이블과 조인
제공된 템플릿을 재사용하여 추가 API를 호출합니다.
배포 스크립트 수정
추가 데이터 메시 개념 적용
표준에 포함되지 않은 추가 필드를 포함하도록 일부 표 또는 출시된 API를 조정합니다.
조직에 적합한 CI/CD 파이프라인을 채택하여 이러한 개선사항을 테스트하고 전반적인 솔루션을 안정적이고 강력한 상태로 유지하세요. 파이프라인은 cloudbuild.yaml 스크립트를 재사용하여 빌드를 자동화함으로써 선택한 저장소에 따라 주기적으로 또는 Git 작업을 기반으로 엔드 투 엔드 배포를 트리거할 수 있습니다.
config.json 파일을 사용하여 개발, 스테이징, 프로덕션 환경에 대해 서로 다른 프로젝트 및 데이터 세트를 정의합니다. 자체 샘플 데이터로 자동화된 테스트를 사용하여 모델이 항상 예상한 결과를 생성하도록 합니다.
리포지토리의 포크 또는 클론에서 변경사항을 명시적으로 태그하고 일부 배포 및 테스트 자동화를 사용하면 업그레이드를 실행하는 데 도움이 됩니다.
지원
이러한 모델 또는 배포자와 관련된 문제가 발생하거나 기능 요청이 있는 경우 Cortex Framework Data Foundation 저장소에서 문제를 생성하세요. 필요한 정보를 수집하는 데 도움이 되도록 클론된 디렉터리에서 support.sh를 실행합니다. 이 스크립트는 문제 해결에 도움이 되는 일련의 단계를 안내합니다.
Cortex Framework 요청 또는 문제가 있는 경우 개요 페이지의 지원 섹션으로 이동하세요.
Looker 블록 및 대시보드
사용 가능한 Looker 블록과 대시보드를 활용합니다. 이는 기본적으로 Cortex Framework의 일반적인 분석 패턴과 데이터 소스를 위한 재사용 가능한 데이터 모델입니다. 자세한 내용은 Looker 블록 및 대시보드 개요를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis step outlines how to execute the deployment of Cortex Framework Data Foundation, following the configuration of the \u003ccode\u003econfig.json\u003c/code\u003e file.\u003c/p\u003e\n"],["\u003cp\u003eThe build process involves running commands within the cloned repository, using \u003ccode\u003egcloud builds submit\u003c/code\u003e to start the build, and monitoring the build progress via the terminal or Cloud Build console.\u003c/p\u003e\n"],["\u003cp\u003eFor users with a Cloud Composer (Airflow) instance, generated integration or CDC files can be moved to the Cloud Composer DAG bucket using specific gcloud storage commands.\u003c/p\u003e\n"],["\u003cp\u003eCustomizations specific to enterprise customers are supported, as identified by \u003ccode\u003e## CORTEX-CUSTOMER\u003c/code\u003e tags in the code, and it is recommended to tag all changes clearly in forked or cloned repositories.\u003c/p\u003e\n"],["\u003cp\u003eUtilize Looker Blocks and Dashboards, which provide reusable data models for analytical patterns and common data sources.\u003c/p\u003e\n"]]],[],null,["# Step 6: Execute deployment\n==========================\n\nThis page describes the sixth step to deploy Cortex Framework Data Foundation, the core\nof Cortex Framework. In this step, you execute the deployment of\nCortex Framework Data Foundation.\n| **Note:** The steps outlined in this page are specifically designed for deploying Cortex Framework Data Foundation from the [official GitHub repository](https://github.com/GoogleCloudPlatform/cortex-data-foundation).\n\nBuild process\n-------------\n\nAfter configuring the [`config.json`](https://github.com/GoogleCloudPlatform/cortex-data-foundation/blob/main/config/config.json)\nfile as described in [Step 5: Configure deployment](/cortex/docs/deployment-step-five),\nfollow these instructions to build your process.\n\n1. Run the following command to locate yourself in the cloned repository:\n\n cd cortex-data-foundation\n\n2. Run the build command with the target log bucket:\n\n gcloud builds submit \\\n --substitutions=_GCS_BUCKET=\u003cvar translate=\"no\"\u003eLOGS_BUCKET\u003c/var\u003e,_BUILD_ACCOUNT='projects/\u003cvar translate=\"no\"\u003eSOURCE_PROJECT\u003c/var\u003e/serviceAccounts/\u003cvar translate=\"no\"\u003eSERVICE_ACCOUNT\u003c/var\u003e@\u003cvar translate=\"no\"\u003eSOURCE_PROJECT\u003c/var\u003e.iam.gserviceaccount.com'\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eLOGS_BUCKET\u003c/var\u003e with the bucket name for logs storage. Cloud Build Service Account needs access to write them here.\n - \u003cvar translate=\"no\"\u003eSOURCE_PROJECT\u003c/var\u003e with the source project.\n - \u003cvar translate=\"no\"\u003eSERVICE_ACCOUNT\u003c/var\u003e with the service account ID.\n3. Follow the main build process from looking at the logs in the terminal\n or in the [Cloud Build console](https://console.cloud.google.com/cloud-build/),\n if you have enough permissions. See the following images for more reference.\n\n **Figure 1**. Example of viewing logs progress in the terminal.\n\n **Figure 2**. Example of viewing logs progress in the console.\n4. Track the child build steps triggered from the Cloud Build\n console or within the logs created from the steps. See the following images for\n more reference.\n\n **Figure 3**. Example of tracking child build steps in the console.\n\n **Figure 4**. Example of tracking child build steps within the logs.\n5. Identify any issues with individual builds. Correct errors, if any. It's\n recommended to paste the generated SQL into BigQuery to identify and\n correct the errors. Most errors are related to fields that are selected,\n but not present in the replicated source. The BigQuery UI helps to\n identify and comment those out.\n\n **Figure 5**. Example of identifying issues through Cloud Build logs.\n\nMove files to the Cloud Composer (Airflow) DAG bucket\n-----------------------------------------------------\n\nIf you opted to generate integration or CDC files and have an instance of\nCloud Composer (Airflow), you can move them into their final bucket\nwith the following command: \n\n gcloud storage -m cp -r gs://\u003cvar translate=\"no\"\u003eOUTPUT_BUCKET\u003c/var\u003e/dags/ gs://\u003cvar translate=\"no\"\u003eCOMPOSER_DAG_BUCKET\u003c/var\u003e/\n gcloud storage -m cp -r gs://\u003cvar translate=\"no\"\u003eOUTPUT_BUCKET\u003c/var\u003e/data/ gs://\u003cvar translate=\"no\"\u003eCOMPOSER_DAG_BUCKET\u003c/var\u003e/\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eOUTPUT_BUCKET\u003c/var\u003e with the output bucket.\n- \u003cvar translate=\"no\"\u003eCOMPOSER_DAG_BUCKET\u003c/var\u003e with the Cloud Composer (Airflow) DAG bucket.\n\n| **Note:** This step is only applicable if you have an instance of Airflow running, as Airflow is commonly used to manage and orchestrate data pipelines.\n\nCustomize and prepare for upgrade\n---------------------------------\n\nMany enterprise customers have specific customizations of their systems, such as\nadditional documents in a flow or specific types of a record. These are specific\nto each customer and configured by functional analysts as the business needs arise.\n\nCortex utilizes `## CORTEX-CUSTOMER` tags in code to denote places where such\ncustomizations are likely required. Use the command `grep -R CORTEX-CUSTOMER` to\ncheck all `## CORTEX-CUSTOMER` comments that you should customize.\n\nIn addition to the `CORTEX-CUSTOMER` tags, you might need to further\ncustomize the following by committing all of these changes with a clear\ntag in the code to your own forked or cloned repository:\n\n- Adding business rules.\n- Adding other datasets and joining them with existing views or tables\n- Reusing the provided templates to call additional APIs.\n- Modifying deployment scripts.\n- Applying further data mesh concepts.\n- Adapting some tables or landed APIs to include additional fields not included in the standard.\n\nAdopt a CI/CD pipeline that works for your organization to keep\nthese enhancements tested and your overall solution in a reliable\nand robust state. A pipeline can reuse the `cloudbuild.yaml`\nscripts to trigger end-to-end deployment periodically, or based on\ngit operations depending on your repository of choice by\n[automating builds](/build/docs/automating-builds/create-manage-triggers).\n\nUse the`config.json` file to define different sets of projects and\ndatasets for development, staging, and production environments. Use\nautomated testing with your own sample data to ensure the models\nalways produce what you expect.\n\nTagging your own changes visibly in your fork or clone of a\nrepository together with some deployment and testing automation helps\n[perform upgrades](/cortex/docs/upgrade-recommendations).\n\nSupport\n-------\n\nIf you encounter any issues or have feature requests related to these models\nor deployers, create an issue in the [Cortex Framework Data Foundation](https://github.com/GoogleCloudPlatform/cortex-data-foundation) repository. To assist with gathering the necessary\ninformation, execute `support.sh` from the cloned directory. This script\nguides you through a series of steps to help troubleshoot.\n\nFor any Cortex Framework requests or issues, go to the\n[support](/cortex/docs/overview#support) section in the overview page.\n\nLooker Blocks and Dashboards\n----------------------------\n\nTake advantage of the available Looker Blocks and Dashboards. These\nare essentially reusable data models for common analytical patterns and data\nsources for Cortex Framework. For more information, see\n[Looker Blocks and Dashboards overview](/cortex/docs/looker-block-overview)."]]
