Cloud Build를 통해 주의를 기울이십시오.

여러 프로젝트를 통해 Pipeline을 구성 할 때 권한 설정

전제가 되는 구성

GKE에 애플리케이션 배포
Source code repository와 Cloud Build를 호스팅하는 CICD 프로젝트와 애플리케이션을 호스팅하는 프로젝트(프로덕션, 개발, 스테이징 등 여러 환경이 있다고 가정)이 존재한다

결론

각 프로젝트, 각 서비스 계정에 적절한 역할을 설정해야 함

CICD 프로젝트

Cloud Build 서비스 계정에 필요한 권한

Cloud Build의 Trigger 실행 권한
GCR에 이미지를 푸시할 권한
GKE의 Endpoint에 대해 kubectl apply를 실행할 수 있는 권한

애플리케이션을 호스팅하는 프로젝트

GKE 작업자 노드의 서비스 계정에 필요한 권한

GCR에서 이미지를 풀어 오는 권한
h tps : // c ぉ d. 오, ぇ. 코 m / 고맙다 r 레기 스트리 / 드 cs / 어세이 s

상기를 그림으로 하면 이하가 됩니다.



참고로 Trigger는 Cloud Build의 기본 서비스 계정이어야 합니다.
그러나 각 빌드 단계는 모든 서비스 계정을 지정할 수 있으며 각 단계에 최소 권한을 부여해야 한다는 관점에서 모든 서비스 계정을 사용하는 것이 좋습니다.
h tps : // c ぉ d. 오, ぇ. 코 m / c ぉ d-bui ld / cs / sekurin g-bui lds / 곤푸 쿠레 우세 rs

다음과 같이 Step별로 서비스 계정을 정의할 수 있습니다.

steps:
- name: 'bash'
  args: ['echo', 'Hello world!']
logsBucket: 'LOGS_BUCKET_LOCATION'
serviceAccount: 'projects/PROJECT_NAME/serviceAccounts/SERVICE_ACCOUNT'

모든 버전을 연동하는 방법

몇 가지 방법이 있다고 생각하지만 git tag를 사용한 예를 설명합니다.
자세한 내용은 아래 자습서를 참조하십시오.
h tps : // c ぉ d. 오, ぇ. 코 m / 쿠베 r 네 s 엔 기네 / 도 cs / 쓰리 아 ls / 기와 ps-c

git tag하고 Push하면 기본 변수 $TAG_NAME에 TAG 정보가 저장됩니다.

사용 가능한 환경 변수는 다음 설명서에 설명되어 있습니다.
htps : // c ぉ d. 오, ぇ. 코 m / c ぉ ㅇ ㅇ ld / ㅇ cs / 곤푸 ㅃ 구린 ㅁ bs 치츠치온 s

$ git tag -a 1.0.3 -m 'test'
$ git push google 1.0.3
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 148 bytes | 148.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://source.developers.google.com/p/xxx/r/hello-cloudbuild-app
 * [new tag]         1.0.3 -> 1.0.3

버전을 Container image 태그로 사용하는 방법

git tag에 지정된 태그 이름이 기본 변수 $TAG_NAME에 저장되므로 cloudbuild.yaml의 build 단계에서 태그를 지정합니다.

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'gcr.io/$PROJECT_ID/hello-cloudbuild:${TAG_NAME}'
  - '.'

GKE에 배포할 때 버전을 지정하는 방법

패턴 1
sed 등을 사용하여 kubernetes 매니페스트 파일을 대체하는 방법이 가능합니다.

# This step generates the new manifest
- name: 'gcr.io/cloud-builders/gcloud'
  id: Generate manifest
  entrypoint: /bin/bash
  args:
  - '-c'
  - |
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_Id}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${TAG_NAME}/g" > kubernetes.yaml;

# This step deploys the new version of our container image
# in the hello-cloudbuild Kubernetes Engine cluster.
- name: 'gcr.io/cloud-builders/kubectl'
  id: Deploy
  args:
  - 'apply'
  - '-f'
  - 'kubernetes.yaml'
  - 'CLOUDSDK_COMPUTE_ZONE=asia-northeast1-a'
  - 'CLOUDSDK_CONTAINER_CLUSTER=cluster-1'
  - 'CLOUDSDK_CORE_PROJECT=xxx'

패턴 2
이미지의 태그를 직접 지정할 수도 있습니다.

    name: 'gcr.io/cloud-builders/kubectl'
    args:
    - 'set'
    - 'image'
    - 'deployment/hello-cloudbuild'
    - 'hello-cloudbuild=gcr.io/$PROJECT_ID/hello-cloudbuild:${TAG_NAME}''

Cloud Build 변수의 문자 조작

다음 Bash 기능을 사용할 수 있습니다.
htps : // c ぉ d. 오, ぇ. 코 m / c ぉ d-bui ld / ㅇ cs / コンフ ぃ ぐりん g ブイ lds / 우세 바 sh an d bin ぢ gs - 스타 _ St ​​링 g_ 오페라 치온 s

$ git tag -a prd-1.0.6 -m 'test'
$ git push google prd-1.0.6
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 433 bytes | 433.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2)
To https://source.developers.google.com/p/xxx/r/hello-cloudbuild-app
 * [new tag]         prd-1.0.6 -> prd-1.0.6

다음은 변수의 시작에서 4자를 삭제합니다. (${TAG:4})

# This step generates the new manifest
- name: 'gcr.io/cloud-builders/gcloud'
  id: Generate manifest
  entrypoint: /bin/bash
  args:
  - '-c'
  - |
     echo "tag name is ${TAG_NAME}";
     TAG=${TAG_NAME};
     echo "tag is ${TAG:4}";
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_Id}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${TAG:4}/g" > kubernetes.yaml;

처음 4자를 삭제했습니다.

Step #3 - "Generate manifest": tag name is prd-1.0.6
Step #3 - "Generate manifest": tag is 1.0.6

프로덕션 환경에 배포하면 앞에 prd-가 부여된 TAG가 푸시될 때 시작되는 Trigger가 만들어집니다. 실제의 배포로 하고 있는 컨테이너 이미지의 TAG는, 상기와 같이 버젼을 캐릭터 라인 조작으로 꺼내는 것이 가능하게 됩니다.

기본 변수와 사용자 정의 변수에 bash 형식의 문자열 조작을 적용할 수 있습니다.


라고 쓰고 있지만, 디폴트 변수는 치환할 수 없었다. .

     echo "tag name is ${TAG_NAME}";
     TAG=${TAG_NAME};
     echo "tag is ${TAG:4}";
     echo ${TAG_NAME:4}
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_Id}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${TAG_NAME}/g" > kubernetes.yaml;
     cat kubernetes.yaml

로그의 네 번째 행과 같이 변수의 값이 삭제됩니다.

Step #3 - "Generate manifest": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #3 - "Generate manifest": tag name is prd-1.0.7
Step #3 - "Generate manifest": tag is 1.0.7
Step #3 - "Generate manifest": 
Step #3 - "Generate manifest": # Copyright 2018 Google LLC

yaml 파일을 어디까지 나눌 수 있습니까?

앱과 같은 리포지토리로 관리하는 패턴과 앱과 다른 리포지토리에서 매니페스트 파일을 정리하여 하나의 리포지토리로 관리하는 패턴이 있습니다만,
완전히 개인의 감상입니다만, 앱과 같은 리포지토리로 관리하는 패턴은, 마이크로서비스적으로 향하고, 따로 관리하는 패턴은, 일원 관리할 수 있으므로 앱과 인프라 담당으로 나누어져 있는 조직, gitops등에 향해 있습니다.
또, Pipeline의 관점이라면 배포 자체는, docker build가 불필요하므로 매니페스트 파일만으로 완결할 수 있으므로, 나누고 있으면, tag를 사용해 배포처를 바꾸는 것이 보다 간단하게 구현할 수 있을 것 같다.