S3

2013年12月17日

このエントリーをはてなブックマークに追加

S3-backedで一歩先行く使い捨て生活

docker-top-logo

前回に続いてPrivate Docker Registry。前回やり残していた検証、

S3 Storage : 使い捨ての良き友

まだ動作検証してないけども、S3と連携させられる所までは分かっている。

この後の戦略・シナリオは、

  1. s3 config済みのカスタムregistryイメージを作成(Dockerfile経由で)
  2. カスタムregistryコンテナを起動
  3. カスタムregistryイメージをpush

ここまで済ませておけば、必要な時にプライベートregistryコンテナを起動すれば良い。カスタムregistryでさえも、気軽に使い捨てられる。この辺の検証は、また別のエントリで。

残り検証作業をしてみた。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
  • s3cmd-1.0.1-1.el6.noarch
事前準備:S3 bucket

新規作成でも既存バケットでも、どちらでも良い。s3cmdでバケットを新規作成する場合の例。

$ s3cmd mb s3://private-docker-registry
Bucket 's3://private-docker-registry' created

※本書用にでっち上げたバケット名

事前準備:Dockerイメージ用ファイル

イメージビルド用に必要なファイルを用意/配置しておく。

  1. Dockerfile
  2. config.xml
1: Dockerfile
$ cat Dockerfile
FROM stackbrew/registry

ADD config.yml /docker-registry/config.yml
2: config.xml(docker-registry用)

コンテナイメージに焼き込むdocker-registry用config.xml

# The common' part is automatically included (and possibly overriden by all
# other flavors)
common:
    # Bucket for storage
    boto_bucket: ***s3 bucket名***

    # Amazon S3 Storage Configuration
    s3_access_key: ***s3_access_key****
    s3_secret_key: ***s3_secret_key***
    s3_bucket: ***s3 bucket名***
    s3_encrypt: 1
    s3_secure: 1

    # Set a random string here
    secret_key: ***適切なパスフレーズ***

priv:
    storage: s3
    storage_path: /priv

privターゲットは、環境変数SETTINGS_FLAVOR用で、privでなくても良い。

イメージビルド
$ sudo docker build -t registry.private .
Uploading context 10240 bytes
Step 1 : FROM stackbrew/registry
 ---> 3321c2caa0cf
Step 2 : ADD config.yml /docker-registry/config.yml
 ---> ad03546fac66
Successfully built ad03546fac66
コンテナ作成

今回は -e=SETTINGS_FLAVOR=priv を指定して起動。これにより、private用途の設定内容を指定して起動可能となる。

$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
接続テスト
$ curl -v http://localhost:5000/
* About to connect() to localhost port 5000 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: gunicorn/18.0
< Date: Tue, 17 Dec 2013 11:22:17 GMT
< Connection: keep-alive
< Expires: -1
< Content-Type: application/json
< Pragma: no-cache
< Cache-Control: no-cache
< Content-Length: 31
< X-Docker-Registry-Version: 0.6.2
< X-Docker-Registry-Config: priv
<
* Connection #0 to host localhost left intact
* Closing connection #0
"docker-registry server (priv)"

"docker-registry server (priv)" となってる。これにより、SETTINGS_FLAVORがprivである事を確認出来る。

いよいよS3-backed Private Registryにpush

イメージ取得とtag打ちは、前回の作業により既に終わってるものとする。

sudo docker push 127.0.0.1:5000/ubuntu
The push refers to a repository [127.0.0.1:5000/ubuntu] (len: 1)
Sending image list
Pushing repository 127.0.0.1:5000/ubuntu (1 tags)
Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c

Pushing tags for rev [8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c] on {http://127.0.0.1:5000/v1/repositories/ubuntu/tags/latest}

clientサイドとしては、何か変化してるのかどうかすら、分からない。

S3バケットを覗いてみる
$ s3cmd ls s3://private-docker-registry/
                       DIR   s3://private-docker-registry/priv/

/priv/ ディレクトリが作成されている。これは "storage_path: /priv" と一致する。

$ s3cmd ls s3://private-docker-registry/priv/
                       DIR   s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/repositories/

その配下には、 /images/ と /repositories/ が作成されている。

$ s3cmd ls s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/

その先にはハッシュ値のディレクトリが存在。これの値は、push時にも出力されていたイメージID。

$ s3cmd ls s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/
2013-12-17 11:24        78   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/_checksum
2013-12-17 11:23        68   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/ancestry
2013-12-17 11:23       437   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/json
2013-12-17 11:23  71488718   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/layer

遂に実態オブジェクトが現れた。pushの裏側でs3バケットにオブジェクトが正しく登録されていた事が分かる。

気軽に使い捨てる

これだけでは使い捨て感を得られないので、使い捨てしてみる。

  1. private registryコンテナを破棄
  2. 新private registryコンテナを作成
  3. ローカルからイメージを一度削除
  4. 新private registry経由でイメージをpull
private registryコンテナを破棄
$ sudo docker kill 411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
新private registryコンテナを作成
$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
febb22cad222594f2158bf240b199deda243bbc976bcf7b956c689b1c3cddffe
新private registryコンテナが起動してる事を確認
$ sudo docker ps
CONTAINER ID        IMAGE                                    COMMAND                CREATED             STATUS              PORTS                    NAMES
febb22cad222        127.0.0.1:5000/registry.private:latest   /bin/sh -c cd /docke   32 seconds ago      Up 31 seconds       0.0.0.0:5000->5000/tcp   evil_brown
イメージ削除前に存在有無確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ローカルからイメージを削除
$ sudo docker rmi 127.0.0.1:5000/ubuntu
Untagged: 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
ローカルにイメージが無い事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
pullしてイメージを取得
$ sudo docker pull 127.0.0.1:5000/ubuntu
Pulling repository 127.0.0.1:5000/ubuntu
8dbd9e392a96: Download complete
再びローカルにイメージが作成された事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)

無事、復活。

あとがき

private registry構築により、複数リポジトリを扱ってみると、DockerイメージがGitライクに操作出来てる事を再認識させられる。実によく出来てる。

  • 成果物としてDockerイメージリポジトリごと納品するケースも出て来るだろうか
  • S3-backedにしておけばオブジェクトが無くなる心配はほぼ皆無で、心配事を減らせるか

遊べそうな事ばかり増えて行く。

参考文献



編集
@hansode at 22:30|PermalinkComments(0)TrackBack(0)

2009年08月20日

このエントリーをはてなブックマークに追加

概要

  • s3fsを使い、Amazon S3をファイルシステム扱いする

前提条件

  • Amazon Web Serviceのアカウントを持っている事
  • s3foxなどでAmazon S3にバケットを作っておく事

作業環境

作業内容

■UNIXグループ設定

  • AWSのキーを/etc/passwd-s3fsに設定(記述)する必要がある
    • 一般ユーザーに見せたくないので、特定アカウント/特定グループにのみ公開する
      • 特定ユーザー名: ubuntu
      • 特定グループ名: s3fs
  • ⇒と言う事で、グループ設定する

▼グループ名「s3fs」存在有無を確認


$ getent group s3fs

▼「s3fs」グループ作成


$ sudo addgroup --system s3fs

▼「s3fs」グループが作成された事を確認


$ getent group s3fs
s3fs:x:120:

▼ubuntuを「fuse」と「s3fs」に追加


$ sudo vigr

▼ubuntuが「fuse」と「s3fs」に追加された事を確認


$ getent group fuse
fuse:x:106:ubuntu
$ getent group s3fs
s3fs:x:120:ubuntu

▼s3fsビルド環境整理

必要に応じてパッケージをインストール。
今回は下記パッケージが不足していたのでインストール。


$ sudo apt-get install libcurl4-gnutls-dev
$ sudo apt-get install libxml2-dev
$ sudo apt-get install libfuse-dev

▼s3syncをビルド


$ wget http://s3fs.googlecode.com/files/s3fs-r177-source.tar.gz
$ tar zxvf s3fs-r177-source.tar.gz
$ cd s3fs
$ make

▼s3fsをインストールし、setgid設定


$ sudo install -m 2755 -o root -g s3fs ./s3fs /usr/local/bin/s3fs
$ ls -la /usr/local/bin/s3fs
-rwxr-sr-x 1 root s3fs 697215 Aug 19 07:17 /usr/local/bin/s3fs

▼/etc/passwd-s3fs作成


$ sudo vi /etc/passwd-s3fs
---
accesskey_id:secret_accesskey_id の形式で記述
---

▼s3fsグループのみ公開する


$ sudo chown root:s3fs /etc/passwd-s3fs
$ sudo chmod 640 /etc/passwd-s3fs

■実際にマウントしてみる

  • S3バケット名: s3fs-sandbox-bucket
  • マウントポイント: /home/ubuntu/mnt-s3fs

▼ユーザー確認


$ whoami
ubuntu

▼マウントポイント作成


$ cd
$ pwd
/home/ubuntu
$ mkdir mnt-s3fs

▼Amazon S3をs3fsでマウント


$ s3fs s3fs-sandbox-bucket mnt-s3fs/

▼マウント状況を確認


$ mount | grep s3fs
s3fs on /home/ubuntu/mnt-s3fs type fuse.s3fs (rw,nosuid,nodev,user=ubuntu)

▼dfを実行してみる


$ df /home/ubuntu/mnt-s3fs
Filesystem           1K-blocks      Used Available Use% Mounted on
s3fs                 274877906944         0 274877906944   0% /home/ubuntu/mnt-s3fs
$ df -h /home/ubuntu/mnt-s3fs
Filesystem            Size  Used Avail Use% Mounted on
s3fs                  256T     0  256T   0% /home/ubuntu/mnt-s3fs

dfには256Tとして認識されている。
Amazon S3の容量に上限は無い。
いつまでもディスク使用率「0%」となるはずだ。

▼lsしてみる


$ cd mnt-s3fs
$ ls -la
total 0

▼ファイル生成


$ touch foo.txt
$ ls -la
total 1
-rw-r--r-- 1 ubuntu ubuntu 0 Aug 20 03:14 foo.txt

$ date | tee date.txt
Thu Aug 20 04:31:22 UTC 2009
$ ls -la date.txt
-rw-r--r-- 1 ubuntu ubuntu 29 Aug 20 04:31 date.txt
$ cat date.txt
Thu Aug 20 04:31:22 UTC 2009

$ df /home/ubuntu/mnt-s3fs
Filesystem           1K-blocks      Used Available Use% Mounted on
s3fs                 274877906944         0 274877906944   0% /home/ubuntu/mnt-s3fs

極小ファイルとは言え、ファイルを生成した。
しかし、使用サイズに変化が見られない。
Amazon S3の無制限を表している。


あとがき

  • Amazon S3をファイルシステムとして扱えるのが面白い
  • 手元の環境に巨大ストレージを構築可能となってしまった
  • しかも、共有ストレージとして利用が可能だ。遅いNFSのようなもの。
  • リアルタイム性が求められる場面、更新頻度が高いファイル(例えばアクセスログ)にはs3fs(Amazon S3)は向かない。

Amazon S3の特性・性質を十分理解した上でs3fsを上手に使えば、様々な利用方法が考えられる。
s3fsは面白いので、色々とハックしてみる予定。




編集
@hansode at 14:25|PermalinkComments(0)TrackBack(0)

2008年10月06日

このエントリーをはてなブックマークに追加

無くなってからでは遅い

消えたら困る大事なデータを定期的にS3へバックアップする

同期ツールをインストール

今回はaws-s3を採用


$ gem install aws-s3

同期スクリプト配置

  • 保持期間は1か月分
  • ファイル名には日付(+%d)を入れておく
  • 一カ月後には同ファイル名でファイルが生成され、上書きされて行く
  • 例)
    • mysql_redmine.sql.01.gz
    • svn_ec2.01.gz

$ cd /root
$ vi ec2-daily-backup.sh
-----
#!/bin/sh
 
# env.
AWS_ACCESS_KEY_ID=**********
AWS_SECRET_ACCESS_KEY=**********
export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY
 
#
# vars.
#
theday=$(date +%d)
 
## mysql
db_name=redmine
db_backup_gzip=/var/backup/daily/mysql/mysql_${db_name}.sql.${theday}.gz
## subversion
svn_name=ec2
svn_backup_gzip=/var/backup/daily/svn/svn_${svn_name}.${theday}.gz
 
# dump
mysqldump --default-character-set=utf8 -uroot ${db_name} | gzip > ${db_backup_gzip}
svnadmin dump /home/svn/repos/ec2/ | gzip > ${svn_backup_gzip}
 
# sync
s3sync -v ${db_backup_gzip}  redmine:backup
s3sync -v ${svn_backup_gzip} redmine:backup

実行権限付与


$ chmod +x ./ec2-daily-backup.sh

一度実行して確認


$ sh -n ./ec2-daily-backup.sh 
$ ./ec2-daily-backup.sh 

更にS3Foxなどで確認

crontabのエントリ修正

エントリ追加


$ crontab -e
----
0 0 * * * /root/ec2-daily-backup.sh >/dev/null 2>&1
----

エントリの内容確認


$ crontab -l



編集
@hansode at 14:50|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

概要

  • EC2をA3へバックアップする手順をまとめた文書

補足

  • EC2はインスタンスを停止させるとデータがクリアされてしまうのでデータのバックアップが必要
  • そこでEC2用ストレージであるS3へバックアップを行う
  • 今回はAMIまるごとバックアップ

作業内容

EC2のイメージのバックアップファイル作成

$ ec2-bundle-vol -d /mnt -k /mnt/pk-*****.pem -c /mnt/cert-*****.pem -u 2337-8359-0872
Please specify a value for arch [i386]: <--- エンター
Copying / into the image file /mnt/image...
Excluding:
         /sys
         /proc
         /proc/sys/fs/binfmt_misc
         /dev
         /media
         /mnt
         /proc
         /sys
         /mnt/image
         /mnt/img-mnt
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.002869 seconds, 365 MB/s
mke2fs 1.39 (29-May-2006)
/etc/fstab:
         # Legacy /etc/fstab
         # Supplied by: ec2-ami-tools-1.3-20041
         /dev/sda1 /     ext3    defaults 1 1
         /dev/sda2 /mnt  ext3    defaults 0 0
         /dev/sda3 swap  swap    defaults 0 0
         none      /proc proc    defaults 0 0
         none      /sys  sysfs   defaults 0 0
Bundling image file...

.....

Creating bundle manifest...
ec2-bundle-vol complete.

ファイルが作成されている事を確認

  • image.manifest.xml
  • image.part.*
S3へアップロード

先の手順で生成されたimage.manifest.xmlが必要

  • -b でバケット名を指定可能
  • -aでアクセスキーを指定
  • -sで秘密アクセスキー指定

# ec2-upload-bundle -b centos5.0-2008081101 -m /mnt/image.manifest.xml -a アクセスキー -s 秘密アクセスキー
Uploading bundled image parts to https://s3.amazonaws.com:443/centos5.0-2008081101 ...
Uploading manifest ...
Uploaded manifest to https://s3.amazonaws.com:443/centos5.0-2008081101/image.manifest.xml.
Bundle upload completed.
AMIへ登録

FirefoxのアドオンElasticfoxを利用

  1. タブから「AMIs and Instances」を選択
  2. 「Machine Images (AMIs)」から「+」をクリック
  3. 「AIM Manifest Path:」に 「centos5.0-2008081101/image.manifest.xml」を指定して「OK」
  4. 「Machine Images (AMIs)」に「centos5.0-2008081101/image.manifest.xml」がある事を確認



編集
@hansode at 14:30|PermalinkComments(2)TrackBack(0)