이 페이지에서는 Google Cloud Deployment Manager를 사용하여 배포를 만들 때의 권장사항을 설명합니다. 이 페이지는 Deployment Manager에 익숙한 사용자를 대상으로 작성되었으며, Deployment Manager 사용 방법을 설명하지 않습니다.
Deployment Manager를 처음 사용하는 경우에는 대신 빠른 시작을 시작하세요.
리소스 관리
|
❑
배포 중에 리소스를 만든 후 리소스를 수정해야 할 경우 Deployment Manager를 사용합니다.
Google Cloud 콘솔 또는
gcloud 등에서 Deployment Manager를 사용하지 않고 리소스를 수정한 경우 원래 배포의 리소스를 수정하려 하면 오류가 발생할 수 있습니다.
리소스를 삭제하지 않고 배포에서 리소스를 삭제하려면 다음 단계를 따르세요.
|
|
❑
배포에 Compute Engine 인스턴스가 있고 인스턴스에 영구 디스크를 연결하려는 경우에는 쉽게 관리할 수 있도록 인스턴스와 별개로 디스크를 정의하세요. 예를 들어 아래 배포에서
example-disk 디스크는 example-instance 인스턴스와 별도로 정의됩니다. 디스크를 연결하기 위해 구성에는 디스크에 대한 참조가 포함됩니다.
resources: # instance - name: example-instance type: compute.v1.instance properties: disks: - type: PERSISTENT source:$(ref.example-disk.selfLink) # disk - name: example-disk type: compute.v1.disk properties: zone: us-central1-a sizeGb: 10 type: ... |
|
❑
Deployment Manager를 사용하여 비공개 Google Kubernetes Engine(GKE) 클러스터를 만들고 관리하려면 배포에서 다음 privateClusterConfig: enablePrivateNodes: true enablePrivateEndpoint: true # Configure the IP range for the hosted master network masterIpv4CidrBlock: IP_RANGE ipAllocationPolicy: useIpAliases: true createSubnetwork: true GKE를 사용하여 비공개 클러스터를 만들 때의 요구사항과 추가 고려 사항은 비공개 클러스터 설정을 참조하세요. |
배포에 사용자 인증 정보 포함
|
❑
Deployment Manager는 YAML 구성의 속성에서 사용자 인증 정보와 관련된 일부 필드를 수정합니다. 이 수정은 속성의 키를 기반으로 수행됩니다. 다음 예시는 이러한 수정의 한 가지를 보여줍니다.
# Config provided to Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: hunter2 # Config as surfaced by Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: (redacted) |
|
❑
배포를 위해 Jinja 또는 Python 템플릿에 사용자 인증 정보를 포함하면 사용자 인증 정보는 생성된 확장 구성과 레이아웃 파일에서 수정되지만 원본 가져오기 파일에는 계속 표시됩니다. 따라서 최상위 YAML 구성에 보안 비밀을 유지하려는 모든 사용자 인증 정보를 배치하는 것이 좋습니다. 여기에서 템플릿 속성을 사용하여 참조할 수 있습니다.
|
|
❑
YAML 파일 또는 항목의 목록 내의 키-값 쌍에 포함된 사용자 인증 정보는 다음 예와 같이 수정되지 않습니다. 따라서 YAML 파일 또는 항목의 목록 내의 키-값 쌍으로 Deployment Manager에 사용자 인증 정보를 제공하지 않는 것을 적극 권장합니다.
# Not a valid instance configuration, used solely for demonstration resources: - name: example-resource type: gcp-types/compute-v1:instances properties: zone: us-central1-a disks: - autoDelete: true boot: true # Will not be redacted password: hunter2 |
템플릿 빌드
|
❑
템플릿을 빠르게 정의하려면 Cloud Foundation Toolkit 프로젝트에 있는 프로덕션에 즉시 사용할 수 있는 샘플 템플릿을 사용하는 것이 좋습니다.
|
|
❑
여러 환경을 만들어야 하는 경우와 같이 복잡한 인프라 요구사항이 있으면 규모에 맞게 Deployment Manager 사용 가이드와 샘플을 참조하세요.
|
|
❑
Python을 사용하여 템플릿을 빌드합니다.
Python 또는 Jinja2를 사용하여 템플릿을 만들 수 있습니다. 시작하기에는 Jinja가 더 쉽지만 여러 환경에 많은 리소스가 분산되어 있는 복잡한 배포에는 Python이 더 유연합니다.
|
|
❑
|
|
❑
스키마 파일을 사용합니다.
스키마는 구성 파일이 특정 템플릿을 사용하기 위해 따라야 하는 규칙 집합을 정의합니다. 스키마를 정의하고 다른 사람이 스키마에 정의된 요구사항을 검토하도록 하면 사용자가 해당 템플릿에 설정할 수 있거나 필요한 속성이 무엇인지 쉽게 이해할 수 있습니다. 이렇게 하면 사용자가 템플릿을 자세히 조사할 필요 없이 구성을 사용할 수 있습니다. 최소한 최상위 템플릿에 대한 스키마 파일은 정의해야 합니다.
|
|
❑
|
|
❑
기본 구성 파일로 가져오는 개별 템플릿 파일을 사용합니다. 이렇게 하면 구성 작업을 보다 쉽게 관리할 수 있습니다.
|
|
❑
구성을 논리적 단위로 세분화합니다. 예를 들어 데이터베이스 및 버킷과 같은 상태 저장 서비스에 대한 구성과 프런트엔드 인스턴스와 같은 보다 일시적인 서비스에 대한 구성을 개별적으로 만듭니다.
|
|
❑
참조를 사용합니다.
참조는 리소스의
selfLink, IP 주소 또는 시스템에서 생성된 ID와 같이 리소스가 생성되기 전까지 정의되지 않은 값에 사용됩니다. 참조를 사용하지 않으면 Deployment Manager가 모든 리소스를 동시에 만들므로 종속 리소스가 올바른 순서로 생성된다고 보장할 수 없습니다. 참조를 사용하여 리소스 생성 순서를 적용할 수 있습니다.
|
|
❑
배포 미리보기를 통해 업데이트가 배포에 영향을 주는 방식을 평가합니다.
Deployment Manager는 개발자가 구성을 미리볼 때 실제 리소스를 인스턴스화하지 않는 대신, 전체 구성을 확장하고 '셸' 리소스를 만듭니다. 이렇게 하면 배포 변경사항을 커밋하기 전에 확인할 수 있습니다.
|
|
❑
특정 리소스의 API 메서드를 확인하여 업데이트 수행에 따른 영향을 파악합니다. Deployment Manager가 각 업데이트를 적용하는 방법을 제어할 수 있도록 배포를 업데이트할 때 업데이트 정책을 설정합니다.
|
|
❑
리소스에 라벨을 사용합니다. 정의하려는 리소스가 라벨을 지원할 경우, 이를 사용해서 리소스에 라벨을 지정합니다. 라벨은 서로 다른 배포에 속하는 리소스를 분류하는 데 유용하며 리소스가 프로덕션 또는 테스트 환경을 지원하는지 여부와 같이 리소스의 가능한 상태를 구분하기 위한 방법도 제공합니다.
|
배포 크기 관리
Deployment Manager는 할당량 한도에 따라 다수의 리소스에서 작동할 수 있습니다. 배포를 생성, 업데이트, 삭제하는 데 소요되는 시간을 줄이고 싶다면 각 개별 배포 내의 리소스 수를 줄일 수 있습니다.
|
❑
리소스 그룹이 그룹의 어떤 외부 리소스에도 의존하지 않는 경우 리소스 그룹을 별도의 배포로 이동할 수 있습니다. 예를 들어 배포에 여러 템플릿이 포함된 경우 각 템플릿을 별도의 배포로 패키징할 수 있습니다.
|
|
❑
구성에서 불필요한 리소스를 삭제합니다. 이후 리소스가 더 필요한 경우 해당 시점에 배포에 리소스를 추가할 수 있습니다.
|
|
❑
선택적으로 배포를 1000개 이하의 리소스로 제한합니다.
|
권한
기본적으로 Deployment Manager는 Google API 서비스 계정의 사용자 인증 정보를 사용하여 다른 API를 인증합니다. Google API 서비스 계정은 자동으로 내부 Google 프로세스를 실행할 수 있도록 특별히 설계되었습니다.
다른 사용자에게 Deployment Manager 프로젝트에 대한 액세스 권한을 부여하려는 경우에는 사용자에게 Deployment Manager를 사용할 수 있는 적합한 권한이 포함된 IAM 역할을 부여해야 합니다. 사전 정의된 여러 가지 IAM 역할을 사용하여 Deployment Manager를 호출하는 데 필요한 사용자 액세스 권한을 결정할 수 있습니다.
|
❑
IAM 역할을 사용하여 Deployment Manager를 사용할 수 있도록 사용자에게 부여될 권한을 제한합니다.
|
|
❑
사용자가 Deployment Manager에서 생성된 리소스에 액세스할 수 있도록 하려면 리소스 사용에 필요한 역할을 사용자에게 부여하지만 리소스를 직접 배포할 수 있는 권한을 부여하지 않습니다.
|
|
❑
소유자 역할을 부여받은 주 구성원은 IAM 정책을 수정할 수 있습니다. 정책에는 민감한 액세스 제어 데이터가 포함되기 때문에 해당 주 구성원이 IAM 정책을 관리해야 할 적절한 목적이 있는 경우에만 소유자 역할을 부여하세요. 최소한의 사용자 집합만 이를 관리하도록 하면 수행해야 하는 감사를 단순화할 수 있습니다.
|
|
❑
Deployment Manager는 Google API 서비스 계정을 사용하여 리소스를 만들고 관리합니다. Deployment Manager를 사용하여 커스텀 IAM 역할과 같은 중요 리소스를 관리하려면 기본 Google API 서비스 계정에 추가 IAM 역할을 할당해야 합니다. 예를 들어 Deployment Manager를 사용하여 커스텀 IAM 역할을 만들고 관리하려면 Google API 서비스 계정에 역할 관리자 역할을 추가해야 합니다.
Google API 서비스 계정에 대한 개요는 Google 관리형 서비스 계정을 참조하세요. 서비스 계정에 역할을 지정하는 단계는 서비스 계정에 역할 부여를 참조하세요. |
자동화
프로젝트 내에 포함된 리소스 생성 자동화와 함께 프로젝트 생성 자동화를 고려하세요. 이렇게 하면 프로젝트 프로비저닝에 대해 코드로서의 인프라 방식을 채택할 수 있습니다. 이 방식은 다음과 같은 여러 이점을 제공합니다.
- Google Cloud 리소스에 대한 액세스 권한이 필요한 팀에 프로젝트를 제공할 때 회사 요구사항을 적용할 수 있습니다.
- 쉽고 빠르게 프로비저닝할 수 있는 일련의 미리 정의된 프로젝트 환경을 제공할 수 있습니다.
- 버전 제어를 사용하여 기본 프로젝트 구성을 관리할 수 있습니다.
- 재현 가능하고 일관적인 프로젝트 구성을 배포할 수 있습니다.
- 자동화된 프로비저닝 프로세스에 프로젝트 만들기를 포함할 수 있습니다.
|
❑
GitHub에서 제공되는 템플릿을 시작점으로 사용하여 프로젝트 만들기를 자동화할 수 있습니다.
|
지속적 통합(CI)/지속적 배포(CD)
CI/CD 파이프라인의 일부로 Deployment Manager를 사용합니다.
|
❑
전체 테스트 및 QA 프로젝트를 만들고 삭제하기 위한 목적으로 CI/CD 파이프라인을 사용하지 마세요.
|
|
❑
Deployment Manager를 사용하면 프로젝트 및 네트워크 구성의 스테이트풀(Stateful) 부분을 만들고 초기 설정 중에 CI/CD 프로세스 외부에서 배포할 수 있습니다. 테스트가 완료된 후에는 파이프라인의 일부로 배포된 스테이트리스(Stateless) 리소스만 포함된 배포를 삭제할 수 있습니다.
|
|
❑
CI/CD 프로세스 중에 개별 구성을 사용하여 테스트 및 QA 프로젝트에 리소스를 배포합니다. 그런 다음 테스트를 완료한 후 Deployment Manager를 사용하여 테스트 및 QA 프로젝트에서 리소스를 삭제할 수 있습니다.
|
| 배포를 테스트합니다. 리소스 프로비저닝을 CI/CD 파이프라인에 포함할 수 있기 때문에 Deployment Manager에서는 프로젝트 구성을 손쉽게 테스트할 수 있는 코드로 취급하고, 현재 프로덕션 환경 또는 변경사항이 적용된 현재 환경의 일관된 복사본을 손쉽게 테스트하고 재현할 수 있습니다. |
|
❑
버전 제어를 사용합니다. 배포 개발 프로세스 중에 버전 제어 시스템을 사용하면 다음과 같은 이점이 있습니다.
|