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 mostra como baixar, instalar e configurar os componentes e as configurações necessários para usar de maneira eficaz buckets e objetos de armazenamento nesse ambiente isolado.

Esta página é destinada a públicos-alvo como admins de TI no grupo de operadores de infraestrutura ou desenvolvedores no grupo de operadores de aplicação 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.

Antes de começar

Para instalar e configurar a CLI do Storage, entre em contato com o administrador do IAM da organização e peça a função Administrador da política de rede da organização (org-network-policy-admin), que permite criar, editar e excluir políticas de rede da organização.

Fazer o download da CLI gdcloud

Siga as instruções para baixar a 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 do 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, na sigla em inglês), uma organização confiável que garante identidades. Você pode solicitar o pacote de confiança da CA do GDC a um membro do seu grupo de operadores de infraestrutura (IO). Para mais informações sobre como receber certificados de CA do GDC, consulte Buscar pacotes de confiança do GDC.
```
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 zonas. Cada bucket de dupla zona 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 zona1 falhar, 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 zona2 ficar inativa, um cliente precisará mudar para usar a zona1 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 zona2.
- 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 seria necessário se usassem o endpoint zonal. Além disso, esse endpoint pode ser acessado de 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 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
```