Migra completamente de Amazon S3 a Cloud Storage

En esta página, se describe cómo migrar completamente de Amazon Simple Storage Service (Amazon S3) a Cloud Storage para los usuarios que envían solicitudes mediante una API. Después de migrar por completo, puedes usar todas las funciones de Cloud Storage, incluidos los proyectos múltiples y OAuth 2.0 para la autenticación.

Si deseas comenzar a usar Cloud Storage rápidamente, puedes elegir una migración simple, que requiere solo unos pocos cambios sencillos en las herramientas y bibliotecas que usas actualmente con Amazon S3.

Migra de Amazon S3 a Cloud Storage

Para migrar por completo de Amazon S3 a Cloud Storage, debes completar los siguientes pasos:

  • Cambia los encabezados x-amz-* existentes por los encabezados x-goog-* correspondientes.
  • Cambia el XML de la Lista de control de acceso (LCA) de AWS al XML de LCA de Cloud Storage correspondiente (consulta Crea y administra Listas de control de acceso).
  • Consulta el encabezado x-goog-project-id en tus solicitudes.

  • Prepárate para usar la autenticación OAuth 2.0 como se describe en Autenticación OAuth 2.0. El primer paso es registrar tu aplicación (desde la que vas a emitir las solicitudes) con Google. Si usas OAuth 2.0, el encabezado Authorization se verá de la siguiente manera:

    Authorization: Bearer OAUTH2_TOKEN

    OAuth 2.0 se basa en SSL para la seguridad, en lugar de requerir que tu aplicación realice una firma criptográfica directamente, y es más fácil de implementar. Con OAuth, tu aplicación puede solicitar acceso a los datos asociados con la cuenta de usuario de un usuario, y el acceso puede alcanzar varios niveles, incluidos solo lectura, lectura y escritura y control total. Para obtener más información, consulta los permisos de OAuth 2.0 de Cloud Storage y Cómo acceder a los datos en nombre de un usuario.

Control de acceso

En esta sección, se muestran algunos ejemplos de control de acceso para ayudarte a migrar de Amazon S3 a Cloud Storage. Para obtener una descripción general del control de acceso en Cloud Storage, consulta la documentación sobre el control de acceso.

En Cloud Storage, hay varias formas de aplicar LCA a buckets y objetos (consulta Crea y administra listas de control de acceso). Dos de las formas de especificar LCA son similares a la forma en que se hace en Amazon S3:

  • El parámetro de string de consulta acl te permite aplicar LCA para permisos específicos.
  • El encabezado de solicitud x-goog-acl te permite aplicar LCA predefinidas, que a veces se conocen como LCA conservadas

Usa el parámetro de string de consulta acl

Puedes usar el parámetro de string de consulta acl para una solicitud de Cloud Storage exactamente como lo harías con una solicitud de Amazon S3. El parámetro acl se usa junto con el método PUT para aplicar las LCA a los siguientes elementos: un objeto existente, un bucket existente o un bucket que estés creando. Cuando utilizas el parámetro de string de consulta acl en una solicitud PUT, debes adjuntar un documento XML (con la sintaxis de LCA de Cloud Storage) al cuerpo de tu solicitud. El documento XML contiene las entradas individuales de LCA que deseas aplicar al objeto o bucket.

En el siguiente ejemplo, se muestra una solicitud PUT a Amazon S3 que usa el parámetro de string de consulta acl. Las LCA se definen en un documento XML enviado en el cuerpo de la solicitud. La solicitud PUT cambia las LCA de un objeto llamado europe/france/paris.jpg que se encuentra en un bucket llamado my-travel-maps. La LCA otorga permiso de FULL_CONTROL a jane@gmail.com.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 19:28:18 GMT
Content-Length: 598
Content-Type: application/xml
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=4c45f25bb679fdab0de5a287625d6a143414728d93c9aeb9f4cc91c33a1c45fg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <Owner>
    <ID>5a6557ba40f7c86496ffceae789fcd888abc1b62a7149873a0fe12c0f60a7d95</ID>
    <DisplayName>ownerEmail@example.com</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>fd447671d60b979f78ee6fcec7b22afc80e6b26a4db16eed01afb8064047949b</ID>
        <DisplayName>jane@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

A continuación, se muestra la misma solicitud en Cloud Storage:

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 19:37:33 GMT
Content-Length: 268
Content-Type: application/xml
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlList>
  <Entries>
  <Entry>
    <Permission>FULL_CONTROL</Permission>
    <Scope type="UserByEmail">
      <EmailAddress>jane@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

Ten en cuenta que Cloud Storage no requiere un elemento <Owner/> en el documento XML de la LCA. Para obtener más información, consulta la sección sobre la propiedad de depósitos y objetos.

También puedes recuperar tus depósitos y objetos de LCA a través del parámetro de string de consulta acl con el método GET. Las LCA se describen en un documento XML, que se adjunta al cuerpo de la respuesta. Debes tener el permiso FULL_CONTROL para aplicar o recuperar las LCA en un objeto o bucket.

Aplica las LCA con un encabezado de solicitud de extensión

Puedes usar el encabezado x-goog-acl en una solicitud de Cloud Storage para aplicar las LCA predefinidas a depósitos y objetos exactamente como lo harías en el encabezado x-amz-acl en una solicitud de Amazon S3. Por lo general, debes usar el encabezado x-goog-acl (x-amz-acl) para aplicar una LCA predefinida a un bucket o un objeto cuando creas o subes el bucket o el objeto. Las LCA predeterminadas de Cloud Storage son similares a las LCA conservadas de Amazon S3, incluidas las privadas, las de lectura pública, las de lectura y escritura públicas y otras. Para obtener una lista de las LCA predefinidas de Cloud Storage, consulta la documentación sobre las LCA predefinidas.

En el siguiente ejemplo, se muestra una solicitud de objeto PUT que aplica la LCA public-read a un objeto llamado europe/france/paris.jpg que se sube en un bucket en Amazon S3 llamado my-travel-maps.

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 20:48:42 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=808150c37dbd1b425b2398421d6fc3dd6d4942dfaae9e519fd5835aa62fd62ab

<888814 bytes in entity body>

A continuación, se muestra la misma solicitud en Cloud Storage:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 20:49:57 GMT
Content-Length: 888814
Content-Type: image/jpg
x-goog-acl: public-read
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<888814 bytes in entity body>

También puedes usar el encabezado x-goog-acl para aplicar una LCA predefinida a un objeto o bucket existente. Para ello, incluye el parámetro de string de consulta acl en tu solicitud, pero no incluyas un documento XML. Aplicar una LCA predefinida en un objeto o bucket existente también es útil si deseas cambiar de una LCA predefinida a otra, o si deseas actualizar una LCA personalizada a una predefinida. Por ejemplo, en la siguiente solicitud de objeto PUT se aplica la LCA predefinida private a un objeto llamado europe/france/paris.jpg que se encuentra en un bucket llamado my-travel-maps.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 00:26:36 GMT
Content-Length: 0
x-goog-acl: private
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<empty entity body>

Para obtener más información sobre cómo administrar las LCA, consulta Crea y administra listas de control de acceso.

Migra de Amazon S3 a los métodos de solicitud de Cloud Storage

Cloud Storage admite los mismos métodos de solicitud HTTP estándar para leer y escribir datos en tus depósitos que Amazon S3. Por lo tanto, la mayoría de las herramientas y bibliotecas que usas actualmente con Amazon S3 funcionarán igual que con Cloud Storage. Cloud Storage admite los siguientes métodos de solicitud:

  • Solicitud de servicio para GET
  • Solicitudes de bucket, incluidas PUT, GET y DELETE
  • Solicitudes de objeto, incluidas GET, POST, PUT, HEAD y DELETE

Para obtener más información, consulta Métodos de referencia de la API de XML. Recuerda que cuando envías solicitudes a Cloud Storage, debes cambiar el cuerpo de la solicitud, si corresponde, para que use la sintaxis de Cloud Storage. Por ejemplo, cuando creas una configuración de ciclo de vida para un bucket, usa el XML de ciclo de vida de Cloud Storage, que es diferente al XML de ciclo de vida de Amazon S3.

Existen algunas diferencias entre la API de XML de Cloud Storage y Amazon S3 que se resumen a continuación:

Funcionalidad de Amazon S3 Funcionalidad de la API de XML de Cloud Storage
Cuando se usan claves de encriptación proporcionadas por el cliente en una carga multiparte, la solicitud final no incluye la clave de encriptación proporcionada por el cliente. En la API de XML de Cloud Storage, todas las solicitudes en una carga multiparte, incluida la solicitud final, requieren que proporciones la misma clave de encriptación proporcionada por el cliente. Este requisito existe porque Cloud Storage no almacena la información de tu clave de encriptación mientras espera a que la solicitud complete la carga, pero requiere la clave para calcular una suma de verificación para el objeto completado.
En Amazon S3, las firmas V4 se pueden usar para autenticar las cargas que usan codificación de transferencia fragmentada. En la API de XML de Cloud Storage, la codificación de transferencia fragmentada y las firmas V4 no se pueden usar simultáneamente por el momento. Algunas herramientas de Amazon S3 usan la codificación de transferencia fragmentada junto con las firmas de forma predeterminada. Debes inhabilitar la codificación de transferencia fragmentada en esos casos.
Parámetros de string de consulta de depósitos GET y POST:
  • “política”: trabaja con las políticas de bucket de Amazon S3
  • "notificación": Notificación de eventos de bucket
  • “requestPayment”: Configura quién paga la solicitud y la descarga de datos desde un bucket
Alternativas:
  • “política”: las LCA de Cloud Storage, la membresía del equipo del proyecto y la capacidad de usar múltiples proyectos abordan muchas de las situaciones en las que se usan las políticas de bucket.
  • "notificación": Usa la CLI de gcloud o la API de JSON Pub/Sub Notifications.
  • “requestPayment”: En Cloud Storage, el parámetro de string de consulta equivalente a requestPayment es billing.
Borra varios objetos.
POST /?delete

Usa la consola de Google Cloud para quitar varios objetos con facilidad.

Como alternativa, la API de JSON admite el envío de solicitudes por lotes para reducir la cantidad de conexiones HTTP que realiza tu cliente.

Migra de Amazon S3 a los encabezados de Cloud Storage

Cloud Storage usa varios encabezados HTTP estándar, así como varios encabezados HTTP personalizados (extensión). Si realizas la transición de Amazon S3 a Cloud Storage, puedes convertir los encabezados personalizados de Amazon S3 en un encabezado equivalente o en una funcionalidad similar, como se muestra en las tablas a continuación.

En muchos encabezados de Amazon S3, solo debes reemplazar el prefijo x-amz por x-goog:

Encabezado de Amazon S3 Encabezado de Cloud Storage
x-amz-storage-class x-goog-storage-class
x-amz-acl x-goog-acl
x-amz-date x-goog-date
x-amz-meta-* x-goog-meta-*
x-amz-copy-source x-goog-copy-source
x-amz-metadata-directive x-goog-metadata-directive
x-amz-copy-source-if-match x-goog-copy-source-if-match
x-amz-copy-source-if-none-match x-goog-copy-source-if-none-match
x-amz-copy-source-if-unmodified-since x-goog-copy-source-if-unmodified-since
x-amz-copy-source-if-modified-since x-goog-copy-source-if-modified-since

Varios encabezados son diferentes o no aplican para Cloud Storage:

Encabezado de Amazon S3 Encabezado de Cloud Storage
x-amz-server-side-encryption No requerido. Cloud Storage encripta automáticamente todos los datos antes de que se escriban en el disco. Para obtener más información, consulta Encriptación.
x-amz-grant-* x-goog-acl con un valor de LCA predefinida.
x-amz-version-id x-goog-generation
x-amz-mfa Usa la autenticación OAuth 2.0.
x-amz-decoded-content-length No se admite como encabezado x-goog.
x-amz-website-redirect-location, x-amz-copy-source-range N/A

Consulta los encabezados HTTP y los parámetros de string de consulta de la API de XML para obtener información acerca de los encabezados de Cloud Storage.

¿Qué sigue?