Instala y configura la CLI de almacenamiento para proyectos

En esta página, se explica cómo instalar y configurar la CLI de gdcloud para administrar el almacenamiento de objetos cuando trabajas con proyectos aislados de Google Distributed Cloud (GDC). En él, se explica cómo descargar, instalar y configurar los componentes y parámetros de configuración necesarios para usar de manera eficaz los buckets y objetos de almacenamiento en este entorno aislado.

Esta página está dirigida a públicos como los administradores de TI del grupo de operadores de infraestructura o los desarrolladores del grupo de operadores de aplicaciones que desean aprovisionar y administrar buckets de almacenamiento de objetos para proyectos en entornos GDC aislados. Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

Antes de comenzar

Para instalar y configurar la CLI de Storage, comunícate con el administrador de IAM de tu organización y solicita el rol de Administrador de políticas de red de la organización (org-network-policy-admin), que te permite crear, editar y borrar políticas de red de la organización.

Descarga la CLI de gdcloud

Sigue las instrucciones para descargar la CLI de gcloud.

Instala la CLI de gdcloud

Para usar el árbol de comandos de almacenamiento, se debe instalar el componente de dependencias de almacenamiento.

  1. Sigue los pasos que se indican en Instala la gdcloud CLI.

  2. Para instalar el componente de dependencias de almacenamiento, ejecuta los siguientes comandos:

    gdcloud components install storage-cli-dependencies

    Para obtener más información sobre el comando components install, consulta Instala la gdcloud CLI.

Configura la CLI de gcloud para el almacenamiento de objetos

Se deben establecer las siguientes configuraciones para usar la CLI de gdcloud para el almacenamiento de objetos.

  1. Reemplaza ACCESS_KEY_ID por el ID de clave de acceso que obtuviste del secreto en cómo obtener credenciales de acceso:

    gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID

  2. Reemplaza SECRET_ACCESS_KEY por la clave secreta que obtuviste del secreto en cómo obtener credenciales de acceso:

    gdcloud config set storage/s3_secret_access_key SECRET_ACCESS_KEY

  3. Reemplaza CA_BUNDLE_FILE por la ruta de acceso al certificado de CA. Este es un certificado digital que pertenece a una autoridad certificadora (CA), una organización de confianza que garantiza identidades. Puedes solicitar el paquete de confianza de la CA del GDC a un miembro de tu grupo de operadores de infraestructura (IO). Para obtener más información sobre cómo obtener certificados de CA de GDC, consulta Cómo recuperar paquetes de confianza de GDC.

    gdcloud config set storage/s3_custom_ca_certs_file CA_BUNDLE_FILE

  4. Reemplaza ENDPOINT por el extremo que proporciona tu operador de infraestructura (IO):

    gdcloud config set storage/s3_endpoint ENDPOINT

    Este paso varía ligeramente para los buckets de doble zona. Cada bucket de doble zona proporciona tres extremos que puedes elegir para acceder al bucket. En la mayoría de los casos, el extremo global es adecuado para aprovechar las conmutaciones por error automáticas:

    • Extremo de Zone1: Zone1 siempre recibe este extremo. Si usas este extremo, tendrás coherencia de lectura después de escritura para cualquier objeto escrito en la zona1. Sin embargo, si la zona1 deja de funcionar, un cliente debe cambiar al extremo de la zona2 o al extremo global para seguir leyendo o escribiendo en este bucket. Si el cliente proviene de un clúster de usuario, solo se podrá acceder a este extremo desde la zona 1.
    • Extremo de Zone2: Zone2 siempre recibe este extremo. Si usas este extremo, tendrás coherencia de lectura después de escritura para cualquier objeto escrito en la zona2. Sin embargo, si la zona2 deja de funcionar, un cliente debe cambiar al extremo de la zona1 o al extremo global para seguir leyendo o escribiendo en este bucket. Si el cliente proviene de un clúster de usuario, solo se podrá acceder a este extremo desde la zona2.
    • Extremo global: Este extremo hace que tu solicitud se enrute a la zona 1 o a la zona 2. Esta opción no proporciona afinidad de sesión, lo que significa que las solicitudes realizadas con la misma sesión pueden llegar a la zona1 o a la zona2. Esto significa que no hay garantía de lectura después de escritura para las solicitudes realizadas al extremo global. El extremo global proporciona una conmutación por error automática en caso de que una zona deje de funcionar, por lo que los usuarios no tendrán que cambiar los extremos en sus cargas de trabajo como lo harían si usaran el extremo zonal. Además, se puede acceder a este extremo desde los clústeres de usuarios en todas las zonas.

    Ejecuta los siguientes comandos en el servidor de la API de administración para ver los extremos globales y zonales de tu bucket y elegir el que deseas 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