Effectuer une migration complète depuis Amazon S3 vers Cloud Storage

Cette page explique comment migrer complètement depuis Amazon Simple Storage Service (Amazon S3) vers Cloud Storage pour les utilisateurs envoyant des requêtes via une API. Une fois la migration terminée, vous pouvez utiliser toutes les fonctionnalités de Cloud Storage, y compris les projets multiples et l'authentification OAuth 2.0.

Si vous souhaitez démarrer rapidement avec Cloud Storage, vous pouvez choisir une migration simple, qui ne nécessite que quelques modifications simples dans les outils et les bibliothèques que vous utilisez actuellement avec Amazon S3.

Migrer depuis Amazon S3 vers Cloud Storage

Pour une migration complète depuis Amazon S3 vers Cloud Storage, vous devez procéder comme suit:

  • Remplacez les en-têtes x-amz-* existants par les en-têtes x-goog-*.
  • Remplacez le fichier XML LCA (Liste de contrôle d'accès) d'AWS par le fichier XML LCA de Cloud Strorage correspondant (reportez-vous à la section Créer et gérer des listes de contrôle d'accès).
  • Définissez l'en-tête x-goog-project-id dans vos requêtes.

  • Préparez-vous à utiliser l'authentification OAuth 2.0 comme décrit dans le document Authentification OAuth 2.0. La première étape consiste à enregistrer votre application (depuis laquelle vous allez envoyer des requêtes) auprès de Google. Lorsque vous utilisez OAuth 2.0, votre en-tête Authorization ressemble à ceci :

    Authorization: Bearer OAUTH2_TOKEN

    OAuth 2.0 repose sur SSL pour la sécurité, au lieu de demander à votre application de procéder directement à la signature cryptographique, ce qui facilite également la mise en œuvre. OAuth permet à votre application de demander l'accès aux données associées au compte d'un utilisateur, et l'accès peut être limité à plusieurs niveaux, y compris en lecture seule, en lecture-écriture et en contrôle total. Pour en savoir plus, consultez les sections Champs d'application OAuth 2.0 de Cloud Storage et Accéder aux données au nom d'un utilisateur.

Contrôle des accès

Cette section présente quelques exemples de contrôle des accès pour vous aider dans votre migration d'Amazon S3 vers Cloud Storage. Pour en savoir plus sur le contrôle des accès dans Cloud Storage, consultez la section Contrôle des accès.

Dans Cloud Storage, il existe plusieurs façons d'appliquer des LCA à des buckets et à des objets (consultez la page Créer et gérer des listes de contrôle d'accès). Il existe deux manières de spécifier les LCA analogues à celle d'Amazon S3 :

  • Le paramètre de chaîne de requête acl vous permet d'appliquer des LCA à des champs d'application spécifiques.
  • L'en-tête de requête x-goog-acl qui permet d'appliquer des LCA prédéfinies, parfois appelées LCA standardisées.

Utiliser le paramètre de chaîne de requête "acl"

Vous pouvez utiliser le paramètre de chaîne de requête acl pour une requête Cloud Storage exactement de la même manière que pour une requête Amazon S3. Le paramètre acl est utilisé avec la méthode PUT pour appliquer des listes de contrôle d'accès aux éléments suivants : un objet existant, un bucket existant ou un bucket que vous créez. Lorsque vous utilisez le paramètre de chaîne de requête acl dans une requête PUT, vous devez joindre un document XML (à l'aide de la syntaxe LCA de Cloud Storage) au corps de votre requête. Le document XML contient les entrées individuelles de la LCA que vous souhaitez appliquer au bucket ou à l'objet.

L'exemple suivant montre une requête PUT adressée à Amazon S3 qui utilise le paramètre de chaîne de requête acl. Les LCA sont définies dans un document XML envoyé dans le corps de la requête. La requête PUT modifie les LCA sur un objet nommé europe/france/paris.jpg qui se trouve dans un bucket nommé my-travel-maps. La LCA accorde à jane@gmail.com l'autorisation 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>jane@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Voici la même requête adressée à 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>

Notez que Cloud Storage ne requiert pas d'élément <Owner/> dans le document XML de la LCA. Pour en savoir plus, consultez la documentation Propriété des buckets et des objets.

Vous pouvez également récupérer les LCA de bucket et d'objet à l'aide du paramètre de chaîne de requête acl avec la méthode GET. Les LCA sont décrites dans un document XML joint au corps de la réponse. Vous devez disposer de l'autorisation FULL_CONTROL pour appliquer ou récupérer des LCA à un objet ou un bucket.

Appliquer des LCA avec un en-tête de requête d'extension

Vous pouvez utiliser l'en-tête x-goog-acl dans une requête Cloud Storage pour appliquer des LCA prédéfinies à des buckets et des objets de la même manière que vous utiliseriez l'en-tête x-amz-acl dans une requête Amazon S3. Vous utilisez généralement l'en-tête x-goog-acl (x-amz-acl) pour appliquer une LCA prédéfinie à un bucket ou à un objet lors de la création ou du téléchargement du bucket ou de l'objet. Les LCA prédéfinies de Cloud Storage sont semblables aux LCA prédéfinies d'Amazon S3, y compris les LCA privées, à lecture publique, à lecture/écriture publique, et d'autres encore. Pour obtenir la liste des LCA prédéfinies de Cloud Storage, consultez le document Listes de contrôle d'accès prédéfinies.

L'exemple suivant montre une requête d'objet PUT qui applique la LCA public-read à un objet nommé europe/france/paris.jpg en cours d'importation vers un bucket nommé my-travel-maps dans 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>

Voici la même requête adressée à 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>

Vous utilisez généralement l'en-tête x-goog-acl pour appliquer une LCA prédéfinie à un bucket ou à un objet existant. Pour cela, utilisez le paramètre de chaîne de requête acl dans votre requête, mais n'y incluez pas de document XML. L'application d'une LCA prédéfinie à un objet ou à un bucket existant est utile si vous souhaitez passer d'une LCA prédéfinie à une autre ou mettre à jour des LCA personnalisées et les configurer en tant que LCA prédéfinies. Par exemple, la requête d'objet PUT suivante applique la LCA prédéfinie private à un objet nommé europe/france/paris.jpg qui se trouve dans un bucket nommé 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>

Pour en savoir plus sur la gestion des LCA, consultez la page Créer et gérer des listes de contrôle d'accès.

Migrer depuis Amazon  S3 vers Cloud Storage - Méthodes de requête

Cloud Storage est compatible avec les mêmes méthodes de requête HTTP standards pour la lecture et l'écriture de données dans vos buckets que celles utilisées dans Amazon S3. Par conséquent, la majorité des outils et bibliothèques que vous utilisez actuellement avec Amazon S3 fonctionneront tels quels avec Cloud Storage. Cloud Storage est compatible avec les méthodes de requête suivantes :

  • Requête de service pour GET.
  • Requêtes de bucket, y compris PUT, GET et DELETE.
  • Requêtes d'objet, y compris GET, POST, PUT, HEAD et DELETE.

Pour plus d'informations, consultez le document Méthodes de référence de l'API XML. Gardez à l'esprit que, lorsque vous envoyez des requêtes à Cloud Storage, vous devez éventuellement modifier le corps de la requête pour utiliser la syntaxe Cloud Storage appropriée. Par exemple, lorsque vous créez une configuration de cycle de vie pour un bucket, utilisez le XML de cycle de vie Cloud Storage, qui est différent du XML de cycle de vie d'Amazon S3.

Voici quelques différences entre l'API XML de Cloud Storage et Amazon S3 :

Fonctionnalité Amazon S3 Fonctionnalité de l'API XML de Cloud Storage
Lorsque vous utilisez des clés de chiffrement fournies par le client dans une importation en plusieurs parties, celle-ci n'est pas incluse dans la requête finale. Dans l'API XML de Cloud Storage, toutes les requêtes lors d'une importation en plusieurs parties, y compris la requête finale, nécessitent que vous fournissiez la même clé de chiffrement fournie par le client. Cette exigence existe, car Cloud Storage ne stocke pas les informations sur la clé de chiffrement en attendant que la requête effectue l'importation, mais il exige la clé pour calculer une somme de contrôle pour l'objet terminé.
Dans Amazon S3, les signatures V4 peuvent être utilisées pour authentifier les importations qui utilisent l'encodage de transfert fragmenté. Dans l'API XML de Cloud Storage, il est actuellement impossible d'utiliser simultanément l'encodage de transfert fragmenté et les signatures V4. Certains outils Amazon S3 utilisent l'encodage de transfert fragmenté avec les signatures par défaut. Dans ce cas, vous devez désactiver l'encodage de transfert fragmenté.
Paramètres de chaîne de requête du bucket GET/POST :
  • "policy" : Utilisation des stratégies de bucket Amazon S3.
  • "notification" : Notification pour les événements de bucket.
  • "requestPayment" : Configuration de la personne assumant les frais de la requête et du téléchargement de données à partir d'un bucket.
 Alternatives :
  • "policy" : Les LCA de Cloud Storage, l'appartenance à une équipe de projet et la possibilité d'utiliser plusieurs projets sont des alternatives qui répondent à de nombreux scénarios dans lesquels des stratégies de bucket sont utilisées.
  • "notification" : Utilisez la gcloud CLI ou les notifications Pub/Sub de l'API JSON.
  • "requestPayment" : Dans Cloud Storage, le paramètre de chaîne de requête équivalent à requestPayment est billing.
Supprimer plusieurs objets.
POST /?delete

Utilisez la console Google Cloud pour supprimer facilement plusieurs objets.

L'API JSON accepte également l'envoi de requêtes par lots afin de réduire le nombre de connexions HTTP établies par votre client.

Migrer depuis Amazon S3 vers Cloud Storage - En-têtes

Cloud Storage utilise plusieurs en-têtes HTTP standards ainsi que plusieurs en-têtes HTTP personnalisés (extensions). Si vous effectuez une transition depuis Amazon S3 vers Cloud Storage, vous pouvez convertir vos en-têtes Amazon S3 personnalisés en en-têtes Cloud Storage personnalisés équivalents ou en une fonctionnalité semblable, comme indiqué dans le tableau ci-dessous.

Pour bon nombre d'en-têtes Amazon S3, il suffit de remplacer le préfixe x-amz par x-goog :

En-tête Amazon S3 En-tête 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

Plusieurs en-têtes diffèrent ou ne sont pas applicables dans Cloud Storage:

En-tête Amazon S3 En-tête Cloud Storage
x-amz-server-side-encryption Facultatif. Cloud Storage chiffre automatiquement toutes les données avant qu'elles ne soient écrites sur le disque. Pour plus d'informations, consultez le document Chiffrement.
x-amz-grant-* x-goog-acl avec une valeur de LCA prédéfinie.
x-amz-version-id x-goog-generation
x-amz-mfa Utilisez l'authentification OAuth 2.0.
x-amz-decoded-content-length Non accepté en tant qu'en-tête x-goog
x-amz-website-redirect-location, x-amz-copy-source-range N/A

Pour en savoir plus sur les en-têtes Cloud Storage, consultez la documentation de référence En-têtes HTTP et paramètres de chaîne de requête avec l'API XML.

Étapes suivantes