Docker

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

http://www.docker.io/

>>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 作ったんじゃないっけ？

>>151
Dockerも反論してるよ。

両方読んで思ったのが、どっちもこの業界で
勝利者になりたいって考えてるんだろうなってこと。

CoreOSが主張している「Dockerが肥大化している」は正しくないと思う。
ただしDockerがオーケストレーションとか周辺技術にまで手を出しているから、
CoreOSが本当に懸念しているのは周辺技術の方だろう。CoreOSもその分野だし。

Dockerがコンテナから始まって周辺技術に手を出しているのと反対に
CoreOSは周辺技術から始まってコンテナに手を出している。
スタート地点が逆なだけで、両者がやろうとしていることは同じだと思うよ。

評価するのは正式版になってからだろうね。初期の段階がシンプルなのは当たり前なので
十分な機能を持った時にシンプルさを保てているかどうかが重要。

CRATE使ってみたいDOCKERて何状態

docker stopが固まる事がある。
CTRL Cで止めると、docker killばできず、docker rm -fもできない状態となるが、docker psで実行中の状態のまま。
dockerデーモンを止めて、コンテナのディレクターを手で削除して、dockerデーモンを止めると回復する。
dockerデーモンを止めずに、回復する方法はないだろうか？

>>154
Boot2Docker使ってるでしょ？

それBoot2Dockerのバグだから。
TinyCoreLinuxの問題かもだけど。

普通に仮想マシンにUbuntuとか入れてやれば安定するよ。
止まらないことなんて一回も起きてない。

そもそもDockerしか入ってなくて、まともにCLI使えない
貧弱なBoot2Dockerは使いづらいだけ。さっさと捨てた方がいい。

>>155
仮想OSでなく、
xeonの物理サーバーにCentOS6.6を入れてdocker-ioの1.4.1-3.el6で使ってます。
終了処理が10秒以上かかる
いろいろ調べた所、docker1.4のバグらしく、1.5だと直っているらしい。
1.5はまだ公式のepelリポジトリに入っていないので待ってみます。

1.6がでたのに、公式とか言ってるのは可愛そうだなｗ

まあLinuxディストリシステムの欠点とも言えるが、
そんなのに頼らないで、本当に欲しいものは
公式サイトからインストールした方がいい。

1.5と何が変わったのかというか、ブログっぽく書いてたページってトップから行けなかったっけ？
久しぶりだからよくわからなくなった

>>158
blogで検索しろ

>>159
すまんな完全に耄碌してた

結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ
あと、リソースのリミットやcgroupはより実利用に向けてだね。あとは、レジストリのメモリサイズ減っててほしいな減ってたら使いたい
何よりもラベル助かる。というか必須にしようや

と、食いつきにくい餌をばらまく

>>157
公式から実行ファイル落としてきて差し替えるだけでアップデートできるしねえ

> 結局、windowsで動かすdockerはvmwareでcolinuxじゃないということかなぁ

誰か解読してくれ

スマン。俺では読解不能。

>>161
Windowsを使うなっていうことだよ。　

>>164
それをいうのならMacOSXもじゃね？
Docker動かんし。

>>162
colinuxは仮想マシンじゃないってことじゃないの？

ああ、「Winだと仮想経由になっちゃってコンテナとは言い難いな」ってことか？
それ踏まえて読み直すとやっと腑に落ちた

しかし読解レベルで食いつきにくいのは勘弁してもらいたいなw

とはいえコンテナが増えてくるとVMでモジュール化しないと管理しきれなくなる

モジュール化するのはいいが、
なんでVMでなんだ？
もっと軽いものでモジュール化しろよ

その軽いものでホスト環境ごと分離できるなら

>>170
Docker in Docker

>>170
それがコンテナ（プロセス）のグループ化って考え方なんだろうけどね。

ようするのpsコマンドの表示の仕方が悪いって話でしょ？
psした時に、特定のグループは一つにまとまって見れて
そのグループ単位で起動とか停止できればいいんでしょ？

複数のコンテナをまとめて管理するなら、docker-composeが使えるし
イメージやコンテナにラベルが付けられるようになったから
自分でコマンド作ればいい。

最終的にはsystemdと連携してプロセスグループとして管理される。
これが現在進行中の流れだよ。

今すぐ使いたかったら、
GoogleのKubernetes等のコンテナ管理ツールを使えば良い

>>171-172
実行状態もだけどコンテナ間通信のためのポート構成のカプセル化が目的
今度試してみる

DebianでDockerを使いたい

>>173
コンテナ間の通信であればポートを気にすることはない。
普通にコンテナ間でIPアドレス指定してアクセスできる。

ポートを気にするのはコンテナの外から
アクセスする部分だけ。

どっかの馬鹿がDockerに関しての話題をここじゃなくて、
こっちでやれって言ったからこっちに書いてるよ。

興味があったらどうぞ

プログラムに詳しくなりたい
http://peace.2ch.net/test/read.cgi/tech/1346595505/

ドッカーポエムが繰り広げられていますね。

DockerでCentOS7使おう思ったら
systemctlが無いやら(7.0)、B-Busがなんやら（7.1）出てしまうので
先人の教えを請うて次の魔法の言葉を打ったらsystemctl使えたけど
docker run --rm -v /usr/local/bin:/target jpetazzo/nsenter
docker run -p 80:80 centos:centos7 /sbin/init
sudo nsenter -t $(sudo docker inspect --format '{{.State.Pid}}' centos) -m -u -i -n -p /bin/sh
なんですの？これ

どこが魔法なんだ？。/sbin/initか？。

>>179
たぶんnsenterがゲストのCentOS7でsystemctl使えるようにする魔法の言葉だと思うんだけど
なにしてるの、これ？
（ちなみに-p 80:80はいらなかったのかも知れないがとりあえず入れただけ）

普通に、CentOSを起動した時に動くデーモンを全部起動してるだけ。
必要なものだけに厳選するなら、supervisordとか他の手段を使ったほうが良いと思う。

これを会社のシステムに使おうとしてる俺の会社って狂ってるよね
社内にLinuxに精通した奴なんておらんし