구성 확인

nomos vet을 수동으로 실행하거나 로컬에서 커밋 전 후크로 실행하는 것 외에도 CI/CD 파이프라인의 구성 변경사항을 검증하는 것이 좋습니다. 이 가이드에서는 GKE 클러스터를 사용할 때 Cloud Build로 구성을 검증하는 방법을 설명합니다. 동일한 설정이 최소한의 변경으로 CircleCI와 같은 다른 컨테이너 기반 CI/CD 시스템에서도 작동합니다.

시작하기 전에

이 가이드를 따르려면 먼저 Anthos Config Management 빠른 시작을 완료해야 합니다.

Cloud Build 구성

Cloud Build API 사용 설정

gcloud

Cloud Build API를 사용 설정하려면 다음 명령어를 실행합니다.

gcloud services enable cloudbuild.googleapis.com

Console

Cloud Build API 사용 설정

GKE 클러스터에 대한 액세스 권한을 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

Console

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

    IAM 페이지로 이동

  2. 구성원 열에서 Cloud Build 서비스 계정을 찾습니다.

    [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com

  3. 해당 행의 연필 아이콘을 클릭합니다.

  4. 다른 역할 추가를 클릭하고 Kubernetes Engine 개발자를 선택한 후 저장을 클릭합니다.

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단계로 진행됩니다.

  1. kubectl config current-context를 실행하여 my-cluster GKE 클러스터에 인증하는 데 필요한 kubeconfig 파일을 생성합니다. 루트 사용자는 제한된 권한으로 이 파일을 생성합니다.
  2. 이 파일을 읽을 수 있도록 다음 단계에서 chmod 444 /kube/config를 실행합니다.
  3. /workspace에서 자동으로 클론되는 Git 저장소에서 nomos vet을 실행합니다.

빌드 트리거 만들기

다음 예시에서는 Cloud Source Repo의 마스터 분기에 커밋할 때마다 실행되는 트리거를 만듭니다. 이전 단계에서 만든 Cloud Build 구성 파일을 사용합니다.

  1. Cloud Console에서 트리거 페이지를 엽니다.

    트리거 페이지로 이동

  2. 저장소 연결을 클릭합니다.

  3. GitHub(미러링됨)를 선택한 후 계속을 클릭합니다.

  4. 저장소를 선택한 후 저장소 연결을 클릭합니다.

  5. 트리거 추가를 클릭합니다.

  6. 다음 표에 설명된 각 필드에 해당 항목을 입력하거나 선택합니다.

    필드 항목
    이벤트 분기로 푸시
    분기 ^master$
    빌드 구성 파일 유형 Cloud Build 구성 파일(YAML 또는 JSON)
    Cloud Build 구성 파일 위치 / cloudbuild.yaml
  7. 만들기를 클릭하여 빌드 트리거를 저장합니다.

빌드 트리거 테스트

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

  1. Cloud Console에서 트리거 페이지를 엽니다.

    트리거 페이지로 이동

  2. 만든 트리거를 찾은 후 트리거 실행을 클릭합니다.

    '마스터 분기에서 시작된 빌드 표시' 메시지가 나타납니다.

  3. 표시를 클릭합니다.

    올바르게 설정된 경우 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 구성 만들기를 참조하세요.

다음 단계