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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2017/02/16(木) 18:01:04.48ID:rGWDv0Eb
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ
2017/10/17(火) 23:33:06.95ID:0cEpFleP
>>171
> サブネット全体に同じ設定入れたいときに、CIDR表記からipの配列作って応答あるものだけの配列にして設定ばらまいたりする
それなら別に配列使わなくても可変長引数で良いよね？

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

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

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


> シェルだけに一生殻にこもっててくれ
俺は適材適所で使う道具を選んでいるだけ
PerlもPythonもRubyも使う。お前は全部Pythonなんだろ？
2017/10/17(火) 23:36:11.06ID:YM8Fx9+d
いやだから好きにしろよ…
shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー
適材適所で使う道具選ぶ作業にもどれ馬鹿
2017/10/17(火) 23:37:48.36ID:ivyQ9Kui
こんなやつ職場にいたら最悪だな
なんでシェル使わねーんだよ！！！とか言ってくるんだろ？
2017/10/17(火) 23:40:13.69ID:YM8Fx9+d
てかrubyとPython使い分けるってどんな状況だよ…
2017/10/17(火) 23:42:10.74ID:0cEpFleP
>>174
> shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー

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

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

まず道具を使えるという前提で話しませんか？
2017/10/17(火) 23:43:14.37ID:0cEpFleP
>>176
大抵はrubyが多いけど、機械学習系はpythonが強いよ。
あとGAEを使うなら起動が速いgoとかね
2017/10/17(火) 23:43:45.13ID:UsY1L3by
ansibleもまともに使えないやつがなんか言い出しててワラタ
2017/10/17(火) 23:44:56.73ID:YM8Fx9+d
プロビジョニングになぜ機械学習が必要なのか…
プロビジョニングが前提だと言ってたおじさんはどこにいったのか
2017/10/17(火) 23:45:01.14ID:0cEpFleP
>>175
> なんでシェル使わねーんだよ！！！とか言ってくるんだろ？

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

何かのバージョンが上がってansibleのプラグインが
対応してねーとか言ってるのを聞くたびに思ってるよｗ
2017/10/17(火) 23:46:29.72ID:YM8Fx9+d
ちなみにそのansibleの対応してないプラグインってのは具体的には何なの？
普通ansibleってプラグインじゃなくてモジュールって言うと思うけど
2017/10/17(火) 23:46:47.23ID:0cEpFleP
>>180
いや、話を聞けよｗ

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

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

ちょっと落ち着こうぜ？ｗ
2017/10/17(火) 23:48:43.51ID:EqLf+bAl
Dockerとansibleのちがいがわかってなかったやつはただの無知だけど
こいつはキチガイだな
2017/10/17(火) 23:49:23.25ID:0cEpFleP
>>182
正確にはモジュールだっけ？
でも公式でプラグインとも書いてあるよ。これとか

http://docs.ansible.com/ansible/latest/win_rabbitmq_plugin_module.html
2017/10/17(火) 23:51:08.93ID:YM8Fx9+d
例としてあがってきたのがインストール以上のことをするモジュールでワラタ
そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん
ばか？
2017/10/17(火) 23:56:54.40ID:0cEpFleP
>>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.86ID:YM8Fx9+d
おーけーわかった
ぼくもうシェルスクリプトしか使わないよ
みんなもおじさんの言うことを聞くんだぞ！
2017/10/18(水) 00:00:38.25ID:HhDhJUF4
>>186
> そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん

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

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

俺が無駄だって思ってるのは、バージョンが上がった時の改修作業じゃない。
CLIなら改修する方法は公式見りゃわかるだろうが、
Ansibleを使ってると、公式で調べた上に、対応するAnsibleの書き方を
調べるという追加作業が増えたり、中間層のモジュール周りでトラブルになるのが無駄だって言ってる。
2017/10/18(水) 00:02:16.30ID:5NdiYnkp
仮想環境とまったく関係ない話してるシェル厨が大暴れしててワラタ
もうシェルスレにしろよｗｗｗ
2017/10/18(水) 00:03:53.87ID:HhDhJUF4
>>188
プロビジョニングに関してはそれが良いと思う。
だってみな手動でのプロビジョニングやってるはずで、
シェルスクリプトでのやり方も知ってるわけだからね。
2017/10/18(水) 00:04:52.12ID:GaIyCTlI
>>191
一生やってなさい
2017/10/18(水) 00:05:23.88ID:HhDhJUF4
>>190
シェルスクリプトはDockerfileやVagrantfileでも使用するよ。
特にDockerfileはシェルスクリプトまんまと言っても過言じゃない。
ENTRYPOINTで呼び出すスクリプトも炊いてはシェルスクリプト
まあ軽いイメージにわざわざプログラム言語入れないしね。
2017/10/18(水) 00:05:44.45ID:HhDhJUF4
>>192
はい。反論が有る限り続けますよ。
2017/10/18(水) 00:06:27.78ID:J5g3uFgF
狂気じみてる
2017/10/18(水) 00:08:45.88ID:GaIyCTlI
ansibleのフォーラムで暴れてこいよ、お前ら全員あしたからシェル使え！！！って
なんで2chでクソ底辺の戯言聞かされなきゃいけねーんだ
2017/10/18(水) 00:10:21.61ID:YCPgdWPh
動かしたいホストで動かしたい処理を動かせるならansibleなんてめんどくさいものをわざわざ使わなくていい
ってことはシェルとSSHで十分なんだよな
2017/10/18(水) 00:15:26.03ID:HhDhJUF4
仮想環境と全く関係ない話だけど、
冪等性が必要だったのはマシンを壊さず使い続けるためで
何度もプロビジョニングを行う必要性から冪等性が必要だった

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

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

だけど、このスレ仮想環境だからね。
このスレ的にはAnsibleは不要ってことなんだよ。
（このスレと関係ある話をしてみましたよｗ）
2017/10/18(水) 00:16:26.91ID:HhDhJUF4
>>196
嫌なら見るなって何処かの誰かが言っていたよｗ
2017/10/18(水) 00:24:25.53ID:HhDhJUF4
>>197
それな。Ansibleの問題点の１つとして
リモート先にpythonがインストールされて
いなければいけないって問題が有る。

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

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

（これも仮想環境コンテナの話ｗ）
2017/10/18(水) 21:44:39.96ID:XAtaZZJd
Vagrantとかいうゴミはどうなったの？
Dockerに駆逐された？
2017/10/18(水) 22:06:41.02ID:HhDhJUF4
>>201
VagrantはDockerとは別のものだよ。

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

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

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

Dockerが駆逐するというより、Dockerの力を借りて
物理マシンでの開発に駆逐される。という感じ
203デフォルトの名無しさん
垢版 |
2017/10/20(金) 00:02:17.81ID:vd2jZWHS
このスレはシェル厨に支配されました
以下、シェルで出来る事を他の方法でやる人は粛清されます
204デフォルトの名無しさん
垢版 |
2017/10/20(金) 00:03:11.17ID:gO2nGHbF
vagrantとvirtual boxの設定
https://surleconomiejp.blogspot.jp/2017/10/vagrantvirtual-box.html
2017/10/20(金) 00:10:03.94ID:pYxyaYmj
>>107
visual stadioコンテナ欲しいです
ごめん、そもそもdockerでwindowsいけます？
2017/10/20(金) 06:24:49.56ID:l3SzA2hH
Docker原理主義者って全部Dockerでやるの？
フロントのNGINXとかデータベースは普通のサーバーのほうが使いやすくねえか？
2017/10/20(金) 08:59:58.03ID:6WjQxFol
全部Dockerだよ
2017/10/20(金) 09:53:29.13ID:uOisOSsS
>>206
Docker原理主義だけど全てDockerで
やるわけじゃないよ。

Docker原理主義っていうのは正しい用途に
Dockerを使うのであって、間違った用途に使うわけじゃない
2017/10/21(土) 08:24:25.20ID:KicYxM26
>>201
VagrantとDockerはレイヤーが違う
2017/10/21(土) 10:40:49.52ID:ut7aXw9f
vagrant: 仮想ネットワーク構築
ansible: シェルスクリプトの起動
シェルスクリプト: (初回のみ) install docker、docker pull、docker run
2017/10/21(土) 11:40:16.52ID:Nlq4KP6d
Vagrantはクライアント環境の再現にしか使ってない
インスタンスに対するdockerとかpipとかのインストール、ソースとかイメージのビルド、実行環境でのdocker pullとrestartはAnsibleを使ってる
DockerはLB、webアプリケーションなどDBを除く、ほぼ全てに対して適用
だけど最近はLBもELBだけでよくね？的な瞬間もあるので、もはやサーブレットとかIronくるむ以外には、あんまり使ってない
ビルド環境をイメージ化しようかと思うこともなきにしもあらずだけどビルドサーバー立てるほうがメンテが楽なので、今はやってない
2017/10/21(土) 12:02:43.48ID:1eBICzfj
docker buildすればWebアプリケーションのデプロイが楽とはいうけど
そんなことしなくてもデプロイ簡単だよな
dot netだったらフォルダ同期してプロセス起動するだけだしランタイムのインストールも要らない
dockerだと鯖にdockerを入れなきゃいけないけどそれがコマンド一発ではないからめんどくさい
2017/10/21(土) 12:05:31.39ID:Nlq4KP6d
>>212
.Netだと事実上WindowsServerじゃないと動かないじゃん…
デフォルトでsshすらあがってないOSは、さすがに手が出しにくいな
2017/10/21(土) 12:09:01.62ID:Nlq4KP6d
そしてフォルダにしちゃうとバージョン管理がしにくそう
ロールバックの仕組みが入れづらくないかい？
てか、.NetならAzureとVS組み合わせれば、同期がどうのとか細かいことは気にせず、めちゃ簡単に最新版をデプロイできるんじゃないの？
2017/10/21(土) 12:24:34.02ID:1eBICzfj
>>213,214
普通にlinux鯖
バージョン管理とデプロイは別の話
2017/10/21(土) 12:26:15.36ID:Nlq4KP6d
バージョン管理とデプロイが別なのは同意
失礼しました

それにしても、今は.Netも普通にLinuxて動くんだね
いろいろと幅が広がるな
2017/10/21(土) 12:33:36.97ID:zkU9oivG
>>212
いや、根本的に発想が違ってる。
「ランタイムライブラリのインストールはいらない」を前提にしているが、
そもそもの問題は、

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

という前提において、

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

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

一つの手としてディレクトリに使用するライブラリを全部入れる
なんて方法もあるだろう。Dockerはその発展系と考えればいい。
2017/10/21(土) 12:33:57.53ID:zkU9oivG
そして都合がいいことにLinuxではカーネルとユーザーランドという区別の仕方が有る。
例えばディストリが違っていても、カーネルは（バージョンの違いはあれど）同じものを使っている。
だからディストリの差というのは（ドライバなどカーネルレベルのモジュールを除いて）
ユーザーランドの違いといえる。カーネルは共通のものが使える。

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

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

話をまとめると、Dockerというのは開発したアプリをちゃんと動かすために
動かして検証した環境、小さいカーネル以外をすべてパッケージ化したもの。
だからLinuxのカーネル＋Dockerがあれば、Dockerイメージだけをデプロイする。
デプロイ先の環境を意識する必要ががないから、デプロイが楽なんだよ。
このOSでは動作保証していません。このライブラリのバージョンでは動作保証していません。なんてことがない
2017/10/21(土) 12:36:07.71ID:Nlq4KP6d
.Netはそういう難しい話はないでしょ
3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？
2017/10/21(土) 12:38:41.42ID:zkU9oivG
>>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.41ID:mrPCTHTL
ID:zkU9oivGはなんでみんなが知ってる事を、だらだら書いてるの？
せめて、お前がどういうシステムをどういう環境でどう運用してるか書けよ
2017/10/21(土) 12:45:23.73ID:zkU9oivG
>>219
> 3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？

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

アプリに.netが含まれていればアプリを配布するだけでいい。
でも、アプリに含まれていなければ、.netのアップデートをしなければいけなくなる。
2017/10/21(土) 12:46:35.39ID:zkU9oivG
>>221
知らないからdockerの方がデプロイが楽って分かってないんでしょｗ

誰もがあんたみたいに知ってるわけじゃないんだから
知ってる人は黙ってなさい
2017/10/21(土) 12:49:27.16ID:mrPCTHTL
むしろお前のほうが.Net開発の現場を知らなそうだけど
どんなに便利でも、Dockerなんて使ってないよ
2017/10/21(土) 12:52:16.98ID:zkU9oivG
>>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.30ID:Lfp6S+wn
>>217
だからその厳密にバージョン指定された依存関係まで含めて簡単にビルドできるんだよ
外部依存を全く無くしてポータブルなバイナリを作るのも簡単
ビルダだけで済む話なのにそのためにdockerを使うのは過剰すぎる
2017/10/21(土) 12:53:44.56ID:zkU9oivG
>>224
> どんなに便利でも、Dockerなんて使ってないよ

すまんな。Dockerが今は便利かどうかの話をしているんだ。
あんたの現場特有の話はしてない。あんたの会社の話を
したって意味ないじゃないｗ
2017/10/21(土) 12:59:17.59ID:zkU9oivG
>>226
.net以外のものを組み合わせるときは？

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

Javaもそうだけど、.NETやJavaの世界で完結していればできるっていうのは
結局.NETやJavaの世界で完結していなければ出来ないって言ってるのと同じなんだよ。
それは現実的ではないよね。
2017/10/21(土) 12:59:28.60ID:mrPCTHTL
>>226
ほんとこれ
NuGetでそこらへんは用が足りてるんだよね

てかVSとAzureより、Dockerのほうが楽とか狂気すぎ
Windows上でDocker動くようにするほうが大変だろ
そんで得られるメリットがプロセスの仮想化です！ってやってられんわ
2017/10/21(土) 12:59:54.34ID:mrPCTHTL
>>228
.Netで完結します
おつかれ
2017/10/21(土) 13:01:46.72ID:hXGDex9u
このスレ定期的に長文基地外がわくね
2017/10/21(土) 13:02:24.19ID:zkU9oivG
.net使うにしても、dockerイメージを使えばデプロイは楽になるだろうね。
なぜなら、そのdockerイメージの中に.netランタイムまで入っているから。

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

Windows 10で最新の.netがインストールされていること
なんて制約はない。
2017/10/21(土) 13:02:55.54ID:zkU9oivG
>>230
> .Netで完結します
遠吠えｗｗｗｗ

誰が、そんな説明で納得すると思ってんるんだ。
出直してこい
2017/10/21(土) 13:03:35.60ID:uF51TTqU
ありとあらゆる条件が全く同等という保証がなければDockerだろうがなんだろうが実機テストは必要
それがテストってものだよ
手元の仮想環境と鯖の仮想環境はおんなじだ(だと思う)からテストはしなくていいなんてのは実社会では通用しないぞ
2017/10/21(土) 13:04:51.34ID:lul59eSB
Dockerはwindowsだと10以降しか対応してなくね？
開発環境が窓っていう、かわいそうな現場は大半がまだ7だからdockerなんか動かないだろ
2017/10/21(土) 13:06:43.75ID:zkU9oivG
>>234
あ、はい、時間とコストの問題です。（言わなきゃ分からんかな？）

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

可能か不可能かのはないをするのは実社会で通用しないぞ？ｗ
重要なのはどれだけコストが小さくできるかだ。
2017/10/21(土) 13:07:37.66ID:uF51TTqU
>>235
virtualboxで動くよ
さすがはdockerというほかない
どこでも使える
2017/10/21(土) 13:09:30.78ID:zkU9oivG
>>235
動くよ？
https://qiita.com/0829/items/d303412b15e8f473f3be

ってか、dockerさえ動けば良いのだからどんな方法でも良い。
アプリ自体はdockerには依存してない。
2017/10/21(土) 13:10:45.14ID:uF51TTqU
>>236
おやおや
君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？
新しい技術を覚えたてで興奮する気持ちはわかるが発言は冷静になってからにしたほうがいいぞ
2017/10/21(土) 13:12:34.46ID:zkU9oivG
ふむ。さすがマイクロソフト。
当然だが組み合わせて使うことの意味をちゃんと知ってるな。

NET Core アプリケーションの Docker イメージのビルド
https://docs.microsoft.com/ja-jp/dotnet/core/docker/building-net-docker-images

NET Core と Docker を一緒に使用する方法を理解するには、まず、提供されるさまざまな
Docker イメージと、適切な使用のタイミングを把握する必要があります。
ここでは、提供されるバリエーションを確認し、ASP.NET Core Web API をビルドし、
Yeoman Docker ツールを使用してデバッグ可能なコンテナーを作成し、
さらにプロセスにおいて Visual Studio Code がどのように役立つかを簡単に確認します。
2017/10/21(土) 13:13:04.58ID:YCde4Ox3
長文で暴れてるのって同一人物だろ
コテつけてほしい
2017/10/21(土) 13:13:53.59ID:zkU9oivG
>>239
> 君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？

ならお前の耳が悪いんでね〜の？ｗ

聞こえたのは「お前」の耳（目）
言ったのであれば、それは俺の口（手）だがｗ

いえ「実機テストが必要ない」と書いてある文章を
示せるというのであれば、示して良いんですよ？ｗ
2017/10/21(土) 13:14:14.77ID:zkU9oivG
>>241

ID変えるようなやつだから無理
2017/10/21(土) 13:17:10.24ID:zkU9oivG
コンテナー - 従来の .NET アプリを Docker で最新化する
https://msdn.microsoft.com/ja-jp/magazine/mt797650.aspx

> このような従来のアプリケーションでは依然として大きなビジネス価値が提供されていますが、
> その保守、アップグレード、拡張、および管理は難しくなっている可能性があります。

やっぱり.NETでは保守、アップグレード、拡張、および管理は難しくなってるんだね。

> 同時に、このようなアプリケーションをすべて作り直すことも、そのために必要な投資に
> 見合わない場合があります。ただし、軽量なコンテナー内でアプリケーションを実行する
> プラットフォームである Docker と、Windows Server 2016 を併用することで、
> 従来のアプリケーションの寿命を伸ばすことが可能です。つまり、機能を追加し、
> セキュリティとパフォーマンスを向上して、継続的配置に移行します。
> それも、時間がかかるうえにコストが高い再構築プロジェクトを実施する必要はありません。

継続的配置（配置＝デプロイ）がDockerは便利だってMSも認めてるね。
2017/10/21(土) 13:18:45.25ID:uF51TTqU
>>242
自分のレスを冷静に見つめ直してごらん
あたかもテスト不要であるように取れる発言を何度もしてるよ
これから社会に出るのだろうし反省することも覚えたほうがいい
2017/10/21(土) 13:21:03.22ID:YCde4Ox3
>>243
あなたにコテつけてほしいってことなんだけど…
2017/10/21(土) 13:23:50.11ID:zkU9oivG
>>245
> あたかもテスト不要であるように取れる発言を何度もしてるよ

引用できない時点で、説得力ゼロ
できないなら、なんなら俺が引用してあげようか？

例えば >>225
> 開発してテストしたら、それは実機環境でテストしてるのほぼ同じなんだよ。
> 違いは小さなカーネル部分だけ（Dockerサーバーのバージョンには依存していない）

「ほぼ」同じと書いて有ることから、全く同じではないということがわかる。
そして「違い」について書いてあるから、違いが有ることも明示されている。
よって実機環境でテストが不要ということにはならない。

さて、次はあんたの番だ。
2017/10/21(土) 13:25:22.89ID:zkU9oivG
>>246
ID見ればわかるし、俺にコテを付けるメリットがない。
というか、５ちゃんねるでコテはつけないというは
俺の中でとっくの昔に決めたルールなので言うだけムダだｗ
2017/10/21(土) 13:41:22.32ID:uF51TTqU
>>247
15日あたりのレスとかなぁ
2017/10/21(土) 13:42:48.09ID:zkU9oivG
そこまで調べて引用できないとか、やっぱりなぁとしか思えんな
2017/10/21(土) 13:46:47.12ID:uF51TTqU
>>122
＞だからローカルで開発で使用していたDockerイメージをそのまま
＞クラウドの仮想化サービス上に持っていくことができる。
＞その作業も単にdocker runするだけ

JavaのWOTAとの対比で語っちゃってるしこれはそうとしか読めんなぁ
2017/10/21(土) 13:55:29.54ID:uF51TTqU
どうした？
言い訳が思いつかないのか？
2017/10/21(土) 14:01:47.02ID:zkU9oivG
>>251
持っていくことができるよ？
持っていってテストするんだろ？
何を言ってるんだとしか思えんわｗ
2017/10/21(土) 14:06:21.17ID:uF51TTqU
>>253
ん〜
ちょっと厳しいなその反論は
じゃあなんでJavaと対比したの？ってなるよね

Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは〜
っていう文脈でしょ？
2017/10/21(土) 14:18:41.57ID:zkU9oivG
>>254
ワロタｗｗｗ
お前バカだわ。うん。バカだわ

Javaが主張した言葉、Write once, run everywhere
で、それがが批判されてるのは、実行できると言うが
そこらじゅうでデバッグ（テスト）しなきゃいけないって批判されているほど、
Javaのrun everywhere「どこでも走るレベル」は"低い"って話だ。
低いから、そこらじゅうでデバッグ（テスト）しなきゃいけない

なぜか？ そりゃそうだ。各OSごとで同じものを使うのではなく
各OS毎にライブラリ側で抽象化レイヤを開発してるからだ。
同じものを使っているんじゃない。違うものを使って同じに見せかけてるから
それじゃ互換性レベルは低くなるよねってことだ。

それに比べてDockerは同じものを使う。ライブラリを各OS毎に用意するのではなく
同じものをイメージに同梱する。だからJavaよりもはるかに高いレベルで
DockerはWrite once, run everywhereを実現している。
違いは高い互換性を持つカーネルのみだからな。
Write once, run everywhereなわけだ。


で、お前は、（Javaが主張した言葉）Write once, run everywhere は
全くテストしなくていいって意味で言ってると思うか？

お前がバカだって言った意味がわかったか？

お前は（Dockerが実現している）Write once, run everywhere を
実機で「全く」テストしなくていいという意味だって勘違してるなってわかったからだよ。
2017/10/21(土) 14:21:12.73ID:zkU9oivG
結局、.NETも同じことになるんだろうな。

Windows実装版とLinux実装版で違いが有るのなら、
全く同じように動くわけじゃない。

同じものを使わなんと同じようには動かんよ。
理論的には動くだろうけど、違う実装なら違いは出る。

全く同じものを使うDockerの利点はそこに有る。
2017/10/21(土) 14:24:16.29ID:uF51TTqU
>>255
残念だけどそう考えてるのは君だけだよ
君のレスを読んだ人は
あ、こいつDocker使えばテストいらんと思ってるな
と思うわけだ
社会に出たら人からどう見られるかってのも大切だから覚えておいてね
2017/10/21(土) 14:31:43.74ID:zkU9oivG
まあ別の言い方で簡単に>>254がバカだって証明するならば

> Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは〜
> っていう文脈でしょ？

write onceはJavaもDockerも同じなので省略するとして

Javaは、test everywhere（どこでもテスト）
Dockerは、not test everywhere（not どこでもテスト）

「どこでもテスト」の反対は「テストなし」ではない
「全て」の反対は「一部」であって「無」ではない
2017/10/21(土) 14:33:36.33ID:zkU9oivG
>>257
> 君のレスを読んだ人は
> あ、こいつDocker使えばテストいらんと思ってるな
> と思うわけだ

だからどこにそう書いてある？引用してみて。

すでに俺は「テストいらないと言ってない所」を引用済み

お前が、他人の説明を間違って解釈して喚いていているやつってのは証明した。
社会に出たら人からどう見られるかってのも大切だから覚えておいてね
2017/10/21(土) 14:36:58.71ID:zkU9oivG
今回は見事論破（笑）できたから

> ちょっと厳しいなその反論は
と言えなかったんだろうなｗ
261デフォルトの名無しさん
垢版 |
2017/10/21(土) 21:13:10.64ID:OISii71C
docker使うケースは頻繁なデプロイが前提だったり迅速なスケールアウトが必要だったりの事情があるはずで、
そういう場合に例えば速度面でVMより起動が速い事が一番のメリットだ、という理由があって使うんじゃねーの？
あと消費リソースがVMより少なくて済むとか。

実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
それこそ全部シェルでやれっつーシェル厨もいるだろうけどw
まぁデプロイ楽にする方法なんて他にもあるし、要求や制約に合わせて選ぶもんだ。

メリットが享受できないユースケース出してきてdocker要らないっつーのも馬鹿だし、
他に方法があるのにdockerをお押しつけるのも馬鹿。

テストにしても、ライブラリのバージョン依存のバグを本番環境でのテストまでに見つけられない方が問題なわけで、
ID:zkU9oivGが言いたいのは、そこのバグはもっと早期に潰してる前提でしょ？
テストなんて工程別に目的持ってやるもんなのに、全部ひっくるめて語るのは暴論だわな。
2017/10/21(土) 22:19:05.77ID:01fxNEyn
>>261
> 実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
だから全く別のものを混ぜないでくれ。分かってないことがバレバレだろ。

ansibleは構成管理ツール。マシンの環境を構築するツール
無理やりDockerに対応づけるならば、Dockerfileを使ったDockerイメージのビルド作業だよ。
（Dockerイメージのビルド作業にAnsibleを使うようなやつはいないが）
ansibleはDockerと違ってイメージを作るものじゃない。
ただのセットアップ手順書だ

Vagrantは、仮想「開発環境」構築ソフトウェア実機で使うことは想定されていない。
無理やりDockerと関連付けるならば、Vagrantで構築された仮想環境には
Dockerサーバーもインストール済みで、すぐにDockerコマンドが使用できる。
みたいな使い方をするんだ。

例えば開発環境の話をしてるとして、 Vagrantで作った仮想マシン VS 物理マシン（Windows、MacOS、Linux） の
どちらであなたは開発してますか？とかこういう使い方をするんだよ。

仮想マシン上でもDockerは使えるし、物理マシン上でもDockerは使える。
物理マシン上で作成したDockerイメージがVagrant上でも動く
クラウドでもDockerサーバーをインストール済みのVMイメージが公式で用意されているから
同じDockerイメージをそのままクラウドでも使うことができる。

Vagrantで作ったイメージが、クラウド上の仮想マシンで動くことなんてまずないからな。
Nested VMは茨の道だよ。それが出来たとしても起動時間、使用メモリ、ネットワークの点から
デメリットしか存在しない

Vagrantが実行環境のイメージ化（＝実行マシン構成が含まれる）とするならば
Dockerはアプリケーションのイメージ化だ。アプリケーションにはマシンの構成が含まれないから
物理・仮想マシン関係なくどこででも動くんだ。ただの１つのアプリケーションだもの
2017/10/21(土) 22:21:53.51ID:GGRodYi7
イメージのビルドにAnsible使ってるよー
2017/10/21(土) 22:27:51.08ID:01fxNEyn
そういやAnsible Containerってのができたんだっけｗ

なんかメリットあんの？
コンテナイメージの作成がDockerfileじゃできないほど
複雑なものでも作るの？

シェルスクリプトが使えない人の救済用以外の
メリットがあるなら教えてください。
2017/10/22(日) 00:59:52.33ID:0M1ELFL1
いや普通にDockerfileのビルドに使ってるでよ
docker_imageってモジュール
2017/10/22(日) 01:00:55.77ID:0M1ELFL1
てかシェルスクリプト使えない人ってどゆこと？
窓ユーザーってこと？質問の意味がよくわからん…
2017/10/22(日) 01:13:03.22ID:sDdgCD4Q
>>265
お、おう。
それはdocker buildコマンドを叩く代わりに
ansibleを使っているってだけの話だな。
dockerコンテナへのデプロイではなく

どころで普段、端末からdocker使えるか？
docker build -t tag . とか
docker run -it debian /bin/bash
みたいなのそらで打てるか？

ansible使わないとコマンド打てないっていうんじゃ恥ずかしいぞ
2017/10/22(日) 01:14:41.12ID:sDdgCD4Q
>>266
世の中には、ansible経由で設定ファイルを書いて
コマンドを実行している人がいるかもしれない。

dockerに新しいオプションが増えてもすぐに使えずに
http://docs.ansible.com/ansible/latest/docker_image_module.html
このモジュールが対応していることしかできないって人もいるかもしれない
2017/10/22(日) 01:17:06.88ID:oq9fIgmy
buildもpushもpullもrunも全部ansibleでやるときあるよ

dockerの基本的なコマンドそらでうてないやつなんているの？
ローカルでやるときはいちいちansibleなんてつかわんのに

質問の趣旨は？？
2017/10/22(日) 01:19:08.12ID:oq9fIgmy
>>268
え、設定ファイルってDockerfileをってこと？？
それをlineinfileとか使って動的生成する人ってことかな
そんな人いないと思うけど…
2017/10/22(日) 01:23:02.03ID:sDdgCD4Q
>>269
そらでうてるものに対して対応するansibleの設定探すの面倒じゃないかなーって思って
それに例えばマイナー（？）なオプションbuild時にラベルつけたくなったらどうするの？とかさ
モジュール対応してないでしょ？
2017/10/22(日) 01:27:52.52ID:sDdgCD4Q
ローカルでやるときはいちいちansibleは使わない

そうだよね。

まず最初にansibleを使わないで作業する
コマンドを叩く、やりたいことを実現する。


それをansible言語に翻訳する作業ってすごく無駄な作業だと思う。
しかもローカルでやれることの一部しかできないし。
2017/10/22(日) 01:29:40.83ID:oq9fIgmy
>>271
まぁ面倒っちゃ面倒かもな
俺はもうスニペット用意してるからそこまで手間でもないけど
--labelは使ったことないから、知らんけど、まぁどうしてもそうなったら仕方ないからcommnd module使うんじゃね？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況