Dockerニュービーが開発環境をDocker対応してみた

プログラミング

Node.jsでアプリケーションを開発するときにベースにしているNodeyard、アップデートとあわせてDocker対応も行ってみました。

アップデート内容

Gulpでのタスク管理の廃止

これまでGulpでビルドタスクなどを定義していたのを、全てnpm run-scriptに移行しました。
どうしてもGulpファイルが秘伝のタレ化してしまうのと、必要なツールがCLIのインタフェースを提供していて直接の利用で問題がないことが理由です。

BrowserifyからWebpackへ移行

Browserifyで行っていたフロントエンドのモジュール管理をWebpackに移行しました。
後述するPostCSSで通常のCSSファイルをインポートできるようになったこともあり、フロントエンドのリソースを一元的に管理したかったためです。
また、Webpackと統合されたwebpack-dev-serverが非常に高機能であることも大きな理由です。

SassからPostCSS + cssnextへ移行

これまでも部分的にcssnextを使っていたりしたのですが、完全にPostCSS + cssnextに移行しました。
cssnextはこれからCSSでサポートが予定されている機能を利用するための、PostCSSのプラグインです。
Sassで利用できた全ての機能を利用できるわけではありませんが、変数やネスト、数式などを利用することができ、概ね問題ありません。
PostCSSのpostcss-importを使うことで、CSSファイルのインポートが可能になるのも移行した理由の一つです。
CSSファイルの形式だけで公開されているサードパーティーのCSSフレームワークを、独自に拡張したりすることができるようになります。
また、Basscssのように、PostCSSに対応したフレームワークも増えているようです。

Webサーバのライブリロード

フロントエンドはこれまでbrowser-sync、今回からはwebpack-dev-serverによりライブリロードが可能だったのですが、nodemonを利用してWebサーバのライブリロードも行えるようにしました。
/dist以下のファイルに変更があると、サーバの再起動が実行されます。
セッションがからむような場合は利用できませんが、単純なAPI開発の際は非常に便利になりました。

Docker対応

モックなどデータベースを利用しない場合はローカル開発でも問題ないのですが、やはりアプリケーション開発となるとデータベースやキャッシュを利用することになります。
今までは直接HerokuのDBに接続したりしていたのですが、準備や切り替えなどの作業が煩雑になります。
そこで、DockerでひとまずPostgreSQLとRedisを利用できる開発環境を構築するようにしてみました。

Dockerはほとんど利用したことがなかったのですが、Lessons from Building a Node App in DockerやDockerのリファレンスを参考に。
オフィシャルのnodeイメージを利用することで、ほんの少しDockerfileを記述するだけで大丈夫でした。
PostgreSQLとRedisはイメージをそのまま利用して、ポートもデフォルト。名前解決もされるのでアプリからの接続も簡単。

Docker for Mac Betaを使うと、ファイルの変更検知も問題なく動作してlocalhostでDocker上のサーバにアクセスできるので、ほとんどローカルと同じように感覚で開発できました。

少し戸惑ったのが、イメージのビルド段階でインストールするnpmのライブラリ。

volumes:
  - .:/nodeyard

カレントディレクトリを単純にマウントすると、ホストにはnode_modulesが存在しないため、コンテナのnode_modulesが削除される。

VOLUME ["/nodeyard/node_modules"]

Dockerfileかdocker-compose.ymlでコンテナ起動時にホストにディレクトリを作成するようにすると、コンテナ内部ではnode_modulesに配置されたものはちゃんと存在するけれども、ホスト側からはからのディレクトリしか見えない。
ホストから操作するファイルはイメージに含めるべきでないし、意識する必要もないんだろうけど、Dockerの正しい挙動なのかな??

教えて偉い人。