FC2ブログ

DockerはVMと同列に比較できるものではない

この記事はブロとものみ閲覧できます
スポンサーサイト



データ・ボリューム・コンテナは不要どころかもう使えない子

一つ前の記事の続き。
まずは更に踏み入ってボリュームだけでもコンテナ間で共有できるとか言われる所以について説明します。

前の記事で述べた通り、ボリュームとは単にコンテナ内にホスト(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/以下に残ります。

よって、別にデータ・ボリューム・コンテナを使えなくても不自由なく使用が可能です。

また、ボリュームを別に作る必要はありますが、実は docker volume create コマンドを使えばボリュームのホスト上での場所も指定することが出来ます。 できそうな雰囲気でしたが執筆時点では出来ませんでした。。
https://docs.docker.com/engine/reference/commandline/volume_create/
プラグインを使えば出来るというような話もありますが試してみない以上は真偽は不明。

これで作ったボリュームはトップレベルの volumes オプションで external: true すれば、マウントすることが出来ます。
https://docs.docker.com/compose/compose-file/#external

ホストに対して、ボリュームを作るのは一回で良いのでこれで無駄にデータ・ボリューム・コンテナを立ち上げなくても不便なく作業できます。

え、別に Version 2 で書けばよくね?

古いバージョンは廃止されることが宣言されてる。
せっかく環境依存性を抑えるためのツールなのに、時期が来たら使えなくなるとか意味が無い。
ということで、解決策がある以上皆さんこれからは Version 3 で書きませう φ(・∀・)

データ・ボリューム・コンテナはデータを保存するためのコンテナでは無い

あと1日で6月になってしまうので更新。今回も Docker ネタ。

ここ1ヶ月半近くずっと Docker を弄くり続けています。本当にやりたいことは Docker を使ったアプリ開発の更に先にあるんだけど、せっかくの機会、ということで Docker を自主的に使って少々時間が掛かってます(でも環境に依存しないようにしたい意図があるし今後のことを考えると今勉強しといたほうが良いって思ってる)。

ちょっと無駄話になってしまうので、読み飛ばしてもらったほうが良いかもしれませんが、一ヶ月半使った感想を書きます。
最初は結構動作にわからない部分が多く、また特に Docker Compose、コンテナ間の組み合わせなどすんなり分かんない部分もあったけどわかってしまえば結構簡単です。ボリュームなど実装がどういうものかわかってしまえば、書き方自体はシンプルで使うのは意外と楽です。

ただ、データの扱いについては非常に混乱したというかややこしいと思いました。


ここから本題。
まず、ボリュームについて理解しなければいけませんでしたが、こっちに関しては比較的シンプルで、各所の説明通りホストのディレクトリを各々の Docker コンテナでマウントして共有してるだけでした。
しかし、データ・ボリューム・コンテナはずっとデータを格納するコンテナ機能があるんだろうと思っていました。でもこれが超越的解釈で全くイメージとは異なる機能でした。
これから Docker を使い始めようと思ってあちこち見て回ってある程度情報を掴んできた人だと丁度こんな勘違いをしていると思います。

結論から言うとデータ・ボリューム・コンテナは単なるコンテナ。
これにボリュームとするホストのディレクトリをマウントさせた上で、ボリュームをコンテナ間で共有するためのいわゆるハブとして、各アプリ用コンテナと通信するようにしたのがこれの正体です。

データ・ボリューム・コンテナはデータを格納するんじゃなくて、あるボリュームを複数コンテナからアクセス出来るようにするためのコンテナです。

そして、こういう機能が Docker に備わっているわけではありません。
ボリュームをマウントさせた通常のコンテナを、ボリュームへのアクセス用ハブとして使っているものをこう呼んでるだけです。

ただし、通常 Docker のコンテナは何らかの個別のアプリを格納し、実行していますが、データ・ボリューム・コンテナでは BusyBox コンテナという最低限の Linux のコマンドのみを備えたコンテナを使用することが多いです(BusyBox は多くのコマンドを持ったツールでこれを格納したコンテナ)。
これが何故かは簡単で、データ・ボリューム・コンテナは単なるアクセスポートとしてしか使わないので容量・動作を軽くするためです。でもこれってなんか勿体なくない?

データ・ボリューム・コンテナはボリュームをコンテナ間で共有するためのものです。
というのが多くのサイトで目にする説明ですが、明らかに言葉不足です。こんな説明じゃ実体なんて分かるはずもなく生き殺し。
こうなる最大の理由はボリュームをコンテナ間で共有できないということが説明されてないことに尽きると思います(図があると尚良し ←)。

そもそも

Dockerは環境を持ち運べるようにしたものであって、データを移動できるようにしたものでは無い。
別にデータ・ボリューム・コンテナ経由でデータを格納したからって、結局データはホストに保存されるので ADD に対して可搬性は高くならない。

これで話は終わり。。

ところが、私を更に混乱させたのが、ボリュームだけでもコンテナ間で共有できるという情報だった。
じゃあなんでデータ・ボリューム・コンテナなんて使うんだ?
ますます理解できなくなってきた。

この後いろいろ調べた末、記事投稿時点でデータ・ボリューム・コンテナは不要だと判明しました。
続く

Docker を CentOS 7 に入れてみた

備忘録。

まず、Docker をインストールする上で、名前が複数あるのが紛らわしくて一旦手を止めた。

docker-engine とか docker-io をインストールと書いてあるサイトがある。

違いを調べたら、どうも Docker EE(Enterprise Edition) がつい先月(2017年3月)リリースされたばかりらしく、今までの無料版は Docker CE(Community Edition)になった模様。
(Ubuntu じゃないので、docker-io がサポート中かは今回未確認。)
http://kenoha.hatenablog.com/entry/2017/03/31/114418

よって、Docker CE for CentOS Distribution をインストールする。
以下にインストール方法が載っているので、順番にコピペする。
コマンドに -y オプションを添えてくれる優しい人達が書いてくれている。
https://store.docker.com/editions/community/docker-ce-server-centos?tab=description

アンインストール方法はこっちに書いてある。
https://docs.docker.com/engine/installation/linux/centos/#uninstall-docker

因みにそのままだと、いちいちホストでの Docker の操作に sudo を打たないといけない。インストール後は自動起動の設定に加えて、docker group への追加が案内されている。
https://docs.docker.com/engine/installation/linux/linux-postinstall/#systemd

ただし、コンテナの使いようによっては、危険を伴う可能性があるので Warning にリンクされているページをよく読むこと。

また、インストール時点での問題ではないものの、以下のように外からアクセスできるようにしていると設定によっては root が乗っ取られる(Docker コンテナを外部に公開するのは危険 とか言われる所以と思われる)ので、特に Docker.sock、不要なポート開放には注意とのこと。
Dockerでホストを乗っ取られた

Docker は既に作ってあるコンテナを起動したり、ホストからファイルを転送した程度なので、自分でコンテナを立ち上げたりはまだしてません(したい)
Webアプリを作るためにテスト環境から本番への以降が簡単なように(+ホストでやってグシャグシャになったときの再構成の手間を省くため)取り敢えず、しばらく Docker でゴニョゴニョする予定です。

スポンサードリンク

ブログ内検索

プロフィール

ふじこlp

Author:ふじこlp
はてなブログへ移行しました。https://higechira.hatenablog.com/

ゆとりの大学生です。どれくらいゆとりかというと土曜日に通常授業を受けたことがただの一度もありません。

IBM時代のT43は観賞用となりましたが、X61は現役。
スクエアThinkPad X Series 最高です。
MacBook Pro 始めました。がやはりThinkPadに勝る打ち心地は存在しませんね。

カレンダー

11 | 2019/12 | 01
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

天気予報


-天気予報コム- -FC2-

フリーエリア

ブロとも申請フォーム

QRコード

QR

アクセスカウンター