仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/02/16(木) 18:01:04.48

開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ

**デフォルトの名無しさん** · 2018/07/05(木) 10:10:29.76

>>551
もともとDockerはLinuxカーネル上で動くものとして作られた
今はWindowsやIBM Zなどに対応しているようだが、使用例は少なく
意識して使おうと思わない限り、Linux（x64）のイメージを使ってるはずだ

Linux（x64）のイメージを使っているのだから、
そのDockerコンテナはMacやWindows上でネイティブに動かない。
だからMacやWindowsでは仮想マシンが使われておりVM上でLinuxが動いている
（このLinuxはDockerを動かすためだけの軽量なLinuxで直接使うことはないのでディストリは意識しなくていい）

Docker for Mac では xhyve (Mac純正仮想マシン）が使われている
Docker for Windows では Hyper-V（Windows純正仮想マシン）が使われている
Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、Docker Toolbox（Virtual Box）を使うしかない

仮想マシンを使用しているということを意識しないように、うまく設定されてはいるが、
それでも仮想マシンであるがゆえに、CPUやメモリの使用する量を仮想マシンに割り当てるしかなく
その範囲でしか使うことができない。これらはDockerの常駐アイコンから設定できる

> Dockerの仮想化ってどのレベルでやってるんでしょうか
勘違いしている人が多いが、仮想化 = ハードウェアエミュレーションという意味ではない
仮想化というのは単に物理的なものを切り離して抽象化するという意味なだけだ

仮想マシンは、マシンを仮想化したものだが、Dockerが提供しているものは、
（実行環境の）仮想化であって仮想マシンではない。ハードウェアを抽象化して
見せているのではなく実行環境（カーネル以外のOSやライブラリなど）を抽象化して見せているだけ

**デフォルトの名無しさん** · 2018/07/05(木) 10:12:02.23

訂正

Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、 "Docker for Windowsが使えない場合は" Docker Toolbox（Virtual Box）を使うしかない

**デフォルトの名無しさん** · 2018/07/05(木) 10:18:19.71

環境構築は人にたよってて
その上でjavaやPHPのコーディングするのがメインなのでちゃんと理解できてない…

今の案件がRailsなんですけど
結論からいうとwindows上のDockerでRailsを動かす同じ環境を構築するのは難しい感じでしょうか

**デフォルトの名無しさん** · 2018/07/05(木) 10:29:08.88

>>554
別に？

同じように使える。というか同じように使えるように
Docker社が頑張ってくれてる。

もともとLinuxカーネルでしか動かないのに
よくもまあこんなに頑張って対応したもんだと思うよ
WindowsやMacでも動くことの重要性を強く認識していたんだな

本番環境ではLinuxカーネル上で動かすわけで、Linux上にだけ対応するという道もあったはず。
でもWindowsやMacに対応したのは、多くの開発者の開発マシンはWindowsやMacで
開発者にとってのツールであるDockerはWindowsやMacでも使えることが重要だと考えていたのだろう

上の方にいる、誰かが作ったアプリをパッケージングして配布することだけしか考えてないやつには
わからんだろうね。だから配布するならansibleで十分じゃんという発想になってしまう。
Dockerはアプリ開発者のためのツールですから

**デフォルトの名無しさん** · 2018/07/05(木) 11:11:14.97

丁寧な回答ありがとうございます
構築してみます

**デフォルトの名無しさん** · 2018/07/05(木) 11:37:29.66

何度もすいません

インストールはできてコマンドラインからも動作させることはできたんですけど
ファイルシステムやメモリの設定はどこから行えばいいんでしょうか

mac版はランチャーがあって
Preference > Daemon > Advanced にファイルシステムの設定ファイルがかけたり
Preference > Advanced からメモリの設定ができたりしたんですけど

**デフォルトの名無しさん** · 2018/07/05(木) 12:38:07.08

>>554
素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
Dockerはほぼどこでも動くけど、どこでも同じように動作するわけじゃないし、トラブルが発生した時の対処手順がDockerと実機サーバーや仮想マシンとでは大きく異なる
本番も開発環境もDockerで統一するなら許容範囲内だけど、それでも環境差異のリスクはあるね

**デフォルトの名無しさん** · 2018/07/05(木) 12:51:42.85

> 素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ

それをやると問題になるのが、（Windows or Macで）ファイルを編集して
すぐにそれを反映させるのが大変になる。いちいちアップロードなんてしてられない
開発時はソースコード書いてテスト実行という流れが1分間に数回のレベルで発生する

また開発時はデバッグ用のモジュールが必要になる。
ログの表示とかデバッガの実行とか。
本番環境と揃えるのは、開発面ですごく効率が悪い
アプリ開発してない、単に配布しかしてないやつにはそれがわからない

**デフォルトの名無しさん** · 2018/07/05(木) 13:01:45.08

>>557
Windowsもタスクトレイのアイコンから設定できるだろ？
Docker Toolboxはどうなってるのかしらんが。

**デフォルトの名無しさん** · 2018/07/05(木) 13:11:16.62

>>558は（Ansibleで構成した）仮想マシンと実機環境が同じだという前提のようだが、
その理屈だと Windows or Mac 上のDockerは仮想マシンで動いてるので
Dockerが動く仮想マシンと、Dockerが動く実機マシンは同じと言える

実際の所、Dockerイメージの中に実行環境が組み込まれているので、
Dockerイメージは、LinuxカーネルとDockerにしか依存しない
Dockerイメージは同じものを使うという前提であれば、
あとはLinuxカーネルとDockerを揃えてしまえばほとんど同じ

たとえ違っていたとしても、Linuxカーネルに関しては高い互換性が
あることが今での実績から明らかで、DockerはDockerコンテナを動かすために
使っているだけで、開発したアプリがDockerに依存しているわけじゃない
なのでLinuxカーネルもDockerもバージョンが変わったところで問題はほとんど発生しない。

環境差異のリスクがあるのはDockerを使わないからなんだ

**デフォルトの名無しさん** · 2018/07/05(木) 14:32:54.33

>>559
大変にならないよ？
もしかしてアプリ開発したことないのかな

**デフォルトの名無しさん** · 2018/07/05(木) 14:37:12.16

>>561
Dockerといえど環境バグは結構あるよ
まあ仮にDocker間で100%互換性があると譲歩したところでテスト、本番が非Dockerなら開発にDockerを使うのはリスクしかない

**デフォルトの名無しさん** · 2018/07/05(木) 15:02:48.88

>>562
じゃあWindows or Macのテキストエディタで
どうやって編集するというのかな？

**デフォルトの名無しさん** · 2018/07/05(木) 15:03:35.76

>>563
本番もDocker使うに決まってるでしょｗ
っていうか、Kubernetesとか使ったことある？
Docker前提だからね。もう大規模はDocker前提の時代になってる

**デフォルトの名無しさん** · 2018/07/08(日) 20:56:23.28

WSLでvagrantを使ってる人いる？
使い心地どうですか？

**デフォルトの名無しさん** · 2018/07/09(月) 12:21:29.06

WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87

**デフォルトの名無しさん** · 2018/07/10(火) 10:00:57.15

GKEもECS+Fargateも使える、この世の中でdocker使わない意味もないし、さすがにmanagedに対してansible使う機会は減ってきたと言わざるを得ない

**デフォルトの名無しさん** · 2018/07/12(木) 00:18:40.48

>>564
ま、それも一理あるね
addじゃなくて、volumeで割り当てれば、host側から編集できる

**デフォルトの名無しさん** · 2018/07/31(火) 15:12:20.08

コンテナは上がってるのに

docker exec -it xxxxx /bin/bash
Error: No such container: xxxxx

になったんですけど原因わかりませんか？

ymlファイルはいじってなくて

xxxxx:
image: yyyyyyyyyyyyyy
container_name: xxxxx

docker ps の結果は普通に起動してる
zzzzzzzzzzzz yyyyyyyyyy "/bin/bash" 4 days ago Up 23 minutes 0.0.0.0:nnnn->nnnn/tcp

昨日までは普通に動いてたのに
設定ファイルは色々いじったんですがコンテナに関係する部分は触ってないはずなのに…

dockerは便利だけどブラックボックスすぎて一度問題起きると自分で全く解決できないのが辛い

**デフォルトの名無しさん** · 2018/08/05(日) 16:25:49.27

よく分からんなら問題解決なんてしないでコンテナ作りなおしちゃおーぜってのがdockerの基本中の基本
根本原因を調べないと再発するのでは？って思うかもしれんけどそのたびに作りなおせば問題ないよね

**デフォルトの名無しさん** · 2018/08/07(火) 08:55:16.65

ずっと再発してたら進まないじゃん

**デフォルトの名無しさん** · 2018/08/07(火) 23:32:53.48

>>572
だから再発するまでは問題ないんだよ
「昨日までは普通に動いてたのに」ってことはコンテナを立ててからしばらくは正常に動いてるってこと
その間だけサービスを提供してダメになったら(なりそうだったら)予備のコンテナに切り替えるってわけ
コンテナ切り替えたら元のコンテナは破棄して次の予備コンテナをスタンバらせる

**デフォルトの名無しさん** · 2018/08/08(水) 07:43:28.52

原因は調べないんでしょう？
ダメじゃん…w

**デフォルトの名無しさん** · 2018/08/08(水) 15:09:32.22

dockerの構築スクリプトも定期的にメンテしないと動かなくなることあるよ

**デフォルトの名無しさん** · 2018/08/08(水) 15:11:24.15

>>570
image-idじゃなくて、container-idをｼﾃｲｼﾅｲﾄ駄目だよ

**デフォルトの名無しさん** · 2018/08/08(水) 15:11:49.43

エラーの原因はコンテナと共にバイナリの海の藻屑となる。。。
積み重なったコンテナはやがて墓場を形成し、次第に人々はこう呼ぶようになった。。。
「どっかー(行っちゃった)の墓場」と。。。

**デフォルトの名無しさん** · 2018/08/09(木) 20:34:37.85

docker for winは登録しないとダウンロードできなくなったみたいだ

**デフォルトの名無しさん** · 2018/08/09(木) 21:19:10.45

そういやWindowsコンテナってあんま話題にならないけどどうなんだろ
XP、.NET 2.0、正体不明の自社・他社COMライブラリ、Excel.Applicationなどが仕事してる古いシステム
まるごとコンテナ化して隔離できんかな

**デフォルトの名無しさん** · 2018/08/20(月) 20:42:31.73

mysqlのdatabaseごとにマウントポイントを変更したい
どうやんの？

**デフォルトの名無しさん** · 2018/09/24(月) 10:53:33.16

Docker Hubから誰でもダウンロードできるコンテナイメージに暗号通貨採掘ボットが潜んでいた
https://jp.techcrunch.com/2018/06/16/2018-06-15-tainted-crypto-mining-containers-pulled-from-docker-hub/

オフィシャルと自作しか信用できんな

**デフォルトの名無しさん** · 2018/09/24(月) 19:46:38.93

内容読む限りKubernetesクラスタとかDockerサーバのセキュリティ甘いやつ狙ってそいつらにデプロイさせてるんだと思う
まぁ自作と公式以外信頼しないのは重要だと思うけど

**デフォルトの名無しさん** · 2018/09/25(火) 22:24:47.75

Dockerってデバッグ実行の設定が面倒っすね

**デフォルトの名無しさん** · 2018/10/10(水) 14:24:27.56

virtualboxの上で直接に動いてるLinuxと
virtualboxの上にのってるVagrant上で動いてるLinux

この２つのLinuxって挙動とか変わってきたりしますか？
C言語とかシェルスクリプトのテスト環境として全く等価なんでしょうか？

**デフォルトの名無しさん** · 2018/10/10(水) 17:09:35.61

変わるわけねーだろ。仕組みを考えろや

**デフォルトの名無しさん** · 2018/10/10(水) 17:11:43.59

>Vagrant上で動いてるLinux
Vagrantは、仮想OS ではないので、Linux は、Vagrant上で動かない

「Vagrant」で検索！

**584** · 2018/10/10(水) 17:25:45.68

>>585
>>586
理解できました
ありがとうございます！

**デフォルトの名無しさん** · 2018/10/10(水) 19:12:20.57

>>584
インストールから設定をキッチリ揃えたわけでもなければ当然ながら等価じゃないよ
無視できる差異かどうかってとこが重要
これはDockerでも同じこと
厳密に同じ環境はどうやったって作れない

**デフォルトの名無しさん** · 2018/10/10(水) 19:32:05.19

>>588
厳密に同じ環境であるかなんて聞いてないだろ

**デフォルトの名無しさん** · 2018/10/11(木) 01:15:56.61

>>588
野良boxでなければ等価だと言ってもよいのでは？

**デフォルトの名無しさん** · 2018/10/11(木) 07:15:08.44

何をもって「挙動が同じ」「等価」とするかだよね
スクリプトでハードウェア情報取得しようとすれば環境によって変わってくるだろうし
外部のWebサイトに対して自分で書いたクローラーを実行するとかなら多分「挙動が同じ」になるだろう

**デフォルトの名無しさん** · 2018/10/12(金) 12:25:02.77

コンテナ上で仮想OSは動かないということだけど、例えば「docker pull ubuntu」で取得したubuntu動かすのと仮想マシンでubuntu動かすのとの違いが良くわからない

**デフォルトの名無しさん** · 2018/10/12(金) 12:45:36.05

>>592
dockerにとってubuntuは材料に過ぎない
ubuntuという材料をベースにDockerfileを書いてアプリを作る
そういうことが簡単にできるように作られたのがdocker

**デフォルトの名無しさん** · 2018/10/12(金) 13:36:53.15

つまりubuntuっぽい(というか見た目は変わらない)動作をするアプリが動いてるだけってことか
ありがとう

**デフォルトの名無しさん** · 2018/10/12(金) 21:21:03.81

マイナーなツールでフォアグラウンド起動のしかたがわからない場合どうする？

**デフォルトの名無しさん** · 2018/10/12(金) 21:45:24.47

フォアグラウンド起動の方法がないじゃなくて
わからないだけなら、調べろとしか

**デフォルトの名無しさん** · 2018/10/13(土) 00:18:26.66

所詮はDockerって省エネを目指した仮想環境に過ぎないからね
そんなこと気にしなければVagrantがベスト

**デフォルトの名無しさん** · 2018/10/13(土) 04:06:41.09

dockerとvagrantという全く違うものを
比較している人に言われましてもｗ

**デフォルトの名無しさん** · 2018/10/13(土) 10:23:57.31

用途がかぶる部分があるので比較する意味は有る

自転車、自動車、鉄道、飛行機は全く違うものだけど、移動するためのものという用途は同じ
旅行や通勤の際にこれらを比較する価値は大いに有る
vagrantとdockerも同様

**デフォルトの名無しさん** · 2018/10/13(土) 11:20:42.44

自動車と運転手を比較してもな。

**デフォルトの名無しさん** · 2018/10/13(土) 11:20:59.09

基本的にはファイルシステムだけカプセル化してるんだっけか？
でもportなんかもカプセル化してるし、どこまでを閉じ込めてるか結構微妙。

**デフォルトの名無しさん** · 2018/10/13(土) 12:11:11.17

>>601
アプリケーションを動かすのに必要なもののうちOS以外の部分を
アプリケーションに内包させていると考えればいい

**デフォルトの名無しさん** · 2018/10/13(土) 12:14:09.83

>>599
なにかアプリを使おうと思った時、わざわざ別マシンを用意して別の環境で動かすのが仮想マシン

今自分が使ってる環境の上でアプリを起動するのがDocker

ぜんぜん違う

**デフォルトの名無しさん** · 2018/10/13(土) 13:02:00.31

>>601
そんな抽象的で意味のない答えは求めてない。

**デフォルトの名無しさん** · 2018/10/13(土) 21:33:30.23

>>603
抽象化ができないエンジニアには難しいかも知れないが
ホストと隔離された環境でなんらかのアプリを使うという抽象的な目的は同じなんだよ
基本になってるテクノロジが違うけどそこは同じ
なので比較検討することには意味が有るわけだ

例えばローカル開発環境を構築するという抽象に対してDockerあるいはVagrantという具象が有る
もちろんそういう意味ではホストに必要なパッケージをインストールするだけの素朴な構成も比較検討に値する
完全仮想化とコンテナ仮想化は違う技術だから比較に値しないなんてのは表層しか捉えられないなにもわかってない人の発想なんだね

**デフォルトの名無しさん** · 2018/10/13(土) 21:48:14.00

技術が違うんじゃなくて、目的が違う
ここまで理解能力がないと、本当に話にならない。

**デフォルトの名無しさん** · 2018/10/13(土) 22:12:07.13

Dockerの典型的な利用例の一つは仮想マシン上でDockerコンテナを動かすこと
仮想マシンとDockerをごっちゃにしているやつはなんでそうするかを理解できない
目的が同じものなのになぜ2つのツールを同時に使うんだ？と思ってる

答えははっきりしてる。それこそ目的が違うものである証拠
Dockerを使うとアプリにそれを動かすのに必要なものがOS以外すべてバンドルされる。
それによってDockerさえ動いていれば、どこの環境にも同じDockerイメージを
持っていって使うことができる。この可搬性こそがDockerの目的

単純にVagrantを使うと特定のOS、ディストリ専用にVagrantfileを書かないといけなくなる
各OSでパッケージ名やデフォルト設定やパスなどが違ってるからだ。

そこで可搬性が高いDockerを併用すると、DockerのインストールまではOS、ディストリ依存に
なってしまうが、それ以降は全く同じ手順でDockerコンテナを起動することができる
Vagrantfileでいろいろ書く必要はないし、VagrantをAnsibleやChefと併用する必要もなくなる

もちろんVagrantを使わない環境、例えばAWSやGCPなどのクラウドでもあっても
今は直接Dockerイメージをサポートしてるのもあって、Dockerイメージを指定するだけでいい

Dockerは可搬性を高くするためのもの
仮想マシンはただのマシンでしか無いし、Vagrantは環境構築ツールでしかない
目的が全然違っている。

**デフォルトの名無しさん** · 2018/10/13(土) 23:33:44.26

>>606
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない

**デフォルトの名無しさん** · 2018/10/13(土) 23:37:37.63

そうやって一般論でごまかすのやめーや

Dockerが考えてる目的を書いただけの話
別の目的に使おうというのなら、使いにくいのは当然だってことだ
少なくとも仮想マシンやVagrantとDockerの目的は違っている
お前の目的の話はしてない。Dockerの目的の話をしてる。

**デフォルトの名無しさん** · 2018/10/13(土) 23:44:07.35

>>607
あらら、まだわからないのか

キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
そして開発環境を構築するという目的を解決する手段はDockerに限らずVagrantでもローカルでも構わない
だから比較検討して目的を達成するのにはどのテクノロジを採用するのがよいかを考えるわけだ

おそらくキミの中ではDockerはこの目的に使うもの、Vagrantはこの目的に使うもの
といったようにただ一つの絶対的な目的があるんだろうな
目的を解決する手段がいくつも有ること、ツールを使う目的はいくつも有ることに気付いていない
最低限そこに気付いてくれないと話しにならないよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:51:41.18

>>609
君のレスを引用すると「Dockerは可搬性を高くするもの」
これがDockerが考えている目的なわけだ(というか君の脳内のDocker社の考える目的というべきか)

じゃあ可搬性を高くしてどうするんだ？
その先の目的がまだあるだろ？
その目的は利用者が抱える課題によって様々なんだよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:52:12.52

> キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ

自分で言ってる通りじゃないかｗ
Dockerの目的は高い可搬性を作る所まで。

Dockerを利用するってことは、別に作業があるんだろ？
その作業の目的が開発環境を構築することであって
Dockerを使う目的ではない

キミ、物事の本質を捉えられるようにならないとダメだよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:53:24.28

>>611
> じゃあ可搬性を高くしてどうするんだ？
> その先の目的がまだあるだろ？

その先の目的？金を稼ぐってことかいな？
その理屈で言えば、どんな道具も目的は同じになるなｗ

**デフォルトの名無しさん** · 2018/10/13(土) 23:58:24.68

今置かれてる状況がある
また解決したい何らかの問題がある
そして解決する手段が複数ある

ここまできて比較検討しないって言っちゃなんだけど技術者失格だろう?

非常に幸運で何らかのテクノロジ一択で業務全部をカバーできる
なんて状況でもなければ必ず比較検討が必要になる

**デフォルトの名無しさん** · 2018/10/14(日) 00:00:31.63

>>614
お前が物事の本質をわかってないだけ。

Dockerの目的は可搬性を上げるためだし、
テキストエディタの目的はテキストファイルを編集するもの

開発環境を作るために、テキストエディタを使うだろと
いくら吠えたって、テキストエディタの目的が開発環境を作ることにはならないのと
同じようにDockerの目的は開発環境の作成ではない

**デフォルトの名無しさん** · 2018/10/14(日) 00:04:44.32

>>612
>Dockerを利用するってことは、別に作業があるんだろ？
>その作業の目的が開発環境を構築することであって
>Dockerを使う目的ではない

開発環境構築は間違いなくDockerを使う目的の1つ

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」

自然だね

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「そんなのはDockerの目的じゃない！」

アホかこいつ

**デフォルトの名無しさん** · 2018/10/14(日) 00:06:49.52

>>613
極論すればそうだな

どんな道具にも複数の利用目的が存在する
どんな目的にも解決手段は複数有る

だから比較検討するんだよ

**デフォルトの名無しさん** · 2018/10/14(日) 00:10:20.62

>>615
道具の目的は作成者や利用者の認識によって様々
テキストエディタの主目的は確かにテキストの編集だろう
だが目的はそれだけではなく人によってことなる
"誰か"の目的を押し付けるべきではない
"おまえ"の目的が全てではない
まずはこの基本的な事実から理解してくれ
話しにならないから

**デフォルトの名無しさん** · 2018/10/14(日) 00:10:43.24

> A「なんのためにDockerを採用したの?」
> B「開発環境構築のために採用しました」

採用と目的は意味が違う
はい論破ｗ

ジョークかよｗ
なんでこんな簡単な指摘をせにゃならんのだ

**デフォルトの名無しさん** · 2018/10/14(日) 00:11:59.29

ほんとさっきからDockerの目的を
違う話にすり替えようとしてるな。
バレバレやで

**デフォルトの名無しさん** · 2018/10/14(日) 00:13:40.14

>>619
「なんのために」って読めなかった？外国人？

**デフォルトの名無しさん** · 2018/10/14(日) 00:14:12.92

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

普通は後期着替え得される

**デフォルトの名無しさん** · 2018/10/14(日) 00:15:15.24

>>620
すり替えてるのはAn0DfPZDだな
Dockerの利用目的などいくらでもあるのに、開発目的の1つでしかない高い可搬性を唯一絶対の目的のように、こいつはすり替えようとしている

**デフォルトの名無しさん** · 2018/10/14(日) 00:15:16.71

例えて言うなら

A「なんのために○○工法を採用したの?」
B「建造物構築のために採用しました」

こう言ってるようなもん

**デフォルトの名無しさん** · 2018/10/14(日) 00:21:29.05

>>622
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

B「開発環境構築手段としてはVagrantやローカル環境へのバッチ処理適用などが候補に上がりました。
弊社の置かれる状況を踏まえて、それらを比較検討した上で、これこれこういうメリットがあると判断して、採用しました」

普通はこうなる
比較検討なんかしない、などというバカだったら採用理由にも説得力がなかっただろうね

開発環境に限った話ではないが、何かを決めるにあたって、検討した選択肢と採用した理由は関係者に対して必ず説明するものだ
業務で開発したことが有るならアタリマエのことだと思うが
もしかしてキミ仕事で開発したこと無い？あるいは一人で開発してるとか？

**デフォルトの名無しさん** · 2018/10/14(日) 00:28:27.93

>>625
> 普通はこうなる

前言撤回かよｗｗｗｗ

俺が間違いを指摘した後に慌てて後付して書くなって
ほんと恥ずかしいやつやなｗ
だいたい、その「これこれこういう」の中身が目的やろうが？

ちゃんと書けよ。Dockerを使うことで可搬性が高くなるというメリットがあるので
その目的のためにDockerを採用しましたって

**デフォルトの名無しさん** · 2018/10/14(日) 00:36:36.30

>>626
>「これこれこういう」の中身が目的やろうが？
「これこれこういう」は利用者の状況や課題によって様々
だから比較検討して答えをだすって何度もレスしとるだろうが
いい加減少しは理解してくれ
話しにならないとはまさにこのこと

**デフォルトの名無しさん** · 2018/10/14(日) 20:01:17.80

なんか話が難しくなってきましたね
ひとまず、docker軽いですよ、vagrantに比べて
buildはややかかるけど、終わってしまえば、起動もさくっといきますよ

**デフォルトの名無しさん** · 2018/10/14(日) 22:23:03.56

何に使えるかと、何のための道具かってのをごっちゃにしてるやつのたわごとだからな。
Dockerはアプリケーションを仮想化するために作られた道具

その道具を使って金儲けができるからって、
いろんなものをごっちゃにしたらダメだって話

**デフォルトの名無しさん** · 2018/10/14(日) 22:25:54.86

>>628
> ひとまず、docker軽いですよ、vagrantに比べて
vagrantは開発環境を作る道具にすぎない。
Dockerと比べるものじゃない。

比較するならば、ホストマシンでアプリを動かす vs 仮想マシンでアプリを動かすだろ
ホストマシンでアプリを直接実行するほうが、仮想マシン上でアプリを動かすよりも軽い
といわれても当たり前でしか無い

**デフォルトの名無しさん** · 2018/10/15(月) 00:07:39.55

うん、だからdockerの方が軽いんだよね？
当たり前でも何でも実際軽くて便利なんだからいいじゃないか

**デフォルトの名無しさん** · 2018/10/15(月) 00:41:31.13

そりゃ仮想マシン使うよりも仮想マシン使わないほうが軽いだろう。
仮想マシン使わないで、普通にパッケージをインストールすれば良い

普通にパッケージをインストールすればいいのに
なぜDockerを使うのか？それこそがDockerを使う目的

**デフォルトの名無しさん** · 2018/10/15(月) 18:32:47.56

課題を解決する手段が複数ある
それぞれ一長一短で状況により正解は異なる
なので比較検討してどれを採用するか決める
これITに限らず一般常識ね

**デフォルトの名無しさん** · 2018/10/15(月) 18:36:41.86

んで、今話してるのは手段ではなくて
Dockerは何をする道具かということ
本質をちゃんと見れないと道具は正しく使えない

**デフォルトの名無しさん** · 2018/10/15(月) 18:41:05.65

周回遅れだね

Dockerの特性は正しく理解した上で比較検討しようという段階の話をしてるので付いてきて

**デフォルトの名無しさん** · 2018/10/15(月) 18:47:15.49

話を逸らすな。
Dockerはアプリケーションを仮想化する道具だって話をしてる

**デフォルトの名無しさん** · 2018/10/15(月) 18:55:53.84

お気の毒ですがそのような話をしているのはあなただけです
あなたはあなたが話ていることをみんなも話ているように錯覚しているようですが実は違うのです
まずは深呼吸して冷静になってください
会話が成立することを期待して待っています

**デフォルトの名無しさん** · 2018/10/15(月) 19:00:16.10

>>637
お前、自分が一人だってわかってないのか？
誰か他に同調してくれるやついるか？

**デフォルトの名無しさん** · 2018/10/15(月) 19:06:03.75

>>638
dockerとvagrant(あるいは他の方法論)を比較するという文脈のレスは私のレス以外にも幾つもありますね
比較するのはおかしいという主張はどうやらあなただけのようですが

**デフォルトの名無しさん** · 2018/10/15(月) 19:13:31.78

docker vagrant 比較
ぐぐったらたくさん出てきた
ちなみに
docker vagrant 比較するのはおかしい
ぐぐったら”おかしい”が除外されて検索された
こりゃ勝負有ったね

**デフォルトの名無しさん** · 2018/10/15(月) 19:18:29.88

>>639
それはお前の意見に同調してるわけじゃないだろｗ
頭悪いんちゃうか？

**デフォルトの名無しさん** · 2018/10/15(月) 19:19:27.50

だいたい、さんざん仮想マシンと比較って言ってくせに
vagrantに言い換えてるし
仮想マシンとvagrantの違いもわかってないようだ

**デフォルトの名無しさん** · 2018/10/15(月) 20:07:06.98

間を取ってLXCで

**デフォルトの名無しさん** · 2018/10/15(月) 20:30:22.20

間っていうか、LXCはシステムコンテナだから、Dockerで仮想マシンのような間違った使い方を
使い方をしようとしている人は、LXCを使うべきだよ

**デフォルトの名無しさん** · 2018/10/16(火) 00:27:22.18

PythonでJupyter Notebook使ったデータ解析環境をPC変更時に新PC上で手動で再現するのが面倒だからDocker上で動かすようにしてる

**デフォルトの名無しさん** · 2018/10/16(火) 00:30:53.46

Jupyter Notebookというアプリにそのアプリを動かすのに
必要なものを全部まとめてるわけだよね。
それが正しい使い方

**デフォルトの名無しさん** · 2018/10/16(火) 02:50:30.16

そもそも再現性気にするくらいならjupyter使うのが間違ってるけどな。

**デフォルトの名無しさん** · 2018/10/16(火) 03:32:28.53

また再現性とか誰も必要だと言ってない話をし始めたｗ

**デフォルトの名無しさん** · 2018/10/16(火) 21:22:37.51

再現性が必要ない？
それはなかなか斬新ですねw
そコマで頭の悪い意見が出るとは思ってなかった。

**デフォルトの名無しさん** · 2018/10/16(火) 22:04:16.59

Jupyter Notebookって試行錯誤を効率化するのが目的なんだから、再現性なんてDockerイメージで担保すればいいというのも、それはそれでありうる判断だろう。

環境独立な再現性があればあった方がいいって点には誰も異論はないと思うが、
それよりも試行錯誤の効率性の方が優先される用途もあるってだけの話だな。

**デフォルトの名無しさん** · 2018/10/16(火) 22:13:56.47

依存性の封じ込めも再現性もvagrantや別の方法でもできるので比較検討が必要