Cloud Monitoring API를 사용하여 Cloud Monitoring 대시보드 자동 관리

이 가이드에서는 Cloud Monitoring API를 사용하여 대시보드를 코드로 처리하는 방법을 설명합니다. Monitoring API를 사용하면 버전 제어 중인 대시보드를 저장하고 Cloud Build를 사용하여 대시보드 생성 및 수정을 자동화할 수 있습니다. 이 문서는 모니터링 인프라를 만들고 유지보수하는 DevOps 엔지니어를 대상으로 합니다.

DevOps 엔지니어는 일반적으로 소프트웨어를 빌드 및 배포하도록 지속적 통합/지속적 배포(CI/CD) 파이프라인을 유지보수합니다. 하지만 모니터링 대시보드와 같은 모니터링 인프라는 파이프라인의 일부가 아인 경우가 많으며 수동으로 업데이트됩니다.

DevOps 엔지니어는 유지보수가 쉬운 일관된 대시보드를 원합니다. 누가 변경했는지, 어떤 대시보드가 변경되었는지 알고 해당 변경사항이 적절한지 확인하고 변경사항을 손쉽게 실행취소하거나 반복할 수 있는 것이 중요합니다. 또한 이러한 대시보드 변경사항을 안정적으로 프로덕션에 푸시하기를 원합니다.

이 가이드에서는 Monitoring API를 사용하여 Monitoring 대시보드 버전을 제어하는 방법을 설명합니다. 버전 제어를 사용하면 누가 대시보드에 어떤 작업을 수행했는지 추적할 수 있으므로 감사 추적을 수행하고 변경사항을 검토 및 롤백할 수 있습니다. 또한 팀이 대시보드를 수동으로 변경할 수 없고 대신 CI/CD 파이프라인을 사용해야 하도록 Monitoring API에 대한 액세스를 제한할 수 있습니다. 액세스를 제한하면 모든 변경사항이 버전 제어를 통과하게 되고 CI/CD 파이프라인만 변경사항을 적용할 수 있으므로 모든 프로젝트에서 대시보드의 일관성이 유지됩니다. Monitoring API에 대한 액세스를 제한하면 검증된 버전 제어 대시보드만 프로덕션으로 푸시할 수 있습니다.

이 가이드에서는 개발자가 Monitoring, Cloud Build, Git에 익숙하고 GitHub 사용자 계정을 가지고 있다고 가정합니다. 이 가이드를 마치면 새 변경사항이 커밋될 때마다 대시보드 업데이트를 프로젝트 여러 개로 푸시하는 파이프라인이 구축됩니다. 그림 1은 Monitoring 대시보드 아키텍처를 보여줍니다.

Monitoring 대시보드 아키텍처를 변경하는 일반적인 워크플로

그림 1. 대시보드를 코드로 처리하는 경우의 Monitoring 대시보드 아키텍처 다이어그램

그림 1은 다음과 같은 Monitoring 대시보드 아키텍처를 변경하는 일반적인 워크플로를 보여줍니다.

  1. 엔지니어가 개발 작업공간에서 대시보드 변경사항을 개발하고 테스트합니다.
  2. 엔지니어가 대시보드 변경사항을 GitHub 저장소로 푸시합니다.
  3. 변경사항이 자동으로 스테이징 작업공간에 배포됩니다.
  4. 동료 엔지니어가 스테이징 작업공간에서 변경사항을 검토하고 승인합니다.
  5. 승인된 변경사항이 자동으로 프로덕션 작업공간에 배포됩니다.

목표

  • 대시보드 버전을 제어하면 다음을 수행할 수 있습니다.
    • 버전 간의 차이점을 검사합니다.
    • 변경사항의 감사 추적을 봅니다.
    • 검토를 마친 변경사항만 배포합니다.
    • 문제가 있는 변경사항을 빠르게 찾아 롤백합니다.
  • 프로덕션에 배포하기 전에 대시보드 변경사항을 테스트합니다.
  • 대시보드를 자동으로 프로덕션에 배포합니다.

이 가이드 정보

이 가이드에서는 GitHub을 사용하여 Git 저장소를 호스팅하지만 Bitbucket 또는 Cloud Source Repositories를 사용해도 무방합니다.

REST API, gRPC API 또는 gcloud 명령줄 도구 통합을 사용하면 Monitoring API에 액세스할 수 있습니다. 이 가이드에서는 gcloud 도구 통합을 사용합니다.

이 가이드에서는 독자가 다음 작업을 담당하는 DevOps 엔지니어라고 가정합니다.

  • 조직의 모든 팀에서 공통의 여러 대시보드를 통해 프로덕션 인프라를 일관되게 볼 수 있도록 합니다.
  • 프로덕션에서 기존 대시보드를 수정하지 않고 계획된 대시보드 변경사항을 검토할 수 있는 워크플로를 제공합니다.
  • 대시보드 변경사항을 자동으로 프로덕션에 배포합니다.

이 가이드에서는 이러한 작업을 수행하는 데 필요한 단계를 설명합니다.

비용

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

  • Compute Engine
  • Monitoring
  • Cloud Build

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

시작하기 전에

프로젝트 만들기

이 가이드에서는 다음과 같은 Google Cloud 프로젝트를 만듭니다.

  • 대시보드의 변경사항을 실험하는 개발 프로젝트
  • 변경사항을 검토하는 스테이징 프로젝트
  • 검토를 마친 대시보드 변경사항을 배포하는 프로덕션 프로젝트

각 프로젝트를 만들려면 다음 단계를 따르세요.

  1. Google Cloud Console에서 Google Cloud 프로젝트를 만듭니다.

    Google Cloud Console로 이동

  2. Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.

  3. Cloud Console에서 Cloud Shell을 활성화합니다.

    Cloud Shell 활성화

    Cloud Shell을 사용하여 이 가이드의 모든 명령어를 실행합니다.

  4. 프로젝트를 사용하도록 Cloud Shell을 구성합니다. PROJECT_ID를 자체 프로젝트 ID로 바꿉니다.

    gcloud config set project PROJECT_ID
    
  5. 필수 Google Cloud APIs를 사용 설정합니다.

    gcloud services enable \
        compute.googleapis.com \
        monitoring.googleapis.com \
        cloudbuild.googleapis.com
    

앞의 단계를 반복하여 스테이징 프로젝트와 프로덕션 프로젝트를 만들고 필요한 API를 사용 설정합니다.

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

gcloud 도구 구성

개발 프로젝트, 스테이징 프로젝트, 프로덕션 프로젝트를 만든 후 다음 단계를 수행하여 구성을 완료합니다.

  1. 이 가이드에서 사용할 프로젝트에서 사용하려는 Compute Engine 리전과 영역의 gcloud 도구 기본값을 설정합니다. 이 가이드에서는 us-central1 리전과 us-central1-a 영역을 사용합니다. 니즈에 맞게 리전과 영역을 변경할 수 있습니다. 자세한 내용은 위치 및 리전을 참조하세요.

    gcloud config set compute/region us-central1
    gcloud config set compute/zone us-central1-a
    
  2. 스테이징 프로젝트 ID와 프로덕션 프로젝트 ID를 환경 변수에 저장합니다. DEV_PROJECT_ID를 개발 프로젝트 ID로, STAGING_PROJECT_ID를 자체 스테이징 프로젝트 ID로, PROD_PROJECT_ID를 자체 프로덕션 프로젝트 ID로 바꿉니다.

    DEV_PROJECT_ID=DEV_PROJECT_ID
    STAGING_PROJECT_ID=STAGING_PROJECT_ID
    PROD_PROJECT_ID=PROD_PROJECT_ID
    
  3. Cloud Shell에서 Git을 자신의 이름과 이메일 주소로 구성합니다. Git은 이 정보를 사용하여 Cloud Shell에서 만든 커밋의 작성자를 식별합니다. YOUR_EMAIL_ADDRESS를 이메일 주소로, YOUR_NAME을 이름으로 바꿉니다. 연결할 때마다 사용자 이름이나 비밀번호를 제공하지 않고 GitHub에 연결하려면 SSH를 사용하여 GitHub에 연결하면 됩니다.

    git config --global user.email "YOUR_EMAIL_ADDRESS"
    git config --global user.name "YOUR_NAME"
    

필수 구성요소 설정

다음 다이어그램과 같이 우선 필요한 인프라와 대시보드를 만들어 기존 환경을 시뮬레이션합니다.

개발 프로젝트, 스테이징 프로젝트, 프로덕션 프로젝트의 프로젝트 구성요소

그림 2. 이 가이드에서 프로젝트마다 만드는 구성요소의 다이어그램

그림 2는 이 가이드에서 각 프로젝트(개발, 스테이징, 프로덕션)에 만드는 다음 구성요소를 보여줍니다.

  • 프로젝트 구성요소:
    • VM1
    • VM2
    • Monitoring 작업공간
      • 대시보드

VM 인스턴스 만들기

이 섹션에서는 개발 프로젝트, 스테이징 프로젝트, 프로덕션 프로젝트에서 가상 머신(VM) 인스턴스를 만듭니다. VM은 뒷부분에서 만드는 대시보드에 표시할 모니터링 측정항목을 생성합니다.

  1. Cloud Shell의 개발 프로젝트에서 VM 인스턴스 vm1vm2를 만듭니다.

    gcloud compute instances create vm1 vm2 --project=${DEV_PROJECT_ID}
    
  2. 스테이징 프로젝트에서 새 VM 인스턴스 vm1vm2를 만듭니다.

    gcloud compute instances create vm1 vm2 --project=${STAGING_PROJECT_ID}
    
  3. 프로덕션 프로젝트에서 새 VM 인스턴스 vm1vm2를 만듭니다.

    gcloud compute instances create vm1 vm2 --project=${PROD_PROJECT_ID}
    

Monitoring 작업공간 만들기

이 가이드에서 각 프로젝트는 자체 작업공간의 호스트이며 서로 다른 팀이 각 작업공간을 관리합니다. 다른 방법으로 작업공간을 구성할 수도 있으며 이러한 경우 다른 단점이 있습니다.

Monitoring 작업공간을 만들어 이 가이드에서 만든 각 프로젝트를 모니터링합니다.

  1. Cloud Console에서 Monitoring 페이지로 이동합니다.

    Monitoring 페이지로 이동

  2. 개발 프로젝트를 선택하고 작업공간과 연결합니다.

    1. 멀티 프로젝트 작업공간을 만들지 않았으면 작업공간이 자동으로 생성됩니다. 이 작업공간 이름은 Cloud 프로젝트 이름과 동일합니다.
    2. 이전에 작업공간을 만들었으면 프로젝트를 작업공간에 추가 대화상자가 표시됩니다. 이 경우 새 작업공간에서 프로젝트 이름을 선택한 후 추가를 클릭합니다.
  3. 앞의 단계를 반복하여 스테이징 프로젝트와 프로덕션 프로젝트의 작업공간을 만듭니다.

대시보드 만들기

다음으로 각 작업공간에 대시보드를 만들어 기존 환경을 시뮬레이션합니다.

  • 개발 작업공간을 사용하면 프로덕션 프로젝트에서 서비스 중인 기존 대시보드에 영향을 주지 않고 대시보드 변경사항을 안전하게 실험할 수 있습니다.
  • 스테이징 작업공간을 사용하면 변경사항을 검토용으로 배포할 수 있습니다.
  • 프로덕션 작업공간을 사용하면 팀에서 프로덕션 인프라를 모니터링하고 검토를 마친 모든 변경사항을 배포할 수 있습니다.

이 가이드에서는 사전 정의된 대시보드를 사용합니다. Cloud Console을 통해 수동으로 대시보드를 만들거나 API를 통해 사전 정의된 대시보드를 사용하여 대시보드를 만들 수도 있습니다.

  1. 개발 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project $DEV_PROJECT_ID
    
  2. 샘플 대시보드의 저장소를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples.git
    
  3. 클론한 저장소로 이동합니다.

    cd monitoring-dashboard-samples
    
  4. 대시보드 ID의 환경 변수를 만듭니다. DASHBOARD_ID를 만들려는 대시보드 ID로 바꿉니다.

    DASHBOARD_ID=DASHBOARD_ID
    
  5. 대시보드 ID에서 정규화된 개발 대시보드 이름을 만듭니다.

    DASHBOARD_NAME="\"name\": \"projects/$DEV_PROJECT_ID/dashboards/$DASHBOARD_ID\","
    

    대시보드를 만들면 API가 자동으로 영숫자 대시보드 ID를 생성합니다. 위 명령어는 대시보드 객체의 이름 필드를 설정하여 커스텀 대시보드 ID를 지정하는 기본 동작을 재정의합니다. 커스텀 대시보드 ID는 다른 사용자가 환경 변수 또는 CI/CD 파이프라인에서 대시보드를 접할 때 대시보드의 목적을 이해하는 데 유용한 의미 있는 식별자입니다.

  6. 클론한 저장소의 샘플 대시보드에 대시보드 ID를 추가합니다.

    sed -i '/"displayName":/a'"${DASHBOARD_NAME}" dashboards/compute/gce-vm-instance-monitoring.json
    
  7. 개발 작업공간에서 대시보드를 만들려면 gcloud 도구 통합을 사용합니다.

    gcloud monitoring dashboards create \
        --config-from-file=dashboards/compute/gce-vm-instance-monitoring.json
    
  8. 변경사항을 삭제합니다.

    git checkout .
    
  9. 스테이징 프로젝트로 변경합니다.

    gcloud config set project $STAGING_PROJECT_ID
    
  10. 대시보드 ID에서 정규화된 스테이징 대시보드 이름을 만듭니다.

    DASHBOARD_NAME="\"name\": \"projects/$STAGING_PROJECT_ID/dashboards/$DASHBOARD_ID\","
    
  11. 샘플 대시보드에 대시보드 ID를 추가합니다.

    sed -i '/"displayName":/a'"${DASHBOARD_NAME}" dashboards/compute/gce-vm-instance-monitoring.json
    
  12. 스테이징 작업공간에서 대시보드를 만들려면 gcloud 도구 통합을 사용합니다.

    gcloud monitoring dashboards create \
        --config-from-file=dashboards/compute/gce-vm-instance-monitoring.json
    
  13. 변경사항을 삭제합니다.

    git checkout .
    
  14. 프로덕션 프로젝트로 변경합니다.

    gcloud config set project $PROD_PROJECT_ID
    
  15. 대시보드 ID에서 정규화된 프로덕션 대시보드 이름을 만듭니다.

    DASHBOARD_NAME="\"name\": \"projects/$PROD_PROJECT_ID/dashboards/$DASHBOARD_ID\","
    
  16. 샘플 대시보드에 대시보드 ID를 추가합니다.

    sed -i '/"displayName":/a'"${DASHBOARD_NAME}" dashboards/compute/gce-vm-instance-monitoring.json
    
  17. 프로덕션 작업공간에서 대시보드를 만들려면 gcloud 도구 통합을 사용합니다.

    gcloud monitoring dashboards create \
        --config-from-file=dashboards/compute/gce-vm-instance-monitoring.json
    

이제 대시보드가 프로그래매틱 방식으로 작업공간에 생성됩니다. Monitoring API를 프로그래매틱 방식으로 사용하면 대시보드 수가 증가해도 대시보드 배포 시간이 일정하게 유지됩니다.

대시보드 생성 확인

Cloud Console의 각 작업공간에서 대시보드가 생성되었는지 확인합니다.

  1. Cloud Console에서 Monitoring > 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. 개발 작업공간을 선택합니다.

  3. 만든 대시보드가 GCE VM 인스턴스 모니터링으로 표시됩니다.

  4. 앞의 단계를 반복하여 스테이징 프로젝트와 프로덕션 프로젝트의 대시보드가 생성되었는지 확인합니다.

프로젝트 중 하나에 대시보드가 표시되지 않으면 해당 프로젝트의 대시보드 만들기 단계를 반복합니다.

다음 섹션에서는 대시보드 변경사항을 안전하게 실험하는 방법과 이러한 변경사항을 프로덕션에 배포하기 전에 검토하는 방법을 설명합니다.

GitHub 저장소 만들기

이 섹션에서는 이 가이드의 나머지 부분에서 사용할 GitHub 저장소를 만듭니다.

  1. GitHub 저장소를 만듭니다.
    1. README로 이 저장소 초기화를 선택합니다. 이렇게 하면 저장소를 즉시 클론할 수 있습니다.

이 저장소는 다음 작업을 수행할 수 있도록 Monitoring 대시보드의 버전을 지정합니다.

  • 버전 간의 차이점을 검사합니다.
  • 변경사항의 감사 추적을 봅니다.
  • 검토를 마친 변경사항만 배포합니다.
  • 팀 간에 공통 대시보드를 공유합니다.

대시보드 버전 관리

다음으로 대시보드 버전을 지정하고 코드로 처리할 수 있도록 대시보드의 JSON 표현을 저장합니다.

  1. 개발 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project $DEV_PROJECT_ID
    
  2. 만든 GitHub 저장소를 홈 디렉터리에 클론합니다.

    cd ~
    git clone YOUR_REPOSITORY_NAME
    
  3. 클론된 저장소로 이동합니다.

    cd YOUR_REPOSITORY_NAME
    
  4. 대시보드의 JSON 표현을 가져와 파일에 저장합니다.

    gcloud monitoring dashboards describe $DASHBOARD_ID --format=json > dashboard.json
    

    dashboard.json 파일에는 특정 리소스 버전(이 경우에는 대시보드)의 식별자인 ETag가 포함되어 있습니다. API를 사용하여 대시보드를 업데이트할 경우 대시보드의 특정 버전을 식별하는 대시보드 ID와 ETag를 지정합니다. 대시보드가 수정될 때마다 새로운 ETag가 생성됩니다.

    dashboard.json 파일에는 작업공간이 호스팅되는 대시보드 ID와 프로젝트 ID를 지정하는 name 필드가 포함됩니다.

  5. 대시보드 생성에 JSON 파일을 사용하려면 ETag를 삭제하고 이름 필드를 매개변수화합니다.

    sed -i '/"etag":/d' dashboard.json
    sed -i 's/projects\/[0-9]\+/projects\/[PROJECT_ID]/g' dashboard.json
    
  6. 대시보드 파일을 저장소에 체크인합니다.

    git add .
    git commit -m "Add dashboard file"
    git push
    

이제 대시보드 버전이 제어됩니다. 버전 제어를 사용하면 변경 내역을 볼 수 있으며 CI/CD 파이프라인을 통해서만 대시보드를 수정할 수 있도록 환경을 구성할 수 있습니다.

최소 권한의 원칙을 따라 CI/CD 파이프라인에서만 API에 대한 읽기-쓰기 액세스 권한을 가지고 대시보드를 수정할 수 있는지 확인합니다. 대시보드 구성을 볼 수 있도록 다른 모든 사용자에게 API에 대한 읽기 액세스 권한을 부여합니다. CI/CD 파이프라인을 통해서만 변경할 수 있도록 허용하면 일관된 환경이 적용되고 대시보드 변경사항의 단일 정보 출처가 보장됩니다.

변경사항을 스테이징으로 푸시하는 빌드 트리거 만들기

이 섹션에서는 버전 제어 시스템의 개발 분기로 변경사항을 푸시할 때 실행되는 빌드 트리거를 만듭니다. 이 빌드 트리거는 버전 제어 시스템에 저장된 대시보드를 사용하여 스테이징에 대시보드를 배포합니다.

  1. Cloud Console에서 스테이징 프로젝트를 선택합니다.
  2. 스테이징 프로젝트에 GitHub 저장소를 연결합니다. GitHub 저장소를 클라우드 프로젝트에 연결하라는 메시지가 표시되면 비즈니스 니즈에 따라 다음 옵션 중 하나를 선택합니다.
    • 모든 저장소 - Cloud Build 앱을 사용하여 액세스할 현재와 미래의 모든 GitHub 저장소를 사용 설정합니다.
    • 특정 저장소만 - Cloud Build 앱을 사용하여 액세스할 수 있는 특정 저장소만 사용 설정합니다. 나중에 저장소를 추가로 사용 설정할 수 있습니다. 이 가이드에서 사용할 저장소를 선택하려면 저장소 선택 드롭다운을 사용하여 이전에 만든 저장소를 사용 설정합니다.
  3. 다음 트리거 설정으로 GitHub 앱 트리거를 만듭니다.

    1. 이름: 트리거에 사용할 이름을 입력합니다.
    2. 이벤트: 분기로 푸시를 선택합니다.
    3. 소스: 이전에 만든 GitHub 저장소를 선택합니다.
    4. 분기: ^dev$를 입력합니다.
    5. 빌드 구성: Cloud Build 구성 파일(YAML 또는 JSON)을 선택합니다. 기본 cloudbuild.yaml 구성 파일 위치를 유지합니다.
    6. 대체 변수 아래에서 변수 추가를 클릭합니다.
    7. 새 변수 값을 추가합니다.

      1. 변수: _DASHBOARD_ID를 입력합니다.
      2. : DASHBOARD_ID 값을 입력합니다.

      빌드가 실행되면 cloudbuild.yaml 파일의 모든 _DASHBOARD_ID가 제공된 값으로 대체됩니다.

  4. 만들기를 클릭합니다.

이제 커밋이 버전 제어 시스템으로 푸시될 때 실행되는 빌드 트리거가 있습니다. 또한 특정 기준과 일치하는 변경사항이 있는 경우에만 실행되는 빌드 트리거도 만들 수 있습니다. 예를 들어 규칙 집합을 대상으로 구성을 검증하는 트리거를 만들 수 있습니다.

Cloud Build 서비스 계정에 권한 부여

Cloud Build는 서비스 계정을 사용하여 빌드를 자동으로 실행합니다. 앞에서 Cloud Build API를 사용 설정할 때 Cloud Build 서비스 계정이 자동으로 생성되고 프로젝트에 대한 Cloud Build 서비스 계정 역할이 부여되었습니다. 이 역할은 서비스 계정에 여러 태스크를 수행할 수 있는 권한을 부여합니다. 하지만 추가 태스크를 수행할 수 있도록 서비스 계정에 더 많은 권한을 부여할 수 있습니다.

이 섹션에서는 스테이징 프로젝트의 Cloud Build 서비스 계정에 Monitoring 작업공간에서 대시보드를 읽고 쓸 수 있는 추가 권한을 부여합니다.

  1. 스테이징 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project $STAGING_PROJECT_ID
    
  2. Cloud Build 서비스 계정에 필요한 권한을 부여합니다.

    PROJECT_NUMBER="$(gcloud projects describe ${STAGING_PROJECT_ID} \
      --format='get(projectNumber)')"
    
    gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
      --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
      --role=roles/monitoring.dashboardEditor
    

개발 중인 대시보드 변경

다음 섹션에서는 개발 프로젝트의 대시보드 변경사항을 안전하게 테스트하고 변경사항을 검토한 후 프로덕션에 자동으로 배포하는 방법을 설명합니다. 앞의 단계에서 대시보드가 코드로 처리되고 버전 제어가 적용되도록 조치했으므로 자동 배포가 가능합니다.

  1. Cloud Console에서 Monitoring > 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. 개발 작업공간을 선택합니다.

  3. 이 가이드 앞부분에서 만든 대시보드를 클릭합니다.

  4. GCE VM 인스턴스 - CPU 사용률 차트에서 차트 옵션 더보기를 클릭한 후 수정을 클릭합니다.

  5. 차트 수정 대화상자가 나타나면 차트 제목 값을 My first change로 변경합니다.

  6. 저장을 클릭합니다.

Monitoring API로 대시보드 업데이트

대시보드를 업데이트하려면 Monitoring API를 사용하여 기존 대시보드에 업데이트를 배포하거나 기존 대시보드를 삭제하고 업데이트된 정의를 사용하여 다시 만들면 됩니다.

업데이트된 대시보드 배포

업데이트된 대시보드를 배포하려면 만들 때나 JSON 표현을 처음 가져올 때 대시보드의 ETag를 저장합니다. 그런 다음 대시보드를 업데이트할 때 ETag를 지정하여 대시보드가 변경되지 않았는지 확인합니다. 다른 엔지니어가 대시보드를 변경한 경우 ETag를 지정하여 대시보드를 변경사항으로 덮어쓰지 않아야 합니다. 즉, 상태를 유지해야 합니다.

하지만 CI/CD 파이프라인에서만 대시보드를 변경할 수 있도록 환경을 잠그면 상태 유지 책임이 있는 사용자가 변경됩니다. 이제 엔지니어가 커밋 간에 동일한 ETags를 확인하는 대신 버전 제어 시스템이 시간 경과에 따른 변경사항을 추적합니다. 버전 제어 시스템의 커밋 내역에서 덮어쓴 변경사항을 볼 수 있습니다.

대시보드 삭제 후 다시 만들기

대시보드를 업데이트하려면 현재 대시보드를 삭제하고 원하는 변경사항으로 새 대시보드를 만들면 됩니다. 이 방법은 배포할 작업공간과 삭제할 대시보드만 지정하면 되므로 보다 쉽게 자동화, 판단, 디버깅을 수행할 수 있습니다. 대시보드를 삭제하고 다시 만들 때 상태를 ETags 형식으로 유지할 필요가 없습니다. 이 방법이 실행 가능하려면 CI/CD 파이프라인에서만 대시보드를 변경할 수 있어야 합니다. 이 방법에서는 대시보드를 변경할 수 없는 인프라의 형태로 취급합니다. 실수로 인한 수정과 같은 의도하지 않은 변경사항이 있으면 언제든지 버전 제어 시스템에서 대시보드를 안전하게 복원할 수 있습니다.

다음 섹션에서는 이 방법을 구현하여 대시보드를 삭제한 후 다시 만드는 방법을 설명합니다.

스테이징에 개발 대시보드 배포

변경사항을 저장소에 푸시하면 빌드 트리거가 대시보드를 스테이징 작업공간에 배포하는 빌드를 시작합니다. 빌드는 제공된 cloudbuild.yaml 파일에 지정된 단계를 실행합니다.

Cloud Build 구성 파일 만들기

로컬 저장소에 다음과 같은 콘텐츠의 Cloud Build YAML 구성 파일을 만듭니다.

cat >cloudbuild.yaml <<EOF
steps:
# Substitute project ID placeholder in dashboard file with project ID supplied by Cloud Build
- name: 'google/cloud-sdk'
  id : 'Substitute project ID'
  entrypoint: 'bash'
  args:
    - '-c' # pass what follows as a command to bash
    - |
      sed -i 's/\[PROJECT_ID\]/'\$PROJECT_ID'/g' dashboard.json

- name: 'google/cloud-sdk'
  id: 'Delete dashboard'
  args:
    [
      'gcloud', 'monitoring', 'dashboards', 'delete',
      '--quiet',
      'projects/\$PROJECT_ID/dashboards/\${_DASHBOARD_ID}'
    ]
- name: 'google/cloud-sdk'
  id: 'Create dashboard'
  args:
    [
      'gcloud', 'monitoring', 'dashboards', 'create',
      '--config-from-file=dashboard.json'
    ]
EOF

이제 개발 중인 대시보드를 자동으로 스테이징 프로젝트에 푸시할 수 있습니다.

변경사항 자동 배포

  1. 개발 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project $DEV_PROJECT_ID
    
  2. 스테이징 작업공간에서 대시보드의 새 JSON 표현을 가져옵니다.

    gcloud monitoring dashboards describe $DASHBOARD_ID --format=json > dashboard.json
    
  3. 대시보드를 만드는 데 사용할 수 있도록 ETag를 삭제하고 JSON 파일의 이름 필드를 매개변수화합니다.

    sed -i '/"etag":/d' dashboard.json
    sed -i 's/projects\/[0-9]\+/projects\/[PROJECT_ID]/g' dashboard.json
    
  4. Cloud Build 구성을 GitHub로 푸시합니다.

    git checkout -b dev
    git add .
    git commit -m "Add changes"
    git push --set-upstream origin dev
    
  5. Cloud Console에서 기록 페이지로 이동합니다.

    기록 페이지로 이동

  6. 스테이징 프로젝트를 선택합니다.

  7. 빌드 기록 페이지에 실행 중인 빌드 트리거의 상태가 표시됩니다.

또한 이 아키텍처를 사용하여 대시보드 업데이트를 자동으로 다른 프로젝트에 푸시할 수 있습니다. 업데이트를 푸시할 프로젝트별로 버전 제어 시스템에 새 커밋이 있을 때마다 업데이트를 푸시하는 빌드를 시작하는 빌드 트리거를 만듭니다.

트리거가 완료되면 개발 대시보드가 스테이징에 배포되었는지 확인할 수 있습니다.

스테이징에 배포 확인

Cloud Console에서 개발 대시보드가 스테이징 작업공간에 배포되었는지 확인합니다.

  1. Cloud Console에서 Monitoring > 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. 스테이징 작업공간을 선택합니다.

  3. 이 가이드 앞부분에서 만든 대시보드를 클릭합니다.

  4. GCE VM 인스턴스 모니터링 대시보드에서 내 첫 번째 변경사항 차트를 사용할 수 있는지 확인합니다.

이제 수동으로 대시보드를 다시 만들지 않고 개발 작업공간에서 스테이징 작업공간으로 대시보드를 자동 배포했습니다. 이 자동화를 사용하면 각 대시보드의 차트 수나 차트 복잡성에 관계없이 대시보드를 작업공간에 일관되고 쉽게 배포할 수 있습니다.

변경사항을 프로덕션으로 푸시하는 빌드 트리거 만들기

이 섹션에서는 pull 요청을 검토한 후 main으로 병합하면 실행되는 빌드 트리거를 만듭니다. 이 빌드 트리거는 버전 제어 시스템에 저장된 대시보드를 사용하여 스테이징 대시보드를 프로덕션에 배포합니다.

  1. Cloud Console에서 프로덕션 프로젝트를 선택합니다.
  2. GitHub 저장소를 프로덕션 프로젝트에 연결하고 이 가이드 앞부분에서 만든 저장소를 선택합니다. 스테이징 프로젝트에서 빌드 트리거를 처음 만들 때 Cloud Build GitHub 앱이 저장소에 이미 설치되어 있으므로 저장소를 사용할 수 있습니다.
  3. GitHub 앱 트리거를 만듭니다.

    1. 이름: 트리거에 사용할 이름을 입력합니다.
    2. 이벤트: 분기로 푸시를 선택합니다.
    3. 소스: 이전에 만든 GitHub 저장소를 선택합니다.
    4. 분기: ^main$를 입력합니다.
    5. 빌드 구성: Cloud Build 구성 파일(YAML 또는 JSON)을 선택합니다.
    6. 대체 변수 아래에서 변수 추가를 클릭합니다.
    7. 새 변수 값을 추가합니다.

      1. 변수: _DASHBOARD_ID를 입력합니다.
      2. : DASHBOARD_ID 값을 입력합니다.

      빌드가 실행되면 cloudbuild.yaml 파일의 모든 _DASHBOARD_ID가 제공된 값으로 대체됩니다.

  4. 만들기를 클릭합니다.

이제 커밋이 버전 제어 시스템으로 푸시될 때 실행되는 빌드 트리거가 있습니다. 또한 특정 기준과 일치하는 변경사항이 있는 경우에만 실행되는 빌드 트리거도 만들 수 있습니다. 예를 들어 규칙 집합을 대상으로 구성을 검증하는 트리거를 만들 수 있습니다.

Cloud Build 서비스 계정에 권한 부여

다음으로 프로덕션 프로젝트의 Cloud Build 서비스 계정에 Monitoring 작업공간에서 대시보드를 읽고 쓸 수 있는 권한을 부여합니다.

  1. 프로덕션 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project $PROD_PROJECT_ID
    
  2. Cloud Build 서비스 계정에 필요한 권한을 부여합니다.

    PROJECT_NUMBER="$(gcloud projects describe ${PROD_PROJECT_ID} \
      --format='get(projectNumber)')"
    
    gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
      --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
      --role=roles/monitoring.dashboardEditor
    

pull 요청 만들기

대시보드 변경사항이 이제 스테이징 작업공간에 있고 이러한 변경사항을 검토할 수 있습니다. 변경사항은 이 가이드 앞부분에서 변경사항을 자동으로 배포하는 설정을 완료했을 때 GitHub으로 푸시되었습니다. 이제 검토 프로세스를 시작하는 pull 요청을 만듭니다.

  1. 이 가이드 앞부분에서 만든 저장소의 GitHub 페이지로 이동합니다.
  2. 비교 및 pull 요청을 클릭합니다.

    비교 및 pull 요청을 위한 GitHub 인터페이스

  3. pull 요청의 제목과 설명을 입력합니다. 제목에는 이 pull 요청이 수행할 내용이 요약되어 있어야 합니다. 여기서는 pull 요청으로 제목이 수정된다고 제목에 명시되어 있습니다. pull 요청에 대한 세부정보를 제공해야 합니다. 여기서는 변경사항 검토 위치와 pull 요청 승인 결과를 설명합니다.

    pull 요청을 여는 GitHub 인터페이스

  4. pull 요청 만들기를 클릭합니다.

이제 검토할 변경사항 집합을 나타내는 pull 요청을 만들었습니다.

pull 요청 검토

pull 요청을 스테이징 작업공간에서 검토한 후 병합하여 변경사항을 프로덕션에 자동으로 배포합니다. 일반적으로 동료 엔지니어가 pull 요청을 검토합니다. 이 가이드에서는 독자가 자신의 변경사항을 동료 엔지니어 입장에서 직접 검토합니다. 변경사항을 검토하려면 다음을 수행하여 스테이징 작업공간으로 이동합니다.

  1. Cloud Console에서 Monitoring > 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. 스테이징 작업공간을 선택합니다.

  3. 이 가이드 앞부분에서 만든 대시보드를 클릭합니다.

  4. GCE VM 인스턴스 모니터링 대시보드에서 제목 변경사항을 검토합니다.

pull 요청 병합

변경사항을 검토했으면 pull 요청을 병합합니다.

  1. 이 가이드 앞부분에서 만든 저장소의 pull 요청 페이지로 이동합니다.
  2. pull 요청을 병합하려면 pull 요청 병합을 클릭한 후 병합 확인을 클릭합니다.

    'pull 요청 병합'이 강조표시된 GitHub 인터페이스

실행 중인 빌드 트리거의 상태를 확인하려면 Cloud Console에서 빌드 기록 페이지로 이동한 후 프로덕션 프로젝트를 선택합니다.

트리거가 완료되면 스테이징 대시보드가 프로덕션에 배포되었는지 확인할 수 있습니다.

스테이징 대시보드가 프로덕션에 배포되었는지 확인

  1. Cloud Console에서 Monitoring > 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. 프로덕션 작업공간을 선택합니다.

  3. 이 가이드 앞부분에서 만든 대시보드를 클릭합니다.

  4. GCE VM 인스턴스 모니터링 대시보드에서 내 첫 번째 변경사항 차트를 사용할 수 있는지 확인합니다.

수동으로 대시보드를 다시 만들지 않고 스테이징 작업공간의 대시보드를 자동으로 프로덕션 작업공간에 배포했습니다. 이 자동화를 사용하면 각 대시보드의 차트 수나 차트 복잡성에 관계없이 대시보드를 작업공간에 일관되고 쉽게 배포할 수 있습니다.

삭제

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

    리소스 관리로 이동

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

다음 단계