애플리케이션 배포

이 페이지에서는 Cloud Deploy를 사용하여 애플리케이션을 원하는 대상 런타임 환경으로 가져오는 방법을 설명합니다. 이 작업을 수행하기 전에 배포 파이프라인 및 대상을 만들어야 합니다.

시작하기 전에

이 섹션에서는 Cloud Deploy를 사용하여 애플리케이션을 배포하기 전에 준비해야 할 사항을 설명합니다.

실행 서비스 계정에 필요한 IAM 역할 및 권한이 있는지 확인합니다.
배포 파이프라인 및 대상을 만듭니다.

Cloud Deploy는 Google Kubernetes Engine, Cloud Run, GKE Enterprise 클러스터에 배포할 수 있습니다. 이들 중 배포하려는 대상에 따라 대상 구성이 달라집니다.
컨테이너 이미지 및 매니페스트를 준비합니다.

배포할 컨테이너 이미지가 하나 이상 있어야 하고 GKE에 배포할 하나 이상의 Kubernetes 매니페스트 또는 Cloud Run에 배포할 서비스 YAML 파일이 필요합니다.

이미지를 빌드하고 배치하려면 지속적 통합 파이프라인 또는 다른 프로세스가 필요합니다. CI 도구는 Cloud Build, Jenkins 또는 Cloud Deploy 배포 파이프라인에 제공할 수 있는 컨테이너 이미지를 생성하는 모든 도구일 수 있습니다.
skaffold.yaml 구성 파일이 있어야 합니다.

Cloud Deploy는 skaffold render를 호출하고, 이 파일을 사용하여 Kubernetes 매니페스트를 렌더링하고 skaffold apply를 호출하여 대상에 배포합니다. 이렇게 하려면 Skaffold에 최소 skaffold.yaml이 필요합니다. 다음 두 가지 방법 중 하나로 가져올 수 있습니다.
- 직접 만듭니다.
  
  skaffold.yaml 파일은 이 예시와 같이 첫 번째 줄에서 지원되는 Skaffold 버전에 해당하는 네임스페이스를 참조해야 합니다.
```
`apiVersion: skaffold/v4beta7`
```
- 자동으로 생성합니다.
  
  아직 skaffold.yaml 파일이 없으면 Cloud Deploy로 자동으로 생성할 수 있습니다. 이 파일은 Cloud Deploy 온보딩, 학습 또는 데모에 적합하며 프로덕션 워크로드에는 사용해서는 안 됩니다.
자세한 내용은 Cloud Deploy에서 Skaffold 사용을 참고하세요. 또한 Skaffold 및 Cloud Deploy와 함께 Helm, Kustomize, kpt 등의 매니페스트 관리 도구를 사용하는 자세한 방법은 Cloud Deploy에서 매니페스트 관리를 참조하세요.

원하는 런타임 환경에 맞게 Cloud Deploy 설정

Cloud Deploy는 다음 런타임 환경 중 하나에 애플리케이션을 배포할 수 있습니다.

배포 파이프라인을 호출하여 출시 버전 만들기

런타임에 배포하도록 Cloud Deploy를 구성했으면 이제 생성된 배포 파이프라인에 따라 배포되도록 애플리케이션을 제출할 수 있습니다.

일반 지속적 통합(CI) 프로세스를 실행하여 배포 가능한 아티팩트를 만듭니다.
Cloud Deploy를 호출하여 출시 버전을 만들어서 배포 파이프라인을 시작합니다.

Skaffold 구성을 포함하는 디렉터리에서 다음 명령어를 실행합니다.
```
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
```
이 명령어는 디렉터리 및 모든 하위 디렉터리의 전체 콘텐츠에 대한 tar 파일을 만들기 때문에 홈 또는 루트 디렉터리에서 이 명령어를 실행하지 않아야 할 수 있습니다. Skaffold 구성이 포함된 디렉터리에서 명령어를 실행하거나 뒷부분의 설명에 따라 --source= 옵션을 포함합니다.

이 명령어에서

RELEASE_NAME은 출시 버전에 지정할 이름입니다. 이 배포 파이프라인의 모든 출시 버전에서 고유한 이름이어야 합니다.

'$DATE', '$TIME' 또는 둘 모두를 포함하여 동적 출시 버전 이름을 지정할 수 있습니다. 예를 들어 이 명령어를 오후 3시 7분(UTC)에 호출하면 'rel-$TIME'이 rel-1507로 해석됩니다. '$DATE' 및 '$TIME'은 작은따옴표로 묶어야 하며, 시간은 명령어를 호출하는 머신의 UTC 시간이어야 합니다.

PIPELINE_NAME은 대상이 진행되면서 이 출시 버전의 배포를 관리할 배포 파이프라인의 이름입니다. 이 이름은 파이프라인 정의의 name 필드와 일치해야 합니다.

REGION은 출시 버전을 만드는 리전의 이름입니다(예: us-central1). 필수 항목입니다.

이 명령어는 구성이 포함된 tar 파일을 Cloud Storage 버킷에 업로드하고 출시 버전을 만듭니다. 또한 Cloud Deploy는 자동으로 출시를 생성하고 배포 파이프라인에 정의된 첫 번째 대상에 이미지를 배포합니다.

이 명령어에 표시된 매개변수 이외에 다음 옵션 중 하나를 포함할 수 있습니다.

--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

이미지 전체 경로 바꾸기에 대한 이미지 이름 모음입니다.
--build-artifacts=<path/file>

이미지 전체 경로 바꾸기를 나타내기 위해 전달할 수 있는 Skaffold 빌드 아티팩트 출력 파일에 대한 참조입니다.

이러한 두 옵션은 상호 배타적입니다.

또한 다음 플래그 중 하나를 포함하여 Cloud Deploy로 skaffold.yaml 파일을 자동으로 생성할 수 있습니다.

--from-k8s-manifest=K8S_MANIFEST

생성된 Skaffold 구성은 이 플래그를 전달하는 Kubernetes 매니페스트를 기반으로 합니다. 이 플래그를 --skaffold-file 플래그 또는 --source 플래그에 사용하면 오류가 발생합니다. 자세한 내용은 skaffold.yaml 생성을 참조하세요.
--from-run-manifest=RUN_MANIFEST

생성된 Skaffold 구성은 이 플래그를 전달하는 Cloud Run 서비스 YAML을 기반으로 합니다. 이 플래그를 --skaffold-file 플래그 또는 --source 플래그에 사용하면 오류가 발생합니다. 자세한 내용은 skaffold.yaml 생성을 참조하세요.

이러한 두 옵션은 상호 배타적입니다.

또한 tar 파일에 포함하지 않으려는 디렉터리에 파일이 있으면 .gcloudignore 파일을 포함할 수 있습니다.

Google Cloud 콘솔에서 출시 버전 만들기

Google Cloud 콘솔을 사용하여 배포 파이프라인의 출시 버전을 만들 수 있습니다. 이는 Cloud Deploy를 시험해 볼 때는 유용하지만 프로덕션 워크로드에는 적합하지 않습니다.

다음 절차에서는 배포 파이프라인과 하나 이상의 대상을 이미 만들었다고 가정합니다. (Google Cloud 콘솔을 사용하여 배포 파이프라인을 만들 수도 있습니다.)

배포 파이프라인 세부정보 페이지에서 특정 배포 파이프라인에 대해 출시 버전 만들기를 클릭합니다.
컨테이너 선택 필드에 배포할 컨테이너 이미지의 경로를 붙여넣거나 입력합니다. 이 필드에 미리 채워진 기본 컨테이너를 사용하여 평가할 수도 있습니다.

선택을 클릭하여 Artifact Registry 또는 Container Registry에서 컨테이너 이미지를 선택할 수도 있습니다.
출시 이름 필드에 이 출시 버전에 고유한 이름을 입력하거나 제공된 기본 이름을 사용합니다.
출시 이름 필드에 출시 이름을 입력하거나 제공된 기본 이름을 사용합니다.

이 이름은 이 출시 버전의 첫 번째 대상에 출시하는 데 사용됩니다. 후속 대상의 경우 승격 대화상자 또는 gcloud deploy releases promote 명령어에서 출시 이름을 지정할 수 있습니다.
필요에 따라 설명 필드에 이 출시 버전에 대한 설명을 포함합니다.
배포 세부정보에서 GKE 배포 또는 Cloud Run 서비스 이름을 입력하거나 제공된 기본 이름을 사용합니다.

GKE의 경우 Cloud Deploy가 매니페스트를 생성합니다. Cloud Run의 경우 Cloud Deploy는 서비스를 만드는 데 사용된 서비스 정의를 생성합니다.
만들기를 클릭합니다.

Cloud Deploy는 생성된 매니페스트 또는 Cloud Run 서비스 정의와 생성된 skaffold.yaml을 사용하여 출시 버전을 만듭니다.

배포 제한 시간 변경

GKE 및 GKE Enterprise 대상 클러스터에 대한 배포의 경우 Kubernetes가 안정적인 배포를 보고할 때까지 시스템에서 기다리는 시간에 영향을 주는 세 가지 제한 시간이 있습니다.

Cloud Build에서 Cloud Deploy에 대해 수행하는 작업에 1시간의 제한 시간이 있습니다.

실행 환경 구성에서 이 제한 시간을 변경할 수 있습니다.
Skaffold에는 배포 안정화를 기다리는 초 단위 시간인 상태 점검 제한 시간(deploy.statusCheckDeadlineSeconds)이 있습니다.

기본값은 600초(10분)입니다. 이 제한 시간을 사용하려면 deploy.statusCheck를 true로 설정해야 합니다. 기본적으로 설정되어 있습니다. statusCheck가 false이면 상태 점검이 없으며, kubectl apply가 성공적으로 완료된 후 출시가 성공으로 표시됩니다.
Kubernetes 리소스인 kind: Deployment의 경우 Kubernetes가 배포 안정화 보고를 기다리는 시간인 Deployment.spec.progressDeadlineSeconds가 있습니다.

이 제한 시간은 Deployment 리소스에만 적용할 수 있습니다. 처음 두 가지 제한 시간은 다음과 같이 연동합니다.
- Kubernetes에서 Deployment.spec.progressDeadlineSeconds가 설정되지 않은 경우, Skaffold 상태 점검 제한 시간이 기본값인지 아니면 명시적으로 설정되었는지 관계없이 적용됩니다.
- Kubernetes에서 Deployment.spec.progressDeadlineSeconds가 설정된 경우, Skaffold가 자체 상태 점검 제한 시간을 무시하고 Kubernetes 진행 기한이 적용됩니다. 하지만 Kubernetes 제한 시간이 명시적으로 600(10분)으로 설정된 경우, Skaffold는 이를 기본값(설정되지 않음)으로 가정하여 무시하고 Skaffold 제한 시간을 사용합니다(설정된 경우).
- 두 가지 제한 시간 모두 설정되지 않은 경우 Skaffold 기본값인 600(10분)이 제한 시간으로 적용됩니다.
Deployment 이외의 다른 Kubernetes 리소스에도 제한 시간이 있을 수 있지만 안정성 제한 시간에 영향을 주지 않습니다. 이러한 제한 시간이 하나라도 있는 경우 안정성 제한 시간과 충돌하지 않는지 검토하세요.

Skaffold 또는 Cloud Build가 타임아웃되면 GKE 배포가 계속 실행됩니다. Cloud Deploy에서 실패가 표시되지만 GKE 클러스터에서는 여전히 성공하거나 실패할 수 있습니다.

배포 안정성 제한 시간을 변경하려면 다음 단계를 따르세요.

skaffold.yaml에서 deploy.statusCheck가 true로 설정되었는지 확인합니다.

기본값은 true입니다. true이면 Skaffold는 상태 점검에서 배포 안정화를 보고할 때까지 기다리며, 여기에는 다음 단계의 제한 시간 값이 적용됩니다.
skaffold.yaml에서 statusCheckDeadlineSeconds를 기다릴 시간(초)으로 설정합니다.
```
deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...
```
기본값은 600(10분)입니다. Skaffold는 이 시간 동안 배포 안정화를 기다립니다. 배포가 안정화되기 전에 이 시간이 초과되면 배포가 실패합니다.
선택적으로 statusCheckDeadlineSeconds 다음에 tolerateFailuresUntilDeadline: true를 추가할 수 있습니다.

이 설정은 Skaffold에 단일 배포가 실패해도 종료되지 않고 statusCheckDeadlineSeconds가 만료될 때까지 실패를 허용하도록 지시합니다. 이 설정은 안정적인 상태에 도달하기 위해 더 많은 시간(상태 확인 기한까지)이 필요할 수 있는 리소스가 있는 경우에 유용합니다.

예를 들어 Istio 또는 Cloud Service Mesh를 사용하는 경우 다음과 유사한 메시지가 표시되며 배포가 실패할 수 있습니다.
```
error iptables validation failed; workload is not ready for Istio.
When using Istio CNI, this can occur if a pod is scheduled before the node is ready.
```
이 설정은 Skaffold 2.0 이상에서만 작동합니다.
kind: Deployment 리소스의 Kubernetes 매니페스트에서 Deployment.spec.progressDeadlineSeconds를 statusCheckDeadlineSeconds에 설정한 값과 동일하게 설정합니다.