Docker

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

Dockerfileはシェル使わないと動的な構成できない
データ保存コンテナは外部からの自動コミット必須で、
何かトラブったら簡単にデータ消えるので、
仮想fsとホストボリュームの組み合わせに落ち着く
動的なネットワークへの対応が無茶

これほとんどLVMとchrootとシェルで仮想マシンイメージ作って
運用してるのと変わらない…というよりそれより不便だし、普通にうんこじゃね？
なんで流行ってんの？

速度のためにここまで不便を強いられるなら、
Vagrant+Chef/Ansible+スナップショットで良い気がしてきた

> なんで流行ってんの？

自分でわざわざLVMとchrootを組み合わせて作らなくても用意されているから。

さらに便利なのが、一度やった処理を省いてくれる機能。

具体的に言うと、OSを0からセットアップする時、
A、B、C といったアプリをセットアップするわけだが、
Cのセットアップ中に、Bの設定が間違っていることに気づいた。
0からやり直しかよ。っていう場合、Aの設定を省ける。

もちろん、Cの設定を何回やり直そうが、A、Bの設定は省ける。
Dockerfileを使うと自動的にこうなるから、
Dockerfileを一歩ずつ作っていける。

仮想マシンがBIOSの起動から始まるから、何度も0からセットアップするのが
苦痛なのと対極にDockerだと、変更点以前は一回しかやらないから早い

> Vagrant+Chef/Ansible+スナップショットで良い気がしてきた

の問題点、Chefの真ん中あたりの設定をちょっと書き換えると
数分かかる。もちろんChefの文法を覚えないといけない。

Dockerはほとんどシェルスクリプトと一緒。

ぶっちゃけどちらもやってることは、単なるCUI使ったインストール、
つまりapt-getやyumでできることなのに、なんぜわざわざ
なぜ変な命令を大量に覚えないといけないのか。
Chefはそこがおかしい。

>>33
Dockerでも書き換えたらやり直しだよ
Chefが嫌いならAnsibleでいいじゃない

>>32
>自分でわざわざLVMとchrootを組み合わせて作らなくても用意されているから。
違う違う逆
結局LVMなどのfs仮想化が必要だって言ってるんだよ

>>34
やり直しじゃないよｗ
やり直すのは変更点より以降だけ
OSのインストールって時間かかるんだよね。

で、Dockerfile使っていればインストールが終わった所で
自動的に保存。あとはDockerfileの一行ずつ自動保存

だからDockerfileが以下のようになってる時、

　[OSインストール完了]
　Aの設定
　Bの設定
　Cの設定


Bの設定を書き換えても、OSのインストールやAの設定は二度とやらない。
これにより、OSのセットアップが試行錯誤でできる。
試行錯誤というのは特殊な命令は必要なく、て単なるシェルスクリプトを作るのと変わらない。

途中までやったら、マシンを削除して0から作り直し、と言ってもやった所は自動的に省かれるから
OSのセットアップしていくのが、簡単に高速に行える。

>>35
> 結局LVMなどのfs仮想化が必要だって言ってるんだよ

LVM作っても、差分セットアップ（今までやった所は省く）は
できないからね。そういう仕組みを自分で作るは面倒すぎる。

自分でわざわざスナップショットを取らないといけないし、
このスナップショットは、なんだろう？ どこから
枝分かれした、どの部分かな？ってのを管理しないといけない。

そういう面倒なことはDockerが全部やってくれるから
Dockerインストールするとすぐに使える。

もしかして、構築テストの話じゃなく、実運用の差分の適用の事言ってる？
Chefは逐次実行じゃなく、環境の中身の差分まで検出して変更するから、
Dockerより遥かに柔軟に実行してくれるよ

上の例のVagrant使う場合は、構築のテストも含む場合が多いから皆1から再度作る
>>34はそういうテストをする場合、Dockerでも同じという意味ね
もしかして、Chef使ったことない？

俺がChef等が意味不明だと思うのは、特別すぎる
言語を使わないといけないというところ。

だってさ本来OSのセットアップなんて、CLIから手動でやれてたわけじゃん？
その手動で入力したコマンドをsetup.shというスクリプトに
まとめて実行すればセットアップが完了できるわけじゃん？

なのにわざわざ別の言語を使うってのが意味不明なんだよね。
Ansibleは少しマシだけど、それでもまだ特殊。

Dockerfileはほぼスクリプト言語だよ。
コンテナ環境の外と通信するための命令が少しあるのと
はコマンド一行実行するごとにコミットする必要があるから、
コマンドの頭にRUN を書くことぐらい。

>>36
インストールが不便って、snapshotからの適用もできるよ
起動は確かに遅いけど、動いてしまえはオーバーヘッドは少ないから、
実運用が不便になるよりはマシと思った

総評として、速度のためにそこまで面倒な事したくないなと思ったよ
過剰に擁護する人は、評判に振り回されてるだけでないかな？

>>39
Chefはそこまで難しくないよ…食わず嫌いもいいとこ
それにRubyが嫌ならAnsibleって選択肢もあるよ
これはDockerfile程度の簡便さで書けるよ

それと俺が本当に一番知りたいのはデータ保存のことなんだ
Dockerに詳しいなら説明お願い
または現実でどう対処してる？

>>38
あぁ、冪等性の話ね。

Chefはね。あるべき状態に保つことはできるけど、
あってはならない状態にすることはできないんだ。
全く同じ状態を作り出せない。

たとえばA、Bという環境があって、AとBの内容が違っていた場合、
Chefを動かしても、AとBを全く同じにすることは出来ない。
レシピに書いてあることは守れるが、書いてないことは守れないから。

全く同じ環境でなければ信用ができないので、結局0から作り直す必要がある。
もしくはベースとなるイメージを自分で管理するとかな
その作業は面倒で遅い。

できてしまったレシピを実行するだけなら楽かもしれんが、レシピそのものを
作るのがすごく面倒だからな。単に新しく仮想マシンを起動するのにも
数分かかるレベルだし（Dockerなら1秒）

Dockerfileを使ったら、環境を作成するたびに0から作っているのと同じになる。
そしてDockerfileの一行ごとに状態がコミットされているから、
0から作っているように見えて、変更点以降のみを実行するから早い。

>>42
データ？ 永続性があるディスクを
Docker内にマウントするだけだろ。

>>43
あのね、そもそもChefは同じ「要件」の環境で動かす事を目的にしてるんだから
要件整えば十分なんて当たり前の話なの
同一環境が欲しいならスナップショット

Dockerのが遥かに制限あるのに何言っちゃってんの？
エバンジェリスト気取りで講義したいなら初心者相手にしてくれよ

>>44
永続性のあるディスクのマウントね…ハア…vオプションを言ってるんだろうね

あのね、それのせいで可搬性のため、fs仮想化しないと駄目って言ってるんだよ
データ専用のコンテナ作る場合でも、自動コミットされないよねとも言ってる
意味わかるか？
外部ツール使わず、簡単に対処する方法あるなら是非教えてください

>>45
だからChefは要件を満たすレベルでしか出来ないわけだろ？

それは同一ではない。同一でないということは
時がたったら同じ状態を0から作ることができないかもしれない。

Dockerは同一に出来る。なぜなら全てスナップショットと
同等のものが使われているから。だから優れているわけ。
これがみんなが使う理由だよ。

>>48
Dockerの効果的な部分って起動と可搬性であって
その部分は従来のスナップショット差分で十分だよ
君どういう使いかたしてるの？

>>47
データ専用コンテナを自動コミット？

おまえもしかして、Dockerをデータのバックアップツール、
スナップショットツールとして使おうとでも思ってるのか？
問題が起きた時に、ある日時のデータに巻き戻すとか。

君はまず、システムとデータを分離することの大切さを
学んだほうがいいよ。原則としてDockerの中にはデータを置いてはいけない。

AWSのEC2とか使ったことある？ あれマシン停止したら
データ消えるのが原則だからね（EBS使えば残せるが）

マシンが存在しない状態から、同じものを何十台も作る
（データは共有でありここには含まれない）という
やり方自体を理解してないでしょ？

>>49
> その部分は従来のスナップショット差分で十分だよ

そりゃできるだろｗ
面倒くさいって話なんだら。

いちいちスナップショットを管理してられるかｗ

Dockerfileの作成とメンテナンスに、
「スナップショットを取る」という作業は存在しない。
なぜならDockerがすべてを管理してくれるから

どのスナップショットが、どのスナップショットを元にして
っていう組み合わせをDockerfileの一行に対応して自動管理。

人間はDockerfileを修正するだけでよく「あのスナップショットから作ったら早いかな？
あれにはなんて名前をつけていたかな」などという作業が不要になる

>>50
EC2は関係ないよね、それにそういう場合普通にEBS使うし

どうやら期待してたものとは随分違うみたいだね
先ほどのは、マウントして永続化という運用をした事があるって事だよね？
具体的にどう使ってるか教えてほしい

それが複雑なら、以前の環境で落ち着く事にするよ

>>51
>いちいちスナップショットを管理してられるかｗ
現実としてDockerで管理してるでしょうが…本当に使ってるのか？
コンテナという定点を作ってるだけで、
派生したコンテナがあれば、結局全て更新する必要が出てくるでしょ

やってる事は同じだよ
ただDockerは軽い

EC2に相当するものをCPU仮想化とか使わずに実現できて、
立ち上げ高速、ベースイメージとかスナップショットをハッシュを使って簡単管理
って感じのものだと思ってた

利点もうひとつあったね、共有リポジトリのベースイメージは確かに便利だ
Vagrantと違い、公式のイメージがあるのは良い

結局、単なる煽り屋の説教強盗だったか
最近こういう奴増えすぎてうんざり

>>53
> 現実としてDockerで管理してるでしょうが…本当に使ってるのか？

俺が管理って言ってるのは、人間がスナップショットを取る作業のことだよ。
DockerはDockerが勝手に管理してくれる。
人間がすることは何もない。

だから楽だって言ってるの。

ローカルのvar/lib下のdockerフォルダの構成と特定のイメージだけを別環境へ移行する方法教えて下しあ

Ｄｏｃｋｅｒ上のCentOS7でsystemdが動かないのはなんで？

>>57
仮想化でも、それなりな管理用ソフトウェア使えばSS周りの使い勝手も良いし、
実際に自分の場合、そこは大して変わらない

そんな枝葉の事はどうでも良いから
Dockerを主体として、データの永続化をさせる具体的な運用方法を教えて欲しい
特にあんたの具体例

これで4回目
いちいちくだらない事で煽ってたんだから、まともに答えなさいよ？

>>60
なんかクレクレ君になってるなｗ

データの永続化ぐらい調べなさいよ。

クレクレ君に餌与えるのも嫌だが、
何も知らないと思われるの癪だからヒントだけあげるわ。

イミュータブル インフラストラクチャ
http://ja.wikipedia.org/wiki/Immutable_Infrastructure
> Immutable Infrastructure（イミュータブル　インフラストラクチャ）は不変なサーバー基盤のこと。
> 具体的には、一度サーバーを構築したらその後はサーバーのソフトウェアに変更を加えないことを意味する。

なんでDocker（やAWSのEC2）が仮想マシン（コンテナ）を沢山起動して
終わったら消すという設計になっているのか。その理由がイミュータブル インフラストラクチャな。
一度サーバーを構築したらその後はサーバーのソフトウェアに変更を加えない。

だから、イミュータブル インフラストラクチャにおいて、
データは仮想マシン（コンテナ）の中に置いてはいけないんだよ。

新しい技術を手に入れたのに、それで古やり方を真似るのは馬鹿がすることでな。
古いやり方を捨てて発想の転換をしなくちゃだめ。

以前やっていたあれをどうやって実現すればいいんだよ！という質問は答える気を無くす。
説明した所で、俺は嫌だ昔のやり方がいい。昔のやり方でこれまでもやってきた。
昔のやり方に戻せっていいだすから。というか既に言ってるからねお前。

ここまで一応真面目に二人ともの長文を読んだつもりだったけど、この言いぐさには笑った。
典型的な「発想の転換」馬鹿だな、という感想しか思い浮かばないわ、さすがにこれ。
的外れなDocker信者が騒げば騒ぐほどbuzzword化しかんねんから、
正直いいから黙っておいてくれよ迷惑すぎるわ本当もうね。

そうさ！ 俺の理解できないものはなんでもバズワードさ！

という意見を見た気がするねｗ

>>61-62
結局老害のレッテル貼って藁人形論法してるだけだな
取ってつけたような解説どうも

考え方の否定なんてしてないし、簡単にできない、向いてないなら、
素直にそう一言言えば良かっただけだ
散々否定してきたから、今更言えないか？

そもそもDockerを無視してEC2！Immutable Infrastructure！という態度は
否定どころか、既に俺の意見の強化すらしてるとも取れるけどな

今レスしてる理由は、単純に自分が使って難しい、不便な部分を
簡単にできるかの様に言うので、教えてと言ってるだけなので

>以前やっていたあれをどうやって実現すればいいんだよ！という質問は答える気を無くす。
「〇〇があるだろ」と言えば終わりだろ

そりゃいくら予防線張ったところで、今更fuseやdevice-mapperとか、
Dockerの優位性なんてない、とぼけた事抜かされても困るよ？
やるならビシっと頼むぜ？ これ5回目な

>>65
Dockerの優位性は、簡単だからだろ。

Dockerと同じ仕組みを作るのに
一体どれだけの時間がかかるのか。

まずスナップショットを自動的にとって
差分で管理する、Dockerfile相当のものを
作らないといけないんだよ。

やってみ。

お前は「理論的には出来る」ってことしか言ってないじゃないか。

喩え話をしよう。

「自動車という技術を使えば、遠くへ速く移動できます。」

「海を渡れないじゃないか！ 俺は島に行きたいんだよ！ 自動車なんか使えない」


こういう会話している気分なんだよね。

>>65
> やるならビシっと頼むぜ？ これ5回目な

言うの忘れてたｗ

1万回繰り返したら、教えてあげるよ。

残り9995回な。はい、がんばって！ はい、がんばって！

永続的ストレージって意味ならDockerが提供するのはマシンローカルなボリュームをマウントする類の機能だけじゃないの？
永続的データの管理っていう意味なら、今すでにDockerを活用してるようなとこはDB使うような形態が多いんじゃないかな？
EBSみたいなネットワーク上の任意のボリュームを管理してマウントしたいとかみたいなのはDockerの範疇では無いんじゃないかなあ？
その辺を実現するためにはDockerの上に何かさらに被せないと駄目なんじゃないかな

>>66-68
>こういう会話している気分なんだよね
結局自分でできもしないのにできるって言ってただけ？ｗ
そりゃ答えられないわな
欺瞞的なホラ吹き野郎よりは、お前がレッテル貼ってたような老害のがマシですわ

>>70
なんで俺にこだわってるの？ｗ

できるかできないか知りたいなら調べてたら？
本当に出来ないと思う？

ならなんでみんな使ってるのさ？
Microsoft、Red Hat、IBM等がGoogleのDockerコンテナ管理ツール、Kubernetesサポートで団結
http://jp.techcrunch.com/2014/07/11/20140710google-microsoft-ibm-and-others-collaborate-to-make-managing-docker-containers-easier/

ちなみに俺は前があと9994回聞かないと答えないぜ？

>>69
多分こいつは、複数台のサーバーを連携して
システムを作るってことをやったことがないのだと思う。
一台で完結するものだけ。

普通は一台でやろうと思ってもスペックが足りないので
あらゆる単位でわけるよね。

その典型的な例が、データベースサーバーだったり
S3だったりするわけ。

まあ、君には言わなくてもわかってると思うがｗ

>>69
ストレージ周りを簡単に連携してくれるか、
データ専用コンテナを簡単に移行したり管理できるツールがあればと思ってる

それと蛇足だが、DBも集中管理で動的にネットワーク設定を変える場合、
再構成かenvで起動毎に埋め込む(今これ)か、
外のカスタマイズしたツールが必要なのも難がある、

管理ツールが整えば解決しそうだけど未実装が多く辛い
まあdocker自身もまだ成熟しきってない状況で、欲を言ったのが悪かったかもね

>>72
はいはいまたレッテル貼りですか？

>>71
あのこれデータ管理の用途でなら
HNで出てたバックアップツールのがまだ使えるんだが…

お前本当に適当にウェブで拾える記事貼ってるだけだな

おまえらもっとちゃんと議論しろ

おもんねーぞ

Docker で、dev, staging, production やらの環境作る場合、それらの設定ファイルってどうすんのがふつう？
それぞれ静的ファイル用意して ADD でコピーするんかね

環境変数指定して切り分けてる

>>77
ほうほうありがと。つことは別々のイメージを作るのか。そりゃそうか

>>78
違う。

全環境用の設定ファイルをADDする
docker run 時に -e オプションで環境変数渡して、設定を切り替える
docker run -e production /path/to/run みたいに
run スクリプトには環境変数毎の挙動を書いとく

ってやってる

>>79
おー、そういうことか！ありがとう
全部放り込むんか。元々Chefユーザーなもんで、templateみたいなのどうするんだろ？って考えてたわ

>>80
めんどくさいからスクリプトファイル内で一括で切り替えれるようにしてる
ほんとは一つ一つの設定を環境変数で指定できるように外出するのがお行儀良いかと

例えば各サービスの listen port とか外部ディレクトリのマウントポイントとか。

>>81
その環境変数をもって、設定ファイル生成→サービス起動の流れか
だいぶイメージつかめてきた

>>82
いえす

dockerでデータ永続化する時はどうするのがベターなの？

自分はnfs鯖作って、docker動かすマシンにマウントさせて-vしてるけどこれじゃない感がすごいw

やっぱりサーバー用途にdockerって微妙だよなあ
いまいち使い方がわからない

>>85
バックアップとるの楽じゃない？
小規模なシステムのサーバーとかには向いてると思うけど。。。

開発環境と使い捨てりゃな継続的テストにはうってつけだろ

使い捨て開発環境ぐらいに留めたほうが良い
OpenVZが要件になった途端、全く使いまわせない事に気づき絶望
悪いことは言わんからChefにしとけ

シェフまじつかいずれー

そう？Chef12でDocker対応したらしいな

最近の sshd いれてセットアップとかやろうとする流れと
そうじゃねーだろって流れが面白い

前者は chef とかやってる人なのかな〜。
後者は chef とかでなんかこれじゃない感がある人なのかなと思ってる。

俺は後者。
sshd とかいれて chef とか頑張ってサービスの起動で
init や systemd ではまって docker ディスってるのとか
全部入りイメージで docker 使いましょうとかの記事とか
みてると docker ってそういうもんじゃないだろうって思っちゃう。

俺ん中では docker は daemontools とかに近い。
設定やアプリをある意味スタティックビルドして配布できる daemontools

異論は認める。まだ変わるだろうしみんな頑張れ

>>91
fabric がいいじゃん。

どうやって儲けるんや

DockerがシリーズCで$40Mを調達、実際に使うのは来年再来年という絶好調の余裕
ttp://jp.techcrunch.com/2014/09/17/20140916dockers-so-hot-it-just-got-40m-it-wont-start-spending-until-next-year/

>>93
redhat google にライセンシーしてるじゃん

>>84
上でデータ専用コンテナで文句言ってたやつだけど、
自分は結局、自力でmapper割当する方式でおさまった
今は良さそうなプロジェクトがある
https://github.com/ClusterHQ/flocker
使えるかはわからないので人柱よろｗ

>>91
その手の話はissueとして挙がった時に、メンテナや開発陣が勝手に決めればいい
ユーザー側で変な風潮作って先入観持つのは駄目だよ

使う側からすれば、目的を達成できれば十分だし、
変なドグマを強要されても気分悪いだけだからさ

ちょっと使ってみたけど
自分的には、vagrantでvirtualboxの代わりにdockerを使うぐらいしか使い道がない
という結論に達した

Windowsインストールできる？

>>97
やったことないからわからんが、OS XでもVirtualBox挟むからいけるんやない？boot2dockerみたいなのがあるのかはしらんけど

本番でどう使うかイマイチわかってないけど、環境を人に配るのが軽いってのはいいな

生Dockerfile, Packer + Chef / Puppet, Chef Container, なんかウェブベースのツールと色々あるけど、どれでやってる？
ひとまず Dockerfile で初めてみたけど、Chef の資産があるなら Chef Container かなと思ってるけどまだ試してない

生Dockerfile or packer

これから始める「DockerでかんたんLAMP環境 for CentOS」
http://knowledge.sakura.ad.jp/tech/1811/

なんかいろいろ作って結果、公式のでいいやってなる罠

CoreOS離反か

離反って何があったんです

coreOS が独自のコンテナ(Dockerみたいなの)を作りはじめた
ttps://github.com/coreos/rocket

そりゃまあ自分で作ったほうが融通が利くわな

欠陥品とまで言ってるぜw

なんとまあ
まあ切磋琢磨は歓迎ですが
ただでさえDockerのバージョンアップに冷や冷やしてるのに、あんま枝分かれされるとおいらみたいなドサンピンにはノウハウ纏めきれなくて困る

CoreOS のブログ
ttps://coreos.com/blog/rocket/

途中までしか読んでないが、Docker が太りすぎて最初に思ってたシンプルなのじゃなくなってきて、
Docker container じゃなくて Docker Platform になってしまい…
それが、CoreOS の Unix 的思想と合わなくなってしまった。とかそういうことっぽい

これからコンテナ型が色々出てくんのか？？？

nsenter だめだめじゃん
arch で pacman がつかえねぇ

vagrant pushが予想してる動きになるならDockerやめたい

やりすぎ感あるよね

Data volume containerを実際に運用してみた人いる？

>>114
しらんかった。いろんなイメージの使用例もホストのマウントばかり例示してたからなぁ と言って、それで作っちまった環境を今更変える気もないわけだが

chrootでいいよもう

>>111
今ならdocker exec でよくない?

>>114
使ってるけど、

・VOLUME指定したディレクトリ配下はデータボリュームコンテナ本体とは別のボリュームになる

・docker commit等ではデータボリュームコンテナ本体部しかimageには含まれない

・ゆえに、docker commit→docker saveとやってもデータは保存されないし取り出せるわけでもない

・結局のところ、VOLUME指定は、ホストの/var/lib/docker/vfs/dir/配下に置かれてるボリュームを
VOLUMEコマンドで指定した名前で、データボリュームコンテナ本体とそれを--volumes-fromで参照するコンテナから
　参照できるようになる仕組みでしかない

というのがわかってないと、ハマると思う。

上で、>>31 が「データ専用のコンテナを都度コミットしないといけない」って書いちゃってるけど、
・コンテナ外にデータがあるんでコミットは不要
・コミットしたところでデータはデータコンテナから作ったイメージ上にはないので無意味
なんだよね。

なので、データボリュームコンテナを使って、溜まったデータをどうにかしたい場合は、
・データ吸出し用の使い捨てコンテナから--volumes-fromでデータボリュームコンテナを参照して吸い出す
・データボリュームコンテナ自体にデータ吸出し機能を仕込んでおく
(データボリュームコンテナを起動させたままで使ってるなら
　docker exec -it コンテナ名 tar cf - 吸い出し対象 >ホスト側吸い出しファイル名
でいいかもしれない。まあ、普通、データボリュームコンテナを起動させたままにしないだろうけど)
・データボリュームコンテナを参照して起動しているアプリケーションコンテナ上で直接どうにかする
のどれかになると思う。

色々書いたけど、データボリュームコンテナは、
「データを別コンテナにパッケージングする」ものじゃなくて「インフラ部からデータを排除する」テクニックと
考えたほうがいいと思う。

ホスト側の/var/lib/docker/vfs/dir/配下に置かれてるボリュームを
「データボリュームコンテナ名-VOLUME宣言時のパス」で名前付けした形で
扱えるのがキモで、
データボリュームコンテナは名前を貸してるだけで
コンテナ自体でデータを抱えてる訳ではないから。

>>117
はいれた
が、archとdockerの相性が悪いのかpacmanがシグネチャがどーのこーの言われてまともに動かない
docker コンテナの中だと vi もまともに動かないし(C-p,C-n,の動きなどが怪しい 他にも多々ある)、まだまだ不具合だらけだな

>>121
多分、
ttps://registry.hub.docker.com/u/base/archlinux/
のイメージ(か、同一方式で構築したもの)を
使ってると思うんだけど、そこのページのコメント部分で色々指摘されてる通り、
イメージ自体がまだ微妙な代物っぽいね。

>>121
ちょっと興味があったんで、手元のWindows上のboot2docker環境で、
docker run -i -t base/archlinux /bin/bash
ってやって
# packman -Syu
# packman -S vi
# vi /etc/fstab
みたいな感じでやってみたけど、とりあえず問題なさそうだったよ。

ああ、キーボードの設定か何かのせいでカーソルキーが効かなかったんで
カーソル移動は昔ながらのhjklでやる羽目になったけど。

>>122
納得できた
色々とありがとう

docker exec すると 色々と挙動がおかしいの俺だけ？
複数行あるファイルをviで編集しようとすると1行表示しかされなかったりする
nsenterでは問題がないのだが・・・

いくら考えても理由がわからんから教えて。

なんでDockerの中に建てたサーバー（例 ウェブサーバー）に
接続するのに、ポートフォーワーディングするわけ？
ルーティングすればいいじゃん。

参考 docker の VM に向けてルーティング追加すればポートフォワード要らないってのにようやく気がついたメモ
http://qiita.com/woremacx/items/e5542bfa8e96c70346aa

ルーティングの設定すれば、ポートフォーワーディングしなくても
普通にDockerコンテナのIPアドレスに接続できるじゃん？

コンテナ2つ起動して、その両方でウェブサーバーが起動している時でも
普通にそれぞれにIPアドレスに接続するだけでいいじゃん？
いちいちポートしていしなくても。

ルーティングのほうが簡単でわかりやすいのに
なんでポートフォーワーディングするやり方ばっかり書いているわけ？

細かい経緯は知らんが、 --net=host 機能追加するときに
デフォルトはサンドボックスにしてると言ってる

https://blog.docker.com/2014/05/docker-0-11-release-candidate-for-1-0/

あとはドッカートホストのやり取りがカーネルから出ていかないから効率的とかなんとかが、この辺に書いてたな。さらにiptableいじるネタばかりかいてるので、変えたい人は勝手にどうぞとってスタンスと思われる

https://docs.docker.com/articles/networking/

すべての疑問が解決はしてないとは思うがどうだろうか

>>126
コンテナとVMを混同してると納得しにくいかも

>>127
ファイアウォールと同じでデフォルト閉じてるあつかいなんですかね？

>>128
その説明じゃ納得出来ないな。

もともとコンテナはOpenVZによるVPS等で
昔から使われているわけで。

>>126

boot2docker などの docker on vm on host 前提でホストが1台だけの場合の話でいいのかな？
# 何を前提にするかによって何がわかりやすくて何が正しいかが変わると思う。

boot2docker の場合、172.17.0.0/16 のルーティングを向けると楽だというのはわかる。
ただ、その場合例えば会社の 172.17.0.0/16 などに繋がらなくなるよね。
しかも、VM内だけでなくホストの設定も変更しないとダメだし。
万人向けの設定方法で、わかってない人に予想外の影響が出るような説明は
避けるべきだと思う。

ネットワークがわかってる人なら実際どうにかできるしね。

で、もし docker 全般（docker on Linux host 含む）という話なら
docker を複数ホストで使う場合を想定したらルーティングはありえない。
その場合は、--net=host でホストのNWを見せるかデフォルトのポートフォワーディングになる。
# docker daemon 起動時に IP分けるなどならありだけど、各ホストの設定が大変

どちらにしても、わかってる人は正直どうでもよくって
わかってない人に無難に使ってもらえる設定がポートフォワーディングだから
その紹介が多いだけ。

まぁ、私の予想です。

ただ、VMwareなどは知らないけど、VirtualBox の初期設定が NAT であることなどからも
デフォルト設定や万人向けの解説などは安全側に倒して置くのが普通じゃないですかね。