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 almacén de objetos cuando trabajas con proyectos de Google Distributed Cloud (GDC) aislado. Se explica cómo descargar, instalar y configurar los componentes y parámetros de configuración necesarios para usar de forma eficaz los buckets y objetos de almacenamiento en este entorno aislado.

Esta página está dirigida a públicos como administradores de TI dentro del grupo de operadores de infraestructura o desarrolladores dentro del grupo de operadores de aplicaciones que buscan aprovisionar y administrar buckets de almacén de objetos para proyectos dentro de entornos de GDC aislado. Para obtener más información, consulta Públicos de la documentación de GDC aislado.

Antes de comenzar

Para instalar y configurar la CLI de almacenamiento, comunícate con el administrador de la organización de IAM para solicitar 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 gdcloud.

Instala la CLI de gdcloud

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

  1. Sigue las instrucciones para instalar la CLI de gdcloud.

  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 CLI de gdcloud.

Configura la CLI de gdcloud para el almacenamiento de objetos

Se deben establecer los siguientes parámetros de configuración para usar la CLI de gdcloud en el almacén de objetos.

  1. Reemplaza ACCESS_KEY_ID por el ID de clave de acceso obtenido del Secret en Obtén credenciales de acceso:

    gdcloud config set storage/s3_access_key_id ACCESS_KEY_ID

  2. Reemplaza SECRET_ACCESS_KEY por la clave secreta obtenida del Secret en Obtén 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 la AC. Este es un certificado digital que pertenece a una autoridad certificadora (CA), una organización de confianza que avala las identidades. Puedes solicitar el paquete de confianza de la AC de GDC a un miembro de tu grupo de operadores de infraestructura (IO). Para obtener más información sobre cómo obtener certificados de la AC de GDC, consulta Recupera 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 un poco para los buckets de dos regiones. Cada bucket de doble región proporciona tres extremos que puedes elegir para acceder al bucket. En la mayoría de las situaciones, el extremo global es adecuado para aprovechar las conmutaciones por error automáticas:

    • Extremo de zone1: Este extremo siempre lo recibe zone1. Si usas este extremo, tendrás coherencia de lectura tras escritura para cualquier objeto escrito en zone1. Sin embargo, si zone1 deja de funcionar, un cliente debe cambiar al extremo zone2 o al 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 zona1.
    • Extremo de zone2: Este extremo siempre lo recibe zone2. Si usas este extremo, tendrás coherencia de lectura tras escritura para cualquier objeto escrito en zone2. Sin embargo, si zone2 deja de funcionar, un cliente debe cambiar al extremo de zone1 o al 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 2.
    • Extremo global: Este extremo hace que tu solicitud se enrute a zone1 o zone2. 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 zona 1 o a la zona 2. Esto significa que no hay garantía de lectura después de la 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 clústeres de usuario 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 elige el que quieras 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