@repeatedly さんが「Docker 周りとのFluentdの記事が無い」と言っていたので、AWS Elastic Beanstalk の Docker で Fluentd を動かす話について書きます。Fluentd というよりは Docker とか Beanstalk の話が厚めです。
要点だけ三行で
- Elastic Beanstalk の Docker で Fluentd を動かすときは
- 起動用のスクリプトを書いたり
- Docker 起動スクリプトを調整したりしましょう
くわしく
Beanstalk やら Docker やらについての簡単な説明は、今年4月の【AWS発表】AWS Elastic Beanstalk for Docker からの引用で済ませておきます。
AWS Elastic Beanstalkを使えば、簡単に、AWSクラウド内でアプリケーションをデプロイおよび管理することができます。 アプリケーションをアップロードすると、Elastic Beanstalkはキャパシティ(Amazon EC2インスタンス)をデプロイ、監視、スケールし、ロードバランサーを使って、正常に稼働しているインスタンスにリクエストを分散してくれます。
Dockerは、さまざまな環境で実行することができる、軽量、ポータブルで、カスタマイズ可能なコンテナという形でアプリケーションのデプロイを自動化します。 コンテナは事前に構築されたDocker イメージや、Dockerfileとして知られるシンプルなレシピから作成することができます。
補足として、Beanstalk には eb コマンドというものがあり、手元にこのコマンドをインストールして eb push で手元の git リポジトリをデプロイできるようになります。AWS を使ってウェブサービスを動かす数ある手法はたくさんありますが、その中でも簡単な方です。わぁ、Heroku みたい！
Docker で Fluentd を動かす話は、既にたくさんの事例が出ていますが、Beanstalk の上となると、少し状況が異なってきます。
まず一番大きい違いが、Beanstalk では Docker コンテナをひとつしか走らせられないことです。つまりリンクが使えないので、nginx と Fluentd でそれぞれコンテナを分けるといったことができず、ひとつのコンテナで nginx と Fluentd を走らせることになります。Docker らしくないですが、デプロイが楽になることを重視したければ我慢しましょう。
もう一つの違いが、これはやり始めてから気づくのですが、コンテナ側の ulimit の制御が難しいということです。ここがこの記事のキモになります。
nginx 公式イメージをベースに Fluentd を組み込んでみます。
起動用のスクリプトを書く
FROM nginx
RUN apt-get update
RUN apt-get -y install curl sudo
RUN curl -L http://toolbelt.treasuredata.com/sh/install-debian-wheezy-td-agent2.sh | sh
ADD run.sh /opt/run.sh
EXPOSE 80
CMD ["sh", "/opt/run.sh"]
service td-agent start
nginx -g "daemon off;"
これで普通の環境なら動くと思います。動きはするんですが、ulimit -n がイマイチです。Request Logs するなり直接 ssh するなりして /var/log/eb-docker/containers/eb-current-app/なんとか-stdouterr.log を見れば分かるんですが、
/etc/init.d/td-agent: 76: ulimit: error setting limit (Operation not permitted)
が出ちゃってます。td-agent の 76 行目というのは、Fluentd の init スクリプトが ulimit を変更するところです。
コンテナ側の ulimit についてはコンテナ側でどうすることもできないので、ホスト側をいじる必要があります。一般にはホスト側の ulimit を上げて docker を再起動という方法が取られているようですが、これを ebextensions に書くと何か微妙な結果になっちゃいます。
あ、ebextensions っていうのは、PaaS な感じの Beanstalk に対して細かい調整をするための仕組みです。yaml を書くことで任意のパッケージをインストールしたりコマンドを実行できたりします。docker を止めて ulimit 上げて docker 起動する ebextensions はこれ。
commands:
restartdocker:
command: service docker stop && ulimit -n 65536 && service docker start
で、これを eb push してやると、なんかエラーが出ます。
Health が Green なのに ERROR とか ERROR とか出ててキモチワルイですね。docker を再起動した後に、さっきまで動いてたコンテナを止めようとしてエラーとか、そんな状況になっていると思われます。
/etc/security/limits.conf を書き換える方法をとったとしても、結局は docker を再起動する必要があり、docker を再起動する限り上のエラーが出てしまいます。
そこで、今回はこれを回避するために Docker ホスト側の起動スクリプトを調整する方法を紹介します。
Docker 起動スクリプトを調整する
コンテナの ulimit を上げるには、ホストで ulimit を上げて再起動する以外にも方法があります。コンテナを動かすとき、つまり docker run を実行するときに --privileged オプションを使うことで、ホスト側の設定に縛られること無くコンテナ側で ulimit を上げることができます。
Beanstalk の docker ホストがどこで docker run を叩いているのがどこかというと、/opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh です。
# run the container
docker run -d \
"${EB_CONFIG_DOCKER_ENV_ARGS[@]}" \
"${EB_CONFIG_DOCKER_VOLUME_MOUNTS[@]}" \
"${EB_CONFIG_DOCKER_ENTRYPOINT_ARGS[@]}" \
$EB_CONFIG_DOCKER_PORT_MAPPING \
$EB_CONFIG_DOCKER_IMAGE_STAGING \
"${EB_CONFIG_DOCKER_COMMAND_ARGS[@]}" 2>&1 | tee /tmp/docker_run.log | tee $EB_CONFIG_DOCKER_STAGING_APP_FILE
これを ebextensions で無理やり書き換えちゃいましょう。
commands:
patchrunsh:
command: sed -i "s/docker run -d/docker run --privileged -d/" /opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh
これで、おかしなエラーを回避しつつ Beanstalk で Fluentd を動かすことができます。めでたしめでたし。
--privileged オプションは、ulimit 上げるだけにしては権限強すぎるなーなんてことを考えてたら、Docker 側でちょうど Proposal: Allow setting ulimits for containers という Pull Request が上がってました。これがリリースされたら、そのオプションを使ったほうがいいでしょうね。
ちなみにこの記事を書いている最中に、Beanstalk が Docker 1.3.2 に対応したことに気づきました。1.3 ということは docker exec が使えるわけで、だいぶ開発が捗りそうです。それでは。
参考リンク
- ホスト側の ulimit を上げてコンテナの ulimit を上げる