ELBってなんじゃ？（アクセスログがやってきた）

ELBにアクセスログ機能が搭載されたので、試してみました。

まず、AWSコンソールのELBのの画面をみてみますが、ここで、古いバージョンのコンソールだとアクセスログの設定ができないので、ヘッダ上部のお知らせアイコンから新しいバージョンに切り替えます。

任意のELBを選択して、下部ペインのDescriptionタブの最下段に、「Access Logs」という項目が追加されているのが分かります。

最初はDisabledになっています。Editのリンクを押下すると、以下のようなダイアログが表示されます。

ここで、「Enable Access Logs」にチェックを入れ、

• Interval：ログ出力間隔（現状５分か60分）
• S3 Location：ログ出力先のS3ロケーション（Create the location for meをチェックすると自動でつくられる）

を入力し、「Save」をクリックします。



しばらくすると、指定したS3のロケーションに、ログが出力されます。

中身をみてみると、以下のようになっています。

2014-03-06T23:50:37.819662Z manage 54.248.248.218:60123 10.156.231.23:80 0.00008 0.002195 0.000074 403 403 0 5039 "GET https://mng.cloudpack.jp:443/ HTTP/1.1"
2014-03-06T23:54:42.332009Z memory 219.117.233.241:43172 10.156.231.23:80 0.000068 2.234742 0.000065 200 200 0 129832 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account HTTP/1.1"
2014-03-06T23:54:45.898722Z memory 219.117.233.241:43172 10.156.231.23:80 0.000069 0.142097 0.000058 200 200 0 766319 "GET https://memory.cloudpack.jp:443/cloudpack/admin HTTP/1.1"
2014-03-06T23:55:05.069736Z memory 219.117.233.241:43172 10.156.231.23:80 0.000082 0.767399 0.000083 200 200 0 129832 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account HTTP/1.1"
2014-03-06T23:55:09.530026Z memory 219.117.233.241:43172 10.156.231.23:80 0.000078 0.701585 0.000067 200 200 0 133234 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/2 HTTP/1.1"
2014-03-06T23:55:11.639899Z memory 219.117.233.241:43172 10.156.231.23:80 0.000088 0.70764 0.000099 200 200 0 133341 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/3 HTTP/1.1"
2014-03-06T23:55:13.555633Z memory 219.117.233.241:43172 10.156.231.23:80 0.000076 0.698172 0.000095 200 200 0 131071 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/4 HTTP/1.1"
2014-03-06T23:55:15.414292Z memory 219.117.233.241:43172 10.156.231.23:80 0.000075 0.885828 0.00009 200 200 0 129831 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/1 HTTP/1.1"
2014-03-06T23:55:20.774540Z memory 219.117.233.241:43172 10.156.231.23:80 0.000075 0.68001 0.000083 200 200 0 23283 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/index?search=miura HTTP/1.1"
2014-03-06T23:55:25.478841Z memory 219.117.233.241:43172 10.156.231.23:80 0.000076 0.817105 0.000061 200 200 0 233574 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account/doc/miura@cloudpack.jp HTTP/1.1"
2014-03-06T23:55:31.467146Z memory 219.117.233.241:43172 10.156.231.23:80 0.000072 0.142359 0.00011 200 200 0 766319 "GET https://memory.cloudpack.jp:443/cloudpack/admin HTTP/1.1"
2014-03-06T23:55:35.995594Z memory 219.117.233.241:43172 10.156.231.23:80 0.000077 0.768791 0.000101 200 200 0 129832 "GET https://memory.cloudpack.jp:443/cloudpack/admin/account HTTP/1.1"
2014-03-06T23:55:37.699927Z memory 54.248.248.218:36526 10.156.231.23:80 0.000064 0.001333 0.000062 403 403 0 5039 "GET https://memory.cloudpack.jp:443/ HTTP/1.1"

ログのフォーマットは、以下のような構成だそうです。

フィールド名	説明	例
タイムスタンプ	クライアントにレスポンスを返したUTC時刻	2014-02-15T23:39:43.945958Z
ELB名	ELBの名前	my-test-loadbalancer
クライアントポート	リクエストしたクライアントのIP	192.168.131.39:2817
バックエンドポート	このリクエストを処理したインスタンスのIP	10.0.0.0.1
リクエスト処理時間	ELBがリクエストをうけとってからインスタンスに渡すまでの経過時間（秒）	0.000073
バックエンド処理時間	インスタンスに渡してからレスポンスヘッダを返し始めるまでの経過時間（秒）	0.001048
レスポンス処理時間	ELBがインスタンスからレスポンスヘッダを受け取りクライアントにレスポンスヘッダを返し初めてからの経過時間（秒） 処理時間にはELBのキューイング時間とインスタンスへの接続要求時間も含まれています。	0.000057
ELBステータスコード	ELBからクライアントへ返されるHTTPステータスコード (HTTPのみ)	200
バックエンドステータスコード	インスタンスからELBへ返されるHTTPステータスコード (HTTPのみ)	200
受信バイト数	クライアントからのリクエストのサイズ（バイト） HTTPリクエストではボディのみでヘッダのサイズは含まれません TCPリクエストではヘッダのサイズも含まれます	0
送信バイト数	クライアントへのレスポンスのサイズ（バイト） HTTPリクエストではボディのみでヘッダのサイズは含まれません TCPリクエストではヘッダのサイズも含まれます	29
"リクエスト"	ダブルクォーテーションで囲まれたクライアントからのリクエスト行。フォーマットは HTTPメソッド + プロトコル://ホスト:ポート + パス + HTTPバージョン TPCリクエストでは"- - -"のようになります。	"GET http://www.example.com: 80/HTTP/1.1"

ELBは自動でスケールするので、漏れ無くロギングできるかどうかは怪しいところですが、簡単にアクセスログをとるには便利そうです。

以上です。

TreasureDataってなんじゃ？（Googleスプレッドシートで簡易ダッシュボード）

前回、TrasureDataでデータのロードとクエリの実行を行いましたが、今回は結果をTreasureDataの外に出してみます。

まず、Google Spreadsheetで空のスプレッドシートを作成します。
名前は適当に、「TreasureDataTest」シートは「dashboard1」と名づけます。

また、Googleでパスワードに2段階認証を掛けている場合、TreasureDataがGoogle Spreadsheetへアクセスできないので、予めGoogleアカウントでアプリ用のパスワードを作成しておきます。

ここまでできたら、TreasureDataの画面に移ります。「New Query」の「Result Output」のプルダウンで出力先の選択肢が表示されますので、今回はGoogleSpreadsheetを選びます。

すると、Google Speardsheet用の設定項目が表示されます。
先ほどつけた、ファイル名、シート名、取得したアプリ用のパスワードなどを指定し、クエリをつくって実行します。

実行がおわると、指定したスプレッドシートに解析結果のデータが表示されます。
そのデータを元に、GoogleSpreadsheetのグラフ機能でグラフを作って簡易ダッシュボードが完成です。

実行のスケジューリングなどもできますので、定期的に内容のかわるスプレッドシートをつくることもできるでしょう。

以上です。

Dockerってなんじゃ？（docker+nginxで複数コンテナにWEBサーバーをたてる）

dockerを使って複数のWEBサーバーを立ててみたいと思います。
複数の外部ポートを使うため、プロキシとしてnginxと併用してみます。

今回は２つのWEBサーバーのコンテナを立て、１つにはwordpress on apache、もう一つは素のnginxを入れてみます。

コンテナにはそれぞれ

• memorycrat.cloudpack.jp
• tenkaippin.cloudpack.jp

というドメインを割り当てます。
また、sshも立ちあげます。

今回はDockerfileを使ってイメージを構築します。
それぞれのコンテナのDockerfileとsupervisorの設定ファイルテンプレートは以下の様にホスト側に配置しておきます。

 $ tree .
.
└── templates
    ├── memorycraft
    │   └── conf
    │       ├── Dockerfile
    │       └── supervisor.conf
    └── tenkaippin
        └── conf
            ├── Dockerfile
            └── supervisor.conf

wordpressコンテナの設定

memorycraftコンテナでは、httpdとsshのサービスを立ちあげます。
また、wordpressをダウンロードし、RDSに接続するように設定ファイルを書き換えます。

./templates/memorycraft/conf/Dockerfile

./templates/memorycraft/conf/supervisor.conf
コンテナをビルドします。

docker build --no-cache --rm -t memorycraft/wordpress templates/memorycraft/conf/

できたら、起動します。

docker run -p 80 -p 22 -d memorycraft/wordpress /usr/bin/supervisord

nginxコンテナの設定

tenkaippinコンテナでは、nginxとsshのサービスを立ちあげます。

./templates/tenkaippin/conf/Dockerfile
./templates/tenkaippin/conf/supervisor.conf
コンテナをビルドします。

docker build --no-cache --rm -t tenkaippin/nginx templates/tenkaippin/conf/

できたら、起動します。

docker run -p 80 -p 22 -d tenkaippin/nginx /usr/bin/supervisord

ホスト側nginxの設定

まず、プロキシ用にnginxをインストールします。

# rpm -ivh http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
# yum install nginx -y

ここで一度コンテナの起動状況を調べてみます。

# docker ps -a
CONTAINER ID        IMAGE                          COMMAND                CREATED             STATUS              PORTS                                          NAMES
5499f267f670        tenkaippin/nginx:latest        /usr/bin/supervisord   About an hour ago   Up About an hour    0.0.0.0:49185->22/tcp, 0.0.0.0:49186->80/tcp   determined_shockley
9b361ac4aaef        memorycraft/wordpress:latest   /usr/bin/supervisord   5 hours ago         Up 5 hours          0.0.0.0:49173->22/tcp, 0.0.0.0:49174->80/tcp   loving_nobel

これで、

• memorycraft:80 → 49174 
• tenkaippin:80 → 49186 

というマッピングになっているのが分かります。（起動時にホスト側のIPを指定することも出来ます。）

次に、仮想サーバごとにプロキシ設定します。まずプロキシの基本設定です。

/etc/nginx/conf.d/proxy.conf

次に、仮想サーバーで、memorycraft.cloudpack.jpとtenkaippin.cloudpack.jpの設定をします。
プロキシの転送先ポートとして、先ほど調べたポートを指定します。

/etc/nginx/conf.d/virtual.conf

DNSの設定

次にRoute53で、２つのサブドメインでこのサーバーに向けたAレコードを登録します。

これで作業は完了です。

確認

それでは、SSH確認してみます。


memorycraft.cloudpack.jp

まずは、ホストサーバでssh接続してみます。

# ssh memorycraft@127.0.0.1 -p 49173
The authenticity of host '[127.0.0.1]:49173 ([127.0.0.1]:49173)' can't be established.
RSA key fingerprint is a2:c9:81:fb:f5:84:57:ee:06:db:8b:18:7e:3c:2a:2e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:49173' (RSA) to the list of known hosts.
memorycraft@127.0.0.1's password:
[memorycraft@9b361ac4aaef ~]$
[memorycraft@9b361ac4aaef ~]$

接続出来ました。

次に、ブラウザを確認します。

おお！接続出来ました！



tenkaippin.cloudpack.jp

ssh接続してみます。

# ssh tenkaippin@127.0.0.1 -p 49175
ssh: connect to host 127.0.0.1 port 49175: Connection refused
[root@ip-10-157-38-165 ~]# ssh tenkaippin@127.0.0.1 -p 49185
The authenticity of host '[127.0.0.1]:49185 ([127.0.0.1]:49185)' can't be established.
RSA key fingerprint is c3:87:55:75:0b:d4:ce:f3:5c:0a:e9:71:e1:0f:fd:ca.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:49185' (RSA) to the list of known hosts.
tenkaippin@127.0.0.1's password:
[tenkaippin@5499f267f670 ~]$
[tenkaippin@5499f267f670 ~]$

接続出来ました。

ブラウザを見てみます。

ちゃんと表示されています！

このように、サーバー資源が限られていてユーザースペースを確実に分離したい場合などには、複数コンテナをつかうと便利かもしれません。

以上です。

Dockerってなんじゃ？（S3プライベートレジストリ）

前回に引き続き、プライベートレジストリです。

前回の方法では、レジストリのコンテナを載せたサーバー自体が落ちてしまったときに登録されたコンテナイメージが全てなくなってしまいます。
dockerのregistryコンテナには、設定ファイルが存在し、永続化のオプションとしてバックエンドにS3を使うことができます。

それでは早速試してみます。

レジストリ側の設定

レジストリのコンテナをbashで起動します。

$ docker run -t -i registry /bin/bash

レジストリに入ったら設定ファイルがある/docker-registry/config/フォルダに移動します。
S3用のサンプルがあるのでそれをconfig.ymlとして使います。

dockerのレジストリでは設定ファイルに_env:VARIABLENAMEとなっている部分があり、環境変数をセットしている部分です。起動時に-eオプションでその環境変数をコンテナに渡すことが出来ます。

このS3用のファイルは、AWSキーやバケット名などに環境変数をセットできるようになっているので起動時にパラメータ渡しが可能です。今回はそのまま変更なしで使います。

# cd /docker-registry/config
# mv config.yml config.yml.org
# cp config_s3.yml config.yml
# cat config.yml
~(略)~
prod:
    storage: s3
    boto_bucket: _env:AWS_BUCKET
    s3_access_key: _env:AWS_KEY
    s3_secret_key: _env:AWS_SECRET
    s3_bucket: _env:AWS_BUCKET
    s3_encrypt: true
    s3_secure: true
    secret_key: REPLACEME
    s3_encrypt: true
    s3_secure: true
    storage_path: /images

接続を終了し、コミットします。

# exit;
# docker ps -a
CONTAINER ID        IMAGE                         COMMAND                CREATED             STATUS              PORTS                    NAMES
1e1e890b9647        registry:0.6.5                /bin/bash              6 minutes ago       Exit 0                                       grave_wozniak

# docker commit 1e1e890b9647 memorycraft/registry

コミットしたS3用のレジストリイメージを起動します。その際前述のように、-eオプションでAWSキーやバケット名などを環境変数として渡します。
また、SETTINGS_FLAVOR環境変数は、config.ymlのprodと対応しています。これによって設定ファイルの各モードを起動時に選択することができます。

# docker run -p 5000:5000 -e SETTINGS_FLAVOR=prod -e AWS_KEY=XXXXXXX -e AWS_SECRET=YYYYYYYYY -e AWS_BUCKET=memorycraft-docker-registry -d memorycraft/registry
#
#
# docker ps -a
CONTAINER ID        IMAGE                         COMMAND                CREATED             STATUS              PORTS                    NAMES
1e1e890b9647        registry:0.6.5                /bin/bash              6 minutes ago       Exit 0                                       grave_wozniak
413aa68a3ad1        memorycraft/registry:latest   /docker-registry/run   9 hours ago         Up 9 hours          0.0.0.0:5000->5000/tcp   prickly_davinci

これで、S3対応のレジストリができました。

S3レジストリへの登録

それではクライアント側からこのレジストリにpushしてみます。流れは前回の記事と同じです。

# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS              PORTS                                          NAMES
ee60c633c8f9        memorycraft/centos:latest   /usr/bin/supervisord   3 days ago          Up 3 days           0.0.0.0:49189->22/tcp, 0.0.0.0:49190->80/tcp   happy_brattain
c118bcc97b1e        539c0211cd76                /bin/bash              5 days ago          Exit 0

# docker commit ee60c633c8f9 176.34.16.242:5000/memorycraft/centos
b939188f4672b83d03e90ad12c4ad9e2ccdfa66d2f50fd44ae18ef314eee5c5b

# docker images
REPOSITORY                              TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
176.34.16.242:5000/memorycraft/centos   latest              b939188f4672        14 seconds ago      443.8 MB
memorycraft/centos                      latest              d0c94b943ba2        4 days ago          437.9 MB

# docker push 176.34.16.242:5000/memorycraft/centos
The push refers to a repository [176.34.16.242:5000/memorycraft/centos] (len: 1)
Sending image list
Pushing repository 176.34.16.242:5000/memorycraft/centos (1 tags)
539c0211cd76: Image successfully pushed
380423464fbc: Image successfully pushed
dc52da789c75: Image successfully pushed
b2ab60219415: Image successfully pushed
52b555115035: Image successfully pushed
a149f9038d0e: Image successfully pushed
3897f6889349: Image successfully pushed
bd1a450e0e46: Image successfully pushed
da6f1a424b7c: Image successfully pushed
4a8d2a1dab88: Image successfully pushed
af06476dc08c: Image successfully pushed
65ec465a844b: Image successfully pushed
318326461017: Image successfully pushed
fc6935aadec7: Image successfully pushed
9022a04f5b3f: Image successfully pushed
4787e46941f7: Image successfully pushed
30f9368972bb: Image successfully pushed
dc6de6feb9a9: Image successfully pushed
d0c94b943ba2: Image successfully pushed
b939188f4672: Image successfully pushed
Pushing tags for rev [b939188f4672] on {http://176.34.16.242:5000/v1/repositories/memorycraft/centos/tags/latest}

無事にpushできたようです。
それではS3バケットを覗いてみると、リポジトリのメタデータやイメージなどがアップされているのがわかります。

レジストリを消してみる

ここで、一度、レジストリ側のサーバーが壊れてしまった。もしくはインスタンスが消えてしまった場合を想定して、０から別のサーバーにレジストリを立てて見たいと思います。

# docker run -t -i registry /bin/bash
# cd /docker-registry/config
# mv config.yml config.yml.org
# cp config_s3.yml config.yml
# cat config.yml
# exit


# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
927bb1ccf9dc        registry:0.6.5      /bin/bash           About a minute ago   Exit 0                                  trusting_mccarthy
# docker commit 927bb1ccf9dc memorycraft/registry
# docker run -p 5000:5000 -e SETTINGS_FLAVOR=prod -e AWS_KEY=XXXXXXXXXXXXXXXX -e AWS_SECRET=YYYYYYYYYYYYYYYY -e AWS_BUCKET=memorycraft-docker-registry -d memorycraft/registry /docker-registry/run.sh

S3からpull

念のためクライアント側もイメージもコンテナも消した状態で、S3レジストリを指定してrunしてみます。

# docker run -t -i 176.34.16.242:5000/memorycraft/centos /bin/bash
Unable to find image '176.34.16.242:5000/memorycraft/centos' (tag: latest) locally
Pulling repository 176.34.16.242:5000/memorycraft/centos
b939188f4672: Download complete
da6f1a424b7c: Download complete
dc6de6feb9a9: Download complete
af06476dc08c: Download complete
b2ab60219415: Download complete
65ec465a844b: Download complete
4a8d2a1dab88: Download complete
3897f6889349: Download complete
a149f9038d0e: Download complete
539c0211cd76: Download complete
30f9368972bb: Download complete
52b555115035: Download complete
bd1a450e0e46: Download complete
318326461017: Download complete
4787e46941f7: Download complete
380423464fbc: Download complete
dc52da789c75: Download complete
d0c94b943ba2: Download complete
9022a04f5b3f: Download complete
fc6935aadec7: Download complete
bash-4.1#

ちゃんと取得できて、コンテナを立ち上げることが出来ました。
これで、S3の高い堅牢性可用性をバックエンドにしたレジストリができました。

以上です。

Dockerってなんじゃ？（プライベートレジストリ）

前回の記事で、Docker Indexというパブリックレジストリについて書きましたが、プライベートなレジストリを作ることも出来ます。それによって社外に出したくない資産などを管理することが出来ます。

Docker Indexには、プライベートレジストリ用のリポジトリが提供されていて、それをpullしてコンテナとしてプライベートレジストリとして使うことが出来るようになっています。

それでは、早速試してみたいと思います。
localhostでも構いませんが、今回はレジストリ専用のサーバーを用意してみます。
最初の記事のようにレジストリサーバー上で、Dockerをインストールしておきます。

レジストリのインストールと起動

そして、Docker Indexのregistoryというリポジトリからpullしてきいます。

# docker pull registry

あとはこれを立ち上げるだけです。レジストリの内部ポートは5000番が使用されます。今回は外部ポートも5000番で指定します。

# docker run -d -p 5000:5000 registry

commit

そしていままでのコンテナサーバー側で、コンテナをコミットしますが、指定の仕方が異なります。

docker commit <コンテナID> <レジストリサーバーIP>:<レジストリポート>/<リポジトリ名>

のようにします。

# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS              PORTS                                          NAMES
7b033c1821a7        centos:6.4                  /bin/bash              38 minutes ago      Exit 0

# docker commit 7b033c1821a7 176.34.16.242:5000/memorycraft
a2a360e08ee87d8fd3c98f08701ce0e4d681164e50432ff032890108eded996c

すると以下のようにタグ付けされたイメージが保存されます。

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
176.34.16.242:5000/memorycraft   latest              a2a360e08ee8        12 seconds ago      360.4 MB

push

そしてこれをpushしてみます。pushもコミットと同様の指定の仕方になります。

# docker push 176.34.16.242:5000/memorycraft
The push refers to a repository [176.34.16.242:5000/memorycraft] (len: 1)
Sending image list
Pushing repository 176.34.16.242:5000/memorycraft (1 tags)
539c0211cd76: Image successfully pushed
a2a360e08ee8: Image successfully pushed
Pushing tags for rev [a2a360e08ee8] on {http://176.34.16.242:5000/v1/repositories/memorycraft/tags/latest}

うまく自前のレジストリにむけてpushされたようです。

確認

次に、ローカルのイメージを削除してみます。

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
176.34.16.242:5000/memorycraft   latest              a2a360e08ee8        3 minutes ago       360.4 MB

# docker rmi a2a360e08ee8
Untagged: a2a360e08ee87d8fd3c98f08701ce0e4d681164e50432ff032890108eded996c
Deleted: a2a360e08ee87d8fd3c98f08701ce0e4d681164e50432ff032890108eded996c

# docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

改めて、自前のレジストリから起動してみます。

# docker run -t -i 176.34.16.242:5000/memorycraft /bin/bash
Unable to find image '176.34.16.242:5000/memorycraft' (tag: latest) locally
Pulling repository 176.34.16.242:5000/memorycraft
539c0211cd76: Download complete
a2a360e08ee8: Download complete
bash-4.1#
bash-4.1#

おお！無事起動しました。

このように、自前のレジストリを用意すると、公開したくないコンテナイメージを社内やシステム内に限定して共有することができます。

以上です。