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

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

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

よろしこ

**デフォルトの名無しさん** · 2019/03/01(金) 08:42:16.02

Docker は本家 Linux でも本番環境だとわりとトラブるって話を1年くらい前に聞いたな。
利用は開発環境やステージング環境までにして
本番はネイティブにした方が無難なような。

**デフォルトの名無しさん** · 2019/03/01(金) 12:21:06.68

設定ミスの可能性もあるだろう
マネージドのDocker Hostをレンタルして同じ構成で動かしてみたらどうだ

**679** · 2019/03/01(金) 22:02:26.08

設定ミスの可能性は無いです

**デフォルトの名無しさん** · 2019/03/01(金) 22:40:15.67

確認した?
エビデンスとったか？

**デフォルトの名無しさん** · 2019/03/01(金) 22:55:07.01

tcpdumpの結果でわりと十分なエビデンスだろう。
突然パケットが流れなくなるような設定間違いってなかなかできない。

**デフォルトの名無しさん** · 2019/03/01(金) 23:02:50.07

>>684
全く「設定ミスがない」ことのエビデンスになってない
それじゃただ単に現象を確認しただけだ

**デフォルトの名無しさん** · 2019/03/02(土) 10:11:20.28

>>685
｢『全く』設定ミスがない｣ことのエビデンスなんて現実的なコストでは提供不能だよ。
特に設定不足系は無理。
ふつうはそんな効率の悪いやり方をしない。
まあ金融・証券系みたいにコスト無視、かつ顧客が無理難題をふっかけるとこだと、顧客が納得するレベルの嘘をついて誤魔化すことはあるけどさ。

**デフォルトの名無しさん** · 2019/03/02(土) 10:37:21.55

｢Docker network stopped working ｣でググるといっぱい見つかるね。
未解決のも多い。

ttps://github.com/moby/moby/issues/32195
なんかはSolved になってるけど
・(正常なネットワークなら問題ない筈の)先進的なネットワークオプションをとにかくdisableせよ
・Docker のバージョンを上げろ
ってなってて、Docker か、あるいは利用しているネットワーク環境のどちらかに不具合があるっぽい。

**デフォルトの名無しさん** · 2019/03/02(土) 11:08:33.63

>>686
俺がなんで括弧つけたかわかってないな

「全く設定ミスがない」こと証明してないと言いたいのではない
「設定ミスがない」ことを全く証明してないと言ったのだ

**デフォルトの名無しさん** · 2019/03/02(土) 11:27:53.49

>>688
ふつうは正しく動作することをもって証明とするんだよ。
数学的な意味での証明には全くならんが、現実的なコストでできる証明ってのはそれくらいしかないんだ。

くだんの人の場合、一応正しくは動作してるのに、しばらくすると止まる、しかもtcpダンプしても止まってるんだから、
症状からしてなにか不具合がある可能性が高い。

そうじゃない、証明する方法があるんだっていうのなら、その方法を具体的に書いてやってくれ。

**デフォルトの名無しさん** · 2019/03/02(土) 11:35:40.93

>>689
もうとっくに書いてんじゃん
マネージドなdockerホスト借りてやってみたらどうだってさ

何も設定項目1つ1つ変更しながらエビデンスとれって言ってるわけじゃないんだよ
適度なサイズのスコープで切り替えながら調査していくの
これって問題調査の基本中の基本だよね？

君が言ってる現実的じゃない方法って
アルゴリズムに例えて言うと線形探索なんだよ
でも俺らは二分探索とか範囲で絞り込むアルゴリズムを知ってるわけだろ？
なんで身につけた知識を応用しないんだ？

**デフォルトの名無しさん** · 2019/03/02(土) 11:50:11.02

>>690
マネージドなDockerホストって書いてた人だったのか。
確かにそれはアリだな。

俺の言葉の使い方だとそれを設定ミスがないことのエビデンスになるとは言わないので
マネージド環境でのテストのことを指してるとは思わなかったよ。
すまんかった。

よくよく考えてみるとアホな顧客にエビデンス要求された時に
有料サービスに丸投げした結果を提供してOKもらうことはたびたびあるので
自分でも似た使い方してたなw
自分でそれがエビデンスという強い言葉に値すると思ってないから思いつかないんだなあ。

**デフォルトの名無しさん** · 2019/03/03(日) 14:34:26.16

issueだらけだもんなぁ
本番には到底耐えきれないよ
本番で使わないならってんで開発でもDockerを使わなくなる
だから実務で役に立つのはVagrantとAnsibleになる

**デフォルトの名無しさん** · 2019/03/03(日) 14:43:33.70

>>692
issueの数で判断できるなら、世の中のメジャーなライブラリやフレームワークはみな使えないことになる

**デフォルトの名無しさん** · 2019/03/03(日) 15:04:33.53

ライブラリやフレームワークに不具合があってもアプリケーションとしてのテストを通過すれば問題はない
でもDockerみたいなのになるとテストしきれないから安易に使えない

**デフォルトの名無しさん** · 2019/03/03(日) 15:07:54.94

>>694
はいキチガイ

**デフォルトの名無しさん** · 2019/03/03(日) 15:11:25.80

>>695
いや常識だぞこれ
お前はテストしとらんのか？

**デフォルトの名無しさん** · 2019/03/03(日) 15:45:08.26

>>696
ソースは？

**デフォルトの名無しさん** · 2019/03/27(水) 18:59:14.57

>>697
Rubyかな

**デフォルトの名無しさん** · 2019/03/27(水) 22:21:53.24

ansible-containerってどうなの？

**デフォルトの名無しさん** · 2019/04/07(日) 22:47:05.10

初心者なんじゃがコンテナ内のphpmyadminから別コンテナのMySQL叩くの難易度どれくらい？

**デフォルトの名無しさん** · 2019/04/08(月) 12:14:30.85

難度Fぐらいかな

**デフォルトの名無しさん** · 2019/04/08(月) 19:16:29.83

USB Type Aが一発で刺さるぐらいの難易度

**デフォルトの名無しさん** · 2019/04/08(月) 21:09:35.64

本当かぁ、？何回かネットや本のコピペしてるけどMySQLとphpmyadmin連携取れないぞ、？

**デフォルトの名無しさん** · 2019/04/08(月) 21:24:00.34

composeのサンプルコピペでいけるやろ

**デフォルトの名無しさん** · 2019/04/08(月) 22:14:51.00

>>704
この後またチャレンジするんだけど皆さん普通に連携取れて出来てるのよね？
本の丸コピが何回やっても動かないし何かMySQLの認証系が怪しいんだが

**デフォルトの名無しさん** · 2019/04/08(月) 23:23:24.47

compose見せてみ

**デフォルトの名無しさん** · 2019/04/09(火) 20:27:46.01

すまん、、そこまでまだ本を読み進めてないでんねん。。下記が本のソース丸コピなんだが
////phpmyadmin編
//_mysqlとphpmyadminのDockerfile用の２つのフォルダ作成
sudo docker network create mysql-nw
sudo docker volume create --name=db-volume
sudo docker run -v db-volume:/var/lib/mysql/ --name=db-container busybox

//////mysql/Dockerfile
#イメージ取得
FROM mysql
#mysqlのrootパスワード設定
ENV MYSQL_ROOT_PASSWORD=dbpass01
#文字コードにutf8mb4をセット
CMD ["mysqld","--character-set-server=utf8mb4","--collation-server=utf8mb4_unicode_ci"]
//////
sudo docker build -t mysql-image .
sudo docker run --volumes-from=db-container --name=mysql-container --net=mysql-nw -d mysql-image

//////phpmyadmin/Dockerfile
#イメージ取得
FROM phpmyadmin/phpmyadmin
#
ENV PMA_HOST=mysql-container PMA_USER=root PMA_PASSWORD=dbpass01
//////

sudo docker build -t pma-image .
sudo docker run --net=mysql-nw --name=pma-container -p 83:80 -d pma-image

**デフォルトの名無しさん** · 2019/04/09(火) 20:29:44.42

ちなみにこれも三行丸コピで動くらしいけど失敗したやつでなぁ
https://blog.thenets.org/how-to-install-mysql-and-phpmyadmin-with-docker/

**デフォルトの名無しさん** · 2019/04/09(火) 21:25:20.32

docker logsは？

**デフォルトの名無しさん** · 2019/04/09(火) 21:34:32.10

CMD["mysqld"
とりま要らんやろこの引数

**デフォルトの名無しさん** · 2019/04/09(火) 22:23:24.21

すんまへん、、何故かイケました。メモ帳に書いてコピペしてるからそう書き間違えないはずなんだがなぜかこれで
//phpmyadmin再度
sudo docker pull mysql:5.7.24

sudo docker pull phpmyadmin/phpmyadmin

sudo docker network create mysql-network

sudo docker run --name=aa-mysql --net=mysql-network -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -v $(pwd)/database:/var/lib/mysql -d mysql:5.7.24

sudo docker run --name=a-mysql-admin --net=mysql-network -e MYSQL_ROOT_PASSWORD=password -e PMA_HOST="aa-mysql" -e PMA_PORT=3306 -p 8081:80 -d phpmyadmin/phpmyadmin

**デフォルトの名無しさん** · 2019/04/09(火) 22:24:25.42

ちなみにこれはなぜか動かなかった
//1
sudo docker network create -d bridge my-bridge-network
//2
sudo docker run --name mysql -e MYSQL_ROOT_PASSWORD=secret -d mysql/mysql-server

sudo docker network connect my-bridge-network mysql

sudo docker inspect mysql//次のhostに付けるip確認
//3
sudo docker run --name phpmyadmin -d -e PMA_HOST=(さっきのIP) -p 808:80 phpmyadmin/phpmyadmin

**デフォルトの名無しさん** · 2019/04/20(土) 09:43:35.04

クラスタ運用だとボリュームの扱いが難しい

ネットワーク経由でストレージをマウントすると遅いし所有権やシンボリックリンクの取り扱いでトラブルが起きやすい
逆にローカルストレージをマウントするとコンテナを特定のホストにピン留めせざるをえなくなって運用性が悪い

どうにかならんかねこのジレンマ

**デフォルトの名無しさん** · 2019/04/20(土) 10:01:01.50

>>713
だからクラウド使うんだよ

ストレージはクラウドサービスが提供しているものを使う
ストレージ用のコンテナは作らない

**デフォルトの名無しさん** · 2019/04/20(土) 10:02:10.88

（ただし開発時にローカルで使うものは別）

**デフォルトの名無しさん** · 2019/04/20(土) 11:37:12.99

クラウドストレージでも結局は同じなのでは？
例としてS3をVolumeとしてマウントしたとして
このVolumeはローカルストレージのVolumeよりも遅いしパーミッションとかで変なトラブルが起きやすい
この性質はイントラのストレージサービスとクラウドのストレージサービスでそう違いがあるとは思えない

**デフォルトの名無しさん** · 2019/04/20(土) 12:03:01.10

S3じゃなくてEBSじゃないのか？

**デフォルトの名無しさん** · 2019/04/20(土) 12:04:41.14

>>716
だからボリュームとしてマウントしたりしない。

アプリはデータをS3に保存するし、S3から取ってくる。
パーミッションとか関係ない。クラウドのセキュリティ機能を使う
クラウドストレージの速度はローカルストレージと遜色ない（コストによるが）

**デフォルトの名無しさん** · 2019/04/20(土) 12:07:44.19

> アプリはデータをS3に保存するし、S3から取ってくる。

補足しておくとアプリはS3のデータを読み書きするとして、

例えばユーザーはファイルをサーバーにアップロードする時、
S3に直接アップロードするしS3から直接ダウンロードする。
アプリを経由してS3のファイルを読み書きしたりしない（してもいいが遅い）

誰でもアップロード・ダウンロードできてしまうことを
防ぐためのセキュリティ機能もS3にある

**デフォルトの名無しさん** · 2019/04/20(土) 12:13:00.81

>>717
EBSを使ってもいいが、アプリの仮想マシンからブロックデバイスとしてマウントはしないんだよ。
EBSをマウントするのは（広い意味での）データベース・サーバーの一台

アプリからは、そのデータベースサーバーに対してネットワークでデータを読み書きする

複数あるアプリの仮想マシンでファイルシステムをマウント（Dockerのボリューム含む）しようという発想が古い
ストレージをマウントするのは仮想マシン1台だし、そこにネットワーク経由でアクセスする。
↑このストレージをバックアップなど含めて適切に管理するのが面倒だから、クラウドストレージを使う

いずれにしろ、アプリからはネットワーク経由でデータの読み書きをする

**デフォルトの名無しさん** · 2019/04/20(土) 12:16:17.88

>>717
例として挙げただけなのでどのストレージサービスでも状況は同じ

>718
ストレージサービスをネイティヴサポートしてない他社製アプリはVolumeマウントするしかないと思うけど違うのかな？
オープンソースならフォークしてファイルアクセスを全てストレージサービスに置き換えることはできなくはないけど労力に到底見合わない
だからどうしてもVolumeマウントに頼らざるをえないケースは多々ある
そういうケースにステートフルコンテナをクラスタに組み込むにはどうするべきか悩ましい

**デフォルトの名無しさん** · 2019/04/20(土) 12:23:55.77

>>721
だからな？新しい仕組みを活かそうと思うなら、
設計から見直さなきゃいけないんだよ。

効率化する新しい仕組みを導入したいのですが
今までの効率の悪いやり方まま変えたくないんです。

↑アホみたいだろ？

やり方を変えないなら、今までのやり方をするしか無いんだよ。
諦めな

**デフォルトの名無しさん** · 2019/04/20(土) 12:44:59.88

>>722
設計を見直すと言われても他社製だからな…
従来のようにバックアップとリストアをしっかり整備して多少のリスクを受け入れるぐらいしか思い浮かばん
ダウンタイムはともかく直近のデータロストは怒られそうできつい

**デフォルトの名無しさん** · 2019/04/27(土) 15:43:09.76

docker hubがハックされてgitアカウントが１９万ぐらい失効されたらしい？

**デフォルトの名無しさん** · 2019/04/27(土) 16:16:17.11

それマ？

**デフォルトの名無しさん** · 2019/04/27(土) 17:32:00.76

取り急ぎググった結果出てきたものを貼ってみる

https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/

By Lawrence Abrams
April 26, 2019 11:30 PM

**デフォルトの名無しさん** · 2019/04/28(日) 22:00:11.04

dockerのGUIでの監視や起動停止とかでまだまともなのないかね？

**デフォルトの名無しさん** · 2019/04/28(日) 22:10:41.17

portainer?

**デフォルトの名無しさん** · 2019/05/02(木) 11:48:40.72

DockerってEEにするとなんか嬉しいの？

**デフォルトの名無しさん** · 2019/05/28(火) 09:41:24.81

>>729
サポート

**デフォルトの名無しさん** · 2019/06/06(木) 12:33:59.71

5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？
VagrantfileとDockerfileのどちらが簡単かという話になるのかな？

**デフォルトの名無しさん** · 2019/06/06(木) 20:02:59.18

そりゃあVagrantだろ
変なトラブルが少ない
開発デスクトップも仮想化できる
環境の再現性がたかい
Linux+Windows混在も楽々

ただしターゲットがDockerの場合に限りローカル鯖もDockerにした方がいい
それは当然のことだな
その場合でも開発デスクトップはDockerを使わないほうがいい

**デフォルトの名無しさん** · 2019/06/06(木) 21:31:04.71

開発に使えないものを本番環境に投入とか論外なわけで
Dockerの使いどころが...
(それを言っちゃあおしまい)

**デフォルトの名無しさん** · 2019/06/06(木) 21:50:38.63

使えるか使えないかの問題じゃなく楽かどうか
本番でDockerを使わないなら本番環境はDockerへの配慮なんてしてない構成になってるはず
その構成をローカルに再現するときにDockerを使うかVagrant/Ansible使うのどっちが工数少ないかってことだ
少なくとも本番環境の構築手順書があるのだから完全仮想化環境で同等の環境を再現するのはさほど難しくない
しかしDockerだとどうしても構成の整理と手順書の読み替えと動作確認が求められてくるので面倒だ

**デフォルトの名無しさん** · 2019/06/06(木) 22:06:41.88

なるほど

**デフォルトの名無しさん** · 2019/06/06(木) 22:37:50.73

>>731
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

何度も言ってるが、仮想マシン（Vagrant）とアプリ仮想化（Docker）は
組み合わせて使うものです！

どちらか一方を使うんじゃない。役目が違うんだから両方使う

**デフォルトの名無しさん** · 2019/06/06(木) 22:53:48.83

大前提としてな。開発環境と本番環境は同一に出来ないんだよ。
可能不可能の話じゃなくて、そんな事やるやつは馬鹿という意味で同一に出来ない

開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境には便利なテキストエディタやIDE、ヘッダファイル、静的解析ツール
その他便利なコマンドなど、いろんなものを入れる必要がある。

それに対して本番環境はそれらは入れない。セキュリティリスクにつながるし
メンテナンス性も考えなるべく小さなイメージにしておく

開発環境と本番環境は同一でないという前提で、
開発環境でどうやってテストするか？という話が出てくる
本番環境に近い環境でないとテストに自信が持てないのは当然

そこでDockerがでてくるんだよ。開発環境で動かすDockerコンテナと
本番環境で動かすDockerコンテナを同一に（もしくは限りなく近く）することで
開発環境と本番環境が違っていても、信頼性のあるテストが実行できる

そうするとDockerコンテナさえ同じであれば、開発環境を統一する意味もなくなる
開発環境がLinuxであってもWindowsであってもMacであっても、
同一のDockerコンテナを使うのだから、信頼性のあるテストが実行できる

だから今はVagrantを使って開発環境を統一するメリットが減ってる。
統一したいならしてもいいが（それは開発者の自由を奪うというデメリットでもある）
統一しなくても良いのが今の開発

**デフォルトの名無しさん** · 2019/06/06(木) 22:59:53.57

>>737
本番環境が全てDockerという幻想の上でしか成立しないな
本番環境がDockerでないなら開発環境でDockerを使うと逆に再現性が低下する

**デフォルトの名無しさん** · 2019/06/06(木) 23:00:18.06

最初の質問に戻るとだな

> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

「ローカル開発環境を同じにしたいならVagrantを使う」
それと同時にDockerも使う

Dockerを使うなら、ローカル開発環境を同じにする意味はさほどない
同じにしないなら Vagrantを使わなくて良い。Dockerだけ使う

これは「ローカル開発環境を同じにしたい場合にDockerが楽」と言ってるのではなくて
「ローカル開発環境を同じにしないならVagrantはいらない」という意味
だから「ローカル開発環境を同じにしたいならVagrantを使う」ということは否定していない

使う目的が違うのだから、どちらを使うか？っていう話にはならない

**デフォルトの名無しさん** · 2019/06/06(木) 23:01:01.11

漏れは、Chef

**デフォルトの名無しさん** · 2019/06/06(木) 23:02:43.90

>>738
もう今は本番環境でDockerを使うのは常識

仮に本番環境でDockerを使わないとしても、
本番環境と同じ環境をDocker以外で作るのは困難

開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
２つを作るのは重いだけ

**デフォルトの名無しさん** · 2019/06/06(木) 23:04:50.40

訂正

開発環境用VM（Vagrant）と本番環境"再現用"VM（Vagrant）の
２つを作るのは重いだけ

本番環境用VMといってしまうと、これを本番環境で使うように思えてしまうので訂正
実際の本番環境はVagrantでは作らないので、本番環境そのものにはならない
高い再現性を求めるなら、開発環境でも本番環境でもDockerを使うのがベスト

**デフォルトの名無しさん** · 2019/06/06(木) 23:07:20.25

開発環境と本番環境が違っていても
Dockerコンテナは同じですよーっていうのが
Dockerを使うメリットなわけだ

**デフォルトの名無しさん** · 2019/06/06(木) 23:28:00.71

>>741
そんな常識ないよ
あほくさ

**デフォルトの名無しさん** · 2019/06/06(木) 23:37:25.82

根拠なく、ないよとか言われてもなｗ

**デフォルトの名無しさん** · 2019/06/06(木) 23:39:58.31

>>745
お前が言うのかそれ

**デフォルトの名無しさん** · 2019/06/06(木) 23:41:53.19

kubernetesとかほぼDocker前提だし

**デフォルトの名無しさん** · 2019/06/06(木) 23:43:28.93

vagrantは "開発環境を作るためだけ" のものだが
Dockerはソフトウェ開発全般で使う

**デフォルトの名無しさん** · 2019/06/06(木) 23:45:35.65

k8sのdocker依存は解消されたって聞いてたんだけど…？

**デフォルトの名無しさん** · 2019/06/06(木) 23:46:54.32

Vagrantはこれから使われなくなっていくよ。俺はもう使ってない。
ローカル開発環境を同じにしたい場合にはたしかに便利だが、
ローカル開発環境を同じにする必要がなくなってきてる。
そういう意味ではVagrantを使わないほうが良いと言える。

**デフォルトの名無しさん** · 2019/06/06(木) 23:47:29.19

>>749
依存してなくても事実上Dockerを使うのが現時点ではベストという話

**デフォルトの名無しさん** · 2019/06/06(木) 23:51:42.77

>>748
Vagrantは本番環境でも使えるしDockerを使わない開発も未だに無数にある
Dockerのメリットは確かに大きいがそれなりのデメリットも同時に抱え込んでしまう
Dockerでやるべき明確な理由がないなら使う必要はない

**デフォルトの名無しさん** · 2019/06/06(木) 23:55:24.99

> Vagrantは本番環境でも使えるし
使えるが使わん。

**デフォルトの名無しさん** · 2019/06/06(木) 23:56:47.52

https://www.vagrantup.com/
Development Environments Made Easy
^^^^^^^^^^^^^^^^^^^^^^^^^^^

「開発環境を簡単に」と書いてあるんだから
本番環境で使おうとするな。想定外の使い方だ

**デフォルトの名無しさん** · 2019/06/07(金) 00:01:11.20

Dockerの使い方でも変なやつがいるけど
本来想定してない用途なのに、使えそうだから使おうというのは
その技術を正しく理解してない証拠なんだよな

**デフォルトの名無しさん** · 2019/06/07(金) 00:04:50.40

VagrantにできてDockerではダメな典型例だとAnsibleなど構成管理ツールの開発・テスト環境を作るときなどがあるね
当たり前だけどOSの様々な機能が制限されるコンテナは仮想マシンの代替にはなりえない

**デフォルトの名無しさん** · 2019/06/07(金) 00:10:21.60

だからVagrant（というよりVM）とDockerはどちらかを使うものじゃなくて
両方組み合わせて使うものだという話になる。

AnsibleのテストするならVMを使うのが一番。各クラウドやKVM等ね。

というかAnsibleのテストでVagrantなんて使うか？
Vagrantで作ったらVagrantユーザーがいるわけで、
それは本来のAnsible実行対象マシンとは違うものになる。

**デフォルトの名無しさん** · 2019/06/07(金) 00:14:22.59

× コンテナは仮想マシンの代替にはなりえない
○ （アプリケーション）コンテナはそもそも仮想マシンの代替として作られたものじゃない

**デフォルトの名無しさん** · 2019/06/07(金) 00:20:56.20

>>757
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない

>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない

**デフォルトの名無しさん** · 2019/06/07(金) 00:32:52.21

あぁ、なるほど。素晴らしい気付きがあった。

Ansible（Chefなども同様だろう）を使うといった時、
playbookを作るのと playbookを実行するという2つの段階がある

playbookを作る場合は、当然テストが必要なわけだがVagrantが便利。
なぜならVMを特定の状態にして何度もplaybookをやり直すから。
具体的にはsnapshotの機能を使う（最初からvagrant boxを作り直すのもあり）

でもこれって、Ansibleに内蔵されているべき機能ではないだろうか？
Vagrantで作るVMと本番環境のVMは違っている。
本当は本番環境（を複製して）を何度も同じ状態にしてテストを実行したいはずだ
通常、本番環境のVMの構築にVagrantは使わない。Ansibleを使って構築するだろう。
ならば、Ansibleだけで本番環境のVMのスナップショットを取れたほうが良いだろう。

今はそれが出来ないからVagrantを使っている。
なるほど、これは良い発見だ！

（独り言）

**デフォルトの名無しさん** · 2019/06/07(金) 00:33:40.26

>>759
> だから君のDocker万能論はちゃんちゃらおかしいということだよ

何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ？

**デフォルトの名無しさん** · 2019/06/07(金) 00:34:23.77

> 全部DockerでOKなんてことはありえない

そんなこと言ってない。

何度も何度もVMと組み合わせて使うって言ってるのに

**デフォルトの名無しさん** · 2019/06/07(金) 00:45:32.53

そうだな万能論は言いすぎた
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない

**デフォルトの名無しさん** · 2019/06/07(金) 00:53:40.24

>>763
やっぱり素でDockerを理解してないんだな・・・

> しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
Dockerはアプリケーションとユーザーランドを一体化させて
一つのアプリケーションのように仮想化するためのものであって
Ansible（構成管理ツール）とDocker（アプリ仮想化）を組み合わせて使うことがそもそも間違い。

俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張？俺が何を主張したっていうんだ？

**デフォルトの名無しさん** · 2019/06/07(金) 00:57:44.41

>>764の組み合わせて使うっていうのは、

DockerをVM（Vagrant）のようの代わりに使って
DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方

Ansibleを使ってVMの構成管理を行い、その一つとして
Dockerコンテナを起動するっていう使い方は問題ない。

俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない

**デフォルトの名無しさん** · 2019/06/07(金) 01:00:45.47

結局俺じゃなくてお前が

DockerをVM（Vagrant）の代わりに使おうとして
DockerはVM（Vagrant）の代わりとしては使えない！って
独り相撲してるだけじゃんか

俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。

**デフォルトの名無しさん** · 2019/06/07(金) 01:01:19.38

>>764
君の主張は自分のレスを読み返したら？
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ

**デフォルトの名無しさん** · 2019/06/07(金) 01:02:31.60

>>767
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない

**デフォルトの名無しさん** · 2019/06/07(金) 01:03:25.33

>>768
ID: XICm～のレスを読み返して

**デフォルトの名無しさん** · 2019/06/07(金) 01:04:03.86

例として一つ出すなら

>>737で
> 開発環境はVagrantで作るが本番環境はAnsibleなどで作る

開発環境はVagrantで作るとはっきり言っている

**デフォルトの名無しさん** · 2019/06/07(金) 01:05:19.99

>>769
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ

**デフォルトの名無しさん** · 2019/06/07(金) 01:07:46.29

>>770
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張

**デフォルトの名無しさん** · 2019/06/07(金) 01:09:11.49

> で、そのレスの後半でDockerを使う話に持っていってるよね

ぽかーんｗ

スレの前半でDockerを使わない話してるよね？
お前、スレの後半しか読んでないの？
スレの後半だけで判断しちゃった？ｗ

**デフォルトの名無しさん** · 2019/06/07(金) 01:10:05.02

>>771
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない

**デフォルトの名無しさん** · 2019/06/07(金) 01:11:18.46

>>774
それで？

**デフォルトの名無しさん** · 2019/06/07(金) 01:12:44.93

>>773
後半を主張するための前振りだろ？
だって君の主張はDockerありきが世界の常識だもんな

**デフォルトの名無しさん** · 2019/06/07(金) 01:14:11.19

>>776
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる

お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。

**デフォルトの名無しさん** · 2019/06/07(金) 01:17:08.93

＞もう今は本番環境でDockerを使うのは常識
＞
＞仮に本番環境でDockerを使わないとしても、
＞本番環境と同じ環境をDocker以外で作るのは困難
＞
＞開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
＞２つを作るのは重いだけ

ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか

**デフォルトの名無しさん** · 2019/06/07(金) 01:17:57.25

> Ansibleの本番環境と同じ環境もDockerで作るんだ

また俺が言ってないことを言い出した。

**デフォルトの名無しさん** · 2019/06/07(金) 01:19:09.37

>>777
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる