Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

プロジェクトのストレージ CLI をインストールして構成する

このページでは、Google Distributed Cloud（GDC）エアギャッププロジェクトを操作するときに、オブジェクトストレージを管理するための gdcloud CLI をインストールして構成する方法について説明します。この分離された環境でストレージバケットとオブジェクトを効果的に使用するために不可欠なコンポーネントと設定をダウンロード、インストール、構成する方法について説明します。

このページは、インフラストラクチャオペレーターグループの IT 管理者や、アプリケーションオペレーターグループのデベロッパーなど、GDC エアギャップ環境内のプロジェクトにオブジェクトストレージバケットをプロビジョニングして管理することを検討している方を対象としています。詳細については、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 コンポーネントをインストールします。

gdcloud CLI をインストールするの手順に沿って、抽出したバンドルの bin ディレクトリを PATH に追加します。
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 を使用するには、次の構成を設定する必要があります。

ACCESS_KEY_ID は、アクセス認証情報の取得でシークレットから取得したアクセスキー ID に置き換えます。
```
gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
```
SECRET_ACCESS_KEY は、アクセス認証情報の取得でシークレットから取得したシークレットキーに置き換えます。
```
gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
```
CA_BUNDLE_FILE は、CA 証明書のパスに置き換えます。これは、ID を保証する信頼できる組織である認証局（CA）に属するデジタル証明書です。GDC CA トラストバンドルは、インフラストラクチャオペレーター（IO）グループのメンバーにリクエストできます。GDC CA 証明書の取得の詳細については、GDC 信頼バンドルを取得するをご覧ください。
```
gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE
```
注: GDC の CA 証明書がすでに環境にインストールされている場合は、これを /etc/ssl/certs/ca-certificates.crt に設定できます。
ENDPOINT は、インフラストラクチャオペレーター（IO）が提供するエンドポイントに置き換えます。
```
gdcloud config set storage/s3_endpoint ENDPOINT
```
注: これは、https:// で始まる完全なエンドポイントです。
この手順は、デュアルゾーンバケットの場合とは少し異なります。各デュアルゾーンバケットには、バケットへのアクセスに使用できる 3 つのエンドポイントが用意されています。ほとんどの場合、自動フェイルオーバーを利用するには、グローバルエンドポイントが適しています。
- zone1 エンドポイント: このエンドポイントは常に zone1 によって受信されます。このエンドポイントを使用すると、zone1 に書き込まれたオブジェクトに対して書き込み後読み取り整合性が確保されます。ただし、zone1 がダウンした場合、クライアントは zone2 またはグローバルエンドポイントを使用するように変更して、このバケットへの読み取り / 書き込みを続行する必要があります。クライアントがユーザークラスタからアクセスしている場合、このエンドポイントには zone1 内からのみアクセスできます。
- zone2 エンドポイント: このエンドポイントは常に zone2 によって受信されます。このエンドポイントを使用すると、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
```