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 repositório de objetos ao trabalhar com projetos do Google Distributed Cloud (GDC) com isolamento físico. Ele aborda como baixar, instalar e definir os componentes e as configurações necessários para usar de forma eficaz os 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 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.

Antes de começar

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

Baixar a 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 para armazenamento de objetos.

Substitua ACCESS_KEY_ID pelo ID da chave de acesso recebido 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 recebida 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 de CA. É um certificado digital que pertence a uma autoridade certificadora (CA), uma organização confiável que confirma identidades. Você pode solicitar o pacote de confiança da CA do GDC a um membro do seu grupo de operadores de infraestrutura (IO, na sigla em inglês). 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 de CA do GDC já estiverem instalados no ambiente, defina 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://.

Esta etapa é um pouco diferente para buckets birregionais. Cada bucket de zona dupla oferece três endpoints que você pode escolher para acessar o bucket. Na maioria das situações, o endpoint global é adequado para aproveitar os failovers automáticos:
- Endpoint zone1: esse endpoint é sempre recebido pela zone1. Se você usar esse endpoint, terá consistência de leitura após gravação para todos os objetos gravados na zone1. No entanto, se a zone1 ficar inativa, um cliente precisará mudar para o endpoint zone2 ou global para continuar lendo/gravando nesse bucket. Se o cliente for de um cluster de usuário, esse endpoint só poderá ser acessado na zona 1.
- Endpoint zone2: esse endpoint é sempre recebido por zone2. Se você usar esse endpoint, terá consistência de leitura após gravação para todos os objetos gravados na zone2. No entanto, se a zone2 ficar inativa, um cliente precisará mudar para o endpoint zone1 ou global para continuar lendo/gravando nesse bucket. Se o cliente for de um cluster de usuário, esse endpoint só poderá ser acessado na zone2.
- Endpoint global: esse endpoint faz com que sua solicitação seja roteada 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 no caso de uma zona ficar 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 por clusters de usuário em todas as zonas.
Execute os seguintes comandos 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
```