Migre totalmente do Amazon S3 para o Cloud Storage

Esta página descreve como migrar totalmente do Amazon Simple Storage Service (Amazon S3) para o Cloud Storage para utilizadores que enviam pedidos através de uma API. Depois de migrar totalmente, pode usar todas as funcionalidades do Cloud Storage, incluindo vários projetos e o OAuth 2.0 para autenticação.

Se quiser começar a usar o Cloud Storage rapidamente, pode escolher uma migração simples, que requer apenas algumas alterações simples às ferramentas e às bibliotecas que usa atualmente com o Amazon S3.

Migre do Amazon S3 para o Cloud Storage

Para migrar totalmente do Amazon S3 para o Cloud Storage, tem de concluir os seguintes passos:

  • Altere todos os cabeçalhos x-amz-* existentes para os cabeçalhos x-goog-* correspondentes.
  • Altere o XML da lista de controlo de acesso (LCA) da AWS para o XML da LCA do Cloud Storage correspondente (consulte o artigo Criar e gerir listas de controlo de acesso).
  • Defina o cabeçalho x-goog-project-id nos seus pedidos.

  • Configure a autenticação OAuth 2.0. A utilização do OAuth 2.0 significa que o cabeçalho Authorization tem o seguinte aspeto:

    Authorization: Bearer OAUTH2_TOKEN

    O OAuth 2.0 baseia-se no SSL para segurança, em vez de exigir que a sua aplicação faça a assinatura criptográfica diretamente, e é mais fácil de implementar. Com o OAuth, a sua aplicação pode pedir acesso a dados associados à conta de um utilizador, e o acesso pode ser limitado a vários níveis, incluindo apenas leitura, leitura/escrita e controlo total. Para mais informações, consulte os artigos Âmbitos do OAuth 2.0 do Cloud Storage e Aceder a dados em nome de um utilizador.

Controlo de acesso

Esta secção mostra alguns exemplos de controlo de acesso para ajudar na migração do Amazon S3 para o Cloud Storage. Para uma vista geral do controlo de acesso no Cloud Storage, consulte o artigo Controlo de acesso.

No Cloud Storage, existem várias formas de aplicar ACLs a contentores e objetos (consulte o artigo Criar e gerir listas de controlo de acesso). Duas das formas de especificar as ACLs são análogas ao que faz no Amazon S3:

  • O parâmetro da string de consulta acl permite-lhe aplicar ACLs a âmbitos específicos.
  • O cabeçalho do pedido x-goog-acl permite-lhe aplicar LCAs predefinidas, que são por vezes conhecidas como LCAs predefinidas.

Usar o parâmetro de string de consulta acl

Pode usar o parâmetro de string de consulta acl para um pedido do Cloud Storage exatamente da mesma forma que o usaria para um pedido do Amazon S3. O parâmetro acl é usado em conjunto com o método PUT para aplicar ACLs ao seguinte: um objeto existente, um contentor existente ou um contentor que está a criar. Quando usa o parâmetro de string de consulta acl num pedido PUT, tem de anexar um documento XML (usando a sintaxe da ACL do Cloud Storage) ao corpo do pedido. O documento XML contém as entradas de ACL individuais que quer aplicar ao contentor ou ao objeto.

O exemplo seguinte mostra um pedido PUT ao Amazon S3 que usa o parâmetro de string de consulta acl. As ACLs são definidas num documento XML enviado no corpo do pedido. O pedido PUT altera as ACLs num objeto denominado europe/france/paris.jpg que se encontra num contentor denominado my-travel-maps. A ACL concede jeffersonloveshiking@gmail.com FULL_CONTROL autorização.

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>

Aqui está o mesmo pedido ao 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>

Tenha em atenção que o Cloud Storage não requer um elemento <Owner/> no documento XML da ACL. Para mais informações, consulte o artigo Propriedade do contentor e do objeto.

Também pode obter LCAs de objetos e contentores através do parâmetro de string de consulta acl com o método GET. As ACLs são descritas num documento XML, que é anexado ao corpo da resposta. Tem de ter autorização para aplicar ou obter LCAs num objeto ou num contentor.FULL_CONTROL

Aplique ACLs com um cabeçalho de pedido de extensão

Pode usar o cabeçalho x-goog-acl num pedido do Cloud Storage para aplicar ACLs predefinidas a contentores e objetos exatamente da mesma forma que usaria o cabeçalho x-amz-acl num pedido do Amazon S3. Normalmente, usa o cabeçalho x-goog-acl (x-amz-acl) para aplicar uma LCA predefinida a um contentor ou a um objeto quando cria ou carrega o contentor ou o objeto. As LCAs predefinidas do Cloud Storage são semelhantes às LCAs predefinidas do Amazon S3, incluindo private, public-read, public-read-write, bem como outras. Para ver uma lista das ACLs predefinidas do Cloud Storage, consulte o artigo ACLs predefinidas.

O exemplo seguinte mostra um pedido de objeto PUT que aplica a ACL public-read a um objeto denominado europe/france/paris.jpg que está a ser carregado para um contentor denominado my-travel-maps no 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>

Aqui está o mesmo pedido ao 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>

Também pode usar o cabeçalho x-goog-acl para aplicar uma ACL predefinida a um objeto ou um contentor existente. Para o fazer, inclua o parâmetro da string de consulta acl no seu pedido, mas não inclua um documento XML no pedido. A aplicação de uma LCA predefinida a um objeto ou um contentor existente é útil se quiser alterar de uma LCA predefinida para outra ou se quiser atualizar LCAs personalizadas para uma LCA predefinida. Por exemplo, o seguinte pedido de objeto aplica a LCA predefinida private a um objeto denominado europe/france/paris.jpg que se encontra num contentor denominado my-travel-maps.PUT

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 mais informações sobre a gestão de ACLs, consulte o artigo Criar e gerir listas de controlo de acesso.

Migre dos métodos de pedido do Amazon S3 para o Cloud Storage

O Cloud Storage suporta os mesmos métodos de pedidos HTTP padrão para ler e escrever dados nos seus contentores que são suportados no Amazon S3. Por conseguinte, a maioria das ferramentas e bibliotecas que usa atualmente com o Amazon S3 funciona tal como está com o Cloud Storage. O Cloud Storage suporta os seguintes métodos de pedido:

  • Pedido de serviço para GET.
  • Pedidos de contentores, incluindo PUT, GET e DELETE.
  • Pedidos de objetos, incluindo GET, POST, PUT, HEAD e DELETE.

Para mais informações, consulte os métodos de referência da API XML. Tenha em atenção que, quando envia pedidos para o Cloud Storage, tem de alterar o corpo do pedido, quando aplicável, para usar a sintaxe do Cloud Storage adequada. Por exemplo, quando cria uma configuração do ciclo de vida para um contentor, use o XML do ciclo de vida do Cloud Storage, que é diferente do XML do ciclo de vida do Amazon S3.

Existem algumas diferenças entre a API XML do Cloud Storage e o Amazon S3, que são resumidas abaixo:

Funcionalidade do Amazon S3 Funcionalidade da API XML do Cloud Storage
Quando usa chaves de encriptação fornecidas pelos clientes num carregamento multipartes, o pedido final não inclui a chave de encriptação fornecida pelos clientes. Na API XML do Cloud Storage, todos os pedidos num carregamento multipartes, incluindo o pedido final, exigem que forneça a mesma chave de encriptação fornecida pelo cliente. Este requisito existe porque o Cloud Storage não armazena as informações da chave de encriptação enquanto aguarda que o pedido conclua o carregamento, mas requer a chave para calcular uma soma de verificação para o objeto concluído.
No Amazon S3, as assinaturas V4 podem ser usadas para autenticar carregamentos que usam a codificação de transferência em blocos. Na API XML do Cloud Storage, não é possível usar simultaneamente a codificação de transferência segmentada e as assinaturas V4. Algumas ferramentas do Amazon S3 usam a codificação de transferência segmentada juntamente com as assinaturas por predefinição; deve desativar a codificação de transferência segmentada nesses casos.
Parâmetros de string de consulta de GET/POST de contentores:
  • "policy" (política): trabalhar com políticas de contentores do Amazon S3.
  • "notification" – Notificação de eventos de contentores.
  • "requestPayment" – Configurar quem paga o pedido e a transferência de dados de um contentor.
 Alternativas:
  • "política" – As ACLs do Cloud Storage, a associação da equipa do projeto e a capacidade de usar vários projetos resolvem muitos dos cenários em que as políticas de contentores são usadas.
  • "notification" – Use a CLI gcloud ou a API JSON Notificações do Pub/Sub.
  • "requestPayment" – No Cloud Storage, o parâmetro da string de consulta equivalente a requestPayment é billing.
Eliminação de vários objetos.
POST /?delete

Use a Google Cloud consola para remover facilmente vários objetos.

Em alternativa, a API JSON suporta o envio de pedidos em lote para reduzir o número de ligações HTTP que o seu cliente estabelece.

Migre dos cabeçalhos do Amazon S3 para os cabeçalhos do Cloud Storage

O Cloud Storage usa vários cabeçalhos HTTP padrão, bem como vários cabeçalhos HTTP personalizados (de extensão). Se estiver a fazer a transição do Amazon S3 para o Cloud Storage, pode converter os seus cabeçalhos personalizados do Amazon S3 no cabeçalho personalizado equivalente do Cloud Storage ou numa funcionalidade semelhante, conforme mostrado nas tabelas abaixo.

Para muitos cabeçalhos do Amazon S3, basta substituir o prefixo x-amz por x-goog:

Cabeçalho do Amazon S3 Cabeçalho do 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

Vários cabeçalhos são diferentes ou não se aplicam no Cloud Storage:

Cabeçalho do Amazon S3 Cabeçalho do Cloud Storage
x-amz-server-side-encryption Não é obrigatório. O Cloud Storage encripta automaticamente todos os dados antes de serem escritos no disco. Para mais informações, consulte o artigo Encriptação.
x-amz-grant-* x-goog-acl com um valor de LCA predefinido.
x-amz-version-id x-goog-generation
x-amz-mfa Use a autenticação OAuth 2.0.
x-amz-decoded-content-length Não suportado como cabeçalho x-goog
x-amz-website-redirect-location, x-amz-copy-source-range N/A

Consulte os cabeçalhos HTTP e os parâmetros da string de consulta para a API XML para ver uma referência aos cabeçalhos do Cloud Storage.

O que se segue?