Vollständig von Amazon S3 zu Cloud Storage migrieren

Auf dieser Seite wird beschrieben, wie Nutzer, die Anfragen über eine API senden, vollständig von Amazon Simple Storage Service (Amazon S3) zu Cloud Storage migrieren. Nach einer vollständigen Migration können Sie alle Features von Cloud Storage verwenden, einschließlich mehrerer Projekte und OAuth 2.0 zur Authentifizierung.

Wenn Sie schnell mit Cloud Storage beginnen möchten, können Sie eine einfache Migration auswählen, die nur wenige simple Änderungen an den Tools und Bibliotheken erfordert, die Sie aktuell mit Amazon S3 verwenden.

Von Amazon S3 zu Cloud Storage migrieren

Für eine vollständige Migration von Amazon S3 zu Cloud Storage müssen Sie folgende Schritte ausführen:

  • Ändern Sie alle vorhandenen Header des Typs x-amz-* in die entsprechenden Header des Typs x-goog-*.
  • Ändern Sie den ACL-XML-Code von AWS in den entsprechenden ACL-XML-Code von Cloud Storage (siehe Access Control Lists (ACLs) erstellen und verwalten).
  • Geben Sie in Ihren Anfragen den Header x-goog-project-id an.

  • Richten Sie wie unter Authentifizierung mit OAuth 2.0 beschrieben die Verwendung der Authentifizierung mit OAuth 2.0 ein. Der erste Schritt besteht darin, Ihre Anwendung, von der Sie Anfragen senden werden, bei Google anzumelden. Bei Verwendung von OAuth 2.0 sieht Ihr Authorization-Header so aus:

    Authorization: Bearer OAUTH2_TOKEN

    OAuth 2.0 greift für die Sicherheit auf SSL zurück und ist leichter zu implementieren. Ihre Anwendung muss also keine direkte kryptografische Signierung vornehmen. Mit OAuth kann Ihre Anwendung Zugriff auf Daten anfordern, die mit dem Konto eines Nutzer verknüpft sind. Der Zugriff kann mehrere Ebenen wie read-only, read-write und full-control umfassen. Weitere Informationen finden Sie unter Cloud Storage OAuth 2.0-Berechtigungen und Im Namen eines Nutzers auf Daten zugreifen.

Zugriffssteuerung

In diesem Abschnitt finden Sie einige Beispiele für die Zugriffssteuerung, die Ihnen die Migration von Amazon S3 zu Cloud Storage erleichtern sollen. Eine Übersicht über die Zugriffssteuerung in Cloud Storage finden Sie unter Zugriffssteuerungsoptionen.

In Cloud Storage gibt es mehrere Möglichkeiten, ACLs auf Buckets und Objekte anzuwenden (siehe Access Control Lists (ACLs) erstellen und verwalten). Zwei dieser Möglichkeiten zum Festlegen der ACLs entsprechen dem Vorgehen in Amazon S3:

  • Mit dem Abfragestringparameter acl können Sie ACLs für bestimmte Bereiche anwenden.
  • Der Anfrageheader x-goog-acl zum Anwenden vordefinierter ACLs, die auch als gespeicherte ACLs bekannt sind

Abfragestringparameter "acl" verwenden

Sie können den Abfragestringparameter acl für eine Cloud Storage-Anfrage genau auf dieselbe Weise wie für eine Amazon S3-Anfrage verwenden. Der acl-Parameter wird in Verbindung mit der PUT-Methode verwendet, um ACLs auf ein vorhandenes Objekt, einen vorhandenen Bucket oder einen Bucket, den Sie gerade erstellen, anzuwenden. Wenn Sie den Abfragestringparameter acl als Teil einer PUT-Anfrage verwenden, müssen Sie mithilfe der ACL-Syntax von Cloud Storage an den Anfragetext ein XML-Dokument anhängen. Das XML-Dokument enthält die einzelnen ACL-Einträge, die Sie auf den Bucket oder das Objekt anwenden möchten.

Das folgende Beispiel veranschaulicht eine PUT-Anfrage an Amazon S3, bei der der Abfragestringparameter acl verwendet wird. Die ACLs sind in einem XML-Dokument definiert, das mit dem Anfragetext gesendet wird. Die PUT-Anfrage ändert die ACLs für ein Objekt mit dem Namen europe/france/paris.jpg, das sich in einem Bucket namens my-travel-maps befindet. Die ACL gewährt jane@gmail.com die Berechtigung 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>

Hier die gleiche Anfrage an 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>

Beachten Sie, dass Cloud Storage im ACL-XML-Dokument kein <Owner/>-Element benötigt. Weitere Informationen finden Sie unter Bucket- und Objektinhaberschaft.

Sie können auch Bucket- und Objekt-ACLs abrufen, indem Sie den Abfragestringparameter acl mit der GET-Methode verwenden. Die ACLs sind im XML-Dokument beschrieben, das an den Antworttext angehängt ist. Sie müssen die Berechtigung FULL_CONTROL haben, um ACLs auf ein Objekt oder ein Bucket anzuwenden oder sie abzurufen.

ACLs mit einem Erweiterungsanfrageheader anwenden

Sie können bei einer Cloud Storage-Anfrage den Header x-goog-acl genau auf dieselbe Weise wie den Header x-amz-acl bei einer Amazon S3-Anfrage verwenden, um vordefinierte ACLs auf Buckets und Objekte anzuwenden. Normalerweise verwenden Sie den Header x-goog-acl (x-amz-acl), um eine vordefinierte ACL auf einen Bucket oder ein Objekt anzuwenden, wenn Sie den Bucket oder das Objekt erstellen oder hochladen. Die vordefinierten ACLs von Cloud Storage sind den gespeicherten ACLs von Amazon S3 ähnlich, beispielsweise "private", "public-read", "public-read-write" und anderen. Eine Liste der vordefinierten ACLs für Cloud Storage finden Sie unter Vordefinierte ACLs.

Das folgende Beispiel zeigt eine PUT-Anfrage für ein Objekt, bei der die ACL public-read auf ein Objekt mit dem Namen europe/france/paris.jpg angewendet wird. Dieses Objekt wird in einen Bucket namens my-travel-maps in Amazon S3 hochgeladen.

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>

Hier die gleiche Anfrage an 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>

Sie können auch den Header x-goog-acl verwenden, um eine vordefinierte ACL auf einen vorhandenen Bucket oder ein vorhandenes Objekt anzuwenden. Hierfür muss Ihre Anfrage den Abfragestringparameter acl enthalten, darf jedoch kein XML-Dokument umfassen. Die Anwendung einer vordefinierten ACL auf ein vorhandenes Objekt oder einen vorhandenen Bucket ist nützlich, wenn Sie zwischen zwei vordefinierten ACLs wechseln oder benutzerdefinierte ACLs durch vordefinierte ACLs ersetzen möchten. Bei der folgenden PUT-Anfrage für ein Objekt wird beispielsweise die vordefinierte ACL private auf ein Objekt mit dem Namen europe/france/paris.jpg angewendet, das sich in einem Bucket namens my-travel-maps befindet.

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>

Weitere Informationen zum Verwalten von ACLs finden Sie unter Access Control Lists (ACLs) erstellen und verwalten.

Anfragemethoden für die Migration von Amazon S3 zu Cloud Storage

Cloud Storage unterstützt die gleichen standardmäßigen HTTP-Anfragemethoden zum Lesen und Schreiben von Daten in Ihren Buckets wie Amazon S3. Der Großteil Ihrer Tools und Bibliotheken, die Sie aktuell in Amazon S3 verwenden, funktioniert daher unverändert in Cloud Storage. Cloud Storage unterstützt die folgenden Anfragemethoden:

  • Dienstanfragen für GET
  • Bucket-Anfragen wie PUT, GET und DELETE
  • Objektanfragen wie GET, POST, PUT, HEAD und DELETE

Weitere Informationen finden Sie unter Referenzmethoden der XML API. Beachten Sie, dass Sie gegebenenfalls den Anfragetext ändern müssen, wenn Sie Anfragen an Cloud Storage senden, damit die richtige Syntax von Cloud Storage verwendet wird. Wenn Sie beispielsweise eine Lebenszykluskonfiguration für einen Bucket erstellen, sollten Sie den Lebenszyklus-XML-Code von Cloud Storage verwenden, der sich vom Lebenszyklus-XML-Code von Amazon S3 unterscheidet.

Zwischen der Cloud Storage XML API und Amazon S3 gibt es einige Unterschiede:

Funktionalität bei Amazon S3 Funktionalität der XML API von Google Cloud Storage
Wenn Sie vom Kunden bereitgestellte Verschlüsselungsschlüssel in einem mehrteiligen Upload verwenden, enthält die letzte Anfrage den vom Kunden bereitgestellten Verschlüsselungsschlüssel nicht. In der XML API von Cloud Storage müssen Sie bei allen Anfragen in einem mehrteiligen Upload, einschließlich der letzten Anfrage, den gleichen vom Kunden bereitgestellten Verschlüsselungsschlüssel angeben. Diese Voraussetzung ist, dass Cloud Storage Ihre Verschlüsselungsschlüsselinformationen nicht speichert, während es auf den Abschluss des Uploads wartet. Der Schlüssel erfordert jedoch, dass die Prüfsumme für das fertige Objekt berechnet wird.
In Amazon S3 können V4-Signaturen zur Authentifizierung von Uploads verwendet werden, die eine aufgeteilte Transferverschlüsselung verwenden. In der Cloud Storage XML API können die aufgeteilte Transferverschlüsselung und V4-Signaturen derzeit nicht gleichzeitig verwendet werden. Einige Amazon S3-Tools verwenden standardmäßig die aufgeteilte Transferverschlüsselung zusammen mit Signaturen. In solchen Fällen sollten Sie die aufgeteilte Transferverschlüsselung deaktivieren.
GET/POST-Abfragestringparameter für einen Bucket:
  • "policy" – zur Arbeit mit den Bucket-Richtlinien von Amazon S3
  • "notification" – zur Meldung von Bucket-Ereignissen
  • "requestPayment" – zur Konfiguration, wer für die Anfrage und den Datendownload von einem Bucket bezahlt
 Alternativen:
  • "policy": Die ACLs von Cloud Storage, die Mitgliedschaft in Projektteams und die Möglichkeit, mehrere Projekte zu verwenden, unterstützen viele der Szenarien, in denen Bucket-Richtlinien zur Anwendung kommen.
  • „notification“: Verwenden Sie die gcloud CLI oder Pub/Sub-Benachrichtigungen der JSON API.
  • „requestPayment“: In Cloud Storage ist der entsprechende Abfragestringparameter für requestPayment billing.
Mehrere Objekte löschen
POST /?delete

Verwenden Sie die Google Cloud Console, um mehrere Objekte ganz einfach zu entfernen.

Alternativ unterstützt die JSON API das Senden von Batchanfragen, sodass sich die Anzahl der HTTP-Verbindungen verringert, die Ihr Client herstellt.

Header für die Migration von Amazon S3 zu Cloud Storage

Cloud Storage verwendet mehrere Standard-HTTP-Header sowie mehrere benutzerdefinierte (Erweiterungs-)HTTP-Header. Wenn Sie von Amazon S3 auf Cloud Storage umsteigen, können Sie Ihre benutzerdefinierten Header von Amazon S3 in die benutzerdefinierten Header von Cloud Storage mit gleicher oder ähnlicher Funktionalität umwandeln (siehe Tabelle unten).

Bei vielen Amazon S3-Headern muss einfach das Präfix x-amz durch x-goog ersetzt werden:

Amazon S3-Header Cloud Storage-Header
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

Mehrere Header unterscheiden sich oder gelten nicht in Cloud Storage:

Amazon S3-Header Cloud Storage-Header
x-amz-server-side-encryption Nicht erforderlich. Cloud Storage verschlüsselt automatisch alle Daten, bevor sie auf ein Laufwerk geschrieben werden. Weitere Informationen finden Sie unter Verschlüsselung.
x-amz-grant-* x-goog-acl mit einem vordefinierten ACL-Wert.
x-amz-version-id x-goog-generation
x-amz-mfa Verwenden Sie die Authentifizierung mit OAuth 2.0.
x-amz-decoded-content-length Nicht als x-goog-Header unterstützt
x-amz-website-redirect-location, x-amz-copy-source-range –

Unter HTTP-Header und Abfragestringparameter für die XML API finden Sie eine Referenz zu Cloud Storage-Headern.

Nächste Schritte