Twitterで「最近開発でDocker使ってて便利だよ」って呟いた話

Docker

概要としてはこんな感じ。
少し前、いわゆるLAMPのプロジェクトをやっていてそれにDockerを導入しました。ついっとした通り、本番投入はまだ怖かったので個々人の開発環境とJenkinsのテスト用止まり。デプロイはAnsibleを使ってDockerコンテナにsshという感じで行いました。*1

Ansibleを採用したのは

という経緯から。*2


上記のような環境で開発してみて分かったのは、ついっとにもありますが

  • クリーンな環境をコマンド一発で高速で構築してデプロイするの快適すぎる
  • 同じDockerfileを使うので「俺の環境では動くんだけど」が無い。Jenkins上でのテストもしかり。
  • PRベース開発でレビューする時、他人の成果を自分のマシン上で動かせるの完全に良い
  • Jenkinsマシンが汚れないしJenkinsマシン自体にいろんなライブラリやツールをセットアップしなくて良い
  • Dockerだろうが実マシンだろうが常に同じ仕組みでデプロイしているので安心感が半端ない
    • デプロイの頻度自体も上記のようにローカルでかなりの回数やるので安心感が更にプラス
  • DockerコンテナにMySQLも入れたので、本物のMySQLをテストに使える
    • sqliteやh2みたいな「テスト用の使い捨てDB」を使わず本物のMySQLを使い捨てられる
    • MySQL固有の機能や方言も使えるしわざわざDBアクセス部分をモック化しなくていい


Ansible自体も、使い方覚えればFabricより快適という状況でした。Fabric自体は単なるPythonであるという圧倒的学習コストの低さが魅力なんですが、逆にただのPythonであるというのがデメリットにもなるなと言う感じ。
結局のところただの手続きなので、デプロイスクリプト自体にバグがない事を保証したり安心したりするのはなかなか難しくて、手順自体が複雑だと高確率でデプロイスクリプトにバグを作りこむ結果になるという感じがしていました。
その点Ansibleはymlを使って宣言的に書けるのでFabricに比べるとかなりシンプルになった感じがあります。ただ、その分柔軟さと言うところではFabricより手間がかかるっぽいので、そこはトレードオフと言う感じかなーと思いました。*3

冪等性とかもAnsibleはある程度はやってくれるっぽいです。*4 *5

Chefは使ってないのでChefとの比較は出来ません…。

問題点

方式自体の問題点というよりは、やはり、共用開発環境や本番環境ではDockerが使えなかったという点。
Dockerfileに対して加えた変更をちゃんと実マシンにも反映しましょうというのが結局のところ「人間が気をつける」に帰結してしまうので、うっかりすると「ローカルやJenkinsでは動くのに共用開発環境では動かない」ってなるのがイケてないなーと思いました。

*1:本来はアプリごとDockerイメージに焼きこんでしまいたかったのですが、上述のように開発と本番で環境が違うので、本番環境でDockerfileによるデプロイは出来ないという状況で、とは言え開発と本番でデプロイ先環境が違うからといってデプロイ方法を変えたくなかったのでこのような方法を取りました。

*2:Chefはなんとなく苦手イメージがある

*3:モジュール書けば何でもできるしモジュール自体の作成難度も高くないのでそんなに手間という感じでは無いっぽいですが、言うてやっぱりFabricの手軽さには勝てない感

*4:モジュールによる？

*5:今回あまり複雑なマシン設定も無かったしアプリのデプロイ自体もバージョンごとにディレクトリ作ってシンボリックリンクで切り替える方式にしたのであまり気にしてなかったというのもある