Migrar completamente de Amazon S3 a Cloud Storage

En esta página se describe cómo migrar por completo de Amazon Simple Storage Service (Amazon S3) a Cloud Storage para los usuarios que envían solicitudes mediante una API. Una vez que hayas completado la migración, podrás usar todas las funciones de Cloud Storage, incluidos varios proyectos y OAuth 2.0 para la autenticación.

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

Migrar de Amazon S3 a Cloud Storage

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

  • Cambia los encabezados x-amz-* por los encabezados x-goog-* correspondientes.
  • Cambia el XML de la lista de control de acceso (LCA) de AWS por el XML de la LCA de Cloud Storage correspondiente (consulta Crear y gestionar listas de control de acceso).
  • Define el encabezado x-goog-project-id en tus solicitudes.

  • Configura la autenticación OAuth 2.0. Si usas OAuth 2.0, el encabezado Authorization tendrá este aspecto:

    Authorization: Bearer OAUTH2_TOKEN

    OAuth 2.0 se basa en SSL para la seguridad en lugar de requerir que tu aplicación realice firmas criptográficas directamente, y es más fácil de implementar. Con OAuth, tu aplicación puede solicitar acceso a los datos asociados a la cuenta de un usuario. El acceso puede tener varios niveles, como 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 el artículo sobre cómo acceder a 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 Control de acceso.

En Cloud Storage, hay varias formas de aplicar LCA a los segmentos y objetos (consulta Crear y gestionar listas de control de acceso). Dos de las formas de especificar las LCAs son análogas a lo que se hace en Amazon S3:

  • El parámetro de cadena de consulta acl te permite aplicar LCAs a ámbitos específicos.
  • El encabezado de solicitud x-goog-acl te permite aplicar LCAs predefinidas, que a veces se conocen como LCAs predeterminadas.

Uso del parámetro de cadena de consulta acl

Puede usar el parámetro de cadena de consulta acl en una solicitud de Cloud Storage exactamente igual que en una solicitud de Amazon S3. El parámetro acl se usa junto con el método PUT para aplicar listas de control de acceso a lo siguiente: un objeto, un contenedor o un contenedor que estés creando. Cuando usas el parámetro de cadena de consulta acl en una solicitud PUT, debes adjuntar un documento XML (con la sintaxis de las LCA de Cloud Storage) al cuerpo de la solicitud. El documento XML contiene las entradas de LCA individuales que quieres aplicar al contenedor o al objeto.

En el siguiente ejemplo se muestra una solicitud PUT a Amazon S3 que utiliza el parámetro de cadena de consulta acl. Las ACLs se definen en un documento XML que se envía en el cuerpo de la solicitud. La solicitud PUT cambia las ACLs de un objeto llamado europe/france/paris.jpg que está en un segmento llamado my-travel-maps. La ACL concede el permiso jeffersonloveshiking@gmail.com FULL_CONTROL.

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>jeffersonloveshiking@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Esta es la misma solicitud a 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>jeffersonloveshiking@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

Tenga en cuenta que Cloud Storage no requiere un elemento <Owner/> en el documento XML de la ACL. Para obtener más información, consulta Propiedad de segmentos y objetos.

También puede obtener las listas de control de acceso de cubos y objetos mediante el parámetro de cadena de consulta acl con el método GET. Las listas de control de acceso se describen en un documento XML que se adjunta al cuerpo de la respuesta. Debes tener FULL_CONTROL permiso para aplicar o recuperar las listas de control de acceso de un objeto o un segmento.

Aplicar ACLs con un encabezado de solicitud de extensión

Puede usar el encabezado x-goog-acl en una solicitud de Cloud Storage para aplicar ACLs predefinidas a los contenedores y objetos de la misma forma que usaría el encabezado x-amz-acl en una solicitud de Amazon S3. Normalmente, se usa el encabezado x-goog-acl (x-amz-acl) para aplicar una LCA predefinida a un segmento o a un objeto al crear o subir el segmento o el objeto. Las LCA predefinidas de Cloud Storage son similares a las LCA predefinidas de Amazon S3, como private, public-read y public-read-write, entre otras. Para ver una lista de las LCAs predefinidas de Cloud Storage, consulta LCAs 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 está subiendo a un segmento llamado my-travel-maps en Amazon S3.

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>

Esta es la misma solicitud a 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 puede usar el encabezado x-goog-acl para aplicar una LCA predefinida a un objeto o un contenedor que ya exista. Para ello, incluya el parámetro de cadena de consulta acl en su solicitud, pero no incluya ningún documento XML. Aplicar una LCA predefinida a un objeto o un segmento ya creado es útil si quieres cambiar de una LCA predefinida a otra o si quieres actualizar las LCA personalizadas a una LCA predefinida. Por ejemplo, la siguiente solicitud de objeto PUT aplica la LCA predefinida private a un objeto llamado europe/france/paris.jpg que está en un segmento 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 gestionar ACLs, consulta el artículo Crear y gestionar listas de control de acceso.

Métodos de solicitud para migrar de Amazon S3 a Cloud Storage

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

  • Solicitud de servicio para GET.
  • Solicitudes de segmentos, incluidas PUT, GET y DELETE.
  • Peticiones de objetos, como GET, POST, PUT, HEAD y DELETE.

Para obtener más información, consulta los métodos de referencia de la API XML. Ten en cuenta que, cuando envíes solicitudes a Cloud Storage, deberás cambiar el cuerpo de la solicitud, si procede, para usar la sintaxis adecuada 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 del XML de ciclo de vida de Amazon S3.

A continuación, se resumen algunas diferencias entre la API XML de Cloud Storage y Amazon S3:

Funciones de Amazon S3 Funciones de la API XML de Cloud Storage
Cuando se usan claves de cifrado proporcionadas por el cliente en una subida multiparte, la solicitud final no incluye la clave de cifrado proporcionada por el cliente. En la API XML de Cloud Storage, todas las solicitudes de una subida multiparte, incluida la solicitud final, requieren que proporcione la misma clave de cifrado proporcionada por el cliente. Este requisito se debe a que Cloud Storage no almacena la información de tu clave de cifrado mientras espera a que se complete la subida, pero necesita la clave para calcular una suma de comprobación del objeto completado.
En Amazon S3, se pueden usar firmas V4 para autenticar las subidas que usan codificación de transferencia fragmentada. En la API XML de Cloud Storage, no se pueden usar simultáneamente la codificación de transferencia fragmentada y las firmas V4. Algunas herramientas de Amazon S3 usan la codificación de transferencia fragmentada junto con las firmas de forma predeterminada. En estos casos, debe inhabilitar la codificación de transferencia fragmentada.
Parámetros de cadena de consulta de segmentos GET/POST:
  • "policy": trabajar con políticas de segmentos de Amazon S3.
  • "notification": se usa para enviar notificaciones sobre eventos de cubos.
  • "requestPayment": configura quién paga la solicitud y la descarga de datos de un contenedor.
 Alternativas:
  • "policy" (política): las ACLs de Cloud Storage, la pertenencia al equipo del proyecto y la posibilidad de usar varios proyectos abordan muchas de las situaciones en las que se utilizan políticas de segmentos.
  • "notification": usa la CLI de gcloud o la API JSON Pub/Sub Notifications.
  • "requestPayment": en Cloud Storage, el parámetro de cadena de consulta equivalente a requestPayment es billing.
Eliminación de varios objetos.
POST /?delete

Usa la Google Cloud consola para quitar varios objetos fácilmente.

También puedes enviar solicitudes por lotes a la API JSON para reducir el número de conexiones HTTP que hace tu cliente.

Migrar de los encabezados de Amazon S3 a los de Cloud Storage

Cloud Storage usa varios encabezados HTTP estándar, así como varios encabezados HTTP personalizados (de extensión). Si vas a cambiar de Amazon S3 a Cloud Storage, puedes convertir tus encabezados personalizados de Amazon S3 en los encabezados personalizados de Cloud Storage equivalentes o en funciones similares, tal como se muestra en las tablas de abajo.

En muchos encabezados de Amazon S3, solo tienes que sustituir 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

Hay varios encabezados que son diferentes o no se aplican en Cloud Storage:

Encabezado de Amazon S3 Encabezado de Cloud Storage
x-amz-server-side-encryption No es obligatorio. Cloud Storage cifra automáticamente todos los datos antes de que se escriban en el disco. Para obtener más información, consulta Cifrado.
x-amz-grant-* x-goog-acl con un valor de LCA predefinido.
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 cadena de consulta de la API XML para obtener una referencia de los encabezados de Cloud Storage.

Siguientes pasos