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

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 do 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.

Fazer o download da CLI gdcloud

Faça o download e extraia um arquivo de pacote da CLI gdcloud seguindo as instruções em Fazer o download da CLI gdcloud. Não use um binário independente da CLI gdcloud que não inclua o diretório bin/component_bundles/.

Instalar a CLI gdcloud

Para usar o grupo de comandos gdcloud storage, instale o componente storage-cli-dependencies de um pacote extraído da CLI gdcloud:

Siga as instruções em Instalar a CLI gdcloud para adicionar o diretório bin do pacote extraído ao PATH.
Para instalar o componente storage-cli-dependencies, execute o seguinte comando:
```
gdcloud components install storage-cli-dependencies
```
Esse comando instala storage-cli-dependencies do diretório bin/component_bundles/ no pacote extraído da CLI gdcloud. Se você executar esse comando em um binário independente da CLI gdcloud que não tenha bin/component_bundles/, o comando vai falhar com um erro component_registry.yaml: no such file or directory. Para resolver esse erro, faça o download e extraia um pacote em Fazer o download da CLI gdcloud e execute bin/gdcloud no diretório do pacote extraído.

Para mais informações sobre o comando components install, consulte Instalar componentes.

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://.

Essa etapa é um pouco diferente para buckets birregionais. Cada bucket de duas regiões 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 zone1.
- 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 de dentro da zone2.
- Endpoint global: esse endpoint faz com que sua solicitação seja roteada para a zona1 ou a zona2. 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 ver 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
```