Dockerは本番運用でばかり使うものでもないという話

　今年のデヴサミではDockerを使って運用環境を便利にしたってな話をぼちぼち聞いた気がする。一方で、Dockerなんて本番環境の運用で使うんじゃないよ、っていう話題が出てきたりしている。デヴサミでDockerを導入したって発表をしてたところは、自分のところで、自分たちの目的に合うように、しっかり知見を貯めていた。その上で本番環境への導入をしていた。お上から「なんじゃ、Dockerを入れると工数削減できるらしいじゃないか」という鶴の一声で唐突に、走っているプロジェクトに入れることになれば災厄になりかねないとは思う。
　そんな話題もあるが、Dockerってすごく便利だと思っていて、本番運用だけで使うものでもないなーと考えている。なので「とりあえず」でDockerを使えるような自分（イチ開発者）なりの使い方を書いておく。先に一つ書いておくと、GUIがないとダメなようならちょっとつらいものではある。

　まず、OSはなんでもいいがDockerは入っているものとする。
　たとえばMySQLを使っているが、MongoDBをちょっと検討したくて、軽くさわってみたくなったとする。通常なら、開発マシンや仮想マシンにインストールして立ち上げたりする。DockerならMongoDBサーバの用意にコマンド一つ。

docker run -p 27017:27017 mongo

これで少し待てばローカルにMongoDBサーバが立ち上がる。あとは自分の使いたい言語でMongoDBとつなぐライブラリを用意してつなぐだけ。Pythonでならpymongoをpipなどでインストールして下記。

from pymongo import MongoClient

client = MongoClient()

　Dockerのコマンドでやっているのは、コンテナと呼ばれるものを走らせる指示と、そのコンテナとクライアントのポートの結び付けだ。ここではmongoというコンテナを走らせろと指示をしており、mongoというコンテナイメージを持ってなければパブリックリポジトリへイメージを探しに行く。
　パブリックリポジトリはOSベンダやらなんやら様々なソフトベンダがイメージを提供している。UbuntuやCentOS、Debianなどのイメージから、RailsやDjangoなどのWebフレームワークがすぐ使えるもの、MySQLやMongoDBなどDBがすぐに使えるものなど、さまざまなものがそろっている。

　コンテナは仮想化の一種なので、依存関係的な意味ではクライアント環境は汚れていない。ただコンテナイメージは使いたいソフト+それが実行される環境（OSなど）の容量を持つため、物理的な容量は多少持っていかれる。けど動作としてはたいして重くはならない。コンテナによる仮想化は、従来の仮想化を使うより軽くなる仕組みになっている。昨今のDockerの盛り上がりを受けて、コンテナとしてAlpineというセキュリティを考慮された数MB程度しかないOSを使うのが流行っている。

　Dockerを使うことで、容易にちょっと触ってみたいDBサーバを用意できた。これをこのまま開発用のDBにしてもいいだろう。仮想環境に用意されたので、依存関係でクライアント環境を汚す心配はない。



　Dockerの使い方をもう一つ。Webアプリケーションの実行環境を用意してみる。例としてここではNodejsで。
　ぼくは開発にWindowsを使っている。Macを開発に使っている人も多数いるだろう。けどそんな人たちの本番サーバはなにかしらのLinuxディストリビューションであることが大半だ。開発環境と本番環境のOSが違うってのは嫌だ。そろえたい。これまでメジャーであったVirtualBoxのようなもので、仮想マシンを立ち上げる？それは手間だし、仮想マシン内でコマンドをいじっているうちに、その環境が秘伝のタレになってきて、本番環境で再現できない可能性だってある。じゃあDockerを使う。

　Dockerを使う前にアプリを準備する。ここでは簡単なもので済ませる。Nodejsで走らせるとポート8000番で待ち受け、Hello World!を返す単純なやつ。

./scripts/app.js

const http = require('http');



const port = 8000;



const server = http.createServer((req, res) => {

  res.statusCode = 200;

  res.setHeader('Content-Type', 'text/plain');

  res.end('Hello World\n');

});



server.listen(port);



console.log(`Server running at port:${port}/`);

　続いてDockerfileを用意する。ここにはどんな環境を用意して、アプリ実行前にやる事前準備をして、ではいざ実行というプロセスを書くことになる。

./Dockerfile

# Nodejsが入っているAlpine OSを使う

FROM node:7.10.0-alpine



# RUNに続くコマンドを実行する

RUN mkdir /app



# クライアントのカレントディレクトリにあるファイルをコンテナの/appへコピー

COPY . /app



# コンテナでコマンドが走るときのカレントディレクトリを設定

WORKDIR /app/scripts



# ポート待ち受け設定

EXPOSE 8000



# あとで走らせるコマンド(Nodejsの実行)

CMD node app.js

　以上二つで必要なファイルはそろった。./Dockerfileと./scripts/app.jsの二つのファイルがカレントディレクトリ以下にある。二つコマンドを打てば、アプリを動かすサーバが立ち上がる。
　まずコンテナイメージの作成。Dockerfileで最終行のCMDの前までを実行し、環境イメージが作成される。

docker build -t node_app

　環境イメージができれば、あとはそれを使って実際に走るコンテナを作る。

docker run -p 8000:8000 node_app

　アプリ作成後は、デプロイまで単純な二つのコマンドで済んでいる。便利。

　実際にDockerでNodejsのWebアプリやるなら、ユーザを用意して、実行はそっちに切り替えようねという話など参考になるのが下記。
http://postd.cc/lessons-building-node-app-docker/


　さいきん開発の遊びに使っていたPCを修理に出したので、手元に予備マシンしかなかった。これだとDBの準備がめんどうだなーと思っていたが、Dockerですんなり解決した。
　Dockerは仮想化の一種であり、クライアント環境を汚さないという恩恵がある。あとはHyper-Vみたいなので仮想マシン一台を丸々立ち上げるより、いろいろ軽い。だから本番のデプロイが便利になる以外にも使い道はたくさん出てきそう。


知らないおじさんの作ったDockerfileとかイメージを無邪気に使っちゃダメ。セキュリティ的に。