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êtesx-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 Identifiants de compte 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
etDELETE
. - Requêtes d'objet, y compris
GET
,POST
,PUT
,HEAD
etDELETE
.
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 :
|
Alternatives :
|
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-mfa |
Utilisez l'authentification OAuth 2.0. |
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
- Planifiez une migration depuis Amazon S3.
- Transférez vos données vers Cloud Storage à partir de sources externes, telles qu'Amazon S3 et Microsoft Azure Blob Storage, à l'aide du service de transfert de stockage.
- Créez des transferts basés sur des événements qui utilisent des notifications d'événement Amazon S3 pour maintenir la synchronisation d'un bucket Cloud Storage avec Amazon S3.