Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Installa e configura la CLI di archiviazione per i progetti

Questa pagina ti guida all'installazione e alla configurazione di gcloud CLI per la gestione dell'archiviazione di oggetti quando lavori con progetti air-gap di Google Distributed Cloud (GDC). Vengono descritti il download, l'installazione e la configurazione dei componenti e delle impostazioni necessari per utilizzare in modo efficace i bucket e gli oggetti di archiviazione in questo ambiente isolato.

Questa pagina è rivolta a segmenti di pubblico come gli amministratori IT all'interno del gruppo di operatori dell'infrastruttura o gli sviluppatori all'interno del gruppo di operatori dell'applicazione che vogliono eseguire il provisioning e gestire i bucket di archiviazione degli oggetti per i progetti all'interno degli ambienti GDC con air gap. Per saperne di più, consulta Segmenti di pubblico per la documentazione GDC con air gap.

Prima di iniziare

Per installare e configurare la CLI Storage, contatta l'amministratore IAM dell'organizzazione per richiedere il ruolo Amministratore policy di rete dell'organizzazione (org-network-policy-admin), che ti consente di creare, modificare ed eliminare le policy di rete dell'organizzazione.

Scarica gcloud CLI

Segui le istruzioni per scaricare gcloud CLI.

Installa la CLI gdcloud

Per utilizzare la struttura dei comandi di archiviazione, è necessario installare il componente delle dipendenze di archiviazione.

Segui le istruzioni riportate in Installa gcloud CLI.
Per installare il componente delle dipendenze di archiviazione, esegui i seguenti comandi:
```
gdcloud components install storage-cli-dependencies
```
Per saperne di più sul comando components install, consulta Installa gcloud CLI.

Configura la CLI gdcloud per l'archiviazione di oggetti

Per utilizzare la CLI gdcloud per l'archiviazione di oggetti, devono essere impostate le seguenti configurazioni.

Sostituisci ACCESS_KEY_ID con l'ID chiave di accesso ottenuto dal secret in Recupero delle credenziali di accesso:
```
gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID
```
Sostituisci SECRET_ACCESS_KEY con la chiave segreta ottenuta dal secret in Ottenere le credenziali di accesso:
```
gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY
```
Sostituisci CA_BUNDLE_FILE con il percorso del certificato CA. Si tratta di un certificato digitale appartenente a un'autorità di certificazione (CA), un'organizzazione attendibile che garantisce le identità. Puoi richiedere il bundle di attendibilità CA GDC a un membro del tuo gruppo di operatori dell'infrastruttura (IO). Per saperne di più su come ottenere i certificati CA GDC, vedi Recuperare i bundle di attendibilità GDC.
```
gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE
```
Nota: se i certificati CA per GDC sono già installati nell'ambiente, puoi impostare questo valore su /etc/ssl/certs/ca-certificates.crt
Sostituisci ENDPOINT con l'endpoint fornito dall'operatore dell'infrastruttura (IO):
```
gdcloud config set storage/s3_endpoint ENDPOINT
```
Nota: questo è l'endpoint completo che inizia con https://.

Questo passaggio è leggermente diverso per i bucket a doppia zona. Ogni bucket dual-zone fornisce tre endpoint che puoi scegliere per accedere al bucket. Nella maggior parte dei casi, l'endpoint globale è appropriato per sfruttare i failover automatici:
- Endpoint Zone1: questo endpoint viene sempre ricevuto dalla zona 1. Se utilizzi questo endpoint, hai una coerenza di lettura dopo scrittura per tutti gli oggetti scritti in zona1. Tuttavia, se la zona 1 non è disponibile, un client deve passare all'utilizzo dell'endpoint globale o della zona 2 per continuare a leggere/scrivere in questo bucket. Se il client proviene da un cluster utente, questo endpoint sarà accessibile solo dall'interno della zona 1.
- Endpoint Zone2: questo endpoint viene sempre ricevuto da Zone2. Se utilizzi questo endpoint, hai una coerenza read-after-write per tutti gli oggetti scritti in zona2. Tuttavia, se la zona 2 non funziona, un client deve passare all'utilizzo dell'endpoint della zona 1 o globale per continuare a leggere/scrivere in questo bucket. Se il client proviene da un cluster utente, questo endpoint sarà accessibile solo dall'interno di zone2.
- Endpoint globale: questo endpoint comporta il routing della richiesta alla zona 1 o alla zona 2. Questa opzione non fornisce l'affinità sessione, il che significa che le richieste effettuate utilizzando la stessa sessione potrebbero arrivare nella zona 1 o nella zona 2. Ciò significa che non esiste alcuna garanzia di lettura dopo la scrittura per le richieste effettuate all'endpoint globale. L'endpoint globale fornisce il failover automatico nel caso in cui una zona non sia più disponibile, quindi gli utenti non dovranno modificare gli endpoint nei loro carichi di lavoro come dovrebbero fare se utilizzassero l'endpoint di zona. Inoltre, questo endpoint è accessibile dai cluster utente in tutte le zone.
Esegui i seguenti comandi sul server API Management per visualizzare gli endpoint globali e di zona per il tuo bucket e scegliere quello che vuoi utilizzare:
```
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
```