지속적 통합 파이프라인에서 회사 정책에 따라 앱 유효성 검사

조직에서 Anthos Config Management와 정책 컨트롤러를 사용하여 Anthos 클러스터에서 정책을 관리하는 경우 지속적 통합(CI) 파이프라인에서 앱의 배포 구성 유효성을 검사할 수 있습니다. 이 가이드에서는 이 결과를 얻는 방법을 보여줍니다. 이 기능은 앱의 CI 파이프라인을 빌드하는 개발자이거나 여러 앱 팀에 CI 파이프라인 템플릿을 빌드하는 플랫폼 엔지니어에게 유용합니다.

정책은 조직의 보안과 규정 준수에서 중요한 부분입니다. Anthos Config Management에 속하는 정책 컨트롤러를 사용하면 조직이 모든 클러스터의 정책을 중앙에서 선언적으로 관리할 수 있습니다. 개발자는 이러한 정책의 중앙 집중식 선언적 특성을 활용할 수 있습니다. 개발 워크플로에서 이러한 특성을 사용하여 가능한 한 빨리 이러한 정책에 따라 앱 유효성을 검사할 수 있습니다. 대신 배포 중에 CI 파이프라인의 정책 위반을 학습하면 두 가지 주요 이점을 활용할 수 있습니다. 이를 통해 보안을 유지한 상태로 전환힐 수 있고 피드백 루프가 강화되어 위반사항을 수정하는 데 필요한 시간과 비용을 줄일 수 있습니다.

Anthos Config Management 및 정책 컨트롤러를 관리하고 특정 앱이 아닌 CI 파이프라인을 빌드하려면 CI 파이프라인에서 정책 컨트롤러 사용을 참조하세요.

이 가이드에서는 Cloud Build를 CI 도구로 사용하고 데모용 정책이 포함된 샘플 GitHub 저장소를 사용합니다.

리소스

이 가이드에서는 Kubernetes 생태계의 여러 도구를 사용합니다. 이 섹션에서는 이러한 도구에는 무엇이 있는지, 서로 어떻게 상호작용하는지, 다른 도구로 바꿀 수 있는지 여부를 설명합니다. 이 가이드에서 사용하는 도구는 다음과 같습니다.

  • Google Cloud 제정책 컨트롤러: 정책 컨트롤러는 Anthos Config Management에 속하는 Google Cloud 제품으로, 오픈소스 프로젝트인 Open Policy Agent - Gatekeeper를 기반으로 합니다. 정책 컨트롤러는 Kubernetes 클러스터에서 생성된 객체에 대한 정책을 적용합니다(예: 특정 옵션의 사용 방지 또는 특정 라벨 사용 적용). 이러한 정책을 제약조건이라고 합니다. 제약조건은 Kubernetes 커스텀 리소스로 정의됩니다. 구성 동기화(독립형 제품 및 Anthos Config Management의 일부로 사용 가능)를 사용하면 Git 저장소에서 이러한 제약조건을 선언하고 기존 개발 워크플로를 정책 관리 프로세스에서 적용할 수 있습니다. 구현에 정책 컨트롤러 대신 Open Policy Agent - Gatekeeper를 사용할 수 있습니다.

  • GitHub: 이 가이드에서는 GitHub를 사용하여 Git 저장소를 호스팅합니다. 하나는 샘플 앱용이고 다른 하나는 Anthos Config Management(정책 컨트롤러의 제약조건 포함)용입니다. 편의상 두 저장소는 단일 Git 저장소의 서로 다른 폴더 두 개입니다. 하지만 실제로는 서로 다른 저장소입니다. 모든 Git 솔루션을 사용할 수 있습니다.

  • Cloud Build: Cloud Build는 Google Cloud의 CI 솔루션입니다. 이 가이드에서는 유효성 검사 테스트를 실행하는 데 사용합니다. 구현 세부정보는 CI 시스템 간에 다를 수 있지만 이 가이드에 설명된 개념은 모든 컨테이너 기반 CI 시스템에서 사용될 수 있습니다.

  • Kustomize: Kustomize는 Kubernetes 구성에 사용되는 맞춤설정 도구입니다. '기본' 구성을 가져오고 맞춤설정을 적용하면 작동합니다. Kubernetes 구성에 대한 DRY(반복 금지) 방식을 사용할 수 있습니다. Kustomize를 사용하면 기본 구성의 모든 환경에 공통적인 요소를 유지하고 환경별로 맞춤설정을 만들 수 있습니다. 이 가이드에서는 Kustomize 구성을 앱 저장소에 보존하며 CI 파이프라인에서 구성을 '빌드'(즉, 맞춤설정 적용)합니다. 이 가이드에서 설명하는 개념을 클러스터에 적용할 수 있는 Kubernetes 구성을 생성하는 모든 도구(예: helm template 명령어)와 함께 사용할 수 있습니다.

  • Kpt: Kpt는 Kubernetes 구성의 워크플로를 빌드하는 도구입니다. kpt를 사용하면 Kubernetes 구성을 가져오기, 표시, 맞춤설정, 업데이트, 유효성 검사, 적용할 수 있습니다. Git 및 YAML 파일과 호환되므로 Kubernetes 생태계의 기존 도구 대부분과 호환됩니다. 이 가이드에서는 CI 파이프라인에서 kpt를 사용하여 Anthos Config Management 저장소에서 제약조건을 가져오고 이러한 제약 조건에 대해 Kubernetes 구성의 유효성을 검사합니다.

파이프라인

이 가이드에서 사용하는 CI 파이프라인은 아래 다이어그램에 나와 있습니다. 이 파이프라인은 Cloud Build에서 실행되며 명령어는 샘플 앱 저장소의 복사본이 포함된 디렉터리에서 실행됩니다. kustomize를 사용하여 최종 Kubernetes 구성을 생성하면 파이프라인이 시작합니다. 그런 다음 kpt를 사용하여 Anthos Config Management 저장소에서 유효성을 검사할 제약조건을 가져옵니다. 마지막으로 kpt를 사용하여 이러한 제약조건에 대해 Kubernetes 구성의 유효성을 검사합니다. 이 마지막 단계를 수행하려면 이 유효성 검사를 수행하는 gatekeeper-validate라는 특정 구성 함수를 사용합니다. 이 가이드에서는 CI 파이프라인을 수동으로 트리거하지만 실제로는 개발자가 Git 저장소에 git push를 실행한 후에 실행되도록 구성합니다.

정책 컨트롤러용 CI 파이프라인

목표

  • Cloud Build로 샘플 앱의 CI 파이프라인을 실행합니다.
  • 정책 위반으로 인해 파이프라인이 실패했는지 확인합니다.
  • 정책을 준수하도록 샘플 앱 저장소를 수정합니다.
  • CI 파이프라인을 성공적으로 다시 실행합니다.

비용

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

  • Cloud 빌드

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용합니다.

이 가이드를 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않도록 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

  1. Cloud 프로젝트를 선택하거나 만듭니다.

    리소스 관리 페이지로 이동

  2. 프로젝트에 결제를 사용 설정합니다.

    결제 사용 설정

  3. Cloud Shell을 열고 이 가이드에 나열된 명령어를 실행합니다.

    Cloud Shell로 이동

  4. gcloud config get-value project 명령어가 방금 선택한 프로젝트의 ID를 반환하지 않으면 Cloud Shell이 프로젝트를 사용하도록 구성합니다.

    gcloud config set project PROJECT_ID
    
  5. Cloud Shell에서 필요한 Cloud Build API를 사용 설정합니다.

    gcloud services enable cloudbuild.googleapis.com
    

샘플 앱 구성 유효성 검사

이 섹션에서는 Google에서 제공하는 샘플 앱 저장소에 사용되는 Cloud Build로 CI 파이프라인을 실행합니다. 이 파이프라인은 샘플 Anthos Config Management 저장소에서 사용 가능한 제약조건을 기준으로 샘플 앱 저장소에서 사용할 수 있는 Kubernetes 구성의 유효성을 검사합니다.

  1. Cloud Shell에서 샘플 앱 저장소를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/csp-config-management.git
    
  2. Cloud Build로 CI 파이프라인을 실행합니다. 빌드 로그가 Cloud Shell에 직접 표시됩니다.

    cd csp-config-management/ci-app/app-repo
    gcloud builds submit .
    

    실행하는 파이프라인은 다음 파일에 정의되어 있습니다.

    steps:
    - id: 'Prepare config'
      # This step builds the final manifests for the app
      # using kustomize and the configuration files
      # available in the repository.
      name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
      entrypoint: '/bin/sh'
      args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
    - id: 'Download policies'
      # This step fetches the policies from the Anthos Config Management repository
      # and consolidates every resource in a single file.
      name: 'gcr.io/kpt-dev/kpt'
      entrypoint: '/bin/sh'
      args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/csp-config-management.git/ci-app/acm-repo/cluster@1.0.0 constraints
                      && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
    - id: 'Validate against policies'
      # This step validates that all resources comply with all policies.
      name: 'gcr.io/config-management-release/policy-controller-validate'
      args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']
  3. 몇 분 후에 파이프라인이 실패하여 다음 오류가 표시되는지 관찰합니다.

    [...]
    Step #2 - "Validate against policies": gcr.io/config-management-release/policy-controller-validate:latest
    Step #2 - "Validate against policies": Error: Found 1 violations:
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": [1] Deployment objects should have an 'owner' label indicating who created them.
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": name: "nginx-deployment"
    Step #2 - "Validate against policies": path: prod.yaml
    [...]
    

    구성에서 위반한 제약조건은 다음 파일에 정의되어 있습니다. K8sRequiredLabels라는 Kubernetes 커스텀 리소스입니다.

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: deployment-must-have-owner
    spec:
      match:
        kinds:
          - apiGroups: ["apps"]
            kinds: ["Deployment"]
      parameters:
        labels:
          - key: "owner"
        message: "Deployment objects should have an 'owner' label indicating who created them."

    이 제약조건에 해당하는 제약조건 템플릿은 GitHub의 이 파일을 참조하세요.

  4. 전체 Kubernetes 구성을 직접 빌드하고 owner 라벨이 실제로 없는지 관찰합니다. 구성을 빌드하려면 다음을 실행합니다.

    kubectl kustomize config/prod
    

회사 정책을 준수하도록 앱 수정

이 섹션에서는 Kustomize를 사용하여 정책 위반을 수정합니다.

  1. Cloud Shell에서 commonLabels 섹션을 Kustomization 파일에 추가합니다.

    cat <<EOF >> config/base/kustomization.yaml
    commonLabels:
      owner: myself
    EOF
    
  2. 전체 Kubernetes 구성을 빌드하고 지금 owner 라벨이 있는지 관찰합니다.

    kubectl kustomize config/prod
    
  3. Cloud Build로 CI 파이프라인을 다시 실행합니다.

    gcloud builds submit .
    

    이제 파이프라인이 다음과 같이 출력됩니다.

    [...]
    Finished Step #2 - "Validate against policies"
    PUSH
    DONE
    [...]
    

삭제

  1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

    리소스 관리 페이지로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제 를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 다음 종료를 클릭하여 프로젝트를 삭제합니다.

다음 단계