이 페이지에서는 파이프라인의 리소스를 프로비저닝하는 방법을 설명합니다.
오케스트레이션 파이프라인의 리소스 프로비저닝 정보
오케스트레이션 파이프라인은 코드형 인프라 (IaC) 접근 방식을 사용하여 Google Cloud 데이터 파이프라인에서 사용하는 리소스를 관리하므로 다음과 같은 이점이 있습니다.
- 버전 제어. 인프라 변경사항은 Git에서 추적됩니다.
- 반복성. 환경을 안정적으로 다시 만들 수 있습니다.
- 협업. 팀원은 인프라 정의를 검토하고 이에 기여할 수 있습니다.
- 자동화. CI/CD 파이프라인에 통합됩니다.
- 선택사항 및 공존. 리소스 프로비저닝 프레임워크는 선택사항입니다. 리소스 프로비저닝에 Terraform 또는 기타 기존 IaC 관행을 이미 사용하고 있는 경우 계속 사용할 수 있습니다. 특정 파이프라인 또는 애플리케이션과 관련된 리소스 하위 집합을 관리할 수 있으며, 다른 도구에서 관리하는 리소스와 공존할 수 있습니다.
오케스트레이션 파이프라인에서 프로젝트는 하나 이상의 배포 환경 을 가질 수 있습니다. 각 배포 환경의 구성은 이 환경에 속하는 파이프라인과 리소스가 배포되는 방식을 정의합니다. 예를 들어 개발을 위한 배포 환경과 프로덕션을 위한 다른 환경을 가질 수 있습니다.
배포 환경 구성의 예입니다. 프로비저닝된 리소스는 resources 매핑에 정의됩니다.
environments:
dev:
project: example-dev-project
region: us-central1
variables:
dataset_name: marketing_analytics_dev
secrets:
dts_api_key: "projects/example-dev-project/secrets/dev-dts-key/versions/latest"
resources:
- type: dataproc.cluster
name: example-static-cluster-resource
definition:
clusterName: example-static-cluster
파이프라인을 배포할 때 오케스트레이션 파이프라인은 상태 비저장 '만들기 또는 업데이트' 모델을 사용하여 정의한 리소스를 프로비저닝합니다.
리소스가 정의되어 있지만 존재하지 않는 경우 오케스트레이션 파이프라인에서 리소스를 만듭니다.
리소스가 존재하는 경우:
(기본값) 정의와 일치하도록 리소스의 구성을 업데이트합니다.
리소스의 구성에서 이 동작을 정의하면 오케스트레이션 파이프라인에서 변경사항을 무시하거나 리소스를 다시 만들 수 있습니다.
구성에서 리소스의 정의를 삭제해도 리소스가 삭제되지는 않습니다. 이 접근 방식은 안전을 우선시하고 실수로 인한 데이터 손실을 방지합니다.
기존 리소스의 이름을 바꾸면 오케스트레이션 파이프라인에서 새 이름으로 새 리소스를 만들고 원래 리소스를 유지합니다.
프로비저닝된 리소스와 리소스 프로필 비교
리소스 프로필은 하나 이상의 Google Cloud 리소스 정의가 포함된 템플릿 파일입니다. 프로비저닝된 리소스와는 다르며 함께 사용할 수 있습니다.
프로비저닝된 리소스 사용:
deployment.yaml의 각 개발 환경 내에서 동일한 리소스 구성을 인라인으로 정의하는 대신 프로필에서 한 번 정의한 후 참조할 수 있습니다. 프로비저닝된 리소스는 리소스 프로필에서 정의할 수 있는 광범위한 리소스 유형을 지원합니다.파이프라인 작업 사용: 작업 기간 동안 리소스가 프로비저닝되는 작업에서 리소스 프로필을 사용할 수 있습니다. 리소스의 구성을 인라인으로 지정하는 대신 리소스 프로필을 사용하면 리소스 구성을 파이프라인 작업과 분리하고 여러 파이프라인 작업에 하나의 구성을 재사용할 수 있습니다. 파이프라인 작업은 임시 클러스터에서 파이프라인 작업을 실행할 때와 같이 Managed Service for Apache Spark 리소스에만 리소스 프로필을 지원합니다.
사용 가능한 리소스 유형 보기
리소스 유형을 참조하세요.
다음 명령어를 사용하여 gcloud CLI에서 사용 가능한 모든 리소스를 볼 수도 있습니다.
gcloud beta orchestration-pipelines resource-types list
새 리소스 추가
배포 환경의 구성에 새 프로비저닝된 리소스를 추가하려면 다음과 같이 정의를 추가합니다.
배포 환경의 구성에서
environments.DEVELOPMENT_ENVIRONMENT.resources목록에 새 항목을 추가합니다.다음 키를 지정합니다.
type: 프로비저닝할 리소스의 유형입니다. Google Cloud 예:bigquery.dataset,dataform.repository. gcloud CLI 명령어를 사용하여 사용 가능한 리소스 유형을 볼 수 있습니다.name:deployment.yaml파일 내 리소스의 논리적 이름입니다.parent: 상위 리소스가 필요한 리소스 유형의 상위 리소스를 지정합니다. 상위 리소스의name을 값으로 입력합니다.updateAction: 리소스의 구성에서 변경사항이 감지될 때 취해야 하는 작업을 지정합니다.(기본값)
patch: 변경된 리소스의 속성을 업데이트합니다.업데이트 작업은 리소스의 구성 (YAML)에 지정된 속성만 수정하고 다른 기존 속성은 변경하지 않습니다. 예를 들어 이 동작을 사용하여 파이프라인 실행에 중요한 속성만 관리하고 다른 속성은 수동으로 구성된 상태로 유지할 수 있습니다.
변경사항이 변경 불가능한 필드에 영향을 미치거나 리소스가 변경 불가능한 경우 배포가 실패합니다. 이러한 경우 변경 가능한 필드만 수정하도록 정의를 조정하는 것이 좋습니다. 이것이 불가능한 경우 업데이트 작업을
recreate로 변경할 수 있습니다.skip: 변경사항을 무시하고 리소스의 구성을 업데이트하지 않습니다.리소스의 존재를 관리하되 구성 변경 및 업데이트는 수동과 같은 다른 수단을 사용하여 수행하려는 경우 이 옵션을 사용하는 것이 좋습니다.
recreate: 변경사항이 감지되면 기존 리소스를 삭제한 후 현재 리소스의 정의를 기반으로 새 리소스를 만듭니다.전적으로 변경 불가능한 리소스 또는 인플레이스로 업데이트할 수 없는 필드가 변경된 경우 이 옵션을 사용하는 것이 좋습니다.
definition: 리소스 API에서 리소스의 구성 구조를 반영하는 매핑으로 리소스의 사양입니다.(선택사항)
metadata: 오케스트레이션 파이프라인 관련 메타데이터입니다. 일부 리소스 유형은 메타데이터 필드를 사용하여 리소스를 구성합니다. Google Cloud 예를 들어metadata.location필드를 사용하여 영역별 리소스를 만들 수 있습니다.
파이프라인을 검증하고 배포합니다. 파이프라인이 배포되면 오케스트레이션 파이프라인에서 새 리소스를 프로비저닝합니다.
예: 장기 실행 리소스
이 예에서는 장기 실행 리소스(이 경우 정적 Managed Service for Apache Spark 클러스터)를 추가하는 방법을 보여줍니다. 프로비저닝되면 파이프라인 작업에서 사용할 수 있습니다. 파이프라인에서 영구 리소스를 사용하는 경우 이 일반적인 접근 방식을 사용하는 것이 좋습니다.
다음 예에서는 example-static-cluster라는 정적 Managed Service for Apache Spark 클러스터를 dev 배포 환경에 추가합니다. 리소스의
정의는 Dataproc API를 기반으로 제공됩니다.
environments:
dev:
project: "example-project"
region: "us-central1"
# A runner environment for executing pipeline actions
composer_environment: "example-runner-environment"
resources:
- type: dataproc.cluster
name: example-static-cluster
updateAction: patch
definition:
config:
masterConfig:
numInstances: 1
machineTypeUri: n1-standard-4
workerConfig:
numInstances: 3
machineTypeUri: n1-standard-4
이 클러스터는 평소와 같이 파이프라인 작업에서 사용할 수 있습니다. 예를 들어 수동으로 만든 클러스터와 비교했을 때 사용에 차이가 없습니다.
modelVersion: "1.0"
pipelineId: "example-dataproc-pipeline"
...
actions:
- pyspark:
name: "run-pyspark-with-pyfiles-on-existing-cluster"
engine:
dataprocOnGce:
existingCluster:
clusterName: "example-static-cluster"
location: {{ region }}
projectId: {{ project }}
mainFilePath: "scripts/my_spark_job_with_pyfiles.py"
pyFiles:
- "scripts/lib1.py"
예: Dataform의 자동화된 빌드 및 출시 프로세스
이 예에서는 Dataform의 자동화된 빌드 및 출시 프로세스를 보여줍니다. 예시 시나리오:
Dataform 저장소는 Developer Connect를 통해 GitHub 저장소에 연결됩니다.
GitHub 저장소에 변경사항을 푸시합니다.
변경사항이 푸시된 후 파이프라인을 배포합니다.
Dataform은 GitHub 저장소에서 코드를 가져와서 컴파일 결과를 만들고 실행할 준비를 합니다.
그런 다음 워크플로 구성을 사용하여 이 자동으로 컴파일된 출시로 워크플로를 실행합니다.
다음 코드 예에서는 dev 배포 환경에서 Dataform 저장소, 출시 구성, 워크플로 구성을 정의합니다.
gitCommitish: "{{ COMMIT_SHA }}"줄은 출시 구성을 배포되는 특정 Git 커밋에 연결합니다.COMMIT_SHA는 배포된 파이프라인 번들의 커밋 SHA로 확인되는 변수입니다.codeCompilationConfig.pipelineConfig.path키는 파이프라인 애셋이 포함된 하위 폴더를 가리킵니다. 이러한 방식으로 단일 저장소에 여러 Dataform 파이프라인을 보관할 수 있습니다.releaseConfig정의에서releaseCompilationResult를auto로 설정하면releaseConfig리소스가 새gitCommitish로 생성되거나 업데이트된 후 오케스트레이션 파이프라인에서 Dataform 컴파일을 트리거하도록 지시합니다.- 프레임워크는 먼저
releaseConfig리소스를 upsert (업데이트 또는 생성)하여 지정된 커밋을 가리킵니다. - 그런 다음
auto설정으로 인해 Dataform API 를 호출하여 해당 커밋의 코드를 기반으로 새 컴파일 결과를 만듭니다. releaseConfig가 새로 생성된 컴파일 결과 ID를 가리키도록 다시 업데이트되어 해당 버전이 "실시간" 버전이 됩니다.
- 프레임워크는 먼저
environments:
dev:
project: example-project
region: us-central1
composer_environment: example-runner-environment
artifact_storage:
bucket: example-bucket
path_prefix: initialized-artifact-bucket
pipelines:
- source: initialized-pipeline.yaml
- source: dataform_local_pipeline.yaml
- source: dataform_service_pipeline.yaml
resources:
- name: {{ repository_name }}
type: dataform.repository
definition:
labels:
bigquery-deployment: preview
- type: dataform.repository.releaseConfig
name: subfolder-release
parent: {{ repository_name }}
definition:
gitCommitish: {{ COMMIT_SHA }}
releaseCompilationResult: auto
codeCompilationConfig:
pipelineConfig:
pipelineType: DATAFORM
path: weather_dataform
- type: dataform.repository.workflowConfig
name: {{ workflow_config_name }}
parent: {{ repository_name }}
definition:
releaseConfig: subfolder-release
invocationConfig:
serviceAccount: {{ service_account }}
variables:
service_account: example-account@example-project.iam.gserviceaccount.com
network_uri: projects/example-project/global/networks/default
subnetwork_uri: projects/example-project/regions/us-central1/subnetworks/default
region: us-central1
repository_name: weather-aggregation-repo
workflow_config_name: updated-subfolder-workflow
생성된 워크플로 구성으로 워크플로를 실행하는 파이프라인 작업의 예입니다.
modelVersion: '1.0'
pipelineId: dataform_service_pipeline
description: Updated run Dataform pipeline via Dataform Service
runner: airflow
owner: data-eng-team
defaults:
projectId: {{ project }}
location: {{ region }}
executionConfig:
retries: 1
actions:
- pipeline:
name: run_dataform_service
framework:
dataform:
dataformService:
location: {{ region }}
projectId: {{ project }}
repositoryId: {{ repository_name }}
workflowInvocation:
workflowConfig: projects/{{ project }}/locations/{{ region }}/repositories/{{
repository_name }}/workflowConfigs/{{ workflow_config_name }}
- python:
name: fibonacci_python
mainFilePath: scripts/fibonacci.py
pythonCallable: fibonacciTen
engine:
local: {}
- sql:
name: dummy_bq_query
engine:
bigquery:
location: {{ region }}
query:
inline: 'SELECT COUNT(*) FROM `{{ project }}.weather_data.sensor_readings`'
tags:
- job:datacloud:vscode