2017/06/01
データ・ボリューム・コンテナは不要どころかもう使えない子
一つ前の記事の続き。まずは更に踏み入ってボリュームだけでもコンテナ間で共有できるとか言われる所以について説明します。
前の記事で述べた通り、ボリュームとは単にコンテナ内にホスト（Docker コンテナを動かしてるOS上）のディレクトリをマウントさせたものでした。つまり、ホストの同じディレクトリをそれぞれのコンテナでマウントしてしまえば別にデータ・ボリューム・コンテナなんて無くても共有できるってことです。
Q.E.D.
証明は出来たかもしれないけどじゃあなんでデータ・ボリューム・コンテナでボリュームをマウントさせようとするのか？
それは上の方法だといちいち Docker コンテナを起動する（docker run）時にボリュームを指定する必要が生じて、環境をまとめるのが目的でDocker使ってんじゃないの？っていう本末転倒な状況に陥るためです。
データ・ボリューム・コンテナだとボリュームの設定をデータ・ボリューム・コンテナの立ち上げ時のみで済ませることが出来ます。その他のコンテナを起動時に --volumes-from でデータ・ボリューム・コンテナを指定するだけで良い。つまり、他のコンテナでは起動時にボリュームの場所を入力しなくて良いのです。
また、これにはさらなる利点があり、コンテナを立ち上げるホストが変わって、ボリュームをマウントしたいホストの場所が変わっても一ヶ所の変更のみで対応することが出来るんです。
でも、このままだとボリュームのディレクトリをいちいちデータ・ボリューム・コンテナ起動時に指定しないといけません。
そこで Docker Compose の登場
Docker Compose には複数のコンテナの設定を纏めて一つのファイルに書けるというメリットの他に、起動時のコマンドオプションを記述できるメリットがあります。よって、ボリュームのディレクトリを記述すれば、起動時の場所の指定も必要なくなります。
さらに、コンテナ間の通信時に docker-compose.yml 内で指定したコンテナ名をホスト名と置き換えられるので、コンテナ名を短くすればコンテナ内アプリのコーディングも楽になります。
しかし、ここで終わらなかった。
Docker Compose Version 3 での volumes_from 削除により無能と化す
平成29年5月31日時点で最新のDocker Compose Version 3 では、ボリュームに関する記述が変更され、よりシンプルになりました。
シンプルになったのは良いですが、結論を言うと同一ホスト上でのボリューム共有を目的にデータ・ボリューム・コンテナを利用する意義が無くなりました。つまり実はもうデータ・ボリューム・コンテナは要らない子。
まず、この件を説明するにはボリュームのマウント方式について説明する必要があります。
今まで、ボリュームについてホストのディレクトリを指定できることを当たり前のように説明していました。しかし、実はボリュームはホストのディレクトリを指定しなくとも作ることが出来るのです（詳しくは以下を参照）。
https://docs.docker.com/compose/compose-file/#volumes
コンテナ内のマウント先は必ず指定しなければなりません。
また、ボリュームには名前を付けることも出来ます（名前付きボリューム）。名前を付けると何が嬉しいかというと、Compose 内で定義しているコンテナ間でボリュームを共有することが出来るのです。Compose Version 2 から登場したトップレベルの volumes オプションで設定できます。
じゃあデータ・ボリューム・コンテナ要らないのか、となるのは早計で実はボリューム名を定義するとホストの場所を指定できなくなります。これだと自分で任意の場所を指定できないため、問題というか不便が生じます。なので、今迄はデータ・ボリューム・コンテナでホストの場所を指定した上で、他のコンテナでは volumes_from オプションでデータ・ボリューム・コンテナを指定することで共有していました。
しかし、なんとあろうことか Docker Compose Version 3 では volumes_from オプションを削除してしまいました。
https://docs.docker.com/compose/compose-file/compose-versioning/#version-3
でも、焦る必要はありません。（Apple風）
そもそもボリュームのホストの場所を指定できないことによる問題の根源は、好きな場所にボリュームを作れないことにありました。しかし、ホストの場所を指定しない場合にボリュームを作るディレクトリの場所は実は決まっています（/var/lib/docker/volumes/以下）。
問題はディレクトリの名前ですが、実は名前付きボリュームならボリューム名を含んだディレクトリ名となっているので、探してアクセスすることは出来ます。さらに、名前付きボリュームは名前を指定することでマウントが可能なので、再利用が可能です（永続化されている）。
※因みにコンテナ内のマウント先のみ指定した場合は適当な名前のボリュームになり、コンテナを削除した時点でコンテナから接続はできなくなりますが、データは/var/lib/docker/volumes/以下に残ります。
よって、別にデータ・ボリューム・コンテナを使えなくても不自由なく使用が可能です。
また、ボリュームを別に作る必要はありますが、
https://docs.docker.com/engine/reference/commandline/volume_create/
プラグインを使えば出来るというような話もありますが試してみない以上は真偽は不明。
これで作ったボリュームはトップレベルの volumes オプションで external: true すれば、マウントすることが出来ます。
https://docs.docker.com/compose/compose-file/#external
ホストに対して、ボリュームを作るのは一回で良いのでこれで無駄にデータ・ボリューム・コンテナを立ち上げなくても不便なく作業できます。
え、別に Version 2 で書けばよくね？
古いバージョンは廃止されることが宣言されてる。
せっかく環境依存性を抑えるためのツールなのに、時期が来たら使えなくなるとか意味が無い。
ということで、解決策がある以上皆さんこれからは Version 3 で書きませう φ(・∀・)
