O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Instale e configure a CLI de armazenamento para projetos

Esta página explica como instalar e configurar a CLI gdcloud para gerir o armazenamento de objetos quando trabalha com projetos isolados do Google Distributed Cloud (GDC). Abrange a forma de transferir, instalar e configurar os componentes e as definições necessários essenciais para usar eficazmente os contentores e os objetos de armazenamento neste ambiente isolado.

Esta página destina-se a públicos-alvo, como administradores de TI no grupo de operadores de infraestrutura ou programadores no grupo de operadores de aplicações, que pretendem aprovisionar e gerir contentores de armazenamento de objetos para projetos em ambientes isolados do GDC. Para mais informações, consulte o artigo Públicos-alvo para a documentação isolada do GDC.

Transfira a CLI gcloud

Siga as instruções para transferir a CLI gcloud.

Instale a CLI gcloud

Para usar a árvore de comandos de armazenamento, o componente de dependências de armazenamento tem de estar instalado.

Siga as instruções em Instale a CLI gcloud.
Para instalar o componente de dependências de armazenamento, execute os seguintes comandos:
```
gdcloud components install storage-cli-dependencies
```
Para mais informações sobre o comando components install, consulte o artigo Instale a CLI gdcloud.

Configure a CLI gcloud para o armazenamento de objetos

As seguintes configurações têm de ser definidas para usar a CLI gdcloud para o armazenamento de objetos.

Substitua ACCESS_KEY_ID pelo ID da chave de acesso obtido a partir do segredo em obter credenciais de acesso:
```
gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
```
Substitua SECRET_ACCESS_KEY pela chave secreta obtida a partir do segredo em obter credenciais de acesso:
```
gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
```
Substitua CA_BUNDLE_FILE pelo caminho para o certificado da AC. Este é um certificado digital que pertence a uma autoridade de certificação (CA), uma organização fidedigna que garante identidades:
```
gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE
```
Nota: se os certificados de AC para o GDC já estiverem instalados no ambiente, pode definir esta opção como /etc/ssl/certs/ca-certificates.crt
Substitua ENDPOINT pelo ponto final fornecido pelo seu operador de infraestrutura (IO):
```
gdcloud config set storage/s3_endpoint ENDPOINT
```
Nota: este é o ponto final completo que começa com https://.

Este passo difere ligeiramente para os conjuntos de dados de duas zonas. Cada contentor de zona dupla oferece três pontos finais que pode escolher para aceder ao contentor. Na maioria das situações, o ponto final global é adequado para tirar partido das comutações por falha automáticas:
- Ponto final Zone1: este ponto final é sempre recebido pela Zone1. Se usar este ponto final, tem consistência de leitura após escrita para todos os objetos escritos na zona1. No entanto, se a zona1 ficar inativa, um cliente tem de mudar para usar a zona2 ou o ponto final global para continuar a ler/escrever neste contentor. Se o cliente estiver a aceder a partir de um cluster de utilizadores, este ponto final só vai estar acessível a partir da zona1.
- Ponto final Zone2: este ponto final é sempre recebido pela Zone2. Se usar este ponto final, tem consistência de leitura após escrita para todos os objetos escritos na zona 2. No entanto, se a zona2 ficar inativa, um cliente tem de mudar para usar o ponto final global ou da zona1 para continuar a ler/escrever neste contentor. Se o cliente estiver a aceder a partir de um cluster de utilizadores, este ponto final só vai estar acessível a partir da zona 2.
- Ponto final global: este ponto final faz com que o seu pedido seja encaminhado para a zona 1 ou a zona 2. Esta opção não oferece afinidade de sessão, o que significa que os pedidos feitos com a mesma sessão podem chegar à zona1 ou à zona2. Isto significa que não existe uma garantia de leitura após escrita para pedidos feitos ao ponto final global. O ponto final global oferece uma comutação por falha automática caso uma zona fique inativa, pelo que os utilizadores não têm de alterar os pontos finais nas respetivas cargas de trabalho, como teriam de fazer se usassem o ponto final zonal. Além disso, este ponto final é acessível a partir de clusters de utilizadores em todas as zonas.
Execute os seguintes comandos no servidor da API de gestão para ver os pontos finais globais e zonais do seu contentor e escolha o que quer usar:
```
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
```