Docker

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

http://www.docker.io/

DockerfileにVolumeを記載したときの動作がわからないです。
これを記載すると、docker run したときに-vのオプションをつけたときと同じ動作をするのでしょうか？

>>233
いいえ。DockerfileのVOLUMEは単にディレクトリを作るだけと考えてください。

例えばmountコマンドで/mnt/hoge/にマウントしようと思ってもできません。
先にマウントポイントとなる/mnt/hoge/ディレクトリを作成しておく必要があります。


VOLUMEは、-vオプションでマウントするためのディレクトリ作成するだけです。

>>234
なるほど。
そういう用途なんですね。
理解しました。

なんかWS2016TP3のイメージダウンロードで失敗して
Docker起動すらできないのだが・・・

docker インスコしたら、なぜかgitがアンインスコされてマジギレなんだが
docker作者いたらぶん殴ってやりてえわ
何考えてるんだ基地害、マジで死ね

ちなWinだが
嫌がらせなのか
gitconfigも消えやがった
マジで損害賠償モンだぞゴミ野郎が
何なんだマジで、インストーラーに選択肢にも出てなかったgitの文字が出てきて嫌な予感がしたが
まさかアンインスコしてわけわからんgitもどきのゴミぶちこまれるとは
スパイウェアかよ、ありえない

1時間無駄にした
俺様の睡眠時間削るとは何様だよゴミの分際で
マジで死ね、勝手に人様の環境のgit削除して入れ直すとかどう考えても頭イカレてんだろ基地害
頭にウンコでもつまってるのかこのゴミみたいなインストら−作ったゴミ屑は
ISISに爆殺されて死ねや

※実際には消えたのではなくて、追加で新しくmsys環境がインストールされ
パスが変わっただけである。

ダメなんだろ。
向いてないね。

Windowsみたいなゴミ使うからそうなる

どっかに行ってしまったんだろうね

それをOSやDockerのせいにするのは無能

コンテナ起動して一個だけコマンド実行して終わったら
コンテナさよならってのはできませんか？

できる

手動でgccのAndroid向けクロスコンパイル環境を作ろうとしてるんだけど、もううまくいかないやー
Dockerにその用途に向いたコンテナないかな？

Dockerは

1. 可能か不可能か・・・可能だ
2. 以前より簡単にできる ・・・ YES
3. 簡単にできる ・・・ NO
4. ハマる・・・YES

だからなｗ

え、Androidビルド環境なんかで悩むところあるか？

>>249
Makefileが手書きのLinux向けフリーウエアをビルドしようとしていて、Makefileをいじっても環境変数をいじってもなかなか通らなくてね
ちゃんと自分でMakefileを修正できていないのが原因なんだろうけど、他も自信がないから環境が整ってるところでやってみたいかな

>>246
よかったらヒント教えていただけると助かります

もし自分で辿りつけたらフィードバックしますね

「docker 起動」
「docker 停止 削除」で検索！

シェルスクリプトにdocker runとdocker rm書けばいいだけだろ

単一のコマンドをコンテナで実行するだけならLXCでいいじゃん

>>254
> 単一のコマンドをコンテナで実行するだけならLXCでいいじゃん
めんどくせーだろｗ

dockerはパッケージでインストールするとして、インストールだけが終わった状態から、
たったこれだけで単一のコマンドをコンテナで実行できるんだぞｗ

docker run debian /bin/bash --version

もちろんdebianの所を変えれば、その他のコンテナで実行できる。
LXCで同じことをやってみてくださいよｗ

docker使おうとしてdocker run コンテナ
ってやってもsyntax errorとか出て何一つ動かない
試したのはfedora,ubuntu,busybox,gccあたり
環境はFedora23 i686
XeleronM410 メモリ512MB

ミスった・・・Celeronね

command not foundではなく、syntax errorとでるのなら、
dockerはインストールされているのだろう？
docker --versionってやってみて。

Docker version 1.8.2-fc23, build 1a57647-dirty
ダウンロードとかは普通にできるんだけどいざ動かそうとするとうんともすんとも言わない
エラーはこんな感じ
exec format error
Error response from daemon: Cannot start container 602972c2cf599bd4702de17c25e64d7608fbc7fbc74c128ca789baad53e0852b: [8] System error: exec format error

32bitだからでは

やっぱり？
32bitダメなのかー

Docker hubでよくわからんのだけど、
公式でないものは、危険な可能性があるってことでいいの？

AUTOMATED BUILDに関しては、リポジトリが表示されているから
おそらく大丈夫なのだろうと思うけど（でも工夫すれば抜け道ありそう・・・）
そうでないものは、どのDockerfileから生成したか？の情報ないよね？

追記、AUTOMATED BUILDの抜け道思いついた。

ソースリポジトリは表示されているけど、
タグを複数つけた時、Dockerfileは何故か一つしか表示されてないみたい。

これを利用すると別のディレクトリで作って、
あたかもこれで作ったみたいな見せ方ができそう。

何する気だよw

>>264
例えばMySQLを高度に最適化したイメージを作った
ふりをして、データを抜くコンテナを作るとか

Dockerの使い方を勉強したいんだけど
どこのサイトを見ても、docker.ioをインストールした後から
の手順が急にぼんやりした説明になっている

xeyesをdocker上で動かすとか
そういう分かりやすいサンプルはないの？

何のためにつかうんだ？

docker上の話は普通にやればいいだけだろ

docker pull ubuntu
docker run -i -t ubuntu /bin/bash
切り替わったらaptでもつかって好きにいじればいい
量産したかったらそのコンテナを登録して増やす

なんかまたDockerを仮想マシンと考えてる奴ができてそうだな。

コンテナをLinux仮想マシン扱いすること自体はいいんでない。意外とそういうところから面白い使い道が発見されるのかもよ

コンテナを仮想マシンとして使うのは、OpenVZが昔からあるから
それを使えばいいんだよ。

DockerはOpenVZではないものとして作られているんだから、
OpenVZ的な使い方をするには合わない。

>>266
docker xeyesでググればxeyesをつかったサンプルがいくつかあるが。
それじゃ不満？

ググるなんて能力あるわけ無いだろやめてやれよ

キーワードまで教えてもらってぐぐれないなんてことないだろ

ここにキーワードがあるじゃろ




・・・・・・

xeyesをdocker上で動かす方法のググり方を教えて下さい
↓
docker xeyes でぐぐる
↓
ありがとうございました。

もしかして: docker lxc

32bit対応してくれねーかなー

無料のLinuxで32bit対応が欲しいという理由は
ハードウェアが対応してないからだと思うが、
新しいパソコンを買ったほうが良いと思うよ。

OSなしでいいんだから3千円台＋送料ぐらいから買える
http://kakaku.com/used/pc/ca=0010/?s2=10

わざわざ32bit限定でdockerが必要なケースがあるのか？

仕事でそれしか支給されてないとかw
流石にそんな会社はないか

>>280
hostapdでWiFiAP使えないと困るからノートになるじゃん
でノートで3000円だと2007年くらいのになってi686しかつかえない
>>281
俺の鯖で動かない
大学受かったら新しい鯖買う予定だけどそれまでは無理
WiFiは〜Piにして鯖と分ければいいんだろうけどね

>>283
家かなんかでサーバー機として常時稼働させていればいい
あんたが今使っているノートからログインして使うんだよ。

>>284
ちがう
自宅の常時稼働鯖がノートじゃないとアクセスポイントにできないって話
で金もない

あとレンタルサーバーでVPSを借りるって手もあるな。

だが大学入試があるなら、遊んでないで勉強しとけ。

>>286
すいませんね勉強に戻ります
カナダに一回払いで買った鯖あるけどローカルでも動かしたい時があるのよ

>>285
だからなんだ？と思うだけだが、
新しくPC買って、そのノートから直結するなり
ハブ経由で接続すればよかろう？

ラズパイでdockerとかアリでしょ？
環境ぶった切ったり
IP毎にサービス割振りしてるよ
OH少なくて助かってる

へー、ラズパイでDocker動いたのか。
ARMだからパッケージ少ないし対応してないと思ってたよ。
基本技術はコンテナだからOSレベルで対応してるのかな。

http://dev.classmethod.jp/hardware/docker-on-raspberry-pi2/
> 結論から言うと動きます。が、実用的ではないです。それは、
> DockerコンテナはDockerホストと同じCPUアーキテクチャでないと動作しないからです

docker はchrootみたいなものなの？
docker動いている最中に ホストからファイル見れたりする？

ググれば全部出てるぞ
日本語訳されてるであろうArchwikiでも読んでこい

OS イメージをベースにして Docker コンテナを作るメリットって、
ホストOS に縛られずにコンテナを配置できるって理解であってる？

ただ、サーバーのメモリやストレージの節約を考えると
ホスト OS は決め打ちにして、コンテナには OS イメージを含めない方がいいと思うけどどうなの？
実際の運用でもサーバーごとに OS やバージョンが異なるなんてことはないはずだしね。

ごめんなさい。すぞい勘違いをしていました。

DockerHub に登録されてる Dockerfile を見ていて気がついたのですが、
Docker イメージは、基本的に何らかの OS イメージをベースにして作るんですね。

FROM scratch となってるものもいくつかありましたが、
FROM を遡っていくとほとんどが何らかの OS イメージをベースにしていました。

OSのイメージはDebianで100MBを切る。
Alpine Linuxならわずか5MBだ

コンテナは仮想マシンじゃない。だからホストOSのカーネルを使用する。
コンテナで起動したアプリ以外の、各種デーモンも起動しない。
だからメモリ使用量もアプリを直接動かすのと大差ない。

つまりサーバーのメモリやストレージの節約は考える必要が無い。

実際の運用ではサーバーごとに OS やバージョンが異なる。
アップデートをすることで日々更新され続けるからだ。
LinuxのLTS（長期サポート）なんて5年しかない

>>293
ホストに縛られないというかコンテナをコピーするだけでそのまま実行環境を別のホストに移せる
あと1つのホストに複数の実行環境を構築できる
これらは従来のVMでも出来ることだけどまるまる1台分を仮想化するのと違ってリソースをより効率よく使うことができる

Dockerを仮想マシンの一種として考えてしまうとインフラよりの発想となってしまう。
これではDockerがもてはやされている理由を理解できない。
Dockerはアプリ開発者の立場で考えるとわかる。

まず（ホスト）OSのアップデートで勝手にライブラリのバージョンが
変わってしまうと困る。例えばRubyのライブラリを勝手に
アップデートされたらアプリが動かなくなる可能性がある。

また、逆にディストリが提供しているパッケージよりも新しいバージョンの
ライブラリを使いたいこともある。1つのホストに複数のアプリを実行する時
アプリごとに使うバージョンを変えたいこともある。
だからアプリ開発者はディストリのパッケージでインストールするライブラリは使わない。
rbenvなどを使ってアプリの一部としてアプリごとにインストールする。
（注 Dockerを使えばrbenvを使う必要はない）

これはRubyライブラリだけの話に限らない。ネイティブライブラリやCLIコマンドなど
アプリから使用するあらゆるものはアプリ独自に入れたい。

アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
必要なものを含めた完全体がコンテナ。コンテナさえあればアプリは完全に動くので、
ホストOSはDockerさえ動けば良くなる。

これがDockerを使う目的なのだから、その目的を達成できない方法はそもそも代替案にはならない。
ホストOSのリソースの効率化とかそういう話じゃないんだよ。

>>295

ただ、DockerHub で配布されてる centos:6.7 に
yum install git すると image size が 190.6 MB → 323.3 MB
yum groupinstall "Development Tools" などとすると image size が 190.6 MB → 693.9 MB

となり、やはりストレージは食うのかなと。

根本的に使い方が間違っているのかもしれませんが、
通常は git とか コンパイラはコンテナに含めないのでしょうか？

>>297

> アプリはアプリだけで動くのではない。動的リンクライブラリやCLIコマンドまで含めて
> 1つの動作するアプリとして完全体となる。つまりアプリとアプリを正しく動かすのに
> 必要なものを含めた完全体がコンテナ。

なるほど参考になります。

コンテナ =
Ruby で言うところの（ 例にあげて頂いた rbenv というよりは）bundler とか、
Node.js の npm (のローカルインストール) の延長で、
OS のストレージにあるものすべて（動的リンクライブラリやCLIコマンドなども含む）を
1つのアプリ環境としてパッケージできるもの

という理解で落ち着きました。

>>298
> 通常は git とか コンパイラはコンテナに含めないのでしょうか？
含めない。

もちろんコンテナイメージ作成中は適当にやっていいし、
利便性を考えて入れておくのもありだけど、

例えばgitを使ってソースコードを配置したいなら、
RUN apt-get install git & git clone 〜 & apt-get remove git (例なので適当）
のようにしてgitを入れて必要な処理が終わったら削除する。

（注 1つのRUNでインストールとアンインストールを実行すること。
複数に分けると、それぞれで中間イメージが保存されるのでサイズが減らない）

> RUN apt-get install git & git clone 〜 & apt-get remove git (例なので適当）
> のようにしてgitを入れて必要な処理が終わったら削除する。
>（注 1つのRUNでインストールとアンインストールを実行すること。
> 複数に分けると、それぞれで中間イメージが保存されるのでサイズが減らない）

確かにおっしゃる通りになりましたが、「複数に分けると〜」のところは
なぜサイズが変わらないのかいまいち理解できません。

コマンドごとにセーブしてるからだよ

都度gitインストールってapt転送分の無駄を感じるな。gitならまだいいけどそれにしても美しくない
ローカル制御細かくやるしかないか

だからapt用のキャッシュプロキシというものがあって
だけどその環境依存の設定をDockerfileに書きたくないから
ビルド時にオプションで環境変数を使えるようにしてくれって
話がついて1.9からサポートされた

寡聞でしたすみません

Docker の質問というより、ヴァーチャルマシンに関する質問だと思うんですが質問させてください。

Windows で Docker から環境を作ったのはいいんですけど、
そのなかのソースコードとかって Windows からアクセスできないんですかね？
いまひとつ開発のスタイルがよくわかりません。

まさかとは思いますが、仮想環境の中にIDEをインストールしてそこで開発とかでしょうか？
よろしくお願いします。

>>306
Dockerの中で動かしつつアプリを開発するのはやめたほうがいいよ。
デバッグ用のツールなど使いづらくなって、単に面倒になるだけ。
Docker使わずに作られたアプリ。それを動かす環境を作る時に
Dockerを使うってだけにした方がいい。

もう少し詳細に説明すると、まずWindows（boot2docker）で考えるとややこしくなるので、
ホストOSにLinuxを使っていると仮定する。

開発はDockerを使わない。IDEはLinuxにインストールする。
これだと何も複雑なことはないよね？これをメインの開発環境とする方がいい。

開発時にはDockerを使わないといったけど、テストを実行すときとか実機でDockerを使うとして、
リリース時とできるだけ同じ状態にしたいとかDockerの中だけで発生する問題とか、
開発時にDockerを使いたい時もある。

そういう時は、ソースコードのディレクトリをData volume（dockerの-vオプション）で
コンテナ内にマウントする。ビルドが必要な物（scssからcssへの変換等）は
Dockerの外でビルドしてそのディレクトリをマウントする。

ただしビルドで生成するものがバイナリ実行ファイル等の場合は、ホストOSとDockerコンテナで
使うOSが違いすぎると動かない可能性があるので、Dockerコンテナでビルドする必要がある。
本来Dockerコンテナにはビルドツール等は入れるものではない。本来はビルドするときは
>>300で書いたようにビルドツールを入れてビルドしてビルドツールを消すことになる。

apt用のキャッシュプロキシでパッケージのダウンロードは避けられるとはいえ、
ビルドのたびにパッケージのインストールとか時間的にやってなれないので、
（実行用のDockerイメージとは別の）ビルドをするためのDockerイメージを作る必要がある。

な？ Dockerを開発時に使うことは出来なくはないし、テスト実行のために出来たほうがいいんだけど
面倒で手間がかかる。だから通常の開発はホストOSでやった方がいいんだ。
ホストOSがWindowsの場合は、vagrantで作ったLinuxで開発するのをおすすめする。

話をWindowsに戻すと、おそらくDocker Toolbox（に含まれるboot2docker仮想マシン）か
boot2dockerを使ってるだろう。これはVirtualboxの仮想イメージなので更にややこしいｗ

俺としてはvagrantで作ったLinuxで開発するのをおすすめする。
Linuxで開発すると言ってもCLIコマンドを実行する程度。
samba使ってファイル共有すれば、ソースコードの修正はWindowsのエディタが使える。
Windowsに入れたIDEを使う場合は、デバッグ機能に多少制限が出るかもしれないので
俺はやってないけど、XクライアントをWindowsに入れて、Linux用のIDEを
使うとかのほうがいいかもしれない。

で、結局の所、開発時にはDocker使わない方がいいので、Windowsで
開発したいなら今までどおりDocker関係なく、Windowsで開発すればいい。

そしてWindowsで開発したアプリをDockerで動かしたい場合だけど、
boot2dockerの中は結局のところLinuxなので>>307の話が通用するとして、
問題はWindowsのソースコードをどうやってboot2dockerから参照するか？

一番簡単なのは、Virtualboxの共有フォルダー機能を使う方法だろう。
（ぶっちゃけboot2docker使ってないのでそこまで詳しくない）

注意が必要なのは、Virtualboxの共有フォルダー機能を使うと、最終的には
Windowsのファイルを見てるわけだから、パーミッション周りで苦労するのと
シンボリックリンクが使えない（頑張れば使える？）などの問題が発生する。

なのでWindows＋boot2dockerでの開発はやっぱりお薦めしないｗ
boot2dockerは、dockerコンテナを動かして。たいけど、ホストOSがWindowsで
Linuxが無いんだよ。って言う時に、おいWindowsでもdockerコンテナ動くぜｗｗｗ
これなら、dockerイメージさえあれば、どこでも同じように動く、
それがたとえWindowsであっても（ｷﾘｯ ってやりたい時だけに使うものだと思ってる。

で、長々と書いたが、Dockerを使うことで、

（ウェブ）アプリを開発する → それを動かす環境を作るのが面倒
っていう時代から、

環境まで含めた（ウェブ）アプリ を開発できる → それを動かすのは簡単！
という時代になったわけだけど、

アプリの開発自体は、今までのやり方のままでいいってこと。

今Windowsを使ってるなら、Windowsでいいし、
俺はvagrantを使って作ったLinuxの開発環境を使ってる。

実機へのデプロイやテスト等で動かすときにDockerを使うことで
同じ実行環境を簡単に作れるから "追加で" Dockerへの対応をするといい。


余談だが、
今までは、アプリエンジニアとインフラエンジニアが分かれていて、
アプリを動かす環境を作成する部分はインフラエンジニアが担当していたから、
その連携が大変でどうたらとかDevOptsとかいう言葉が出てきたりしたけど、
Docker出現で実行環境づくりがインフラエンジニアからアプリエンジニアに移ってきてるんだよ。
アプリエンジニアは大変（笑）というかインフラエンジニアの仕事が減って、クラウドを使えば
さらにコードでインフラかけるから、この2つを分ける必要ないよね？ってなってきてると思ってる。

追記

> 一番簡単なのは、Virtualboxの共有フォルダー機能を使う方法だろう。
Virtualboxの共有フォルダーは遅いという問題もある。

やり方は他にもgitでリポジトリからソースコードを持ってきたり、
結局はソースコードさえあればいいのだからNFSを使って
共有したりする方法もある。

DockerコンテナもData volumeを使わずに、git cloneしたり。
（実機で使うDockerイメージは、イメージ作成時にgit cloneするべきだろう）

git cloneするということは、（開発中の）ソースコードが
リポジトリにpushされている必要があるね。

とまあ、できるにはできるけど、開発中にDockerを使いつつ作業するのは面倒なだけ。
でもDockerで動くようにしていれば、gitリポジトリにソースコードをpushした時に
CIでDocker使ってテストを実行するなんてことができるようになる。

なげーよ

>>311
だから？

>>307-310
すごく参考になりました。
わからないことも多いですが、ざっくりと雰囲気はつかめました。
右も左もわからず暗中模索してましたが少し霧が晴れた感じです。
いただいたレスをよく読み返して学習の指針とさせていただきます。
ありがとうございました。

>>307-310

質問者と同じく開発スタイルで迷っていたので参考になりました。

> ただしビルドで生成するものがバイナリ実行ファイル等の場合は、ホストOSとDockerコンテナで
> 使うOSが違いすぎると動かない可能性があるので、Dockerコンテナでビルドする必要がある。

ただ、これに関してはホスト OS と Docker コンテナで使う OS を同じにすればいいと思うので
ホスト OS でビルドして、Docker コンテナにはコンパイラなどのビルド環境を入れないように
してもいいかなと思ってます。

boot2docker は罠ですね。

docker-machine create する場合も、Docker ホストは自動的に boot2docker になりますが、
ここを任意の OS に切り替えられると話が早そうです。

>>314
理屈上はそうなんだけどね。

でもそうすると、ホストで開発しやすいOSを使う＝コンテナも同じものに
制限されてしまうので、分けるほうが好ましい。

Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
開発ではホストOSにUbuntuを使っていても、awsで動かすときは
CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

まあ別に開発中であれば自己責任で適当に使っていいと思うよ。
アプリ開発のためのインフラとしてDockerを使って開発環境を整備するんじゃなくて
開発作業の一貫としてDockerというツールを使うという使い方。
Dockerの中で開発するのは面倒なだけだからさ。
（あくまで ”アプリ開発" スタイルの話。インフラ・運用の話ではない）

>>315
boot2dockerは、アプリ開発者がWindowsで開発している時に
Dockerを簡単に使うためのものではなくて、

アプリは完成したものとして、そのアプリを動かしたい時に
ホストがWindowsの場合に使う手段だと思ったほうがいいよ。

わざわざWindowsをサーバーに使う人は居ないだろうから
実運用向きではなく、Docker自体の勉強で使うときとか、
Windows上にDockerコンテナでサービスを動かしてそのサービスを
個人的に使うのを目的とするとか。
（例えばHTML Validatorをローカルで動かすとか）

> Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
> 開発ではホストOSにUbuntuを使っていても、awsで動かすときは
> CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

なるほど。そういう観点ですね。
だとすると以下の引用のようにビルド用のイメージを作るってことになると思いますが、

> ビルドのたびにパッケージのインストールとか時間的にやってなれないので、
> （実行用のDockerイメージとは別の）ビルドをするためのDockerイメージを作る必要がある。

この場合、ホスト OS とビルド用の Docker コンテナは -v でフォルダ共有してから対象ファイルをビルド。
そして、実行用のコンテナを作る際には、ホスト OS から （実行用コンテナに）ビルド済みバイナリを ADD すればいいということですね。

>>318
なので、基本的にアプリ開発中はDockerを使わない。
で、どうしても必要だと思ったときは使うけど・・・
うーん、その場合はいくつかやり方が考えられるんだけど、どれも一長一短

・docker buildでビルドする
完全に動くDockerイメージを作る途中で、ビルドも行う方法。
ビルドツールは入れて消すのでサイズも小さいし実運用でも使える。
だけど毎回ビルドツール入れるので時間がかかる。

・docker buildでビルドする（その2）
サイズは諦めてビルドツールを入れたイメージからイメージを作る。
サイズは最小にはならないが、それが問題になることは少ないだろうから一番楽かも

・実行用イメージとビルド用イメージを分ける
>>318で書いてあるやり方ね。実行用イメージは小さくて実運用でも使え
ビルドの時間も少なくなるけど、作るのが面倒くさい。
ビルド済みファイルを受け渡しする方法を作らないといけないし、
特にフレームワークがビルドとかもしてくれる仕組みだと
なんか二度手間感がある

・docker runした時にビルドする。
必然的にビルド環境も含めたイメージになる。
ファイル更新時に自動的にビルドしてくれるようなフレームワークを
使っている場合、この方が便利かもしれない。テストも実行できるし、
実運用用は別で作ることになるだろう。

ちゃんと作るならおそらく3番目が良さそうではあるけど、開発にとって便利か？
って考えると4番目かなーとも思うけど、そこまでやるのが面倒なので
開発中はDocker使わんでいいやんって思ってるわけ。

一つのDockerfileで開発にもデバッグにもテストにも実運用にも使える
万能な方法があればいいんだけど、

そういやテスト実行環境っていうのもあるんだよね。

実行環境は、実行出来るだけで良い。
デバッグは、最低限デバッグモードで起動できればいいから、その場合は実行環境用と
共通化できるがデバッグのためのツールを入れるならば、追加でなにか必要。
ビルド環境は、ビルドツールが必要。
テスト実行環境は、実行環境に加えてテスト用ライブラリやツールが必要


やっぱり、それぞれわけないとだめだよなーっていうのが現時点の俺の結論。

> なので、基本的にアプリ開発中はDockerを使わない。

まあ結局そういうことですね。今のところは運用環境として割り切って使っていこうと思います。
諸々のノウハウありがとうございました。

>>321
使わないと言っても、開発の終盤っていうか、区切りがいい時点で
実環境をDockerにしているとして、それと同じ環境でテストを
実行したいって場合には使うけどね。

ただ無理して開発時までDocker使いまくるのはちょっと違うかなーって思う。

あー、そうそう例えばウェブアプリを開発していて、データベースとして
MySQLを使う場合に、ホストOSに直接入れるんじゃなくてDocker使っていれる。
なんて使い方はするよ。

自分の場合、開発をアプリごとに新規で立ち上げた VirtualBox(Vagrant) のゲスト OS 内で
やっているので、DB を含むアプリで使うミドルウエアは ゲスト OS に入れることにしてます。

今のところ Docker の使いどころは、リモート環境へ配布するときに Vagrant 内で
Docker イメージを作ってそのままデプロイできるってあたりかなと思ってます。

>>323
> 自分の場合、開発をアプリごとに新規で立ち上げた VirtualBox(Vagrant) のゲスト OS 内で
> やっているので、DB を含むアプリで使うミドルウエアは ゲスト OS に入れることにしてます。
俺もそんな感じ。

スレ違いだけど、これをやると幾つもの仮想マシンにソースコードが分散してしまうのと、
仮想マシンをアップデートするときに、いくつもメンテナンス作業（再プロビジョンは時間がかかる）が
必要だったり、ベースとなるboxファイルを更新しても、既存の仮想マシンはそれを使うわけじゃないし
消してから作りなおせばいいんだけど、仮想マシン上にあるソースコード、全部コミットしたっけ？
消してよかったっけ？とかなって、まだ満足していない。
ホームディレクトリの設定も仮想マシン毎に必要になるし。
常に最新の開発環境が、素早く使えればいいんだけどな。

> 今のところ Docker の使いどころは、リモート環境へ配布するときに Vagrant 内で
> Docker イメージを作ってそのままデプロイできるってあたりかなと思ってます。
ミドルウェアに使うのも便利だよ。例えばいろんなバージョンのMySQLでテストするとか。

仮想マシンじゃなくてchroot環境のすごい版てことか

>>325
その通り。

OpenVZいうコンテナ技術を使ってKVMのような仮想マシンを
つくり上げるソフトウェアがあるが、これとは考え方が
違うということに注意する。

chrootが特定のプロセスだけのルートディレクトリを変更するのと同じように
Dockerが作るものは、特定のプロセス（のように見える物）であって
マシンを作っているわけではない。

じゃあGUIアプリを動かすのは
Dockerじゃうまくイカないんだな
X飛ばすしかないもんな

>>327
普通に出来てるぞ。これとか

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/

Xはクライアント・サーバーモデルなのでウェブアプリと
同じようにXアプリとしてネットワーク通信経由で動くよ。


たぶんあんたはGUIのログイン画面とかあってVNCで接続するようなものを
イメージしているのだろうけど、そもそもそれは仮想マシン的使い方であって
Dockerの本来想定する使い方じゃない。

とは言えvncserverとか入れれば出来ないことはないんじゃね？
デスクトップ環境全体を一つのアプリとして考えるという、
ChromeでOS作りましたみたいな話になるけどｗ

>>328
ホストは64bit環境だけど
32bitライブラリじゃないと動かないアプリがあるので
Dockerで閉じ込めたい と思っただけ

chrootだとXつかうのに 結構手間かかったけど
Dockerでもやっぱゴチャゴチャするんだな

まあ地味にもっと面倒くさいのは 音を出す方なんだよな

上でdllヘルがどうとかあったけどwinなら実行ホルダにdll突っ込んどけば避けられるんだよな
ハードリンク使えば容量も食わない
Linuxもようやく追いついたということか

dockerの実際の運用例の解説とかでオススメの書籍はありませんか？