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.

Instalar e configurar a CLI de armazenamento para projetos

Nesta página, mostramos como instalar e configurar a CLI gdcloud para gerenciar o armazenamento de objetos ao trabalhar com projetos isolados do Google Distributed Cloud (GDC). Ele explica como fazer o download, instalar e configurar os componentes e as configurações necessários para usar de forma eficaz buckets e objetos de armazenamento nesse ambiente isolado.

Esta página é destinada a públicos-alvo como administradores de TI do grupo de operadores de infraestrutura ou desenvolvedores do grupo de operadores de aplicativos que querem provisionar e gerenciar buckets de armazenamento de objetos para projetos em ambientes isolados do GDC. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Fazer o download da CLI gdcloud

Siga as instruções para fazer o download da CLI gdcloud.

Instalar a CLI gdcloud

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

Siga as instruções em Instalar a CLI gdcloud.
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 Instalar a CLI gdcloud.

Configurar a CLI gdcloud para armazenamento de objetos

As configurações a seguir precisam ser definidas para usar a CLI gdcloud no armazenamento de objetos.

Substitua ACCESS_KEY_ID pelo ID da chave de acesso obtido do secret em Como receber credenciais de acesso:
```
gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
```
Substitua SECRET_ACCESS_KEY pela chave secreta obtida no secret em como receber credenciais de acesso:
```
gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
```
Substitua CA_BUNDLE_FILE pelo caminho para o certificado da CA. É um certificado digital que pertence a uma autoridade certificadora (CA), uma organização confiável que garante identidades:
```
gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE
```
Observação: se os certificados da CA para GDC já estiverem instalados no ambiente, defina como /etc/ssl/certs/ca-certificates.crt
Substitua ENDPOINT pelo endpoint fornecido pelo operador de infraestrutura (IO):
```
gdcloud config set storage/s3_endpoint ENDPOINT
```
Observação :este é o endpoint completo que começa com https://.

Essa etapa varia um pouco para buckets de duas regiões. Cada bucket de duas zonas fornece três endpoints que podem ser usados para acessar o bucket. Na maioria das situações, o endpoint global é adequado para aproveitar os failovers automáticos:
- Endpoint da zona 1: esse endpoint é sempre recebido pela zona 1. Se você usar esse endpoint, terá consistência de leitura após gravação para todos os objetos gravados na zona 1. No entanto, se a zona1 ficar inativa, um cliente precisará mudar para usar a zona2 ou o endpoint global para continuar lendo/gravando nesse bucket. Se o cliente vier de um cluster de usuário, esse endpoint só poderá ser acessado na zona 1.
- Endpoint da zona 2: esse endpoint é sempre recebido pela zona 2. Se você usar esse endpoint, terá consistência de leitura após gravação para todos os objetos gravados na zona 2. No entanto, se a zona 2 ficar inativa, um cliente precisará mudar para usar o endpoint da zona 1 ou o global para continuar lendo/gravando nesse bucket. Se o cliente vier de um cluster de usuário, esse endpoint só poderá ser acessado na zona 2.
- Endpoint global: esse endpoint faz com que sua solicitação seja encaminhada para a zona 1 ou a zona 2. Essa opção não oferece afinidade da sessão, o que significa que as solicitações feitas usando a mesma sessão podem chegar na zona1 ou na zona2. Isso significa que não há garantia de leitura após gravação para solicitações feitas ao endpoint global. O endpoint global oferece failover automático caso uma zona fique inativa. Assim, os usuários não precisam mudar os endpoints nas cargas de trabalho como fariam se usassem o endpoint zonal. Além disso, esse endpoint pode ser acessado de clusters de usuários em todas as zonas.
Execute os seguintes comandos no servidor da API de gerenciamento para conferir os endpoints globais e zonais do seu bucket e escolha o que você 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
```