長らく開発環境は Vagrant + VirtualBox でした。このところ CircleCI 2.0 への移行 をきっかけに開発環境も docker 化(docker-compose 化) をすすめています。

Vagrant 利用時の問題点

開発環境を維持していくためにプロビジョニングの整備が必要でした。流行り廃りの中で Chef, Itamae, 最終的に Ansible と使用するツールを変えてきました。

プロビジョニング実行時には, 運用ポリシーにもよりますが, 適用前後の状態変化をチェックするコードを用意しなければならない場合がありました。例えば Go のバージョンのみ変更したい場合, インストール済みの Go のバージョンをチェックし新たにインストールしたいバージョンと差異があるか確認, 必要があればインストールを実行といった具合です。

また, ミドルウェアのバージョンアップにあわせて各自のローカル環境でプロビジョニングを実行する必要がありました。それぞれのマシンで実行するため総時間としてはそれなりの時間が必要です。

docker-compose に移行した結果

メリット

  • docker イメージの作成のみ考えればよく, 既存の状態チェックを意識せずに済む
  • イメージにして Docker Hub 等に置けば各ローカル環境でプロビジョニング作業は不要
  • Vagrant + VirtualBox よりもメモリの消費が少ない
  • CI 環境を含めて考えれば環境構築の手間が浮く
    • プロダクションのサーバ環境まで面倒みれると最高っぽい

デメリット

  • docker-compose の操作を覚える必要がある
  • 複数のコンテナを管理する必要があり煩雑
    • DB やアプリサービスごとに bash で入って状態をチェックする場合がある
  • 通常のサーバ環境を念頭において作業するとわかりづらい

迷ったこと

  • 特定のプロジェクトにおいて, MySQL のユーザ追加等をイメージ側で管理するか否か
    • 汎用性を重視し, $ docker-compose up をラップした Rake タスクでユーザ追加で対応中

実際に開発環境に採用してみて

もっとも助かっているのはメモリ使用量が減ったことです。

使い始めた当初は通常のサーバと異なり, 各サービスごとに作ったコンテナに入って作業する必要があり混乱しました。しかし慣れてしまえば大した問題ではなく, CI 環境との兼ね合いを考えれば大したコストではありませんでした。

一点問題として, デザイナーさんが関わる案件の場合, 現実的に運用できるか疑問が残っています。docker-compose のコマンド体系をある程度把握してもらう必要がでてくるためです。Git/GitHub や Gulp, WebPack が必要な環境において, そういったコマンドの習得コストをどのように考えるべきか悩ましいです。

最後に

docker は存在をしりつつ本格的な導入は遅いタイミングになってしまいました。次回から開発環境は基本 docker ベースでやっていきたいと思います。