Português do Brasil English
Devin no Facebook  Devin no Twitter  RSS do Site 
Programas    

s3cmd: mandando arquivos para a Amazon S3


Comentários  7
Visualizações  
542.256

Quando a computação em nuvem da Amazon Web Services surgiu, um dos primeiros produtos a serem oferecidos foi o S3, que permite armazenar arquivos em um storage distribuído. No S3, cada arquivo é um objeto compartilhado entre vários servidores, distribuindo entre eles cópias de segurança.

Existem algumas maneiras para se manipular um storage S3. A AWS fornece uma interface API para conversar com seus serviços, e é através desta API que diversos programas conversam com o S3. Inclusive, o próprio gerenciador web é feito em cima dessa API principal. Por ser uma API pública, qualquer pessoa pode fazer programas ou interfaces para trabalhar com o S3.

s3cmd

O s3cmd é um programa de linha de comando pra Linux que implementa a API do S3 e faz as seguintes operações:

  • Lista os storages S3 (chamados buckets) e seus conteúdos;
  • Cria e remove buckets;
  • Puxa (GET) e manda (PUT) arquivos;
  • Tem um modo de sync parecido com o rsync;
  • Permite armazenar dados criptografados.

Ou seja, dá pra fazer muita coisa com o S3. A ferramenta é bastante usada principalmente para enviar backups para um storage. Em termos de enviar e pegar arquivos, o s3cmd é uma ótima pedida. Ele trabalha usando o método nativo do S3 e por isso todos os arquivos são objetos, assim como o S3 implementa. Digo isso porque há outras ferramentas que implementam um sistema de arquivos diferente da implementação nativa do S3 e com isso ganham vantagens e desvantagens: apesar do sistema de arquivos poder ser montado em um diretório, ter controle de permissões, diretórios, poder ser acessado como qualquer outro programa diretamente do S3, entre outras vantagens, o sistema fica dependente da ferramenta e não é compatível com a API de objetos normais.

Em outras palavras, se você estiver procurando algo simples para mandar, receber e fazer syncs de arquivos, pode usar o s3cmd que ele é a ferramenta certa. Mas se você for querer algo mais complexo para usar com outros programas, tem que experimentar outras ferramentas como o s3ql ou s2fs.

Este tutorial segue a versão s3cmd 1.0.1.

Instalação

Para algumas distribuições, o s3cmd já está disponível empacotadinho, bonitinho e prontinho pra usar. Neste caso:

No Fedora / Fedora EPEL (CentOS e RHEL):

yum install s3cmd

No Ubuntu / Debian:

apt-get install s3cmd

Mas se por acaso não tiver os pacotes nos repositórios que você configurou, basta incluir o repositório do próprio s3cmd e instalar. Visite a página de Downloads de pacotes e repositórios do s3cmd.

Se preferir pegar o pacote do código-fonte (o s3cmd é feito em Python, então nem precisa compilar), é bem fácil. Basta baixar o arquivo do código fonte aqui.

No caso de pegar o pacote do código-fonte, você pode:

  • (Recomendado) Executar python setup.py install para fazer o python instalar tudo corretamente;
  • Executar a ferramenta no diretório que você descompactou;
  • Copiar o executável (cp s3cmd /usr/local/bin) e a página de manual (cp s3cmd.1 /usr/local/share/man/man1) pro sistema;

Configuração

Uma vez instalado o s3cmd, é fácil configurar. Com seu usuário, digite o seguinte:

s3cmd --configure

Esse comando irá iniciar a configuração interativa do programa, onde você precisa colocar as informações:

  • Access Key e Secret Key – São as chaves de segurança do seu usuário na AWS (criado no IAM);
  • Encryption Password – É uma senha grande para criptografar os arquivos via GPG, caso você queira;
  • Use HTTPS protocol – Usar HTTPS (SSL) ao invés de HTTP texto puro, altamente recomendado colocar Yes;

Respondida essas perguntas básicas, o programa ainda testa se sua configuração está correta e consegue acessar os buckets S3 e pergunta se deseja salvar a configuração que você acabou de fazer (óbvio que você vai querer!). Quando salva a configuração, ela fica no caminho:

$HOME/.s3cfg

Onde $HOME é, obviamente, o seu diretório HOME.

NOTA
NOTA


Durante algumas configurações, o teste para ver se a configuração funciona pode falhar mesmo se a Access Key e Secret Key forem corretas. Para testar a configuração, o s3cmd manda listar os buckets disponíveis no S3. Se as chaves que você estiver usando só permitem você escrever em um bucket, provavelmente o teste irá falhar (pois ele não pode listar o resto dos buckets). Neste caso, ignore o teste na configuração e siga adiante.

Usando

Com tudo configurado fica muito fácil usar o s3cmd. Vamos lá!

Criando um bucket:

$ s3cmd mb s3://devin-teste
Bucket 's3://devin-teste/' created

Agora vou listar todos os buckets:

$ s3cmd ls
2013-05-20 22:42  s3://devin-backup
2013-05-20 22:42  s3://devin-img
2013-05-20 22:41  s3://devin-teste

Colocando (PUT) um arquivo no bucket devin-teste:

$ s3cmd put devin_logo_avatar.png s3://devin-teste
devin_logo_avatar.png -> s3://devin-teste/devin_logo_avatar.png  [1 of 1]
 777403 of 777403   100% in    8s    84.88 kB/s  done

Listando agora o conteúdo do bucket devin-teste:

$ s3cmd ls s3://devin-teste
2013-05-20 22:44    777403   s3://devin-teste/devin_logo_avatar.png

Pegando (GET) o arquivo:

$ s3cmd get s3://devin-teste/devin_logo_avatar.png
s3://devin-teste/devin_logo_avatar.png -> ./devin_logo_avatar.png  [1 of 1]
 777403 of 777403   100% in    6s   111.08 kB/s  done

Mandando outro arquivo e logo depois removendo:

$ s3cmd put httpd.conf s3://devin-teste
httpd.conf -> s3://devin-teste/httpd.conf  [1 of 1]
 11858 of 11858   100% in    3s     3.79 kB/s  done

$ s3cmd del s3://devin-teste/httpd.conf
File s3://devin-teste/httpd.conf deleted

Agora um sync! Sincronizar o diretório /etc/httpd no bucket devin-backup:

$ s3cmd sync /etc/httpd s3://devin-backup
/etc/httpd/conf.d/README -> s3://devin-backup/httpd/conf.d/README  [1 of 19]
 366 of 366   100% in    1s   185.84 B/s  done
/etc/httpd/conf.d/autoindex.conf -> s3://devin-backup/httpd/conf.d/autoindex.conf  [2 of 19]
 2893 of 2893   100% in    1s  1500.63 B/s  done
/etc/httpd/conf.d/deflate.conf -> s3://devin-backup/httpd/conf.d/deflate.conf  [3 of 19]
 769 of 769   100% in    1s   392.22 B/s  done
/etc/httpd/conf.d/errors.conf -> s3://devin-backup/httpd/conf.d/errors.conf  [4 of 19]
 118 of 118   100% in    1s    59.14 B/s  done
/etc/httpd/conf.d/expires.conf -> s3://devin-backup/httpd/conf.d/expires.conf  [5 of 19]
 320 of 320   100% in    1s   164.55 B/s  done
/etc/httpd/conf.d/php.conf -> s3://devin-backup/httpd/conf.d/php.conf  [6 of 19]
 691 of 691   100% in    1s   346.27 B/s  done

...cortando...

/etc/httpd/conf/magic -> s3://devin-backup/httpd/conf/magic  [19 of 19]
 13077 of 13077   100% in    2s     5.20 kB/s  done
Done. Uploaded 38604 bytes in 37.1 seconds, 1040.47 B/s

O comando sync funciona igual ao rsync. No nosso caso, qualquer modificação que seja feita no diretório /etc/httpd, vai ser replicada para o S3 quando eu executar o comando sync novamente.

Agora vou remover o bucket vazio (se tiver algo dentro, ele não remove):

$ s3cmd rb s3://devin-img
Bucket 's3://devin-img/' removed

Essas são as operações básicas que a maioria dos usuários s3cmd precisam.

Objetos acessíveis publicamente

Todos os objetos do S3 podem ser acessíveis publicamente através de um servidor web da própria Amazon AWS. Por padrão, os objetos que você coloca no bucket S3 são private (privado), ou seja, não acessíveis por esse servidor Web. Se você mudar a ACL do arquivo para public ele vai ficar disponível.

Por exemplo, para configurar aquele arquivo que já mandamos como público:

$ s3cmd setacl --acl-public s3://devin-teste/devin_logo_avatar.png

Sendo público, ele fica disponível na URL:

  • http://.s3.amazonaws.com (no exemplo, seria http://devin-teste.s3.amazonaws.com/devin_logo_avatar.png

Se você quiser já mandar um arquivo, basta usar o –acl-public no comando put:

$ s3cmd put --acl-public httpd.conf s3://devin-teste
httpd.conf -> s3://devin-teste/httpd.conf  [1 of 1]
 11858 of 11858   100% in    2s     4.53 kB/s  done
Public URL of the object is: http://devin-teste.s3.amazonaws.com/httpd.conf

Criptografia

Ao configurar com o s3cmd –configure, uma das perguntas é uma senha para criptografar arquivos. Essa senha fica guardada no .s3cfg e tem como objetivo mandar os arquivos para o S3 criptogragados de forma transparente. Em outras palavras, o s3cmd executa o GPG em seus arquivos, criptografando com a senha, e manda o resultado pro s3. Para baixar arquivos criptografados ele faz a mesma coisa, baixa e depois descriptografa com o GPG+senha.

$ s3cmd put -e /etc/passwd s3://devin-teste
/tmp/tmpfile-M575hbawQldKmMMpho7X -> s3://devin-teste/passwd  [1 of 1]
 1010 of 1010   100% in    2s   399.90 B/s  done

Repare que ele transferiu o arquivo /tmp/tmpfile-M575hbawQldKmMMpho7X, que nada mais é que o arquivo que eu quis enviar, só que criptografado. Se você baixar o arquivo por qualquer outra ferramenta, não vai conseguir ver seu conteúdo (experimente pegar o arquivo via navegador, na interface web). Mas se você baixar pelo s3cmd, ele já deixa o arquivo certo novamente:

$ s3cmd get s3://devin-teste/passwd
s3://devin-teste/passwd -> ./passwd  [1 of 1]
 1010 of 1010   100% in    0s  1255.62 B/s  done
NOTA
NOTA


O sync não possui suporte ao parâmetro -e (–encrypt), por isso, se quiser mandar arquivos criptografados, terá que mandar com o get. Se quiser diretórios e seus conteúdos (recursivamente), use o parâmetro –recursive junto com o put.

Outra forma de criptografar os arquivos é utilizar a própria criptografia da AWS, também chamado de Server Side Encryption (SSE). Neste modo, você manda o arquivo para a API, e ela internamente criptografa e armazena o arquivo. Se você for pegar o arquivo, a própria amazon decriptografa e te manda. Pra usar é bem simples, basta adicionar um header da seguinte forma:

s3cmd put --add-header=x-amz-server-side-encryption:AES256 /etc/passwd s3://devin-teste

Datacenters diferentes

Todos os exemplos até agora manipularam buckets no datacenter us-east-1 (Virgínia do Norte – EUA). Se vocẽ quiser usar qualquer outro datacenter, basta usar o parâmetro –bucket-location como o exemplo abaixo:

Cria um bucket no datacenter em São Paulo:

s3cmd mb --bucket-location=sa-east-1 s3://devin-sp

A partir daí, tudo o que você fizer no bucket devin-sp será armazenado no datacenter em São Paulo.

Outras configurações e opções

Como dito antes, o s3cmd –configure grava os parâmetros no arquivo .s3cfg. Você pode criar várias configurações e colocar em vários arquivos diferentes. Isso é útil, por exemplo, pra quando você tem múltiplas aplicações copiando para o s3, cada um com um usuário diferente (com access keys e secret keys diferentes). Com isso você pode fazer assim:

s3cmd -c /etc/s3cmd/backup.cfg put /etc/passwd s3://devin-backup
s3cmd -c /etc/s3cmd/img.cfg put ratos_motoqueiros_de_marte.jpg s3://devin-img

Cada cfg vai ter uma configuração diferente :-)

E por falar em configuração, dando uma olhada no arquivo s3cfg, podemos ver várias opções! Algumas delas que é interessante citar:

  • bucket_location: A região (datacenter) padrão dos buckets. Pode ser: us-east-1, us-west-1, sa-east-1, e por aí vai. Nos comandos, corresponde ao parâmetro –bucket-location que falamos antes;
  • default_mime_type: Qual o tipo de arquivo (MIME). Para alguns tipos de arquivos, como imagens, o S3 já reconhece e diz que é uma imagem. Mas para todo o resto, o padrão é binary/octet-stream, ou seja, binário. Quando binário, ao tentar servir publicamente, o usuário acaba fazendo download do arquivo. O parâmetro -m no especifica que tipo de arquivo. Exemplo: text/plain faz com que o arquivo seja um arquivo de texto, então aparece no navegador ao invés de fazer download;
  • get_continue: Quando for fazer a operação de puxar arquivos (get), se o arquivo existir localmente e estiver pela metade, o s3cmd tenta continuar de onde parou;
  • human_readable_sizes: Na hora de listar os arquivos, mostrar seus tamanhos de uma forma mais legível (1K ao invés de 1024);
  • reduced_redundancy: No storage distribuído do S3, colocar True nessa opção significa que os arquivos que você enviar pelo s3cmd ficarão com menos máquinas (menos redundância). Por consequencia, a probabilidade de você perder o arquivo aumenta, mas o custo por GB do storage na AWS diminui;
  • socket_timeout: Quanto tempo o s3cmd espera para se conectar na API. Para conexões lentas e inconfiáveis, dá pra aumentar esse número;

Para cada uma dessas opções do s3cfg, há um parâmetro de linha de comando. Consulte a página de manual (man s3cmd) para uma referência mais completa.

Possíveis problemas

A grande maioria dos problemas que você pode ter são problemas na hora de conectar na API e durante o envio do arquivo.

Isso significa que se algo cair durante a transferência de algum arquivo, o s3cmd tem que recomeçar. Não é incomum pegar erros de rede durante a transferência, que tentando alguns minutos depois, funcione perfeitamente. São erros bem inconstantes. Por exemplo: ao escrever este tutorial, houve algumas falhas de transferência de arquivos para o datacenter em São Paulo, mas ao tentar uns 10 minutos depois, funcionou perfeitamente.

O s3cmd vai tentando mandar o arquivo até conseguir, aumentando o intervalo de tempo entre uma tentativa e outra, e abaixando a banda utilizada para mandar os arquivos (throttle).

Broken Pipe / Connection reset by peer

$ s3cmd put devin-tirinha.jpg s3://devin-sp
devin-tirinha.jpg -> s3://devin-sp/devin-tirinha.jpg  [1 of 1]
  24576 of 236372    10% in    3s     7.07 kB/s  failed
WARNING: Upload failed: /devin-tirinha.jpg ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...

...corte...

devin-tirinha.jpg -> s3://devin-sp/devin-tirinha.jpg  [1 of 1]
  36864 of 236372    15% in    3s    10.23 kB/s  failed
WARNING: Upload failed: /devin-tirinha.jpg ([Errno 104] Connection reset by peer)
WARNING: Retrying on lower speed (throttle=0.05)
WARNING: Waiting 9 sec...

Sua rede está instável! Algo entre a API e o seu computador não está conseguindo manter as conexões. Isso pode ocorrer, mas não tem muito o que se fazer, a não ser esperar o s3cmd tentar mandar de novo e obter sucesso.

Algumas pessoas reportaram que aumentar o parâmetro socket_timeout ajuda nestes problemas. O socket_timeout define o tempo para esperar antes de conectar à API, e o que ocorre geralmente é um erro brusco no meio da transferência.

Arquivos muito grandes (multipart)

O limite para o envio de um único objeto para o S3 é de 5GB. Com o passar do tempo, a própria Amazon resolveu superar esse limite adicionando o recurso de multipart upload. Neste modo, o cliente manda via API vários pedaços de arquivos. Quando todos estes pedaços chegam ao servidor, o próprio S3 junta todas as partes e faz um objeto.

Com o upload em modo multipart, você pode enviar vários pedaços e criar um único objeto de até 5TB, um aumento considerável em relação a 5GB :P

A versão 1.0.1 do s3cmd, utilizada neste tutorial, não suporta uploads multipart.

A versão 1.1.0+, que é beta, já suporta este tipo de envio, então é uma boa pegar o código-fonte e testar, caso precise. Apesar de ser beta, parece que bastante gente já usou e aprovou o bom funcionamento. Usando essa versão, você já tem o suporte ao multipart habilitado por padrão para arquivos maiores que 15MB. Mas você pode mudar, por exemplo…

Enviando um arquivo de 150MB, dividido em pedaços de 5MB (mínimo permitido pela Amazon):

s3cmd put --multipart-chunk-size-mb=5 150mb.img s3://devin-teste

Então, com o multipart habilitado, uma regra recomendável é: sempre use multipart para enviar arquivos a partir de 100MB.

Referências

542.256

Comentários  7
Visualizações  
542.256


TagsLeia também

Apaixonado por Linux e administração de sistemas. Viciado em Internet, servidores, e em passar conhecimento. Idealizador do Devin, tem como meta aprender e ensinar muito Linux, o que ele vem fazendo desde 1997 :-)


Leia também



Comentários

7 respostas para “s3cmd: mandando arquivos para a Amazon S3”

  1. Muito útil o tutorial Hugo, obrigado!

  2. Leonardo disse:

    Olá, ótimo tutorial, tenho uma dúvida quanto ao sync:

    Por exemplo, vou sincronizar a pasta com os backups de dados da minha empresa com um bucket S3, tenho cerca de 100gb de dados. Minha dúvida é, sempre que eu der o comando sync ele vai mandar toda vez esses 100gb ou ele só vai mandar os últimos arquivos modificados?

  3. John Mendes disse:

    Amigo, estou com uma dúvida.
    Ao tentar configurar, onde devo pegar as chaves?

    s3cmd –configure
    Access Key e Secret Key – São as chaves de segurança do seu usuário na AWS (criado no IAM);

  4. Tiago disse:

    Hugo quero primeiramente agradecer, artigo excelente.
    Cara existe algum comando que vai realizar essa tarefa periodicamente ou tenho que fazer isso pelo cron?

  5. Gabriel disse:

    Como pegar somente o ultimo arquivo adicionado no bucket?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *