s3cmd
v2.4.0
S3tools / S3cmd メーリング リスト:
S3cmd には Python 2.6 以降が必要です。 S3cmd バージョン 2 以降では、Python 3 以降もサポートされています。
インストール手順を参照してください。
S3cmd ( s3cmd ) は、Amazon S3 および S3 プロトコルを使用する他のクラウド ストレージ サービス プロバイダー (Google Cloud Storage や DreamHost DreamObjects など) でデータをアップロード、取得、管理するための無料のコマンドライン ツールおよびクライアントです。コマンド ライン プログラムに精通したパワー ユーザーに最適です。また、バッチ スクリプトや、cron などからトリガーされる S3 への自動バックアップにも最適です。
S3cmd は Python で書かれています。これは、GNU Public License v2 (GPLv2) に基づいて利用可能なオープン ソース プロジェクトであり、商用および個人利用の両方で無料です。 Amazon に支払う必要があるのは、ストレージの使用料のみです。
2008 年の最初のリリース以来、S3cmd には多くの機能とオプションが追加されてきました。最近数えたところ、マルチパート アップロード、暗号化、増分バックアップ、S3 同期、ACL およびメタデータ管理、S3 などのコマンド ライン オプションが 60 以上ありました。バケット サイズ、バケット ポリシーなど。
Amazon S3 は、誰でも任意の量のデータを保存し、後で再度取得できる、インターネットからアクセスできるマネージド ストレージ サービスを提供します。
S3はAmazonが運営する有料サービスです。 S3 に何かを保存する前に、「AWS」アカウント (AWS = アマゾン ウェブ サービス) にサインアップして、アクセス キーとシークレット キーのペアの識別子を取得する必要があります。これらのキーを S3cmd に渡す必要があります。これらは、S3 アカウントのユーザー名とパスワードであるかのように考えてください。
この記事の執筆時点では、S3 の使用コストは次のとおりです (米ドル)。
使用されるストレージ容量の 1 か月あたり 1 GB あたり 0.023 ドル
プラス
GB あたり 0.00 ドル - すべてのデータがアップロードされます
プラス
GB あたり 0.000 ドル - 最初の 1GB/月のデータ ダウンロード 1 GB あたり 0.090 ドル - 最大 10 TB/月のデータ ダウンロード 1 GB あたり 0.085 ドル - 次の 40 TB/月のデータ ダウンロード 1 GB あたり 0.070 ドル - 次の 100 TB/月のデータ ダウンロード 1 GB あたり 0.050 ドル - データのダウンロード/月 150 TB 以上
プラス
PUT、COPY、または LIST リクエスト 1,000 件あたり 0.005 ドル GET リクエスト 10,000 件あたり 0.004 ドル、その他すべてのリクエスト
たとえば、1 月 1 日にニュージーランドでの休暇から 2 GB の写真を JPEG でアップロードした場合、1 月末には、1 か月間の 2 GB のストレージ容量の使用に対して 0.05 ドル、2 GB のデータのアップロードに対して 0.0 ドル、そしてリクエストには数セント。休日の貴重な写真を完全にバックアップするには、0.06 ドルをわずかに超える金額になります。
2月には触れないでください。データはまだ S3 サーバー上にあるため、その 2 ギガバイトに対して 0.06 ドルを支払いますが、転送には 1 セントも請求されません。バックアップの継続コストとしては 0.05 ドルになります。それほど悪くはありません。
3 月に、あなたの写真の一部への匿名の読み取りアクセスを許可すると、友人が、たとえば 1500 MB の写真をダウンロードします。ファイルはお客様が所有するものであるため、発生した費用はお客様の負担となります。つまり、3 月末には、ストレージ料金として 0.05 ドル、さらに友人が生成したダウンロード トラフィックに対して 0.045 ドルが請求されることになります。
最低月額契約やセットアップ料金はありません。使用したものに料金を支払います。最初の請求額は 0.03 米ドルか、0 ドル程度でした。
これが Amazon S3 の料金モデルを簡単に説明したものです。詳細については、Amazon S3 ホームページを確認してください。
言うまでもなく、これらのお金はすべて Amazon 自体によって請求されます。S3cmd の使用に対する支払いは明らかにありません :-)
S3に保存されているファイルは「オブジェクト」と呼ばれ、その名前は正式には「キー」と呼ばれます。これはユーザーにとって混乱を招く場合があるため、オブジェクトを「ファイル」または「リモート ファイル」と呼ぶことがよくあります。各オブジェクトは 1 つの「バケット」にのみ属します。
S3 ストレージ内のオブジェクトを記述するために、次の形式の URI のようなスキーマを発明しました。
s3://BUCKET
または
s3://BUCKET/OBJECT
バケットは、いくつかの制限があるディレクトリまたはフォルダーのようなものです。
DNS 互換のバケット名を使用することをお勧めします。これは、たとえば、大文字を使用すべきではないことを意味します。 DNS コンプライアンスは厳密には必須ではありませんが、以下で説明する一部の機能は、DNS と互換性のない名前付きバケットでは使用できません。さらにもう 1 つのステップは、バケットに完全修飾ドメイン名 (FQDN) を使用することです。これにはさらに多くの利点があります。
FQDN 名前付きバケットの詳細については、このテキストの後半の「仮想ホスト」を参照してください。
バケットとは異なり、オブジェクト名にはほとんど制限がありません。これらは、最大 1024 バイトの長さの任意の UTF-8 文字列にすることができます。興味深いことに、オブジェクト名にはスラッシュ文字 (/) を含めることができるため、 my/funny/picture.jpgは有効なオブジェクト名になります。 myおよびfunnyという名前のディレクトリやバケットがないことに注意してください。これは実際にはmy/funny/picture.jpgという単一のオブジェクト名であり、S3 はそれがディレクトリ構造のように見えることをまったく気にしません。
このような画像の完全な URI は、たとえば次のようになります。
s3://my-bucket/my/funny/picture.jpg
S3 に保存されるファイルはプライベートまたはパブリックのいずれかになります。プライベートなものはアップロードしたユーザーのみが読み取ることができますが、パブリックのものは誰でも読み取ることができます。さらに、パブリック ファイルには、 s3cmdまたは同様のツールを使用するだけでなく、HTTP プロトコルを使用してアクセスすることもできます。
ファイルの ACL (アクセス コントロール リスト) は、アップロード時に、 s3cmd putまたはs3cmd syncコマンドで--acl-publicまたは--acl-privateオプションを使用して設定できます (以下を参照)。
あるいは、 s3cmd setacl --acl-public (または--acl-private ) コマンドを使用して、既存のリモート ファイルの ACL を変更できます。
https://aws.amazon.com/s3 にアクセスし、右側の列の [Web サービスにサインアップ] ボタンをクリックして登録を完了します。 Amazon が S3 の使用料を請求できるようにするには、クレジット カードの詳細を入力する必要があります。最後に、アクセス キーと秘密キーが得られます。
別の IAM ユーザーを設定する場合、そのユーザーのアクセス キーには、何かを行うために少なくとも次の権限が必要です。
他のポリシーの例は、https://docs.aws.amazon.com/AmazonS3/latest/dev/example-policies-s3.html で見つけることができます。
s3cmd --configure実行します2 つのキーの入力を求められます。確認メールまたは Amazon アカウント ページからキーをコピーして貼り付けます。コピーするときは注意してください。大文字と小文字が区別されるため、正確に入力する必要があります。そうしないと、無効な署名などに関するエラーが発生し続けます。
キーに s3:ListAllMyBuckets 権限を忘れずに追加してください。そうしないと、アクセスのテスト中に AccessDenied エラーが発生します。
s3cmd ls実行して、すべてのバケットをリストします。S3 の使用を開始したばかりなので、現時点では所有しているバケットはありません。したがって、出力は空になります。
s3cmd mb s3://my-new-bucket-nameでバケットを作成します上で述べたように、バケット名は S3 のすべてのユーザー間で一意である必要があります。つまり、「test」や「asdf」などの単純な名前はすでに使用されており、より独創的な名前を作成する必要があります。できるだけ多くの機能をデモするために、FQDN という名前のバケットs3://public.s3tools.orgを作成してみましょう。
$ s3cmd mb s3://public.s3tools.org
Bucket 's3://public.s3tools.org' created
s3cmd lsを使用してバケットを再度リストします。これで、新しく作成されたバケットが表示されるはずです。
$ s3cmd ls
2009-01-28 12:34 s3://public.s3tools.org
$ s3cmd ls s3://public.s3tools.org
$
確かに空いていますね。
$ s3cmd put some-file.xml s3://public.s3tools.org/somefile.xml
some-file.xml -> s3://public.s3tools.org/somefile.xml [1 of 1]
123456 of 123456 100% in 2s 51.75 kB/s done
2 つのディレクトリ ツリーをバケットの仮想「ディレクトリ」にアップロードします。
$ s3cmd put --recursive dir1 dir2 s3://public.s3tools.org/somewhere/
File 'dir1/file1-1.txt' stored as 's3://public.s3tools.org/somewhere/dir1/file1-1.txt' [1 of 5]
File 'dir1/file1-2.txt' stored as 's3://public.s3tools.org/somewhere/dir1/file1-2.txt' [2 of 5]
File 'dir1/file1-3.log' stored as 's3://public.s3tools.org/somewhere/dir1/file1-3.log' [3 of 5]
File 'dir2/file2-1.bin' stored as 's3://public.s3tools.org/somewhere/dir2/file2-1.bin' [4 of 5]
File 'dir2/file2-2.txt' stored as 's3://public.s3tools.org/somewhere/dir2/file2-2.txt' [5 of 5]
ご覧のとおり、 /somewhere 'ディレクトリ' を作成する必要はありません。実際、これは単なるファイル名のプレフィックスであり、実際のディレクトリではなく、事前に作成する必要はありません。
--recursiveオプションを指定してput使用する代わりに、 syncコマンドを使用することもできます。
$ s3cmd sync dir1 dir2 s3://public.s3tools.org/somewhere/
$ s3cmd ls s3://public.s3tools.org
DIR s3://public.s3tools.org/somewhere/
2009-02-10 05:10 123456 s3://public.s3tools.org/somefile.xml
--recursive (または -r) を使用して、すべてのリモート ファイルをリストします。
$ s3cmd ls --recursive s3://public.s3tools.org
2009-02-10 05:10 123456 s3://public.s3tools.org/somefile.xml
2009-02-10 05:13 18 s3://public.s3tools.org/somewhere/dir1/file1-1.txt
2009-02-10 05:13 8 s3://public.s3tools.org/somewhere/dir1/file1-2.txt
2009-02-10 05:13 16 s3://public.s3tools.org/somewhere/dir1/file1-3.log
2009-02-10 05:13 11 s3://public.s3tools.org/somewhere/dir2/file2-1.bin
2009-02-10 05:13 8 s3://public.s3tools.org/somewhere/dir2/file2-2.txt
$ s3cmd get s3://public.s3tools.org/somefile.xml some-file-2.xml
s3://public.s3tools.org/somefile.xml -> some-file-2.xml [1 of 1]
123456 of 123456 100% in 3s 35.75 kB/s done
$ md5sum some-file.xml some-file-2.xml
39bcb6992e461b269b95b3bda303addf some-file.xml
39bcb6992e461b269b95b3bda303addf some-file-2.xml
元のファイルのチェックサムは、取得されたファイルのチェックサムと一致します。うまくいったようです:-)
S3 から「ディレクトリ ツリー」全体を取得するには、再帰的 get を使用します。
$ s3cmd get --recursive s3://public.s3tools.org/somewhere
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt saved as './somewhere/dir1/file1-1.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt saved as './somewhere/dir1/file1-2.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-3.log saved as './somewhere/dir1/file1-3.log'
File s3://public.s3tools.org/somewhere/dir2/file2-1.bin saved as './somewhere/dir2/file2-1.bin'
File s3://public.s3tools.org/somewhere/dir2/file2-2.txt saved as './somewhere/dir2/file2-2.txt'
宛先ディレクトリが指定されていなかったため、 s3cmdディレクトリ構造を現在の作業ディレクトリ (「.」) に保存しました。
以下の間には重要な違いがあります。
get s3://public.s3tools.org/somewhere
そして
get s3://public.s3tools.org/somewhere/
(末尾のスラッシュに注意してください)
s3cmdファイルの名前付けに常にパスの最後の部分、つまり最後のスラッシュの後の単語を使用します。
s3://.../somewhereの場合、最後のパス部分は「somewhere」であるため、再帰的 get はローカル ファイルに somewhere/dir1、somewhere/dir2 などの名前を付けます。
一方、 s3://.../somewhere/では、最後のパス部分は空であり、s3cmd は「somewhere/」プレフィックスのない「dir1」と「dir2」のみを作成します。
$ s3cmd get --recursive s3://public.s3tools.org/somewhere/ ~/
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt saved as '~/dir1/file1-1.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt saved as '~/dir1/file1-2.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-3.log saved as '~/dir1/file1-3.log'
File s3://public.s3tools.org/somewhere/dir2/file2-1.bin saved as '~/dir2/file2-1.bin'
見る？これは、前の例の~/somewhere/dir1ではなく~/dir1です。
s3://public.s3tools.org/somewhere/ の下にあるものをすべて削除します。
$ s3cmd del --recursive s3://public.s3tools.org/somewhere/
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt deleted
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt deleted
...
次に、バケットを削除してみます。
$ s3cmd rb s3://public.s3tools.org
ERROR: S3 error: 409 (BucketNotEmpty): The bucket you tried to delete is not empty
ああ、 s3://public.s3tools.org/somefile.xmlのことを忘れていました。とにかくバケットを強制的に削除できます。
$ s3cmd rb --force s3://public.s3tools.org/
WARNING: Bucket is not empty. Removing all the objects from it first. This may take some time...
File s3://public.s3tools.org/somefile.xml deleted
Bucket 's3://public.s3tools.org/' removed
基本的な使い方は前のセクションで説明したとおり簡単です。
-vオプションを使用して冗長レベルを上げることができ、プログラムがそのボンネットの下で何をしているのかを本当に知りたい場合は、 -d指定して実行すると、すべての「デバッグ」出力が表示されます。
--configureで構成すると、使用可能なすべてのオプションが~/.s3cfgファイルに吐き出されます。これは、お気に入りのテキスト エディターですぐに変更できるテキスト ファイルです。
転送コマンド (put、get、cp、mv、および sync) は、オブジェクトが失敗した場合でも転送を続行します。障害が発生した場合、その障害は stderr に出力され、終了ステータスは EX_PARTIAL (2) になります。オプション--stop-on-errorが指定されている場合、または構成オプション stop_on_error が true の場合、転送は停止し、適切なエラー コードが返されます。
詳細については、S3cmd / S3tools のホームページを参照してください。
著作権 (C) 2007-2023 TGRMN ソフトウェア (https://www.tgrmn.com)、Sodria SAS (https://www.sodria.com/) および寄稿者
このプログラムはフリーソフトウェアです。 Free Software Foundation によって公開されている GNU General Public License の条件に基づいて、再配布したり変更したりすることができます。ライセンスのバージョン 2、または (オプションで) それ以降のバージョンのいずれか。
このプログラムは役立つことを期待して配布されていますが、いかなる保証もありません。商品性や特定目的への適合性についての暗黙の保証もありません。詳細については、GNU 一般公衆利用許諾書を参照してください。
