Deployment Manager 사용 권장사항

이 페이지에서는 Deployment Manager를 사용한 배포 만들기의 권장사항을 설명합니다. 이 페이지는 Deployment Manager에 익숙한 사용자를 대상으로 작성되었으며, Deployment Manager 사용 방법을 설명하지 않습니다.

Deployment Manager를 처음 사용하는 경우에는 대신 빠른 시작을 시작하세요.

리소스 관리

배포 중에 리소스를 만든 후 리소스를 수정해야 할 경우 Deployment Manager를 사용합니다. Cloud Console 또는 gcloud 등에서 Deployment Manager를 사용하지 않고 리소스를 수정한 경우 원래 배포의 리소스를 수정하려고 하면 오류가 발생할 수 있습니다.

리소스를 삭제하지 않고 배포에서 리소스를 삭제하려면 다음 단계를 따르세요.

  1. 배포 구성에서 리소스의 정의를 삭제합니다.
  2. 배포를 업데이트하고 `gcloud` 명령어에 --delete-policy ABANDON을 추가합니다. 그러면 배포와 리소스의 연결이 해제되므로 Cloud Console 또는 gcloud를 사용하여 리소스를 수정할 수 있습니다.
배포에 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 옵션 및 ipAllocationPolicy 옵션을 설정합니다.


     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true
    

GKE를 사용하여 비공개 클러스터를 만들 때의 요구사항과 추가 고려 사항은 비공개 클러스터 설정을 참조하세요.

템플릿 빌드

템플릿을 빠르게 정의하려면 Cloud Foundation Toolkit 프로젝트에 있는 프로덕션에 즉시 사용할 수 있는 샘플 템플릿을 사용하는 것이 좋습니다.
여러 환경을 만들어야 하는 경우와 같이 복잡한 인프라 요구사항이 있으면 규모에 맞게 Deployment Manager 사용 가이드와 샘플을 참조하세요.
Python을 사용하여 템플릿을 빌드합니다. Python 또는 Jinja2를 사용하여 템플릿을 만들 수 있습니다. 시작하기에는 Jinja가 더 쉽지만 여러 환경에 많은 리소스가 분산되어 있는 복잡한 배포에는 Python이 더 유연합니다.
유형 하나만 사용하도록 구성 파일(YAML 파일)을 구성하고 최상위 템플릿을 이러한 유형으로 사용하여 다른 모든 템플릿을 호출합니다. 이 방법을 사용하면 템플릿 집합을 복합 유형으로 쉽게 변경할 수 있습니다.
스키마 파일을 사용합니다. 스키마는 구성 파일이 특정 템플릿을 사용하기 위해 따라야 하는 규칙 집합을 정의합니다. 스키마를 정의하고 다른 사람이 스키마에 정의된 요구사항을 검토하도록 하면 사용자가 해당 템플릿에 설정할 수 있거나 필요한 속성이 무엇인지 쉽게 이해할 수 있습니다. 이렇게 하면 사용자가 템플릿을 자세히 조사할 필요 없이 구성을 사용할 수 있습니다. 최소한 최상위 템플릿에 대한 스키마 파일은 정의해야 합니다.
템플릿 속성출력을 사용합니다. 속성 및 출력을 사용하면 영역, 머신 크기, 머신 수, 애플리케이션 상태(테스트, 프로덕션, 스테이징)와 같은 변수를 템플릿에 전달하고 IP 주소 및 selfLink와 같은 출력 값을 다시 VM 인스턴스로 가져올 수 있습니다. 속성 및 출력은 기본 템플릿을 수정하지 않고도 재사용할 수 있도록 템플릿 유연성을 높여줍니다.
기본 구성 파일로 가져오는 개별 템플릿 파일을 사용합니다. 이렇게 하면 구성 작업을 보다 쉽게 관리할 수 있습니다.
구성을 논리적 단위로 세분화합니다. 예를 들어 데이터베이스 및 버킷과 같은 상태 저장 서비스에 대한 구성과 프런트엔드 인스턴스와 같은 보다 일시적인 서비스에 대한 구성을 개별적으로 만듭니다.
참조를 사용합니다. 참조는 리소스의 selfLink, IP 주소 또는 시스템에서 생성된 ID와 같이 리소스가 생성되기 전까지 정의되지 않은 값에 사용됩니다. 참조를 사용하지 않으면 Deployment Manager가 모든 리소스를 동시에 만들므로 종속 리소스가 올바른 순서로 생성된다고 보장할 수 없습니다. 참조를 사용하여 리소스 생성 순서를 적용할 수 있습니다.
배포 미리보기를 통해 업데이트가 배포에 영향을 주는 방식을 평가합니다. Deployment Manager는 개발자가 구성을 미리볼 때 실제 리소스를 인스턴스화하지 않는 대신, 전체 구성을 확장하고 '셸' 리소스를 만듭니다. 이렇게 하면 배포 변경사항을 커밋하기 전에 확인할 수 있습니다.
특정 리소스의 API 메서드를 확인하여 업데이트 수행에 따른 영향을 파악합니다. Deployment Manage가 각 업데이트를 적용하는 방법을 제어할 수 있도록 배포를 업데이트할 때 업데이트 정책을 설정합니다.
리소스에 라벨을 사용합니다. 정의하려는 리소스가 라벨을 지원할 경우, 이를 사용해서 리소스에 라벨을 지정합니다. 라벨은 서로 다른 배포에 속하는 리소스를 분류하는 데 도움이 되며, 리소스가 프로덕션 또는 테스트 환경을 지원하는지 여부와 같이 리소스에 가능한 상태를 구분하기 위한 방법도 제공합니다.

권한

기본적으로 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 파이프라인을 사용하지 마세요.
  • 추가 비용이 발생할 수 있는 VM 인스턴스 또는 리소스를 삭제하도록 선택할 수도 있지만, 이러한 리소스를 삭제하면 빌드 파이프라인을 완성하는 데 걸리는 시간에 부정적인 영향을 줄 수 있으므로, 다시 만드는 데 시간이 오래 걸릴 수 있는 재사용 가능한 애셋은 그대로 두는 것을 고려할 수 있습니다. 네트워크, 서브넷, 방화벽 규칙을 설정하는 데에는 비용이 들지 않습니다.
  • 프로젝트를 삭제할 때는 프로젝트가 완전히 삭제될 때까지 며칠 동안 프로젝트 할당량에 포함된 상태로 유지된다는 것에 주의하세요. 이것은 또한 프로젝트 이름을 재사용할 수 없다는 의미입니다.
  • Deployment Manager를 사용하면 리소스 할당량을 초과하지 않도록 프로젝트에서 리소스를 쉽게 삭제할 수 있습니다.
Deployment Manager를 사용하면 프로젝트 및 네트워크 구성의 스테이트풀(Stateful) 부분을 만들고 초기 설정 중에 CI/CD 프로세스 외부에서 배포할 수 있습니다. 테스트가 완료된 후에는 파이프라인의 일부로 배포된 상태 비추적 리소스만 포함된 배포를 삭제할 수 있습니다.
CI/CD 프로세스 중에 개별 구성을 사용하여 테스트 및 QA 프로젝트에 리소스를 배포합니다. 그런 다음 테스트를 완료한 후 Deployment Manager를 사용해서 테스트 및 QA 프로젝트에서 리소스를 삭제할 수 있습니다.
배포를 테스트합니다. 리소스 프로비저닝을 CI/CD 파이프라인에 포함할 수 있기 때문에 Deployment Manager에서는 프로젝트 구성을 코드로 취급하여, 현재 프로덕션 환경 또는 테스트에 변경사항이 적용된 현재 환경의 일관된 복사본을 쉽게 재현할 수 있습니다.
버전 제어를 사용합니다. 배포 개발 프로세스 중에 버전 제어 시스템을 사용하면 다음과 같은 이점이 있습니다.
  • 이전의 문제가 없는 구성으로 대체합니다.
  • 변경사항에 대한 감사 추적을 제공합니다.
  • 구성을 지속적 배포 시스템의 일부로 사용