Docker

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

http://www.docker.io/

おまんこ

>>2
はるな愛と椿姫彩菜と佐藤かよと誰のが舐めたい？

くじらかわいい

ほう

インストールしたお

LXC単品ではなくDockerを使うメリットってなによ

Docker Indexを利用したコンテナイメージの共有とかはいいかな

ソースコードをguthubで管理するのと、同じイメージで利用できるし

>>7
* Dockerfile
* aufs
* Docker Index
* NW(bridge, iptables etc)

NW はかってに色々されるのが気持ち悪いけど、
基本的にだれでも強制的に同じような構成になるので
ミドルウェアの設定を説明したり、他人に自分と同じテスト環境を
用意するのがすごく楽。

要は、やりたいことがコンテナ操作じゃなくて、その上に
のってるアプリケーションで何かをすること という場合に
（インフラエンジニアではない大半の人）インフラ部分を
かってに用意してくれる。

カスタムイメージつくりにハマり中

apt-get update すると一気にファイル要領が増えるなあ
ちょっと考え中

素に近いイメージ作った後、Dockerfileでいじったほうがいいかも

RHEL も Ubuntu も Docker がらみで、界隈で話題になっているというのに
この板では扱いが地味だな

Dockerのための軽量OS「Red Hat Enterprise Linux Atomic Host」、Red Hatが発表 − Publickey
http://www.publickey1.jp/blog/14/dockerosred_hat_enterprise_linux_atomic_hostred_hat.html

Red HatがEnterprise LinuxとPaaSプラットホームOpenShiftでDockerをサポートへ | TechCrunch Japan
http://jp.techcrunch.com/2014/04/16/20140415red-hat-to-bring-docker-support-to-enterprise-linux-and-openshift/

Ubuntu 14.04 LTS Debuts With OpenStack Icehouse and Docker Support | Linux.com
http://www.linux.com/news/software/applications/770342--ubuntu-1404-lts-debuts-with-openstack-icehouse-and-docker-support

>>11
coreos の方が軽い

まぁ、redhatだとサポートは長く続きそうという期待はあるけどな。

Dockerをダウンロードする場所を教えてくれ。

くれぐれも言っておく、
曖昧な答えは希望してないぞ。

正しい場所を教えてくれ。

Docker使ってマシンを使い捨てにするのはいいんだけど、
マシン再起動したらデータ消えましたじゃ話にならないし、
データはどこかに保存しなきゃいけないだろ？
どうすんの？

「AWS Elastic Beanstalk」でDockerコンテナの作成、管理が可能に
http://www.atmarkit.co.jp/ait/articles/1404/24/news130.html

>>15
コンテナ内ファイルはホストで取り出せる
あるいはコンテナ外のDBとか
サーバーにアクセスすればいい

core@localhost / $ docker run centos /bin/echo "Hello World"
Unable to find image 'centos' locally
Pulling repository centos
0b443ba03958: Downloading [==========> ] 19.55 MB/91.18 MB 32m21s
539c0211cd76: Downloading [==========> ] 20.61 MB/98.56 MB 33m24s
511136ea3c5a: Download complete
7064731afe90: Download complete

このまま帰ってこないんだけど、何か忘れてる?

Docker行っちゃったんかなあ。ww

>>19
くっそwww こんなんで

1.0リリース記念

GAEで動くのは良さそうだけどインスタンス扱いどうなるんだろ

どういう意味？

>>12
centosのイメージはシェルが腐ってる

>>24
特に困ったことないけども

apt-cache で、dock アプリを探していて、Docker に
であったわけだが、ぐぐってみても、コンテナが何それで
ちんぷんかんぷん。潔く諦めたでござる

入れてみたけどあまり使ってない

CentOSのイメージで

Changing password for user root.
New password:
/usr/share/cracklib/pw_dict.pwd: No such file or directory
PWOpen: No such file or directory

こんなエラー出るんだけど俺だけ？

ubuntuでやってみれ

>>28
公式のはrpm上インストール済みでも、ファイルが消されまくってるのが原因ぽい。
その現象だけなら、cracklib再インストールで治るはず
いろいろやりたい場合は、自分でcentOSイメージを作った方が良さそうだね

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