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

Esta página orienta você na instalação e configuração da CLI gdcloud para gerenciar o armazenamento de objetos ao trabalhar com projetos isolados do Google Distributed Cloud (GDC). Ela aborda como fazer o download, instalar e configurar os componentes e as configurações necessários para usar buckets e objetos de armazenamento de maneira eficaz nesse ambiente isolado.

Esta página é destinada a públicos-alvo, como admins de TI do grupo de operadores de infraestrutura ou desenvolvedores do grupo de operadores de aplicativos, que querem provisionar e gerenciar buckets de repositório de objetos para projetos em ambientes GDC com isolamento físico. 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 ser 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 para armazenamento de objetos.

Substitua ACCESS_KEY_ID pelo ID da chave de acesso recebido do segredo em Como receber credenciais de acesso:
```
gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
```
Substitua SECRET_ACCESS_KEY pela chave secreta recebida do segredo em Como receber credenciais de acesso:
```
gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
```
Substitua CA_BUNDLE_FILE pelo caminho do certificado da AC. Esse é um certificado digital que pertence a uma autoridade de certificação (AC), 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 AC para o GDC já estiverem instalados no ambiente, então você pode definir isso como /etc/ssl/certs/ca-certificates.crt
Substitua ENDPOINT pelo endpoint fornecido pelo operador de infraestrutura (IO, na sigla em inglês):
```
gdcloud config set storage/s3_endpoint ENDPOINT
```
Observação: esse é o endpoint completo que começa com https://.

Essa etapa é um pouco diferente para buckets de duas zonas. Cada bucket de duas zonas oferece 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 zona 1 ficar inativa, um cliente precisará mudar para o endpoint global ou da zona 2 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 o endpoint global ou da zona 1 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 a 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 zona 1 ou na zona 2. 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 da mesma forma que precisariam se usassem o endpoint zonal. Além disso, esse endpoint pode ser acessado em clusters de usuários em todas as zonas.
Execute os comandos a seguir no servidor da API de gerenciamento para conferir os endpoints globais e zonais do bucket e escolher 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
```