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

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

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

よろしこ

**デフォルトの名無しさん** · 2017/10/15(日) 12:51:15.75

俺もansibleはゴミって昔から主張してるけど、なぜかありがたがって使う人がいる
互換性酷い、yaml生産性悪い、かゆいとこ手が届かんで最悪
docker & ssh & shell scriptが最強
この組み合わせなら、誰でも使えるし、可能性も無限大
KISSの原則ってやつだな
dockerはどうなるかわからんがssh & shell scriptは長く安心して利用できる点も高評価

**デフォルトの名無しさん** · 2017/10/15(日) 13:48:47.99

>>139
> 互換性酷い、yaml生産性悪い、かゆいとこ手が届かんで最悪
それな。

使うために "中間層" が必要なるという仕組みが悪い
アプリのインストールや設定とか普段シェルスクリプトでやってるはず

だけどAnsibleとかそのアプリをインストールするためのプラグイン（中間層）が必要になる。
それをアプリが公式に用意しているならまだマシだけどそれは少数派
Ansibleがどれだけ成長したとしても、アプリに完全対応はできない。
バージョンが変わるたびにこの組み合わせで正しく動くだろうか？って考えなきゃいけない。

そしてプラグインを使うための知識が必要になる。
普段シェルスクリプトでやってるのと同じことをやるだけなのに
別の知識と道具が必要になる。

あとYAMLは本当に設計ミスだと思う。
構成っていうのは一連の流れで作るものなので
スクリプトの方が適切。

**デフォルトの名無しさん** · 2017/10/15(日) 14:23:35.60

ansibleはmodule使ってる限り冪等なのがいいんだろ

そして、yamlもそこまで悪くない
docker-composeでも使うし、生産性低いならきちんと訓練すべきだと思う

**デフォルトの名無しさん** · 2017/10/15(日) 14:40:41.95

> ansibleはmodule使ってる限り冪等なのがいいんだろ

「使ってる限り」と言ってる時点で駄目なんだよ。
なぜmoduleを使う？自分で作ればよかろう？
もちろん作るのが大変だから使うのだろうがそれで起きてるのが互換性問題。

アプリ開発社からすればAnsibleや誰かが作ってる
非公式の質の低いモジュールを使わざるを得ない
ここでいう質の低いっていうのは、アプリのあるバージョンに
完全に対応していなかったり一部の機能が抜けていたりする。
そしてそれを自分で直さないといけなくなる

Dockerの場合はモジュールなどというものはなく自分でDockerfileを作るのが基本
もちろんある程度用意されているがほんの数行のファイルなので自分でメンテナンスできる。

> そして、yamlもそこまで悪くない
YAMLが悪いと言っているのではない。設定として使うのは問題ない。
構成管理のように順番があってその通りに実行していかなければいけないものを
YAMLという順番が関係ないようにみえる形式を使うのがダメだという話
やってることがスクリプト実行ならスクリプトで書けば良いんだよ。
設定とスクリプトは違うもの。

**デフォルトの名無しさん** · 2017/10/15(日) 16:06:17.00

まぁ、そんなこと言い始めたらshなんて可読性も低いしpythonのほうがいいとかになるんだよね
少なくとも個人が書いたスクリプトより、ansibleのmoduleのほうが信頼性は高いよ
DockerだってFrom句使うほうが普通だろ
なんで、どっちかはダメと攻撃せずにいられないのか
酸っぱい葡萄が大好きなんだな

**デフォルトの名無しさん** · 2017/10/15(日) 16:14:25.83

> まぁ、そんなこと言い始めたらshなんて可読性も低いしpythonのほうがいいとかになるんだよね
> 少なくとも個人が書いたスクリプトより、ansibleのmoduleのほうが信頼性は高いよ

意味が分からん。ごく普通にシェル使ってインストールとかしてるだろ？
もしかして黒い画面恐怖症かなにかか？

スクリプトは単純に何かのインストールコマンドと
ファイルの変更ぐらいしかしないよ。
なんでいつもやってる作業を置き換えないといかんのさ

**デフォルトの名無しさん** · 2017/10/15(日) 16:15:43.59

> DockerだってFrom句使うほうが普通だろ
From区にはdebianとかrubyとかしか使わんなぁ。
公式で用意されていればそれ使うけど、
用意されてないならされてないで
自分でDockerfile書くだけだし。

**デフォルトの名無しさん** · 2017/10/15(日) 16:16:17.65

っていうかFrom区ってなんだｗ
FROMだろ

**デフォルトの名無しさん** · 2017/10/15(日) 16:27:35.49

誰が書いたかも知らないようなmoduleは危険だぞ
人類はnpm left-padで痛い目にあったばかりじゃないか

**デフォルトの名無しさん** · 2017/10/15(日) 16:29:20.49

それな、DockerとAnsibleの違い

Ansibleは自分でやるべきことを誰かにやらせて楽をする。
Dockerは自分でやるべきことを自分でやるがその作業が楽になる。

誰かにやらせて楽をする方がいいかもしれんが、
それはその誰かが信用できる場合だけなんやで。

**デフォルトの名無しさん** · 2017/10/15(日) 17:31:51.97

>>145
あ、そうなんだ。そういう人にとってはansibleのモジュールは使いにくいかもね。
一般的にはnginxとかフレームワークくらいは使うと思うけど。
てか、yml書くのだってvimが普通なのに、なんでsh書かないとterminal恐怖症なんだよ
意味わからん

**デフォルトの名無しさん** · 2017/10/15(日) 17:44:48.24

てか、ansibleもDockerも同じ
なくてもどうにかなるんだけど、使える人は使う
使えない人は使わないし、使いたいとも思わない
そんだけ

**デフォルトの名無しさん** · 2017/10/15(日) 18:06:11.48

ansibleは生産性下げてるよ
fabricとかでいいじゃないか
ああいうのでいいんだよ、ああいうので

**デフォルトの名無しさん** · 2017/10/15(日) 18:19:59.49

>>149
Ansibleのモジュールはシェルスクリプトでできることの
全てを網羅してないっていうのが一番の問題なんだよ。

nginxがバージョンアップした時、新しく追加された設定項目に
モジュールはすぐに対応してくれない。

シェルを使っていればすぐできることが
Ansibleだと対応する機能をいちいち調べて
シェルとは違う方法で記述しないといけない。

その中間の変換作業が無駄

それに当然の話だけど、Ansibleは自社で開発しているアプリ用の
モジュールが存在しない。作らないといけない。
おかしいと思わないのかね？シェルですでにやってる作業と同じことを
調べ直す作業を何故やっているのかと

あー、もちろんAnsibleでシェルスクリプトを実行できるのは知ってるよ。
そんなのを使うならシェルスクリプトでいいじゃんって話だからね。

**デフォルトの名無しさん** · 2017/10/15(日) 19:00:33.44

それでいいんじゃね？
別に使わないとできないことはないよ
でもそれはshellだろうがDockerだろうがAnsibleだろうが同じ

そもそもAnsibleは環境構築以外だと、デプロイの導火線の発火に使うことが多いだろうから自社アプリ用のモジュールがなぜ必要なのかわからんけど
あなたにとってシェルがベストな選択肢なら、シェルがいいんじゃね？

**デフォルトの名無しさん** · 2017/10/15(日) 19:05:19.96

>>151
そこらへんは議論の余地があるかもね
他にもPuppetもあるしChefもある

全部sshとshで実現できるってんなこといったら、その他スクリプト言語もラッパツールも全否定だからな…
彼は一体何と戦ってるのか…

**デフォルトの名無しさん** · 2017/10/15(日) 19:35:47.65

たかが数行、長くても数十行の単純なスクリプトでOK
冪等性などという高尚な概念を導入しなくても問題なく運用できる
これでわざわざ構成管理ツールを導入しようって方がどうかしてる

**デフォルトの名無しさん** · 2017/10/15(日) 19:37:08.37

>>153
> そもそもAnsibleは環境構築以外だと、デプロイの導火線の発火に使うことが多いだろうから

だろ？ Ansibleでデプロイはしないし、だからデプロイそのものが簡単になるわけじゃない。
デプロイをするのはデプロイツールだが、Dockerを使えばデプロイツールが不要になる。
なぜなら単に1アプリを動かせばいい程度になるから
>>138ですでに書いたことだけどね

> あなたにとってシェルがベストな選択肢なら、シェルがいいんじゃね？

クラウド使って大規模アプリ開発をするようになると必然的にそうなるよ
トラブルを避けるためローカルとサーバーでなるべく同じ環境でやるのが良いんだが、
サーバーと同じOS使って開発するのは現実的ではない。
だからDockerを使ってアプリの実行環境だけを同じにする。

Dockerを使うと冪等性は必要なくなり、デプロイの内容もシンプルになる
一番楽なのがシェルスクリプト。Dockerfileもシェルスクリプトがベースになってる。

>>154
> 彼は一体何と戦ってるのか…

俺？俺は↓これと戦ってる。これと

127 返信：デフォルトの名無しさん[sage] 投稿日：2017/10/15(日) 11:35:26.06 ID:jiVarmiT [9/10]
>>125
>まずDocker
ねーよwww
普通にansible使え

**デフォルトの名無しさん** · 2017/10/15(日) 19:42:08.08

> 他にもPuppetもあるしChefもある

PuppetもChefも、普段誰もがシェルスクリプトでやってることを
置き換えるには、重すぎる。いつもやってることをやるだけだろ？
本来新しいことは何も覚えなくてすむはずだ。

> 全部sshとshで実現できるってんなこといったら、その他スクリプト言語もラッパツールも全否定だからな…

そんなことは言っていない。
sshとshで実現できると言ってるのは、普段シェルでみんながやってる作業だけだよ。

パッケージのインストールとかその設定ファイルの変更とか、
そんなのその他のスクリプト言語やラッパーツールでやってないでしょｗ

普段やってることは普段やってる方法でやりましょうってこれだけの話だよ。
みんなシェルスクリプトでやってるんだからそれでいいじゃん。アホらしい。

**デフォルトの名無しさん** · 2017/10/15(日) 20:13:25.63

俺は逆にクラウド使うって大規模なクラスタ組む時以外はansibleなんて使わんけどな
できることはシェルと同じでもRoleやinventoryパターンに慣れたらsshだのシェルだのなんてやってられんわw

**デフォルトの名無しさん** · 2017/10/16(月) 15:59:08.48

可読性とモジュール性とかカプセル化、の問題じゃね?
シェルにはオブジェクトや配列はない。
それどころかまともに型もない。
Ansible Puppet Chefはシェルに型と配列記法を
無名関数なんかを使えるようになっているから付加価値はあるだろ、
1つあれば十分のようには思えるが。
C言語あるからわざわざJava覚える必要ないって
言わないでしょ?

**デフォルトの名無しさん** · 2017/10/16(月) 20:48:46.81

インベントリ管理は便利だと思う
Yamlはなぁ…これpythonそのままでよかったんじゃねえか？

**デフォルトの名無しさん** · 2017/10/16(月) 23:20:32.48

>>159
DSLって知ってる？ドメイン固有言語。
特定のタスク向けに設計されたコンピュータ言語

シェルというのはユーザーとコンピュータとの対話を行うために作られたもので、
慣れも有るだろうけど日常的な操作（＝特定のタスク）が使いやすいもの
シェルスクリプトはその日常的な操作をスクリプトにしたもの。
言い換えると日常的な操作に特化したDSLなんだよ。

型や配列が使えるからということで、シェルの代わりにプログラム言語使って
system()関数とかでコマンド呼び出しとかしないでしょ？

だからプログラム言語的な能力で比較するのは意味ないんだよ。
一般的な言語の機能を捨ててまで、特定のタスク向けに設計しているわけなんだから。
用途（プロビジョニング）を前提に適しているかどうかって話をしないと

> シェルにはオブジェクトや配列はない。
bashなら配列も連想配列もある。
が、そもそもプロビジョニングという用途で配列とか連想配列は使わん

**デフォルトの名無しさん** · 2017/10/16(月) 23:23:09.34

YAMLとかPythonがダメって言ってるんじゃないよ。
普通に何かを作る時は使ってるし。

普段やってる作業を、別のやり方に変えるのが無駄だなぁって話

その別のやり方に大きなメリットが有るならまだしも、
別のやり方に変えるプラグインが必要で、そのプラグインができることしか
できなくなってしまうとか、劣化してるからさ。

**デフォルトの名無しさん** · 2017/10/17(火) 03:23:19.58

>>161
プロビジョンで配列や連想配列を使わないんじゃなくて
便利じゃないから誰も使わないだけだよ。
bashに配列があっても集約する対象として複雑な概念が
オブジェクトとして構造化されていないから。
bashがRubyやPythonが出て来る前から設計されていたわけじゃないし
Chefとかはbashよりもさらに進化してオブジェクト指向に対応した
プロビジョン用DSLなわけじゃん。
Chef内でシェルも記述できるんだからシステムコール使いたいなら
そこで使えばいい。
依存関係もbashでInculudeなりラッパーするなりより
プロビジョンツール使ったほうが整理しやすいよ。

**デフォルトの名無しさん** · 2017/10/17(火) 03:35:54.06

要る要らないとかどうでもいいわ好きなもん使えよ

**デフォルトの名無しさん** · 2017/10/17(火) 04:15:27.00

スレが伸びてると思ったら、奇形児が暴れてたのな

**デフォルトの名無しさん** · 2017/10/17(火) 07:59:02.88

Ansibleは奇形

**デフォルトの名無しさん** · 2017/10/17(火) 09:37:38.20

>>163
プロビジョンのどこで配列や連想配列を使うんだ？

**デフォルトの名無しさん** · 2017/10/17(火) 09:55:50.26

>>163
なんかお前、本末転倒になってるよな。
やりたいことベースじゃなくて
配列が有るから配列使うんだ、
オブジェクト指向だからすごいんだ
みたいな

> Chef内でシェルも記述できるんだからシステムコール使いたいなら
> そこで使えばいい。

ならシェルスクリプトでやればいい。
っていうか普段のセットアップ作業でシステムコールなんか使わない

だから普段の手動のセットアップ作業を思い出せって
そこで必要なものしかいらないんだよ。配列とか使ってないだろ。
（もちろんループなどはシェルスクリプト使える）

**デフォルトの名無しさん** · 2017/10/17(火) 11:59:23.93

配列も連想配列も使うだろ
俺はansibleは嫌いだしシェルも可読性ゴミだからpythonで書いてるけど

**デフォルトの名無しさん** · 2017/10/17(火) 22:31:09.27

>>169
どういう時に配列や連想配列使う？
何度も言うけどシェルを使っている時という前提は忘れないでね。

シェルを使うの具体的な例は、cdやlsやapt-getやcpやrmなど
CLIコマンドを使って何かしらのアプリのインストール作業
プロビジョニングの話なんだからそれぐらいは前提

あとforで$@をぐるぐると引数を回すのは配列ではない。
だってそれを配列と言ってしまうと、>>159の前提である
> シェルにはオブジェクトや配列はない。
が崩れてしまうから、引数のことではないのは明らか

**デフォルトの名無しさん** · 2017/10/17(火) 23:27:36.98

>>170
サブネット全体に同じ設定入れたいときに、CIDR表記からipの配列作って応答あるものだけの配列にして設定ばらまいたりする
あと、mongodbのインストールするときにsource listにおまじない書かなきゃいけないんだけど、
osのversionによって書き方が違うからversionとおまじないを連想配列で持ってるよ

てかお前はシェル使ってりゃいいじゃん、誰も否定してないよ
リッチなスクリプト言語もツールも使わなきゃ死ぬってわけじゃないんだ
シェルだけに一生殻にこもっててくれ

**デフォルトの名無しさん** · 2017/10/17(火) 23:32:40.82

そうだPowerShellを使おう

**デフォルトの名無しさん** · 2017/10/17(火) 23:33:06.95

>>171
> サブネット全体に同じ設定入れたいときに、CIDR表記からipの配列作って応答あるものだけの配列にして設定ばらまいたりする
それなら別に配列使わなくても可変長引数で良いよね？

> osのversionによって書き方が違うからversionとおまじないを連想配列で持ってるよ
それはcaseでやれる

って感じで使わないと思うわけだよ。

難しく考えすぎじゃね？絶対配列じゃなきゃできないって思い込んでるでしょ？

> シェルだけに一生殻にこもっててくれ
俺は適材適所で使う道具を選んでいるだけ
PerlもPythonもRubyも使う。お前は全部Pythonなんだろ？

**デフォルトの名無しさん** · 2017/10/17(火) 23:36:11.06

いやだから好きにしろよ…
shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー
適材適所で使う道具選ぶ作業にもどれ馬鹿

**デフォルトの名無しさん** · 2017/10/17(火) 23:37:48.36

こんなやつ職場にいたら最悪だな
なんでシェル使わねーんだよ！！！とか言ってくるんだろ？

**デフォルトの名無しさん** · 2017/10/17(火) 23:40:13.69

てかrubyとPython使い分けるってどんな状況だよ…

**デフォルトの名無しさん** · 2017/10/17(火) 23:42:10.74

>>174
> shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー

その一言でよくわかったよ。

俺はどれが適切かという使う道具の話をしてる。
でもあんたの理由は道具じゃなくて「人」じゃん

まず道具を使えるという前提で話しませんか？

**デフォルトの名無しさん** · 2017/10/17(火) 23:43:14.37

>>176
大抵はrubyが多いけど、機械学習系はpythonが強いよ。
あとGAEを使うなら起動が速いgoとかね

**デフォルトの名無しさん** · 2017/10/17(火) 23:43:45.13

ansibleもまともに使えないやつがなんか言い出しててワラタ

**デフォルトの名無しさん** · 2017/10/17(火) 23:44:56.73

プロビジョニングになぜ機械学習が必要なのか…
プロビジョニングが前提だと言ってたおじさんはどこにいったのか

**デフォルトの名無しさん** · 2017/10/17(火) 23:45:01.14

>>175
> なんでシェル使わねーんだよ！！！とか言ってくるんだろ？

普段シェルを使ってセットアップしてるわけで
そのやり方を知っているはずなのに、
なぜわざわざansibleに置き換えるんですか？って

何かのバージョンが上がってansibleのプラグインが
対応してねーとか言ってるのを聞くたびに思ってるよｗ

**デフォルトの名無しさん** · 2017/10/17(火) 23:46:29.72

ちなみにそのansibleの対応してないプラグインってのは具体的には何なの？
普通ansibleってプラグインじゃなくてモジュールって言うと思うけど

**デフォルトの名無しさん** · 2017/10/17(火) 23:46:47.23

>>180
いや、話を聞けよｗ

俺が適材適所で言語を選んでいるってだけの話だ

> シェルだけに一生殻にこもっててくれ
とか言い出したから、俺はこもってないって話をしただけだ。

ちょっと落ち着こうぜ？ｗ

**デフォルトの名無しさん** · 2017/10/17(火) 23:48:43.51

Dockerとansibleのちがいがわかってなかったやつはただの無知だけど
こいつはキチガイだな

**デフォルトの名無しさん** · 2017/10/17(火) 23:49:23.25

>>182
正確にはモジュールだっけ？
でも公式でプラグインとも書いてあるよ。これとか

http://docs.ansible.com/ansible/latest/win_rabbitmq_plugin_module.html

**デフォルトの名無しさん** · 2017/10/17(火) 23:51:08.93

例としてあがってきたのがインストール以上のことをするモジュールでワラタ
そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん
ばか？

**デフォルトの名無しさん** · 2017/10/17(火) 23:56:54.40

>>182
まあ対応してないモジュールも有るだろうけど、
俺が今いったのは新しい設定にモジュールが対応してないって話

具体的に何？と聞かれたらIssuesみろよ。大量に～って思うだけなんだが
https://github.com/ansible/ansible/issues
https://github.com/ansible/ansible/pulls

まあ例えばこんなのとかわかりやすいかな？
tcpってオプションを選択できるようにするんだろうけど
こういうのだよ。普通にCLIでやってりゃできることなのに、
モジュールを更新しないと使えない。
https://github.com/ansible/ansible/pull/31228/files

ずーっと最新バージョンを追いかけていって大変だなぁとしか思えない

**デフォルトの名無しさん** · 2017/10/17(火) 23:58:23.86

おーけーわかった
ぼくもうシェルスクリプトしか使わないよ
みんなもおじさんの言うことを聞くんだぞ！

**デフォルトの名無しさん** · 2017/10/18(水) 00:00:38.25

>>186
> そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん

何度も言うけど、シェルスクリプトは自分で普段使っているわけでやり方知ってる。

シェルスクリプトでのやり方知ってるのに、対応するAnsibleの設定はどれだーって調べて
モジュールが対応していなければ、対応されるのを待たないといけない（自分でPR出してもいいけどさ）

俺が無駄だって思ってるのは、バージョンが上がった時の改修作業じゃない。
CLIなら改修する方法は公式見りゃわかるだろうが、
Ansibleを使ってると、公式で調べた上に、対応するAnsibleの書き方を
調べるという追加作業が増えたり、中間層のモジュール周りでトラブルになるのが無駄だって言ってる。

**デフォルトの名無しさん** · 2017/10/18(水) 00:02:16.30

仮想環境とまったく関係ない話してるシェル厨が大暴れしててワラタ
もうシェルスレにしろよｗｗｗ

**デフォルトの名無しさん** · 2017/10/18(水) 00:03:53.87

>>188
プロビジョニングに関してはそれが良いと思う。
だってみな手動でのプロビジョニングやってるはずで、
シェルスクリプトでのやり方も知ってるわけだからね。

**デフォルトの名無しさん** · 2017/10/18(水) 00:04:52.12

>>191
一生やってなさい

**デフォルトの名無しさん** · 2017/10/18(水) 00:05:23.88

>>190
シェルスクリプトはDockerfileやVagrantfileでも使用するよ。
特にDockerfileはシェルスクリプトまんまと言っても過言じゃない。
ENTRYPOINTで呼び出すスクリプトも炊いてはシェルスクリプト
まあ軽いイメージにわざわざプログラム言語入れないしね。

**デフォルトの名無しさん** · 2017/10/18(水) 00:05:44.45

>>192
はい。反論が有る限り続けますよ。

**デフォルトの名無しさん** · 2017/10/18(水) 00:06:27.78

狂気じみてる

**デフォルトの名無しさん** · 2017/10/18(水) 00:08:45.88

ansibleのフォーラムで暴れてこいよ、お前ら全員あしたからシェル使え！！！って
なんで2chでクソ底辺の戯言聞かされなきゃいけねーんだ

**デフォルトの名無しさん** · 2017/10/18(水) 00:10:21.61

動かしたいホストで動かしたい処理を動かせるならansibleなんてめんどくさいものをわざわざ使わなくていい
ってことはシェルとSSHで十分なんだよな

**デフォルトの名無しさん** · 2017/10/18(水) 00:15:26.03

仮想環境と全く関係ない話だけど、
冪等性が必要だったのはマシンを壊さず使い続けるためで
何度もプロビジョニングを行う必要性から冪等性が必要だった

ここで仮想環境の話に戻すと、仮想環境では壊して作り直せば
いいので、冪等性が必要なくなった。

仮想環境だけで仕事が回ってるって会社は少ないだろうから
仮想環境以外のものにAnsibleを使うのはありだろう。

だけど、このスレ仮想環境だからね。
このスレ的にはAnsibleは不要ってことなんだよ。
（このスレと関係ある話をしてみましたよｗ）

**デフォルトの名無しさん** · 2017/10/18(水) 00:16:26.91

>>196
嫌なら見るなって何処かの誰かが言っていたよｗ

**デフォルトの名無しさん** · 2017/10/18(水) 00:24:25.53

>>197
それな。Ansibleの問題点の１つとして
リモート先にpythonがインストールされて
いなければいけないって問題が有る。

この制約もあるんでDockerfileでansible（python）は
使わないってのもあるんだろう。ベースとなる
ディストリにpythonが入っていないbusyboxを使う場合もあるしさ

例えpythonが使えたとしてもdockerイメージ作るだけの作業で
Dockerfileの中でansibleをインストールなんてのはやりたくないな。

（これも仮想環境コンテナの話ｗ）

**デフォルトの名無しさん** · 2017/10/18(水) 21:44:39.96

Vagrantとかいうゴミはどうなったの？
Dockerに駆逐された？

**デフォルトの名無しさん** · 2017/10/18(水) 22:06:41.02

>>201
VagrantはDockerとは別のものだよ。

ただしDockerを使えば物理マシンでも比較的楽に
開発環境を作れるからVagrantを持ち出すまでもなくなってる。

でもそれはMacOSの話でWindowsは少なくともBash for Ubuntu for Windowsが
まともに動き出してからだな。と言ってももうベータ外れるらしいが。

だから（MacOS or Windows）+Dockerで開発するのが実用的と
みなせればVagrantはいらなくなる。

Dockerが駆逐するというより、Dockerの力を借りて
物理マシンでの開発に駆逐される。という感じ

**デフォルトの名無しさん** · 2017/10/20(金) 00:02:17.81

このスレはシェル厨に支配されました
以下、シェルで出来る事を他の方法でやる人は粛清されます

**デフォルトの名無しさん** · 2017/10/20(金) 00:03:11.17

vagrantとvirtual boxの設定
https://surleconomiejp.blogspot.jp/2017/10/vagrantvirtual-box.html

**デフォルトの名無しさん** · 2017/10/20(金) 00:10:03.94

>>107
visual stadioコンテナ欲しいです
ごめん、そもそもdockerでwindowsいけます？

**デフォルトの名無しさん** · 2017/10/20(金) 06:24:49.56

Docker原理主義者って全部Dockerでやるの？
フロントのNGINXとかデータベースは普通のサーバーのほうが使いやすくねえか？

**デフォルトの名無しさん** · 2017/10/20(金) 08:59:58.03

全部Dockerだよ

**デフォルトの名無しさん** · 2017/10/20(金) 09:53:29.13

>>206
Docker原理主義だけど全てDockerで
やるわけじゃないよ。

Docker原理主義っていうのは正しい用途に
Dockerを使うのであって、間違った用途に使うわけじゃない

**デフォルトの名無しさん** · 2017/10/21(土) 08:24:25.20

>>201
VagrantとDockerはレイヤーが違う

**デフォルトの名無しさん** · 2017/10/21(土) 10:40:49.52

vagrant: 仮想ネットワーク構築
ansible: シェルスクリプトの起動
シェルスクリプト: (初回のみ) install docker、docker pull、docker run

**デフォルトの名無しさん** · 2017/10/21(土) 11:40:16.52

Vagrantはクライアント環境の再現にしか使ってない
インスタンスに対するdockerとかpipとかのインストール、ソースとかイメージのビルド、実行環境でのdocker pullとrestartはAnsibleを使ってる
DockerはLB、webアプリケーションなどDBを除く、ほぼ全てに対して適用
だけど最近はLBもELBだけでよくね？的な瞬間もあるので、もはやサーブレットとかIronくるむ以外には、あんまり使ってない
ビルド環境をイメージ化しようかと思うこともなきにしもあらずだけどビルドサーバー立てるほうがメンテが楽なので、今はやってない

**デフォルトの名無しさん** · 2017/10/21(土) 12:02:43.48

docker buildすればWebアプリケーションのデプロイが楽とはいうけど
そんなことしなくてもデプロイ簡単だよな
dot netだったらフォルダ同期してプロセス起動するだけだしランタイムのインストールも要らない
dockerだと鯖にdockerを入れなきゃいけないけどそれがコマンド一発ではないからめんどくさい

**デフォルトの名無しさん** · 2017/10/21(土) 12:05:31.39

>>212
.Netだと事実上WindowsServerじゃないと動かないじゃん…
デフォルトでsshすらあがってないOSは、さすがに手が出しにくいな

**デフォルトの名無しさん** · 2017/10/21(土) 12:09:01.62

そしてフォルダにしちゃうとバージョン管理がしにくそう
ロールバックの仕組みが入れづらくないかい？
てか、.NetならAzureとVS組み合わせれば、同期がどうのとか細かいことは気にせず、めちゃ簡単に最新版をデプロイできるんじゃないの？

**デフォルトの名無しさん** · 2017/10/21(土) 12:24:34.02

>>213,214
普通にlinux鯖
バージョン管理とデプロイは別の話

**デフォルトの名無しさん** · 2017/10/21(土) 12:26:15.36

バージョン管理とデプロイが別なのは同意
失礼しました

それにしても、今は.Netも普通にLinuxて動くんだね
いろいろと幅が広がるな

**デフォルトの名無しさん** · 2017/10/21(土) 12:33:36.97

>>212
いや、根本的に発想が違ってる。
「ランタイムライブラリのインストールはいらない」を前提にしているが、
そもそもの問題は、

1. アプリを開発する
2. そのアプリはいろんなライブラリを使用している

という前提において、

理論的にはライブラリのバージョンが異なっていても互換性が完璧なら動くはずだが、
バージョンが異なると動かなくなることがある。
という現実的な問題を解決するために生まれたんだよ。

アプリを完璧に動かしたいのであれば、開発したアプリだけではなく
アプリが使用しているライブラリなど全てを含めた「パッケージ」を
作らなければいけない。

一つの手としてディレクトリに使用するライブラリを全部入れる
なんて方法もあるだろう。Dockerはその発展系と考えればいい。

**デフォルトの名無しさん** · 2017/10/21(土) 12:33:57.53

そして都合がいいことにLinuxではカーネルとユーザーランドという区別の仕方が有る。
例えばディストリが違っていても、カーネルは（バージョンの違いはあれど）同じものを使っている。
だからディストリの差というのは（ドライバなどカーネルレベルのモジュールを除いて）
ユーザーランドの違いといえる。カーネルは共通のものが使える。

カーネルは小さい機能に留めておくことで高い互換性を保っている。
そしてLinuxを構成する大部分はユーザーランドレベルのもの。

Dockerの話に戻すと、Docker（コンテナ）の仕組みっていうのは、
アプリが使用しているライブラリをディレクトリにまとめるなんてちゃちなやり方ではなく、
今、ユーザーランドの説明をしたろ？なんと大胆にカーネル以外の全てを１つのイメージにまとめてるんだよ。

話をまとめると、Dockerというのは開発したアプリをちゃんと動かすために
動かして検証した環境、小さいカーネル以外をすべてパッケージ化したもの。
だからLinuxのカーネル＋Dockerがあれば、Dockerイメージだけをデプロイする。
デプロイ先の環境を意識する必要ががないから、デプロイが楽なんだよ。
このOSでは動作保証していません。このライブラリのバージョンでは動作保証していません。なんてことがない

**デフォルトの名無しさん** · 2017/10/21(土) 12:36:07.71

.Netはそういう難しい話はないでしょ
3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？

**デフォルトの名無しさん** · 2017/10/21(土) 12:38:41.42

>>213
> デフォルトでsshすらあがってないOSは、さすがに手が出しにくいな

Dockerだとデプロイ先にSSHなんて不要だからね。
カーネルとDockerサーバーだけあれば動く。

もちろんそのOSに.netのとあるバージョンが
インストールされていることなんて制約はない。

.netがインストールされていることと
dockerがインストールされていることは
一緒ではないか！と思うかもしれないがそれは違う。

テストして動作確認したアプリは、.netの場合
そのインストールされている.netライブラリの機能を利用しているが
dockerの場合は、dockerのライブラリを利用しているわけじゃない。

dockerの場合dockerイメージを起動するのに必要ってだけで、
アプリが利用しているのは、イメージに含まれているライブラリと
小さなLinuxカーネルのみでアプリ自体はdockerには依存していない。
アプリが.netに依存しているのとここは大きな違い

**デフォルトの名無しさん** · 2017/10/21(土) 12:42:02.41

ID:zkU9oivGはなんでみんなが知ってる事を、だらだら書いてるの？
せめて、お前がどういうシステムをどういう環境でどう運用してるか書けよ

**デフォルトの名無しさん** · 2017/10/21(土) 12:45:23.73

>>219
> 3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？

だから同じ4系でも互換性問題は発生するいう考え方だよ。
それを防ぐためにアプリ自体に.netをまるまる含めたようなもの

アプリに.netが含まれていればアプリを配布するだけでいい。
でも、アプリに含まれていなければ、.netのアップデートをしなければいけなくなる。

**デフォルトの名無しさん** · 2017/10/21(土) 12:46:35.39

>>221
知らないからdockerの方がデプロイが楽って分かってないんでしょｗ

誰もがあんたみたいに知ってるわけじゃないんだから
知ってる人は黙ってなさい

**デフォルトの名無しさん** · 2017/10/21(土) 12:49:27.16

むしろお前のほうが.Net開発の現場を知らなそうだけど
どんなに便利でも、Dockerなんて使ってないよ

**デフォルトの名無しさん** · 2017/10/21(土) 12:52:16.98

>>214
> てか、.NetならAzureとVS組み合わせれば、同期がどうのとか細かいことは気にせず、めちゃ簡単に最新版をデプロイできるんじゃないの？

「AzureとVS組み合わせれば」っていうのがダメだね。
それは「簡単」ではない。

Dockerは「Dockerサーバーがあれば」デプロイできる。
その「AzureとVS組み合わせる」のは大変だが、
「Dockerサーバー」はどこでも存在する。

手元のWindowsマシンだろうが、Linuxマシンだろうが、MacOSマシンだろうが、
「Dockerサーバー」は存在する。

だから手元にデプロイしたものをそのままAzureだろうがAWSだろうがGCPだろうが
オレオレクラウドだろうが、めちゃ簡単にデプロイできる。
こういうレベルのものを「めちゃ簡単」と言うんだよ。

この手元にデプロイしたものをっていうのが本当に便利で、
開発してテストしたら、それは実機環境でテストしてるのほぼ同じなんだよ。
違いは小さなカーネル部分だけ（Dockerサーバーのバージョンには依存していない）

**デフォルトの名無しさん** · 2017/10/21(土) 12:53:44.30

>>217
だからその厳密にバージョン指定された依存関係まで含めて簡単にビルドできるんだよ
外部依存を全く無くしてポータブルなバイナリを作るのも簡単
ビルダだけで済む話なのにそのためにdockerを使うのは過剰すぎる

**デフォルトの名無しさん** · 2017/10/21(土) 12:53:44.56

>>224
> どんなに便利でも、Dockerなんて使ってないよ

すまんな。Dockerが今は便利かどうかの話をしているんだ。
あんたの現場特有の話はしてない。あんたの会社の話を
したって意味ないじゃないｗ

**デフォルトの名無しさん** · 2017/10/21(土) 12:59:17.59

>>226
.net以外のものを組み合わせるときは？

全てのライブラリが.netで作られているならば可能かもしれないけど
それは現実的ではない。Cのライブラリが使われることも有る。
RubyやPythonで作られているかもしれない。
すでに存在するnginxやmysqlなどと組み合わせることも有る。

Javaもそうだけど、.NETやJavaの世界で完結していればできるっていうのは
結局.NETやJavaの世界で完結していなければ出来ないって言ってるのと同じなんだよ。
それは現実的ではないよね。

**デフォルトの名無しさん** · 2017/10/21(土) 12:59:28.60

>>226
ほんとこれ
NuGetでそこらへんは用が足りてるんだよね

てかVSとAzureより、Dockerのほうが楽とか狂気すぎ
Windows上でDocker動くようにするほうが大変だろ
そんで得られるメリットがプロセスの仮想化です！ってやってられんわ

**デフォルトの名無しさん** · 2017/10/21(土) 12:59:54.34

>>228
.Netで完結します
おつかれ

**デフォルトの名無しさん** · 2017/10/21(土) 13:01:46.72

このスレ定期的に長文基地外がわくね

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

.net使うにしても、dockerイメージを使えばデプロイは楽になるだろうね。
なぜなら、そのdockerイメージの中に.netランタイムまで入っているから。

Dockerサーバーがあれば（それはきっと手元のマシンに入っているだろう）
どこぞのdockerイメージを、手元の環境を見直すこと無く直ぐに動かすことができる。

Windows 10で最新の.netがインストールされていること
なんて制約はない。

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

>>230
> .Netで完結します
遠吠えｗｗｗｗ

誰が、そんな説明で納得すると思ってんるんだ。
出直してこい

**デフォルトの名無しさん** · 2017/10/21(土) 13:03:35.60

ありとあらゆる条件が全く同等という保証がなければDockerだろうがなんだろうが実機テストは必要
それがテストってものだよ
手元の仮想環境と鯖の仮想環境はおんなじだ(だと思う)からテストはしなくていいなんてのは実社会では通用しないぞ

**デフォルトの名無しさん** · 2017/10/21(土) 13:04:51.34

Dockerはwindowsだと10以降しか対応してなくね？
開発環境が窓っていう、かわいそうな現場は大半がまだ7だからdockerなんか動かないだろ

**デフォルトの名無しさん** · 2017/10/21(土) 13:06:43.75

>>234
あ、はい、時間とコストの問題です。（言わなきゃ分からんかな？）

手元が実機とほぼ同じであれば、実機で見つかるバグは手元でほとんど再現します。
だからより早く少ないコストで修正できるということです。

可能か不可能かのはないをするのは実社会で通用しないぞ？ｗ
重要なのはどれだけコストが小さくできるかだ。

**デフォルトの名無しさん** · 2017/10/21(土) 13:07:37.66

>>235
virtualboxで動くよ
さすがはdockerというほかない
どこでも使える

**デフォルトの名無しさん** · 2017/10/21(土) 13:09:30.78

>>235
動くよ？
https://qiita.com/0829/items/d303412b15e8f473f3be

ってか、dockerさえ動けば良いのだからどんな方法でも良い。
アプリ自体はdockerには依存してない。