この記事は Docker2 Advent Calendar 2016 の24日目として予定していましたが、Dockerの17日目が投稿されていなかったため、代わりに投稿します。
(正直、あまりこういう事は言いたくないのですが期限を守れない方は業務ではどうしているんでしょう。。@koki_cheeseさん24日目キャンセルしてしまいました。ごめんなさいm(_ _)m)
さて、本題です。
弊社では2016年に入ってから8割の案件でDockerを利用するようになってきました。
そこで、効率的に運用するために幾つかのサービスを検討した結果、AWSのElasticBeanstalkというサービスに辿り着きました。
ElasticBeanstalkとは何か?
簡単にいうと、AWSの各サービスをまとめてコントロールするためのサービスです。ElasticBeanstalkを利用することで、EC2, ECS, RDS, ELB, Auto Scaling, プロビジョニング、モニタリングなどをウィザードに従い数ステップで作成・管理することが出来ます。
また、簡易的なバージョン管理機能も備えておりアプリのロールバックも容易です。
さらには、ElasticBeanstalkはDockerだけではなく、Java, .NET, PHP, Node.js, Python, Ruby, GoなどのアプリケーションもサポートされているのでDockerはちょっと...という人でも安心です。
Amazon様すごすぎぃ!
CircleCIを使って本番運用する上でのデメリット
さて、ここまでElasticBeanstalkの凄さばがりに触れてましたがデメリットもあります。
ElasticBeanstalkのと言うよりはDockerのデメリットなんですが、何と言ってもデプロイに時間が掛かり過ぎるんです!!
たとえばRailsの場合、precompile次第ではありますが数分でデプロイが終わるところを、
git pull
bundle exec rails db:migrate
bundle exec rails assets:precompile
bundle exec pumactl -F config/puma.rb phased-restart
Docker環境だと、弊社ブログにある通り場合によっては数十分掛かってしまいます。
このままでは本番で緊急対応したいバグなどがある場合に、非常に困る...
CircleCIでの高速化を可能な限りやってみる
最近だとCIはWerckerやAWS CodeBuildなど、気になるサービスが続々と出てきていますが、CircleCIでも工夫次第ではかなり高速化出来ます。
1. awsebcliのインストール
CircleCIでBeanstalkのデプロイを行うにはawsebcliが必要ですが、利用にはPython2.7.9または3.4以上が必要です。
CircleCIでは現時点(2016/12/24)でOSバージョンが2つ用意されています。
Ubuntu 12.04
Ubuntu 14.04
Ubuntu 12.04を選択している場合、バージョンが古いためデプロイ時にPython2.7.9以上をインストールしなければならず、この作業に約2分掛かってしまいます。Ubuntu 14.04はPython2.7.11が乗っているため、OSを変更するだけで2分短縮できます。
この短縮は大きいですね!
- Ubuntu 12.04
- Ubuntu 14.04
注)2016年7月以降に新規でAdd ProjectsしたプロジェクトではデフォルトでUbuntu 14.04になっています。
2. cache_directoriesを利用してprecompileをキャッシュする
CircleCIではデプロイするたびにデプロイ用コンテナを新規に作成しているので毎回フルでprecompileが走ってしまいます。これは非常に無駄。キャッシュしましょう。
(略)
dependencies:
pre:
- pip install awsebcli
post:
- | # precompileしたものをcacheしたいのでここでprecompile
if [ $CIRCLE_BRANCH = 'master' ]; then
RAILS_ENV=production bundle exec rails assets:precompile assets:clean
elif [ $CIRCLE_BRANCH = 'staging' ]; then
RAILS_ENV=staging bundle exec rails assets:precompile assets:clean
fi
cache_directories:
- public/production/assets
- public/staging/assets
- tmp/cache/assets
これで2回目以降のデプロイでキャッシュが読み込まれてprecompileが高速化されます。弊社の環境ではプロジェクトによっては10分以上もの短縮が図れました。
これはもう、キャッシュ!せずにはいられないッ!
3. cache_directoriesを利用してbundle installをキャッシュする
さあ、ここまで来るとキャッシュ出来るところは全部したくなります。bundle installもキャッシュしちゃいましょう!
(略)
dependencies:
pre:
- docker run -v `pwd`:/root -v ~/gem_cache:/root/vendor ruby:2.3.3 bash -c "cd /root && bundle install --path=vendor/bundle --without development test && rm -rf ./.bundle"
- rm -rf ./vendor/bundle
- cp -r ~/gem_cache/bundle ./vendor/bundle
cache_directories:
- ~/gem_cache
これでさらに数分短縮です!
しくみ製作所の技術力は世界一ぃ!!(すみません、ほんと言い過ぎました...申し訳ございませんm(__)m)
最後に
弊社では、これらを実施することで20分ほど掛かっていたデプロイが6分ほどに短縮されたプロジェクトもあります。
他にも、皆さまが実施している短縮方法などあれば是非教えてください
Dockerのデプロイ時間短縮を図ってみんなで一緒にしあわせになっていきましょう!