さぁ、新しいプロジェクトだ! 今回はこんな言語で、こんなアーキテクチャで行くぜ!
そして各メンバーが開発環境を整え始めると…
メンバーA:「隊長! インストールが失敗します!」
隊長 :「あー、ライブラリxxxのバージョンが古いね。先にこっちのアップデートしようか。」
メンバーB:「隊長! ちゃんと手順書通りセットアップしたんですけどビルドが失敗します!」
隊長 :「うーん・・・、あれ、 -aオプションつけてインストールした?」
開発者あるあるですね。
そこで普段使いのワークスペースとしてdocker-composeを使ってみましょう。
例えばこんな使い方
例1 AWS CLIを使おう
Python 2.6.5 以降が必要です。
pip を使ってインストールします。pip install awscli
正規の手順は上記です。超簡単なのでそんなに嫌がらなくても良いのですが、Pythonのバージョン問題とかありますよね。他の目的でPythonを使っていてpipのバージョン問題などでハマるかもしれません。
aws:
image: pebbletech/docker-aws-cli
volumes:
- "~/.aws:/root/.aws"
こんな内容のファイルを用意して、このファイルと同じディレクトリで下記のコマンドを叩いてみましょう。
$ docker-compose run aws sh
Pulling aws (pebbletech/docker-aws-cli:latest)...
latest: Pulling from pebbletech/docker-aws-cli
e110a4a17941: Already exists
e41aa98800d1: Pull complete
Digest: sha256:2101b7918fd2bd533f12d17b12d5f7efe079a67b49dc26a2a366190f7c96fa85
Status: Downloaded newer image for pebbletech/docker-aws-cli:latest
ほら、あっという間にaws-cliが使えるように。
/ # aws s3 ls
2016-08-25 14:04:47 api-gw-serverless-dev-serverlessdeploymentbucket-xxxxx
2016-08-25 13:16:07 aws-nodejs-dev-serverlessdeploymentbucket-xxxxx
2015-12-16 10:02:37 cf-templates-xxxxxxx-ap-northeast-1
2015-11-19 08:02:28 cf-templates-xxxxxxx-us-west-2
ポイントはホストマシンの~/.aws
をコンテナにマウントすることです。
~/.aws
├── config
└── credentials
(上記のファイル何?という人はこちらを参照してください)
例2 言語処理系のバージョンを固定する
メンバーA:「隊長! SyntaxError: Unexpected token ILLEGALエラー出ます」
隊長 :「ェ… node.jsのバージョンが0.10って古いよ。4系前提なんだけど。あと、mochaをグローバルインストールしてね」
上記の例はNode.jsの例ですが、処理系のバージョン違い、指定のパッケージの入れ忘れなど悩ましいですよね。
こうしてみましょう。
.
├── Dockerfile
├── docker-compose.yaml
└── test
└── hoge.test.js
FROM mhart/alpine-node:4.4.7
RUN npm install -g mocha
RUN mkdir -p /opt/myapp
WORKDIR /opt/myapp
ENV NODE_ENV=test
node:
build: .
volumes:
- ".:/opt/myapp"
"use strict";
const assert = require("assert");
describe("適当なテスト", ()=>{
it("あれがこうなる", ()=>{
assert.equal(`env=${process.env.NODE_ENV}`,"env=test");
});
});
例の如くdocker-compose
を実行してshを起動します。
$ docker-compose run node sh
/opt/myapp # mocha
適当なテスト
✓ あれがこうなる
1 passing (8ms)
ポイントは
- Dockerfileで必要なものをインストールした状態にしてある
(Node.js 4.4.7とmocha) - カレントディレクトリをボリュームマウントしている
というところです。
まとめ
上記2つの例のようにコマンドを実行するワークスペースをDockerで提供してあげると、メンバーの作業端末固有のトラブルを減らすことが出来ます。(Docker慣れは必要ですがそろそろ必須スキルでしょう)
誰か一人がちょっと苦労して、Dockerfile, docker-compose.yamlを書いてバージョン管理に入れて置くだけで良いのです。
この方式の問題
良いことづくしですが、若干の問題が無いわけでもありません。
- Windowsのdocker-composeではrunサブコマンドが使えない
ひょっとしたらDocker for Windows付属のcomposeならできるかもしれません(自分の手元にDocker for Windowsが動く環境が無く、Docker Toolboxでしか試せていません) - コンテナ上で作られたファイルはroot:rootが所有者になる
→考え中(あまり困っていないが)
ぜひ普段使いのDockerライフを!