스토리지 CLI 설치 및 구성

이 페이지에서는 Google Distributed Cloud (GDC) 에어 갭 프로젝트를 사용할 때 객체 스토리지를 관리하기 위해 gdcloud CLI를 설치하고 구성하는 방법을 안내합니다. 이 가이드에서는 이 격리된 환경에서 스토리지 버킷과 객체를 효과적으로 사용하는 데 필수적인 구성요소와 설정을 다운로드, 설치, 구성하는 방법을 설명합니다.

이 페이지는 GDC 에어 갭 환경 내에서 프로젝트의 객체 스토리지 버킷을 프로비저닝하고 관리하려는 인프라 운영자 그룹 내 IT 관리자 또는 애플리케이션 운영자 그룹 내 개발자를 대상으로 합니다. 자세한 내용은 GDC 에어 갭 문서 대상을 참조하세요.

시작하기 전에

스토리지 CLI를 설치하고 구성하려면 IAM 조직 관리자에게 연락하여 조직 네트워크 정책을 만들고, 수정하고, 삭제할 수 있는 조직 네트워크 정책 관리자 (org-network-policy-admin) 역할을 요청하세요.

gdcloud CLI 다운로드

gdcloud CLI 다운로드의 안내에 따라 gdcloud CLI 번들 보관 파일을 다운로드하고 추출합니다. bin/component_bundles/ 디렉터리가 포함되지 않은 독립형 gdcloud CLI 바이너리를 사용하지 마세요.

gdcloud CLI 설치

gdcloud storage 명령어 그룹을 사용하려면 추출된 gdcloud CLI 번들에서 storage-cli-dependencies 구성요소를 설치합니다.

  1. gdcloud CLI 설치의 안내에 따라 압축을 푼 번들의 bin 디렉터리를 PATH에 추가합니다.

  2. storage-cli-dependencies 구성요소를 설치하려면 다음 명령어를 실행합니다.

    gdcloud components install storage-cli-dependencies

    이 명령어는 추출된 gdcloud CLI 번들의 bin/component_bundles/ 디렉터리에서 storage-cli-dependencies를 설치합니다. bin/component_bundles/가 없는 독립형 gdcloud CLI 바이너리에서 이 명령어를 실행하면 component_registry.yaml: no such file or directory 오류와 함께 명령어가 실패합니다. 이 오류를 해결하려면 gdcloud CLI 다운로드에서 번들을 다운로드하고 추출한 후 추출된 번들 디렉터리에서 bin/gdcloud를 실행합니다.

    components install 명령어에 대한 자세한 내용은 구성요소 설치를 참조하세요.

객체 스토리지용 gdcloud CLI 구성

객체 스토리지에 gdcloud CLI를 사용하려면 다음 구성을 설정해야 합니다.

  1. ACCESS_KEY_ID를 액세스 사용자 인증 정보 가져오기의 보안 비밀에서 가져온 액세스 키 ID로 바꿉니다.

    gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID

  2. SECRET_ACCESS_KEY을 액세스 사용자 인증 정보 가져오기의 보안 비밀에서 가져온 보안 비밀 키로 바꿉니다.

    gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY

  3. CA_BUNDLE_FILE을 CA 인증서 경로로 바꿉니다. 이는 ID를 보증하는 신뢰할 수 있는 조직인 인증 기관 (CA)에 속한 디지털 인증서입니다. 인프라 운영자 (IO) 그룹의 구성원에게 GDC CA 트러스트 번들을 요청할 수 있습니다. GDC CA 인증서를 가져오는 방법에 대한 자세한 내용은 GDC 트러스트 번들 가져오기를 참조하세요.

    gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE

  4. ENDPOINT를 인프라 운영자 (IO)가 제공하는 엔드포인트로 바꿉니다.

    gdcloud config set storage/s3_endpoint ENDPOINT

    이 단계는 이중 리전 버킷의 경우 약간 다릅니다. 각 이중 리전 버킷은 버킷에 액세스하기 위해 선택할 수 있는 세 개의 엔드포인트를 제공합니다. 대부분의 경우 자동 장애 조치를 활용하려면 전역 엔드포인트가 적합합니다.

    • zone1 엔드포인트: 이 엔드포인트는 항상 zone1에서 수신됩니다. 이 엔드포인트를 사용하는 경우 zone1에 작성된 모든 객체에 대해 쓰기 직후 읽기 일관성이 적용됩니다. 하지만 zone1이 다운되면 클라이언트는 이 버킷에 계속 읽기/쓰기를 수행하기 위해 zone2 또는 전역 엔드포인트를 사용하도록 변경해야 합니다. 클라이언트가 사용자 클러스터에서 오는 경우 이 엔드포인트는 zone1 내에서만 액세스할 수 있습니다.
    • 영역2 엔드포인트: 이 엔드포인트는 항상 영역2에서 수신됩니다. 이 엔드포인트를 사용하는 경우 zone2에 기록된 모든 객체에 대해 쓰기 직후 읽기 일관성이 적용됩니다. 하지만 zone2가 다운되면 클라이언트는 이 버킷에 계속 읽기/쓰기를 수행하기 위해 zone1 또는 전역 엔드포인트를 사용하도록 변경해야 합니다. 클라이언트가 사용자 클러스터에서 오는 경우 이 엔드포인트는 zone2 내에서만 액세스할 수 있습니다.
    • 전역 엔드포인트: 이 엔드포인트는 요청을 zone1 또는 zone2로 라우팅합니다. 이 옵션은 세션 어피니티를 제공하지 않습니다. 즉, 동일한 세션을 사용하여 수행된 요청이 zone1 또는 zone2에 도착할 수 있습니다. 즉, 전역 엔드포인트에 대한 요청에는 쓰기 후 읽기 보장이 없습니다. 전역 엔드포인트는 영역이 다운될 경우 자동 장애 조치를 제공하므로 사용자는 영역 엔드포인트를 사용할 때와 달리 워크로드에서 엔드포인트를 변경할 필요가 없습니다. 또한 이 엔드포인트는 모든 영역의 사용자 클러스터에서 액세스할 수 있습니다.

    관리 API 서버에 대해 다음 명령어를 실행하여 버킷의 전역 및 영역 엔드포인트를 확인하고 사용할 엔드포인트를 선택합니다.

    kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.globalEndpoint}" --kubeconfig MANAGEMENT_API_SERVER

kubectl get buckets BUCKET_NAME -n PROJECT_NAME -o jsonpath="{.status.zonalEndpoints}" --kubeconfig MANAGEMENT_API_SERVER