구성 검증

이 튜토리얼에서는 Google Kubernetes Engine (GKE)Enterprise 버전 클러스터를 사용할 때 Cloud Build를 사용하여 구성을 검증하는 방법을 설명합니다. 동일한 설정이 최소한의 변경으로 CircleCI와 같은 다른 컨테이너 기반 CI/CD 시스템에서도 작동합니다.

nomos vet 명령어를 실행하여 구성의 유효성을 확인하는 것 외에 CI/CD 파이프라인의 구성 변경사항을 검증하는 것을 권장합니다.

목표

구성 동기화가 저장소의 구성에 nomos vet를 사용하도록 지시하는 Cloud Build 구성 파일을 만듭니다.
개발 브랜치가 변경될 때마다 구성이 확인되도록 Cloud Build 트리거를 만듭니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

구성 동기화(GKE Enterprise 일부)
Cloud Build

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

Cloud Build API 사용 설정

API 사용 설정

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

Cloud Build API 사용 설정

API 사용 설정

구성 동기화 요구사항을 충족하는 GKE Enterprise 클러스터를 만들거나 이에 대한 액세스 권한을 얻습니다. 이러한 클러스터를 만드는 방법에 대한 자세한 내용은 구성 동기화 시작하기를 참조하세요.

Cloud Build 서비스 계정 권한 부여

GKE Enterprise 클러스터에 대한 액세스 권한을 Cloud Build 서비스 계정에 부여

gcloud

Cloud Build 서비스 계정에 Kubernetes Engine Developer 역할을 추가하려면 다음 명령어를 실행합니다.

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUM=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

콘솔

Google Cloud Console에서 IAM 페이지를 엽니다.

IAM 페이지로 이동
구성원 열에서 Cloud Build 서비스 계정이 있는 행을 찾습니다.
```
PROJECT_NUMBER@cloudbuild.gserviceaccount.com
```
이 행에서 주 구성원 수정을 클릭합니다.
다른 역할 추가를 클릭합니다.
역할 선택 목록에서 Kubernetes Engine Developer를 선택한 후 저장을 클릭합니다.

Cloud Build 구성 만들기

Cloud Build 구성 파일을 만들고 구성 파일이 있는 저장소의 루트 디렉터리에 저장합니다(예: my-repo/cloudbuild.yaml).

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/config-management-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

다음을 바꿉니다.

ZONE: 클러스터가 실행되는 영역입니다.
CLUSTER_NAME: 클러스터 이름입니다.
POLICY_DIR: 동기화할 저장소의 최상위 수준을 나타내는 Git 저장소 내의 경로입니다.

이 구성은 3단계로 진행됩니다.

kubectl config current-context를 실행하여 my-cluster GKE 클러스터에 인증하는 데 필요한 kubeconfig 파일을 생성하세요. 루트 사용자는 제한된 권한으로 이 파일을 생성합니다.
이 파일을 읽을 수 있도록 다음 단계에서 chmod 444 /kube/config를 실행합니다.
/workspace에서 자동으로 클론되는 Git 저장소에서 nomos vet을 실행합니다. 구조화되지 않은 저장소를 사용하는 경우 대신 nomos vet --source-format=unstructured를 실행합니다.

빌드 트리거 만들기

다음 예시에서는 Cloud Source Repositories 저장소의 마스터 브랜치에 커밋할 때마다 실행되는 트리거를 만듭니다.

Google Cloud 콘솔에서 트리거 페이지를 엽니다.

트리거 페이지로 이동
저장소 연결을 클릭합니다.
GitHub(미러링됨)를 선택한 후 계속을 클릭합니다.
저장소를 선택한 후 저장소 연결을 클릭합니다.
트리거 추가를 클릭합니다.
다음 표에 설명된 각 필드에 해당 항목을 입력하거나 선택합니다.

필드 항목

이벤트 브랜치로 푸시

브랜치 ^master$

구성 Cloud Build 구성 파일(YAML 또는 JSON)

Cloud Build 구성 파일 위치 / cloudbuild.yaml
만들기를 클릭하여 빌드 트리거를 저장합니다.

필드	항목
이벤트	브랜치로 푸시
브랜치	^master$
구성	Cloud Build 구성 파일(YAML 또는 JSON)
Cloud Build 구성 파일 위치	/ cloudbuild.yaml

빌드 트리거 테스트

트리거를 실행하여 설정을 수동으로 테스트합니다.

Google Cloud 콘솔에서 트리거 페이지를 엽니다.

트리거 페이지로 이동
만든 트리거를 찾은 후 트리거 실행을 클릭합니다.

'마스터 브랜치에서 시작된 빌드' 메시지가 나타납니다.
표시를 클릭합니다.

올바르게 설정된 경우 Cloud Build 단계가 녹색으로 나타납니다.

잘못된 Cloud Build 구성

Cloud Build 구성 파일이 잘못되면 트리거를 실행할 수 없습니다.

이를 테스트하려면 저장소의 Cloud Build 구성을 다음 파일로 업데이트합니다. 6번째 줄에 잘못된 들여쓰기 간격이 있습니다.

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
  path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/nomos-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

6번째 줄의 path:가 올바르게 들여쓰기되지 않았으므로 트리거를 수동으로 다시 실행하면 다음과 같은 오류 메시지가 표시됩니다.

Failed to trigger build: failed unmarshalling build config cloudbuild.yaml:
unknown field "path" in cloudbuild_go_proto.BuildStep.

이 구성을 수정하려면 6번째 줄의 path:를 5번째 줄의 name:과 같은 수준으로 들여쓰기합니다. Cloud Build 구성 파일 구조에 대한 자세한 내용은 기본 Cloud Build 구성 만들기를 참조하세요.

삭제

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 프로젝트를 삭제합니다.

gcloud projects delete PROJECT_ID

개별 리소스 삭제

개별 리소스를 삭제하려면 다음 단계를 완료합니다.

Cloud Build 구성 파일을 삭제합니다.
만든 Cloud Build 트리거를 삭제합니다.
이 튜토리얼에서 사용한 클러스터를 삭제합니다.

다음 단계

Cloud Build 알아보기
구성 동기화를 일시적으로 중지