Migrer depuis Amazon S3 vers Cloud Storage

Cette page explique comment migrer depuis Amazon Simple Storage Service (Amazon S3) vers Cloud Storage pour les utilisateurs envoyant des requêtes via une API.

Si vous débutez sur Cloud Storage et que vous ne souhaitez pas utiliser directement l'API, vous pouvez envisager d'utiliser Google Cloud Console pour définir et gérer les transferts. Google Cloud Console fournit une interface graphique à Cloud Storage qui vous permet, à l'aide d'un simple navigateur, d'accomplir la plupart de vos tâches de stockage, y compris la migration de vos données depuis Amazon S3 vers Cloud Storage.

Présentation de la migration

Si vous êtes un utilisateur d'Amazon S3, vous pouvez facilement migrer vos applications qui utilisent Amazon S3 vers Cloud Storage. Il existe deux options de migration :

  • Migration simple : il s'agit du moyen le plus simple pour faire vos premiers pas avec Cloud Storage si vous venez d'Amazon S3, car il vous suffit d'apporter quelques petites modifications aux outils et aux bibliothèques que vous utilisez actuellement avec Amazon S3.

  • Migration complète : une migration complète d'Amazon S3 vers Cloud Storage requiert quelques étapes supplémentaires par rapport à une simple migration. Toutefois, cela vous permet de bénéficier de toutes les fonctionnalités de Cloud Storage, y compris la prise en charge de plusieurs projets et de l'authentification OAuth 2.0.

Migration simple

Lors d'une migration simple depuis Amazon S3 vers Cloud Storage, vous pouvez utiliser vos outils et bibliothèques existants pour générer des requêtes REST authentifiées vers Amazon S3, afin d'envoyer également des requêtes authentifiées à Cloud Storage. Les seules actions que vous devez effectuer pour envoyer des requêtes à Cloud Storage sont les suivantes :

  • Définissez un projet Google par défaut.
  • Obtenez une clé HMAC.
  • Effectuez les modifications suivantes dans vos outils ou bibliothèques existants :

    • Modifiez le point de terminaison de la requête pour utiliser le point de terminaison de requête de l'API XML pour Cloud Storage.
    • Remplacez la clé secrète et la clé d'accès d'Amazon Web Services (AWS) par l'ID d'accès et le secret correspondants de Cloud Storage (désignés par le terme unique "votre clé HMAC Cloud Storage").
    • Assurez-vous que vos en-têtes x-amz- utilisent des valeurs autorisées par Cloud Storage. Par exemple, x-amz-storage-class doit utiliser l'une des classes de stockage Cloud Storage disponibles.

      Lorsque vous utilisez l'API XML de Cloud Storage dans un scénario de migration simple, spécifier l'identifiant de signature AWS dans l'en-tête Authorization informe Cloud Storage de l'utilisation des en-têtes x-amz-* et de la syntaxe XML LCA d'Amazon S3 dans votre requête. Cloud Storage traite les en-têtes x-amz-* qui possèdent un équivalent x-goog-*, tels que ceux répertoriés dans le tableau d'en-têtes.

Grâce à ces modifications, vous pouvez commencer à utiliser vos outils et bibliothèques existants pour envoyer des requêtes de code HMAC (Hash Message Authentication Code) à Cloud Storage.

Les exemples suivants montrent comment répertorier les buckets Cloud Storage à l'aide du SDK Amazon S3 :

Go

Pour en savoir plus, consultez la documentation de référence de l'API Cloud Storage en langage Go.

import (
	"context"
	"fmt"
	"io"
	"time"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/credentials"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/s3"
)

func listGCSBuckets(w io.Writer, googleAccessKeyID string, googleAccessKeySecret string) error {
	// googleAccessKeyID := "Your Google Access Key ID"
	// googleAccessKeySecret := "Your Google Access Key Secret"

	// Create a new client and do the following:
	// 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
	// 2. Use Cloud Storage HMAC Credentials.
	sess := session.Must(session.NewSession(&aws.Config{
		Region:      aws.String("auto"),
		Endpoint:    aws.String("https://storage.googleapis.com"),
		Credentials: credentials.NewStaticCredentials(googleAccessKeyID, googleAccessKeySecret, ""),
	}))

	client := s3.New(sess)
	ctx := context.Background()

	ctx, cancel := context.WithTimeout(ctx, time.Second*10)
	defer cancel()
	result, err := client.ListBucketsWithContext(ctx, &s3.ListBucketsInput{})
	if err != nil {
		return fmt.Errorf("ListBucketsWithContext: %v", err)
	}

	fmt.Fprintf(w, "Buckets:")
	for _, b := range result.Buckets {
		fmt.Fprintf(w, "%s\n", aws.StringValue(b.Name))
	}

	return nil
}

Java

Pour en savoir plus, consultez la documentation de référence sur l'API Cloud Storage en langage Java.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.Bucket;
import java.util.List;

public class ListGcsBuckets {
  public static void listGcsBuckets(String googleAccessKeyId, String googleAccessKeySecret) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds =
        new BasicAWSCredentials(googleAccessKeyId, googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient =
        AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current buckets
    List<Bucket> buckets = interopClient.listBuckets();

    // Print bucket names
    System.out.println("Buckets:");
    for (Bucket bucket : buckets) {
      System.out.println(bucket.getName());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }

Python

Pour en savoir plus, consultez la documentation de référence sur l'API Cloud Storage en langage Python.

import boto3

def list_gcs_buckets(google_access_key_id, google_access_key_secret):
    """Lists all GCS buckets using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.
    client = boto3.client(
        "s3",
        region_name="auto",
        endpoint_url="https://storage.googleapis.com",
        aws_access_key_id=google_access_key_id,
        aws_secret_access_key=google_access_key_secret,
    )

    # Call GCS to list current buckets
    response = client.list_buckets()

    # Print bucket names
    print("Buckets:")
    for bucket in response["Buckets"]:
        print(bucket["Name"])

Bien que la plupart des actions soient disponibles via le SDK Amazon S3 V2, il n'est possible de répertorier les objets qu'avec la méthode disponible dans le SDK Amazon S3 V1. Les exemples suivants montrent comment utiliser cette méthode pour répertorier des objets :

Go

Pour en savoir plus, consultez la documentation de référence de l'API Cloud Storage en langage Go.

import (
	"context"
	"fmt"
	"io"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/credentials"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/s3"
)

func listGCSObjects(w io.Writer, bucketName string, googleAccessKeyID string, googleAccessKeySecret string) error {
	// bucketName := "your-gcs-bucket-name"
	// googleAccessKeyID := "Your Google Access Key ID"
	// googleAccessKeySecret := "Your Google Access Key Secret"

	// Create a new client and do the following:
	// 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
	// 2. Use Cloud Storage HMAC Credentials.
	sess := session.Must(session.NewSession(&aws.Config{
		Region:      aws.String("auto"),
		Endpoint:    aws.String("https://storage.googleapis.com"),
		Credentials: credentials.NewStaticCredentials(googleAccessKeyID, googleAccessKeySecret, ""),
	}))

	client := s3.New(sess)
	ctx := context.Background()

	result, err := client.ListObjectsWithContext(ctx, &s3.ListObjectsInput{
		Bucket: aws.String(bucketName),
	})
	if err != nil {
		return fmt.Errorf("ListObjectsWithContext: %v", err)
	}

	fmt.Fprintf(w, "Objects:")
	for _, o := range result.Contents {
		fmt.Fprintf(w, "%s\n", aws.StringValue(o.Key))
	}

	return nil
}

Java

Pour en savoir plus, consultez la documentation de référence sur l'API Cloud Storage en langage Java.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.ObjectListing;
import com.amazonaws.services.s3.model.S3ObjectSummary;

public class ListGcsObjects {
  public static void listGcsObjects(
      String googleAccessKeyId, String googleAccessKeySecret, String bucketName) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";
    // String bucketName = "bucket-name";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds =
        new BasicAWSCredentials(googleAccessKeyId, googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient =
        AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current objects
    ObjectListing objects = interopClient.listObjects(bucketName);

    // Print objects names
    System.out.println("Objects:");
    for (S3ObjectSummary object : objects.getObjectSummaries()) {
      System.out.println(object.getKey());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }
}

Python

Pour en savoir plus, consultez la documentation de référence sur l'API Cloud Storage en langage Python.

import boto3

def list_gcs_objects(google_access_key_id, google_access_key_secret, bucket_name):
    """Lists GCS objects using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.

    client = boto3.client(
        "s3",
        region_name="auto",
        endpoint_url="https://storage.googleapis.com",
        aws_access_key_id=google_access_key_id,
        aws_secret_access_key=google_access_key_secret,
    )

    # Call GCS to list objects in bucket_name
    response = client.list_objects(Bucket=bucket_name)

    # Print object names
    print("Objects:")
    for blob in response["Contents"]:
        print(blob["Key"])

Définir un projet par défaut

Pour utiliser Cloud Storage dans un scénario de migration simple, nous vous recommandons de définir un projet par défaut. Lorsque vous définissez un projet par défaut, vous indiquez à Cloud Storage le projet à utiliser pour des opérations telles que le service GET ou le bucket PUT. Si vous ne configurez pas de projet par défaut, vous devez spécifier un en-tête de projet dans certaines requêtes.

Pour définir un projet par défaut, procédez comme suit :

  1. Ouvrez la page Paramètres Cloud Storage dans Google Cloud Console.
  2. Sélectionnez l'onglet Interopérabilité.
  3. Cliquez sur Définir PROJECT-ID comme projet par défaut dans la section Projet par défaut pour l'accès interopérable.

    Si le projet est déjà le projet par défaut, le message PROJECT-ID est votre projet par défaut pour l'accès interopérable s'affiche.

Ce projet est maintenant défini comme votre projet par défaut. Vous pouvez modifier votre projet par défaut à tout moment en choisissant un projet différent et en suivant les instructions ci-dessous.

Autre possibilité : spécifier un en-tête de projet

Au lieu ou en plus de définir un projet par défaut, vous pouvez utiliser l'en-tête x-amz-project-id dans chaque requête nécessitant de spécifier un projet.

  • Une requête dont l'en-tête x-amz-project-id est défini utilise le projet spécifié dans cet en-tête, même si vous avez défini un projet par défaut.

L'en-tête x-amz-project-id est utile dans les cas suivants :

  • Vous utilisez plusieurs projets.
  • Vos requêtes sont effectuées par un compte de service associé à un autre projet, car les comptes de service utilisent leur projet parent comme projet par défaut.

Notez qu'Amazon S3 n'inclut pas de projets. Par conséquent, vous ne pouvez pas spécifier un en-tête x-amz-project-id selon les outils ou les bibliothèques clientes que vous utilisez. Dans ce cas, vous devez définir un projet par défaut.

Utiliser les clés HMAC pour une migration simple

Pour utiliser l'API XML de Cloud Storage dans un scénario de migration simple, vous devez utiliser les clés HMAC (Hash-based Message Authentication Code) en tant qu'identifiants. En règle générale, vous devez créer une clé HMAC associée à un compte de service, mais vous pouvez également en utiliser une associée à un compte utilisateur.

S'authentifier dans un scénario de migration simple

En-tête d'autorisation

Pour les opérations nécessitant une authentification dans le cadre d'un scénario de migration simple, vous devez inclure un en-tête de requête Authorization comme vous le feriez pour les requêtes adressées à Amazon S3. La syntaxe de l'en-tête Authorization pour une requête Amazon S3 est la suivante :

Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

Dans un scénario de migration simple, vous modifiez uniquement l'en-tête pour utiliser votre ID d'accès HMAC Google et vous vous assurez que la Signature qui y est jointe est bien calculée avec votre clé secrète HMAC Google :

Authorization: ALGORITHM Credential=GOOG-ACCESS-ID/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

L'en-tête Authorization comporte les parties suivantes :

  • ALGORITHM : l'algorithme de signature et la version dont vous vous servez. L'utilisation de AWS4-HMAC-SHA256 indique que vous utilisez une signature HMAC V4 et que vous avez l'intention d'envoyer des en-têtes x-amz-*. Vous pouvez également vous servir de GOOG4-HMAC-SHA256, ce qui indiquerait que vous utilisez une signature HMAC V4 et que vous avez l'intention d'envoyer des en-têtes x-goog-*.

  • GOOG-ACCESS-ID : l'ID d'accès identifie l'entité qui émet et signe la requête. Dans une migration simple, remplacez l'ID de clé d'accès Amazon Web Service (AWS) que vous utilisez pour accéder à Amazon S3 par votre ID d'accès HMAC Google. Votre ID d'accès HMAC Google commence par GOOG.

  • CREDENTIAL_SCOPE : champ d'application des identifiants, tel que défini dans la signature. Dans le cadre d'une migration simple, vous n'avez pas besoin de modifier le champ d'application des identifiants si vous utilisez AWS4-HMAC-SHA256 comme valeur pour ALGORITHM.

  • SIGNED_HEADERS : liste des noms des en-têtes, séparés par des points-virgules, devant être inclus pour signer cette requête. Tous les en-têtes doivent être en lettres minuscules et triés par code de caractère.

    Voici un exemple de chaîne d'en-têtes signée de style Amazon S3 :

    content-type;host;x-amz-date

    Dans une migration simple, vous n'avez pas besoin de modifier la chaîne d'en-têtes signée.

  • SIGNATURE : signature permettant d'authentifier la requête. Dans une migration simple, remplacez les informations de la clé d'accès AWS par les informations de la clé HMAC Google équivalentes.

Exemple de requête d'authentification

Les exemples suivants permettent d'importer un objet nommé /europe/france/paris.jpg dans un bucket nommé my-travel-maps, d'appliquer la LCA prédéfinie public-read et de définir un en-tête de métadonnées personnalisé pour les examinateurs. Voici la requête pour un bucket dans Amazon S3 :

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Voici la requête pour un bucket dans Cloud Storage :

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=GOOG-ACCESS-ID/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Voici la requête canonique correspondante ayant été créée pour cette requête :

PUT
/europe/france/paris.jpg

content-length:888814
content-type:image/jpg
host:my-travel-maps.storage.googleapis.com
x-amz-acl:public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer:joe,jane

content-length,content-type,host,x-amz-acl,x-amz-date,x-amz-meta-reviewer
82e3da8b3f35989512e8d428add7eca73ab0e5f36586e66fbad8e1051343cbd2

Voici la chaîne de caractères à signer correspondante ayant été créée pour cette requête :

AWS4-HMAC-SHA256
20190311T192918Z
20190311/us-east-1/s3/aws4_request
73918a5ff373d7a03e406fbf9ea35675396b06fca2af76c27a5c451fa783ef65

Cette requête n'ayant pas fourni d'en-tête Content-MD5, une chaîne vide est affichée dans le message (deuxième ligne).

Contrôle des accès dans un scénario de migration simple

Pour être compatible avec les migrations simples, Cloud Storage accepte les LCA produites par Amazon S3. Dans un scénario de migration simple, vous utiliserez AWS comme identifiant de signature indiquant à Cloud Storage de s'attendre à une syntaxe LCA utilisant la syntaxe XML de la LCA d'Amazon S3. Vous devez vous assurer que les LCA d'Amazon S3 que vous utilisez sont mappées sur le modèle LCA de Cloud Storage. Par exemple, si vos outils et bibliothèques utilisent la syntaxe LCA d'Amazon S3 pour accorder une autorisation de bucket WRITE, ils doivent également octroyer une autorisation de bucket READ, car les autorisations de Cloud Storage sont concentriques. Il n'est pas nécessaire de spécifier à la fois les autorisations WRITE et READ lorsque vous accordez l'autorisation WRITE à l'aide de la syntaxe de Cloud Storage.

Cloud Storage est compatible avec la syntaxe LCA d'Amazon S3 dans les scénarios suivants :

  • En cas de requête adressée à Cloud Storage pour récupérer des LCA (par exemple, une requête "GET Object" ou "GET Bucket"), Cloud Storage renvoie la syntaxe LCA d'Amazon S3.
  • En cas de requête adressée à Cloud Storage pour appliquer des LCA (par exemple, une requête "PUT Object" ou "PUT Bucket"), Cloud Storage s'attend à recevoir la syntaxe LCA d'Amazon S3.

Dans un scénario de migration simple, l'en-tête Authorization utilisera AWS comme identifiant de signature, mais avec votre ID d'accès Google.

Authorization: AWS4-HMAC-SHA256 Credential=GOOG-ACCESS-ID/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

L'exemple suivant est une requête GET adressée à Cloud Storage pour renvoyer les LCA à un objet.

GET europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

La réponse à la requête inclut la LCA utilisant la syntaxe d'Amazon S3.

<?xml version='1.0' encoding='UTF-8'?>
<AccessControlPolicy>
    <Owner>
        <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490
        </ID>
        <DisplayName>OwnerName</DisplayName>
    </Owner>
    <AccessControlList>
        <Grant>
            <Grantee xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
                xsi:type='CanonicalUser'>
                <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490</ID>
                <DisplayName>UserName</DisplayName>
            </Grantee>
            <Permission>FULL_CONTROL</Permission>
        </Grant>
    </AccessControlList>
</AccessControlPolicy>

L'exemple suivant est une requête PUT adressée à Cloud Storage pour définir les LCA sur un objet. L'exemple montre un corps de requête avec la syntaxe LCA d'Amazon S3.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
Content-Length: 337
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AmazonCustomerByEmail">
        <EmailAddress>jane@gmail.com</EmailAddress>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Enfin, dans un scénario de migration simple, vous pouvez également utiliser l'identifiant de signature GOOG1 dans l'en-tête Authorization. Dans ce cas, vous devez utiliser la syntaxe LCA de Cloud Storage et vous assurer que tous vos en-têtes sont des en-têtes Google, sous la forme x-goog-*. Bien que cela soit une possibilité, nous vous recommandons de passer à une migration complète telle que décrite ci-dessous afin de tirer pleinement parti des avantages de Cloud Storage.

Migration complète

Une migration complète d'Amazon S3 vers Cloud Storage vous permet de bénéficier de toutes les fonctionnalités de Cloud Storage, y compris de l'authentification OAuth 2.0. 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 Google 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 la section Authentification OAuth 2.0.

Pour une migration complète d'Amazon S3 vers Cloud Storage, vous devez apporter les modifications suivantes :

  • 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>

Contrôle des accès dans une migration complète

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 permettant 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 d'accès privé, en lecture publique, en 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.

Il existe quelques différences entre l'API XML de Cloud Storage et celle d'Amazon S3. En voici un résumé, avec les alternatives suggérées pour Cloud Storage :

Fonctionnalité Amazon S3 Fonctionnalité de l'API XML de Cloud Storage
Importation en plusieurs parties
POST /<object-name>, PUT /<object-name>

Dans l'API XML de Cloud Storage, vous pouvez importer une série d'objets de type composant, en effectuant une importation séparée pour chaque composant. Vous pouvez ensuite composer les objets pour en faire un seul objet composite.

Remarque : Bien que l'API JSON offre une fonctionnalité d'importation en plusieurs parties, nous utilisons cette fonction pour envoyer des métadonnées avec des données d'objet. Cela n'est pas équivalent à la fonctionnalité d'importation en plusieurs parties de S3.

Paramètres de chaîne de requête du bucket GET/POST :
  • "policy" : Utilisation des stratégies de bucket Amazon S3.
  • "website" : Configuration de sites Web de bucket.
  • "tagging" : Marquage des buckets à des fins de répartition des coûts.
  • "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.
  • "website" : Exécutez la commande gsutil web pour gérer des sites Web, ou essayez l'API JSON (consultez le document sur les buckets).
  • "tagging" : Utilisez plusieurs projets pour suivre différents centres de coûts. Pour plus d'informations sur les projets, consultez le document Gestion des projets.
  • "notification" : Utilisez les notifications Pub/Sub de gsutil ou de l'API JSON.
  • "requestPayment" : Utilisez plusieurs projets avec différents profils de facturation pour gérer les personnes assumant les frais des requêtes et des données téléchargées à partir d'un bucket. Pour plus d'informations sur la configuration de la facturation, consultez la section Facturation de la documentation d'aide de la console API Google.
Supprimer plusieurs objets.
POST /?delete

Utilisez la commande rm gsutil pour supprimer facilement plusieurs objets. La commande rm accepte l'option "-m" pour effectuer des suppressions parallèles (suppressions multithread/multitraitement).

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.

Compatibilité de l'API XML avec Amazon S3

Pour plus d'informations sur l'interopérabilité des API XML, consultez les discussions marquées par la balise google-cloud-storage sur Stack Overflow. Consultez la page Ressources et assistance pour en savoir plus sur les forums de discussion et l'abonnement aux annonces.