Docker

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

http://www.docker.io/

>>854
いやいや生成されたバイナリ一つで済むからワンバイナリ言ってるわけだし。
windows環境ならlinux用にバイナリ出力すればいいだけ
最近はワンバイナリですまないかもしれないけどね。

そもそもワンバイナリならdockerも要らないけどな

buildさげ

久しぶりに来たら squash の話してるけどすでに実装されてるぞ。
ただし、Experimental。

仕組みとしては、通常のbuildをしてできたイメージを1layerにする処理がまた走る。
内部的にはイメージが2つできる感じ。
手元のディスク容量的には損だけど、squash 前の繰り返しする場合に
レイヤーが再利用されるのでそういう面で便利。

使い方は、docker daemon を experimental オプションつけて起動して、
docker build --squash -t foo .

次の 17.03 か 17.04 あたり（バージョニングルールが変わった）で experimental 外れるんじゃないかな

golang を docker で build する意味に関してはいくつかある。

vendoring tool （依存パッケージのバージョン含めた管理）の代わりにセットアップされたイメージを用意するという方法。
最近は golang から dep という公式ツールが出て今後の方針が見えてきたとはいえ
テストなどを考えると vendoring の処理自体を毎回するとか面倒なのでコンテナ使うのは悪くないと思う。

ほかは cgo の問題（golang の中で c をインラインで書ける機能）。
golang の net/http はそのままで名前解決の部分が libc に依存しているので build 環境に左右される。
これは debian などで glibc 環境で build したイメージが glibc へダイナミックにリンクされてしまい
Alpine の musl libc で起動できないという現象（または逆）がある。
net/http の場合は CGO_ENABLED=0 や -a オプションなどで golang での実装へ回避できるが、
mattn/go-sqlite3 など中身は C のライブラリへのリンクしか無いと言うものが結構ある。
mattn/go-sqlite3 場合だと動作環境に sqlite のライブラリを入れるか
ldflags などを工夫して static バイナリをなんとか作るかという面倒なことをする必要がある。
docker イメージならライブラリ突っ込んで置けばいいので楽。

あとは、コマンドの統一。
いろいろなコマンドを docker run hoge 的に統一できるということ。
docker hub に登録しておけばどの環境でもこのコマンドで取得して実行できる。
golang の場合は容量的に空のイメージである scratch イメージを base にバイナリ放り込むという感じかな。
これを頑張ってる例としては whalebrew。

なんでそこまでしてGoなんて糞言語使わなきゃいけないんだ
デプロイがシンプルであることだけが存在価値の言語なのに

>>860
お金のにおいがするからじゃないの？
なんか出してもいない広告で100億円儲けてる業界みたいだし。

普通に仮想マシンの中にLinuxとか色々ソフトを入れてサーバー立てるんじゃなくて
Dockerを使うと良いことあるの？

>>862
バイナリファイルを一個コピーするだけで
アプリが使えたら楽だろ？

wget 取ってて/usr/local/bin あたりに入れて
chmod +x するだけで使える。


アプリを動かすまでにApacheを設定してPHPをインストールして
WordPressをインストールして動かすの大変だろ？

Docker使えば、docker run するだけで使える

今時そんなのはPaaSでワンクリックだけどね
Dockerはむしろ、アプリ個別に好き勝手に環境をガンガン作り込んでも
インフラや運用体制が破綻しないのがメリット

>>858
>>859
サンクス。squash期待だわ

まさにcgoもあってnvidia-dockerでgo使ってる。
何故goとか言われると辛いが便利なので使ってるわけで、
使うとなるとdockerに閉じ込めれたほうが便利なんだし、
いいじゃん俺が何使おうが、みたいな感じだよね

>>862
VMより軽い。そんだけ。
VMで使えてるならVMでいいんじやん？

VM1個しか要らないならメリットなし？

ただの仮想マシンは移したりするときに
イメージ全部運ぶの大変そうなのは分かる

>>867
説明が面倒なんで説明してないだけ。
俺だったらdocker使えるなら全部docker使って、
どうやっても無理なとこだけVM使うとかするけど、
君、docker使いたくないんでしょ？ならVMでいいよ。
説明がメンドイ

>>867
君開発の人じゃないでしょ？

>>867
それはちょっと違う
Dockerを使うなら、これまでVM1個に色々入れてたものは複数のコンテナに分けて構成することになる
構成要素のそれぞれを独立して動作する一つのパッケージとして扱えるので個別の変更が比較的容易になる
変更せずに決まった形で運用するだけなら全くメリットはない、というか
全体的に見れば環境は当然1VMに比べて極めて複雑になるのでデメリットしかない

>>867
Docker使い()はね、Docker使うことが目的なんだ。

>>862
環境を壊さないところかな。
OS１個でも色々な環境をつくれる。
お互い排他にできるからRootで作業しても安心。

質問します
Exposeではない方法でdocker の外側からコンテナにアクセスする方法がわからないので教えていただきたいです
Bridge を用いるのはわかるのですが，いまいちよくわからないので

ttp://christina04.hatenablog.com/entry/2016/07/22/193000
これでどうだろうか。

>>874
その方法、

Mac でdocker0がなくなっちゃってるのよねー
https://github.com/docker/docker/issues/22753

他にも
https://docs.docker.com/docker-for-mac/networking/

Known Limitations, Use Cases, and Workarounds
There is no docker0 bridge on macOS
I cannot ping my containers
Per-container IP addressing is not possible
Use cases and workarounds
I want to connect from a container to a service on the host
I want to connect to a container from the Mac

RPi3 HypriotOS なので Mac の件は大丈夫です.ありがとうございます.
ですが，>>874 のブログだと結局外部からアクセスするには expose するしかないのでしょうか

そもそもアクセスって何がしたいのさ

Win10 homeでも動くようになるってのはどうなったんだっていう

WindowsコンテナにしてもDocker for Windows にしても Win10 Home で動くという話は聞いたことはないな
まぁ、対応するとしたら Microsoft なんだけど hyper-V を home 持ってくることは無いんじゃないかな

用途は研究です
コンテナ内のアプリケーションと外部のアプリケーションで通信を行いたいのです
ホストosのiptables をいじって転送するように設定したら可能でしょうか
コンテナから外には繋がるので

Dockerの期待と現実〜Docker都市伝説はなぜ生まれるのか〜
https://www.slideshare.net/zembutsu/docker-expectations-and-reality

Docker導入のための、コンテナの利点を解説した説得資料 - Qiita
http://qiita.com/niisan-tokyo/items/88a53a1b4aa7ad60723e

>>881
研究とはDockerでいろいろ変なことをやってみる研究ですか？
それともDockerを実務で使うための研究ですか？

アタックして中身の情報を盗み出す研究じゃね？

>>884 docker は単にデーモンを分けて動かしてメンテナンス性を上げるためです

Docker v17.03がリリース。今月からバージョン番号制度が変更になり、毎月リリース体制に − Publickey
http://www.publickey1.jp/blog/17/docker_v1703.html

>>887
毎月リリースはいいんだけど、安定板は平行して出てこないのかな。

>>882
面白かった
>>883
うんこだった

Windowsで
VirtualBoxで試したらIOがめちゃめちゃ遅くてまともに動作しない
Hyper-Vではそんな事は無かった

ならスレチってわかるよな？

>>891
VMのLinuxで動かしてるからスレチではない。

>>892
で、Dockerの話題はいつ始まるの？

dockerってすごいよね！

docker、すっごーい！たのしー！
マジこれヽ(´ー｀)ノ

今のDockerはRHEL6/CentOS6をサポートしないと言ってるけど、実際のところはどうなの？

・サポートしないとは言っているが今のところ一通り動く
・一応動作するが一部問題がある
・動かない

動かそうと思えば動かせる。
でも、動いたCentOS6はもはやCentOS6ではない。

なるほど、ありがとう。
でもこれ↓意味わからん。

>でも、動いたCentOS6はもはやCentOS6ではない。

>>898
いじりすぎ、ってことだろ。

rhel7でもdocker動かそうとするとサブスク必要で
かつ彼等のecosystem使わないといけない風潮あるから
なんか嫌

イアンマードックを偲んでdebian使え。

>>900
当たり前だろ！

当たり、前田の〜♪

Docker for WindowsでWindowsのディレクトリをボリュームとして使うと正常に動作しないっぽい
WindowsのファイルシステムだとLinuxコンテナに必要な機能がないからか
ファイルやディレクトリの所有者はそのままになるからか

大量にディスクIOが発生してGitLabの動作が重たいから
sameersbn/docker-gitlabだけWindowsのディレクトリを使ったら正常に動作しなくなった
素直にLinuxマシンを用意しろってことか

windows10でアップデート後問題なく動いていたのにふと再起動かけたらShared Drivesで共有ドライブ認証出来なくなって困った
Apply押すと詳細な共有の設定も初期化されるしどういうことだ・・・

Linux板で何言ってるんだか

windows10で使っちゃダメだよ

そもそも、そこまでして頑なにWindows使う人の気持ちがわからない…

Windowsコンテナも同時に使いたいとか？

(´・ω・｀)別にdocker入れなくてもいいんだけど、
dockerを入れて複雑化して誰も触れない環境にするために使ってるようなもんかな

>>908
Windowsしか使えない人なんだからしょうがない。

職場環境とかだと割とOS限定されるし
どうしてもwindowsで実現しなくちゃ行けない場合もあるのかな？

ただ罵るだけとかlinux板も落ちたよなぁとオモタ

落ちたも何もUNIX板から追い出された隔離所だし

「Windows使ってる」が「Windowsしか使えない」に短絡するバカっていまだにいるんだなぁ。

WSL その81 - WSLでどのようなテストが行われているのか
https://kledgeb.blogspot.jp/2017/04/wsl-81-wsl.html

WindowsによるLinux互換レイヤー実装、
もうLinuxと8割ぐらい互換性があるようだな

DockerがWindows上でネイティブに動くという夢も
近いうちに実現するかもしれない。
そうなるとDocker動かすのに仮想マシンHyperVも必要なくなる

WSLはbetaが取れるまでは様子見

windowsでないと使えない人たちが何しにここ来てんの？ｗ

Dockerコンテナに特化した「RancherOS」正式版リリース。Linuxカーネル上でDockerを実行、システムもユーザーもすべてをコンテナ空間に − Publickey
http://www.publickey1.jp/blog/17/dockerrancheroslinuxdocker.html

マイクロソフト、Windows Serverのコンテナ機能でLinuxコンテナのサポートを発表。主要なLinux OSとLinuxKitに対応。DockerCon 2017
http://www.publickey1.jp/blog/17/windows_serverlinuxlinux_oslinuxkitdockercon_2017.html

WSL のようなものではなくて結局 Hyper-V 経由だけど「Hyper-V コンテナ」の実装として出してきたね。
すでに、Hyper-V コンテナで実装されている Windows コンテナと同様であると考えると、
Hyper-V でラップしてその中で kernel とプロセスが動く。

ただ、これをまとめて操作できるインターフェースが用意されるのかな。
docker run すれば hyper-v コンテナ経由で Linux の環境とコンテナが上る感じで engine は windows 側？
そうすれば、Docker for Windows みたいな専用VMを意識しなくて良くなる（この Linux が moby になるのかな）。
これがちゃんと実装されれば、windows 上では windows コンテナと Linux コンテナ混在で同じ操作性で扱うことができそう。
Hyper-V コンテナなら Windows10Pro でも動くのでその点も良い。

気になるのは Network と共有ファイルシステム。

Network は Hyper-V の設定で面倒なところだけど、Overlay に関しては windows/linux 混在できるようにわざわざしてくれてるので
使いやすく実装してくれることを期待。
https://blogs.technet.microsoft.com/virtualization/2017/04/18/ws2016-overlay-network-driver/

共有ファイルシステムは Docker for Mac でも性能や権限がよく問題になっているので
これがいい感じになるようならば、Windows で開発してもいいかなという人も増えるのでは。

意味の無いことだとは思うのですが
ドッカーッてsystemdな環境をinitな環境と切り替えて使えたり出来るもんなのでしょうか？

dockerは仮想環境のディストリビューションは何になるの？もしかしてホストOSと同じ？

>>921
ディストリはホストと別でもよい
ホストUbuntuでコンテナCentOSとかでもOK

docker用に最適化されたCoreOSってのもあるからそれでもいいのよ

>>920
何考えてんだ？レベル

coreOSは普通のディストロとはかなり使い勝手が違うから慣れてないのに使うのはオススメしないな
それとcoreOSはdockerじゃなくてrktだろ

セキュア重点の特化OSで使い勝手同じのってあるの

どうせならdockerkitにしようぜ

>>919
そこまでして、ホストでWindowsを使う必要がない。
窓は、窓でええやんと。

windowsユーザーが気軽にdockerを使えるようになるってことだろ
わざわざwindowsを使いに行くという話ではない
Linuxユーザーにとってはコンテナが増えることで利益を得られるんじゃないの

dockerってカーネルが同じものを共有する≒システムコールが同じじゃないとならない
と思っていた
Win上で動くって結局のところvmwareと中身が同じでいいのかな？

一方でwin自体がcuiにbashを可能にする動きがあるから、母艦がwinでもlinuxと同じコマンドでdockerが操作できて会社で泣く泣くwinを使わせるクソ製造業の皆様もdockerの恩恵を享受できると

>>930
WindowsもMacもLinuxカーネルではないので、
Docker用の仮想マシンを作成して、そこにLinuxをインストールして
コンテナを動かしています。

そのため、仮想マシンの設定（CPU数や搭載メモリ等）の影響を受けます。

ネイティブにDockerコンテナを動かしたいのであれば
Linuxカーネルの機能をOSが搭載する必要があります。

それをやっているのがBash on Ubuntu on Windowsで有名な、
Windows Subsystem for Linux (WSL) プロジェクトなのです。

>>931
一番の問題はファイルシステムじゃない？
その辺の問題は解決するんか

ファイルシステムはfuseみたいな物を使えばどうにでもなるんじゃねーの

だな。WindowsはISOファイルや読み書き可能なvhdファイルを
ディスクとしてマウントする機能がすでにある。

それ以前にBash for Ubuntu for Windowsだって書き込み先は実際にはNTFSのはずなのに、
lxfsとしてマウントされ、Linuxを動かすのに必要な情報が記録されている。

あとは、Linuxで動くアプリが正しく動作する事ができるlxfsというファイルシステムに
Dockerというアプリがデータを書き込むだけの話

Docker使ったら素人でも分散処理するWebサーバー立てられる？

無理

dockerゴミという話
http://anond.hatelabo.jp/20170422000230

Dockerの運用なんかクラウドプラットフォームに丸投げするもんでしょ
PaaSのための共通パッケージフォーマット、それ以上でも以下でもない

docker使って、開発の手間を惜しんで、
代わりに運用コストを上げてしまった
って話に見えるな。

実際、docker利用してるプロジェクトに、
後から参加するとそんな状態になってることが
多い気がする

>>935
こういう質問が来るって事は、Dockerがなんなのか分かってないんだろうな。

じゃあ何を使えばいいの？

>>941
そりゃREADME.mdでしょｗ

Dockerfileなんて、README.mdに書いて有ることを
自動的に実行できるようにしただけなんだから。

README.mdみてWordpressをインストールして
設定をvi使って書き換えてMySQLのセットアップしてって
やればDocker使わなくても同じことができる

そんなん面倒くさい

じゃシェルスクリプトでよくね

仕組みを理解して、readmeに書いてあることくらい読んで、
そんでdocker使うなり使わないなりすればいいのさ。
理解せずにdockerでやる！とか、拾ってきたイメージで
ガチガチャやって、動かないとか言いながら散々いじって、
車輪の再発明みたいなことして、他の人に理解できないような
ゴミを作って、動きました！とかやるから質が悪い

まあdockerに限らずなんでもそんな感じだけどね

>>937
たぶん、chrootとかlxcとかちゃんとやったことがないんだろうな。
おれだったら、systemd-nspawnのほうがイヤだｗ
（脱線：ちなみに、Docker、VMwareは好きだけど、vagrantも嫌いだし、JS系だったら、gruntも嫌いだ。grunt使うぐらいだったら、Rakefileでかまへん。）

Dockerなんか、chrootでtar、シェルスクリプトと同じだと言われればそうだけど、なんとなくDockerやろうぜとかだったら、結局めんどいってなるんだろうなーと。

意味のあるコンテナを作れていないだけな気がする。
なんとなくコンテナを拾ってガチャガチャだったら、あかんで。

VagrantもLinuxだとVMじゃなくてDockerコンテナが作れるらしいけど
なんかyml書くのが難しそう
Dockerfileの方が簡単に書ける

docker大好きっ子の俺だけど、
dockerfileだけは氏ねよと思うわ

>>946
RakefileはRubyな

本番運用してない部門だから、dockerfileは書かず公式に外から設定ファイルを突っ込む形だわ
本番の人たちはわざわざイメージ作ってるのかな？めんどくさそう

>>950
本番運用のシステムを作るとめんどくさいよ。
だからDockerをつかって、本番運用のシステムを
簡単に作れるようにするわけ

('・c_・` )ｿｯｶｰ

コンコンするのはノッカー

　質問なんですが、「立ち上げ直後に落ちてしまうコンテナから、原因となるファイルを削除する」手段は無いでしょうか？

事例：
　mongoのオフィシャルイメージから立ち上げたコンテナが、原因不明で立ち上げ後即落ちるようになった。
　特定のファイル( /tmp/mongodb-27017.sock )を削除すれば良い、という情報を得たので削除を行いたいが、
　普通に起動しても即座に落ちる(エントリポイントでmongodの立ち上げに失敗してシャットダウンしてる)ので、docker exec出来ない。

　最悪、コンテナ消してイメージから再作成すれば良いのですが、本来的にはどのように対処すべきでしょうか？