Docker

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

http://www.docker.io/

>>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 であることなどからも
デフォルト設定や万人向けの解説などは安全側に倒して置くのが普通じゃないですかね。

>>130
なるほど。わかってきたよ。ようするに使い方の違いの問題だ。
俺が今Dockerを使ってやろうとしているのは主に開発の効率化で

各個人専用の独立した開発環境を作りたいから
> ただ、その場合例えば会社の 172.17.0.0/16 などに繋がらなくなるよね。
これとは逆に外が見えたり、外から見えない方が好ましい。

閉じた環境のネットワークの中に軽量なサーバーを複数台、
例えば構成が少し違ったり、アプリのバージョンが違うものを
立てて実験したりしたい時に、いちいちポートフォワーディングの設定を〜
とかをするのが面倒なんだ。

だがDocker社も含めてDockerを使っている人達の多くはインフラ系で開発系ではないのだろう。
（この二つで担当者を分けるのはナンセンスだと俺は思っているが）
だからそういう情報が少ないんだろうな。

Dockerを使って実運用のサーバーを作る時にルーティングがありえないっていうのはわかるよ。
その場合はpipework等を使って任意のIPアドレスを割り振るって話だ。

ただ（開発用に）ルーティングを使った使い方の話が少ない理由がよくわからなかったんだ。

Dockerを使ってる人の多くはプログラマーな場合が多い。
なのでルーティングの知識は無い。
ポートフォワードならローカルからサーバーのMySQLにつなぐとか要件があってそこそこの知識がある。

>>132
１行目と2行目がどう関連してるのかよくわからないな。
今時ならなおのことネットワークに疎いプログラマなんぞ
いないだろうに。

>>132がプログラムに疎いインフラ屋なのだろう。

インフラ屋っていうのは取りあえず動くコードさえ
かければいいので、アプリを作れるレベルにない事が多いからさ。

なんでも屋と分業しているチームの違いじゃね

>>132 は分業しか知らない上に、
ルーティングひとつまともに知らない人ばかりの場所で働いてると
まれによくある話だ

そんな奴らが回収率の高いビジネスに持ってけるわけないので、放っておけば良い

DockerってDockefileに書いた順番に
イメージをコミットしていくだろう？

その時、Dockerfileの上のほうを修正すると
その下のコマンドを全部再実行することになる。

その時間を節約するには、Dockerfileは常に追記していくことになる。
でもそうするとDockerfileが見づらくなる。
だからといって並び替えると、コマンドを再実行することになって時間がかかる。

このジレンマどうにかならないもんかね。

Dockerって最後にCMDとかでapacheをフォアグラウンドで起動したりするけどさ、
あれって普通に起動してスリープで止めたほうが楽だよな？
Docker自体にそういう機能があってもいいと思うけど。

CMD service apache2 start && sleep 36500d

これならapache起動前の環境変数の設定とかやらなくて済む
欠点としては標準出力の内容を見れないところだけど、
普通はログファイルに出力できるからsleepの代わりにtailを使えばいいし。

CMD service apache2 start && tail -f /var/log/apache2/error.log

CoreOSとかinit.dを使った起動方法が存在しないなら直接起動するしか無いけど、
普通のディストリ使ってるなら普通に起動したほうが楽だと思う。

Redhat Enterprise Linux 6.6でDockerを動作させようとしたのですが、
dockerサービスを起動すると、ログに
kernelを3.8.0にアップグレードしろと出て動作しません。
kernel2.6のままで、
Dockerを動作させる方法はないでしょうか？

RH純正のrpmなら、動作するのでは？

動かないなら、RHEL v7.1で試した方がいいかと。

#6系よりもkernelのバージョンは上だし、Dockerの正式サポートがされているし > v7.1

>>139
RHEL7系はアーキテクチャが大きく変わって枯れていないので、
運用管理者が嫌がっているのです。
昨年12月位にCentOS6.6でDockerを試した時は動いたので、
RHEL6.6でも大丈夫かと思ったのですが。
今はCentOS6.6でもDockerは動作しないようです。
GitLabやDockerHub,Mavenリポジトリ,Jenkins,Sourceスタティックチェックサービス
など最新の開発サービスを、コンテナで分けて管理しようと思ったのですが
まだ共通に使われるサービスに、Dockerを利用するのは時期尚早みたいですね。

Atomic Host もリリースされたし、硬くdockerを運用したいなら、RHELはいいディストリビューションだと思いますけどね〜

枯れてないことを言い訳にしても、新しい仕組みであるdockerを活用できるとは思えない…

今作ったCentOS6.6で普通に動くが

>>142
EPELのdocker-io？それとも、別のパッケージ？

>>143
EPELの

>>118-120

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

見事にハマったよ。そのレス読んでたけど具体的に触るまで
聞いてても頭にはいらないもんだな。

そもそも、ボリュームを確認するためのdocker volumesコマンドがまだ未実装なんだな？
ボリューム”コンテナ" と言ってるし、コマンドないし、これハマって当然だろ。
https://github.com/docker/docker/pull/8484

未実装のdocker volumesの代わりに、docker-volumesというのがある。
https://github.com/cpuguy83/docker-volumes

これ使ったら、どのコンテナがどういうふうに参照しているかわかったよ。
docker-composeと組み合わせたときの挙動とか。

試してないけど、そこに書いてあるボリュームのデータの吸い出しは
docker-volumes exportでできるんじゃないかな？

もう少しまともに使えるようになってから使えばいいのだ
慌てるなんちゃらは稼ぎが悪い

そんなこと言ってたら手遅れになるよｗ

あれよあれよという間に Docket が肥大してしまったので、
もっと軽量でコンパクトなコンテナ実装が出るのを期待してる。

Dockerの周辺技術が増えただけで
別にDocker自体は肥大化してないと思うけどね。

どうせどんな技術も
肥大化 → 機能を限定した軽いもの登場 → それもバージョンアップで肥大化
の流れになってるしｗ

結局、軽いものっていうのは、当初は機能が少ないから軽いだけで
どちらにしろ肥大化の道をたどる。

まあRocketでも使えば？

Docker がシンプルじゃなくなってるから coreOS が Rocket 作ったんじゃないっけ？