Docker

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

http://www.docker.io/

>>772
盆栽じゃないんだから、再構築する材料はとっておこうよ。

他に方法がなければ作り直すしかありませんが、ファイル修正できるならそっちの方が早いので。
docker diffで変更されたファイルが確認できるんで変更をrevertする方法もあったらいいんですが。

一体どうやったらそんな状況になるんだ

ENTRYPOINTがコケるような変更を加えてdocker stop
で簡単に再現できるかと。

docker cp 使って変えたファイルを取り出して修正した後に
docker cp でコンテナに放り込んで start すればOK

ありがとうございます！助かりました。

10:00に問題を書き込んで13:30に解決、
かかった時間は3時間30分

> 他に方法がなければ作り直すしかありませんが、ファイル修正できるならそっちの方が早いので。

本当に早かったんですかねぇ（・∀・）ﾆﾔﾆﾔ

？
そりゃ、cpで済む方が早いでしょ？

書き忘れてたけど、StorageDriver に aufs や overlay(fs) を使ってるなら実ファイルは
/var/lib/docker 以下にあるので最悪はそこからでも触れる。
変えてしまったファイルのパスの確認もできる。
ただし、DeviceMapper の場合だと簡単ではない。
btrfs や zfs の場合は試したこと無いから知らない。

http://paste.ofcode.org/QqeZLmXfui3HBPqTUDmD6j

>>781
まともな使い方してればdocker buildで終わりだってことでしょ

死んだコンテナのイメージを差し替えて立ち上げることが可能ならそれでもいいんですが、
ボリュームを回収して新しいコンテナを立ち上げるしかないんじゃないですか？
まぁ、コンテナが立ち上がらなくなること自体がまともな使い方じゃないと言えばそうですが。

いや永続化が必要なデータは外部のDBに置くかVOLUME使おうよ
コンテナは常に使い捨てが基本だよ

そこは使い方様々ですからねぇ。
自分も壊して構わない前提でいろいろいじくりまわしていて、仮にデータがすべて
失われたとしても作り直せばいいだけなんですが、その手間が省けるならそれに
越したことはないと。
というかそもそも>>772も、その問題を解決したいというよりも書いている通りそのまま、
そのような方法があるかどうか知りたいから質問したわけですけどね。

作り直す手間ってなに？
どこに手間があるの？

自分でケツも拭けないクソが偉そうに能書きたれてるな。哀れ

>>786みたいな盆栽遊びが好きな人には、ビルドとかものすごい手間に感じるんじゃないの。

>>787
>>786のことであれば、ボリュームに入っているデータのことだけど？
ようはコンテナ立ち上げた後のアプリケーションの設定やなんか。

>>790
コンテナ立ち上げた時点でアプリケーションの設定なんか終わってるんだが？

当たり前のことを言うね。

コンテナにログインとかやるやつは
頭がおかしい。

overlayfsを使ってる方ってCentosなんですか？Fedoraですか？
無知な学生ですが、プロの皆様にお聞かせいただきたいです

>>91
かなり遠い所へのレスだけどまさにこれ。
「へえ、docker使ってみるか」
「マ゛マ゛〜、sshdどご〜」
ってなったわ。

sentosではaufsがマージされなくなったのか
いつの間に

お前らはどうやってDockerfile書いてるの？
手動で手順を確認しながらメモって後でDockerfileに清書？

複雑なときはそうするけど基本的にはトライ&エラーだな
前のステップをなるべく弄らないようにすればビルド時間はそれほど問題にならない
で一通りできたらリファクタリングして完成

同一ホスト配下でブリッジ接続の複数コンテナに対して標準のポートでhttp, httpsをつなぎたい場合、nginxだったりのリバースプロキシを用意するのが標準？
redmineやjenkinsだったりを使いたいと思ってるんだけど、Dockerの機能を使ってルーティング出来たりする？

>>796

tmux などで上下分割して、上で docker run --rm -it debian bash して、試行錯誤
下では vim などで Dockerfile 開いて記述

ホスト側で透過プロキシとして squid を動かしているので（dockerで)、やり直しになってもそれほど気にならない。

コマンドの細かい挙動などをチェックしたい場合が多いので今のところは上の方法でやっているけど、
一旦 Dockerfile へは1行ずつ記述して最後にきれいにするほうが速くて良い場合も多いと思う。
1.13 からは squash も追加されるようなのでそこまでしなくて良くなるかもしれないし。

>>798

docker にはその機能はない。

nginx でのリバースプロキシで良ければ nginx-proxy というコンテナを起動するのが良いと思う。
これは、docker api が提供するどのコンテナが起動しているかなどのメタ情報とテンプレートをもとに、
コンテナ生成/削除時の設定ファイルの修正や、プロセスの再起動をしてくれる「docker-gen」という
アプリケーションと nginx を組み合わせている。
これにより、コンテナが立ち上がったり、終了したりすると nginx.conf を修正してそのコンテナへ
プロキシする設定の追加/削除を行い nginx の reload をしてくれる。

機能を実現するために、docker.sock を他人が管理するコンテナに見せないといけないので
そのセキュリティ上の問題点は理解すること。

https://github.com/jwilder/nginx-proxy

自動でなくてよければ、自分で管理する nginx を立てるのでも良いと思う。

>>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 を用いるのはわかるのですが，いまいちよくわからないので