Docker

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

http://www.docker.io/

>>799
オイラはローカルディレクトリをコンテナのホームにマウントして一通りやってからbashのHistoryから必要なものを抜いて作るな
会社の串が特殊なので一度通してからじゃないと安心できない

>>796 だけどレスさんくす
わりと人それぞれなんだな
参考にさせてもらうわ

>>800
詳しくありがとう。nginxでのリバースプロキシはVMで作ったことがあるから先ずそっちを検討かな。挙げてくれたコンテナも調べてみるよ。

盆栽作りってすごくしっくりくるな
わろたｗｗｗ

>>796 >>802だけど複雑だったから結局>>796の方法でやってる
>>801の方法も良さげだなぁ
インストール時間が作業時間のボトルネックだね

会社でDockerのおすすめの本を聞かれたんだが、
なんか、Dockerって教科書的に学ぶより自分なりの使い方を編み出すほうがいいと思うんだが…どう答えりゃいいんだ

>>806
その人もどこから始めていいかわからないんじゃないの？
読んだ本でいいのがあれば自分の感想も含めて教えてやればいいし、読んでないならそう答えれば

> なんか、Dockerって教科書的に学ぶより自分なりの使い方を編み出すほうがいいと思うんだが…どう答えりゃいいんだ
バカか？

なんのために作られたのかを理解しなければ、
変な使い方をして使いにくいと愚痴る馬鹿ができあがるだけだろ

初心者ですまんが、dockerに固めたライブラリ類のアップデートってどう管理するの？
セキュリティ警告出てるバージョンが含まれてるかどうかscanする方法はある？

>>809
Docker Hub を使えるなら Docker Security Scanning
https://docs.docker.com/docker-cloud/builds/image-scan/
http://www.publickey1.jp/blog/16/docker_security_scanning.html

手元でチェックしたいなら vuls
https://github.com/future-architect/vuls/blob/master/README.ja.md
vuls やってみた系記事、作者が日本人なのでこれ以外にもいっぱい記事がある。
http://cross-black777.hatenablog.com/entry/2016/05/09/090000

両方ちゃんと使ったことはないので、pip や bundle、npm などでインストールされた
言語のライブラリのチェックをしてくれるかは知らない。

言語のライブラリ周りは VersionEye あたりが使えるのかな
https://www.versioneye.com/
https://www.infoq.com/jp/news/2016/09/versioneye

ぜひ試してレビューしてほしい

>>810
ありがとう
vuls試してみる

>>806
プログラマならDocker教科書
インフラ屋なら知らん オーライリー本でも買っておけば？

Dockerってなにがいいの？

現実として手間やリスクをペイするかはともかく、少なくとも転職活動のときのネタにはなる

>>813
VPCに比べていろいろ面倒くさくない

インフラを保守的に運用しつつ、スキルのあるアプリエンジニアに最大限の自由を与えることができる
特にオンプレだと顕著
もともとバリバリのクラウド開発でサーバーなんか使い捨てだよという感じなら起動が早いくらいしかメリットはない

アプリのデプロイの話をしてないやつは
エセインフラエンジニアだから
話半分に聞いていればいい

>>816
オンプレはほぼ同意見。
あとは、開発者の手元に似たような開発環境を用意しやすいぐらいかな。

クラウドに関しては、GKE や ECS がサービスとして存在していることを考えると
ある程度の柔軟性をもったパッケージングと配布（デプロイ）が準備され、
それが逆に一定のルールとなって縛っていることがメリットだと思う。
そのおかげでどのようにスケールするかなどがある程度決めれるから。

結局、オンプレもクラウドも一番大きいのはこのルールなのかなと思ってる。

ちなみにすごくどうでもいいことだが、docker が出た当初からインフラ屋の俺はこれを
アプリエンジニアとのプロトコルと呼んでいる。

macvlanでapacheを複数ホストする方法を教えてくれ。
dockerホストのVMにmacvlanでapacheコンテナを複数作成。
それぞれmacvlanで192.168.0.1, 192.168.1.2を割当。
dockerホストと別のVM(192.168.0.254)から192.168.0.1, 192.168.0.2へのpingが通らない。
192.168.0.1と192.168.0.2の間ではpingが通る。
誰か助けてー

■参考(公式ドキュメント)
https://docs.docker.com/engine/userguide/networking/get-started-macvlan/

>>819
docker host が VM 上だと macvlan が通らないことがあるのでそこのチェック
(コンテナの mac が vm とは異なるものなので、virualbox だと自動的にフィルターされる。
そのため、promiscuous mode にしないといけなかったと思う。）

単純なデバッグとしては外部からの ping がホストまで届いているか tcpdump してみれば？
macvlan モードはオンプレなら何も気にしなくていいけどVMだとそっち側で色々されちゃうので
一筋縄ではいかないのがちょっとつらい。
あとは、ホストへの通信が簡単にはできないのも辛い。

>>820
コメントありがとう。
ググってるだけでまだ触れてないけど、難易度高そうですな…

社内用にgitlabとか簡単に構築したくて入れたけど便利だな
nginx-proxyとかgitlab-runnerにdocker.sock渡してるの怖いけど

そうそう、そういうのを無効化するのが醍醐味
わかって使えばこの上もないツール

自作のアプリならいいけどそういう他人が
作ったものっていうのはデータの永続化が困る。

どこを保存すればいいのか、調べりゃある程度わかるけど
本当にそれだけでいいのか判断できない。

データディレクトリってちゃんと別れていればいいけど
設定ファイルは別の場所だったり、
「管理画面から入れるプラグイン」は特定のディレクトリに入ったりで
コンテナ消したときにちゃんと復帰できるのか自信が持てない。

そういうものは、docker commit で頑張れなくもないけど、
コンテナが immutable であることを前提に設計されている docker を使って
運用するのは向かないものなので VM や lxc なんかで運用するしたほうがよい。

気になって追いかけるときに docker diff なりを使うのもありだけど
結局コード読まないと最終的に判断できないんだから
そういうものは docker 使うのを諦めたほうがよい。

そもそも出来合いのものをDockerで運用する意味はないわ
既存のDockerのクラスタがあるからついでに乗せるとか、
単発のジョブならありだけど

Windows10でドライブマウントうまくいく？
日本語入ってると見れない

dockerスゲーわ

どの部分に凄みを感じたん？

鯖がコンテナ積んでるロゴ

Dockerは確かにロゴやサイトの美的センスはあるよな
LinuxオタのくせにGNU的な気持ち悪さを微塵も感じさせない

>>831
GNU的な気持ち悪さってなんだよ?w

https://cdn.worldvectorlogo.com/logos/gnu.svg

鯖だったのかアレは
個人的にはイカも悪くないと思う

ズートピアの警察署長

アップデートされました。

>>834
海の仲間たちのデザインも悪くない。
センスいいと思う。

このスレって技術者だけで、研究生なんかはいないのかな？

情報系の学生ならいるけど特に研究に使ってるわけじゃないな

今月のソフトウェアデザインを読んでdockerを始めてみたけど自分にどんなメリットがあるのか見出だせない...ラズパイ+dockerで機械学習とかやってみようかなぁ

今Docker実践入門という本で勉強してるけどとても楽しい
今まで必死に書いていた構築手順書とかから解放されそう

インフラ系の人が構築を楽にしたいなら構成管理ツールをやった方がためになると思うけどな
Dockerはあくまでアプリのパッケージ化技術
そこを勘違いしてDockerに入ってきたインフラ系の人が結局 ? となったまま去っていくケースが多い

DockerとImmutable Infrastructureとクラウドのせいで
構成管理ツールいらないんじゃね？って思ってるんだが
シェルスクリプトで十分でしょ

ちなみにDockerfileはほぼシェルスクリプトと思ってる

docker使ってるとubuntu14で一行で
git最新版(2.x)入れる方法とかクソみたいな
知識が必要になるのが辛い。

けどそれ以外は楽しいね〜

複数行で書いていって、完成したら ; でつないで一行にするだけじゃね？

もっともなんで最新版gitをDockerの中に
あえて入れないといけないのかがわからんけど。

Dockerの中のgitは人間が直接使うわけじゃない
最新版でなくても動けばよかろう？

一行にするだけでも可読性が悪くなるよな。gitのsquashみたいな機能があったらいいんだけど。

前に

BEGIN # ここから
RUN なんとか
RUN なんとか
EMD # ここまで

を1レイヤーにすれば良いんじゃね？
みたいなIssueがあった気がするがあれどうなんたんだろう。

ぶっちゃけヒアドキュメントみたいなものが使えれば
一行である必要はないはずなんだよな

>>847
go使うのにある程度新しいgitが必要だったのよ

ディスク容量さえ増えなければ複数行でいいんだよね？
squash diskみたいなのが欲しい。rmしてそれやると、
イメージサイズが減ってくような奴w

なんで？としか言いようがないな。
goは普通にバイナリ提供されてるだろ
goを使うだけなのにどこでgit使うんだ？

goはビルドシステムがgitに依存してる
まあgoはバイナリがポータブルなのが売りなので、そもそもコンテナ内でビルドする必要はないんだが

>>853
ほお、じゃあ外でビルドしてからgopath以下を
全部コンテナに突っ込めばよかったんかな。
イメージを小さくするにはそのほうが良いかも

>>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使え。