Docker Part3

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

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

>>301
何で俺の書き込み見て必死に追従してんの？
昨日やってやれよｗ

>>304
スレ違いだからやらないと言った。
しかしクソコードが広まるのは世の中のためにならない

>>305
君はエネルギーの使い方が間違ってるね。
しかも結局スレ違いじゃ無いじゃんｗ

>>306
意味不ｗ
お前が最初からまともなものを出してれば
俺が無駄なエネルギー使うことはなかったんだよ。

qiitaとか下手にSEOが高いからクソコードが広まりすぎて
うんざりするわ。世の中のためになることにエネルギーを使う
クソコードの排除は世の中のためだ。

> しかも結局スレ違いじゃ無いじゃんｗ
修正内容見ろよ。Dockerと関係ないだろ。物理 or 仮想マシンでも
同じ修正が必要だ。俺はお前のクソコードを修正しただけで
Dockerに関するレスをしたわけじゃない。スレ違いだが
さすがにクソコードは看過できん

>>307
分かったから涙拭けよｗ
お前がどう言い繕うとも、俺のコード見て動き
始めた事はなんら変わりは無いｗｗｗ

ハズカシーｗ

>>308
そんなことよりお前のコードのバグ（pepper_49がインストールされてない）
というのを指摘するほうが重要。
お前のコードは一行たりとも利用してない。
お前のコードは役に立たない

どっちもありがとうやで(*‘ω‘*)

なあにいいってことよ。
シンプルかつ無駄のない正しいコードを書くのが好きだからなｗ

>>309
いやいや、そういう問題じゃない

>何で俺の書き込み見て必死に追従してんの？

悪いけどこれが俺の感想の全てｗｗ
粘着してるし、お前は昨日も一昨日も暇だったんだよな？
俺はスゲー忙しかったけど。で暇なくせに結局
Dockerfileの修正を持って問題解決となったスレ違いでも
何でもない事象にスルー決め込んでたんだよな？

で、俺が書いたのみて「成程ここが問題なのか。
俺がエレガントに解いてやろう♪」とでもやって、ドヤ顔で
ここに投下したんだよな？

悪いけど失笑意外何も無いよｗ

>vi ./work/nacl_sdk/sdk_tools/download.py

>※L18-19をコメントアウト
>19 # ca_certs = os.path.join(SCRIPT_DIR, 'cacerts.txt')
>20 # request.set_ssl_info(ca_certs=ca_certs)

あ、ここで ./naclsdk install pepper_49　やなとかそれ位分れよｗ
それ関連のファイル修正したんだからｗ

あほやなぁｗ

> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)
というエラーで、証明書の問題だなんてすぐわかるだろ。

その時点でDockerと関係ないことは明らかだったから、
関係ないからよそに行けって最初から言ってるんだがｗ

↓

196 自分：login:Penguin[sage] 投稿日：2019/11/15(金) 04:45:41.79 ID:E8h29lNR
どっかーとかんけいないので
どっかーにいってください

> あ、ここで ./naclsdk install pepper_49　やなとかそれ位分れよｗ

やればわかるが、それ失敗する。

なぜかと言うと、コメントアウトしたという事実が消えてなくなるから

>>315
Dockerを消すなよｗ

>>316
Dockerのせいではない。
お前、やっぱりわかってないんだな。
俺のDockerfileの修正内容見て、疑問に思わなかったのか？

>>317
ドヤ顔で師匠面すんなよｗ
やっぱお前、俺の書込みにレスするなｗ
悪いけどお前が何を言おうと、俺の中で丸二日何もしなかった癖に
俺が書き込んだ瞬間に、必死に追従する恥ずかしい奴、と言う印象以外何も無い。
俺にとっては、>>298で
「BUILD SUCCESSFUL」これを見た瞬間にタスク（と言うか懸案）は終わり。
もう一切の興味は無い。お前が余りにもハズカシーからレスしてあげてるだけ。
じゃーなｗ

師匠面（笑） お前が、俺のことを師匠に見えてしまってるから
そんな発想が出てくるんだぞｗ

さて>>301の解説するか

まず実行して表示されるエラーの内容から証明書に問題があることはすぐにわかる。
Ubuntu 14.04だから証明書が古いんだろうなと最初は思ったが、実際は、nacl_sdkに入ってる cacerts.txt が古い（2015年）
Ubuntu自体はアップデートされてるので問題なかった。なのでファイルをコピーするだけで解決。

そう解決するはずだった。それが解決しなかった。

> RUN curl -LO http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip && unzip nacl_sdk.zip && rm nacl_sdk.zip
> RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
> RUN ./nacl_sdk/naclsdk version
> RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
> RUN cd nacl_sdk && ./naclsdk install pepper_49

これ見て疑問に思うべきなのは、同じcpがニ回ある所とバージョン番号を出力してるだけの
naclsdk version がある所。これ、意味がないように見えるがちゃんと意味がある。

>>312が動かないと言ったのは、naclsdk を実行すると修正が巻き戻る（用に見える）から。
cacerts.txt が巻き戻るし、コメントアウトしたはずの download.py も巻き戻る。
>>297がDockerfileにしてないのは、この理由がわからず、試行錯誤して（何故か）動いたものを
書いただけだからだろう。だからやったはずのnaclsdk install pepper_49も書き忘れた。

巻き戻る理由は、>>302で書いたように推測だが、おそらくSDKのアップデート処理。
ネットから最新版？をとってきてると思われる。Google Cloud SDKがそうだが
コマンド実行時に最新版を使わせるためにアップデート機能が内蔵されてる。
という経験があるから気づいた。こういうのに気づけるのは経験の差だな。

本当にアップデートであるかは見てはないが、naclsdk（bashスクリプト）が呼び出してるのが
sdk_update.py というファイルだから多分あってるだろう。

つまり、

1. naclsdk version で行われている（であろう）アップデートによる
証明書エラーを回避するために、新しい証明書をcpする。

2. naclsdk version でアップデートを行う。

3. 証明書が巻き戻ったので、再度新しい証明書をcpする。

4. naclsdk install pepper_49

という流れになってる。


>>301で言った意味不明な修正というのはこのこと。
ちゃんと調べれば、アップデート処理をスキップする方法があるかもしれない。
という意味で、マシなやり方がありそうだがと書いた。

もしDockerfileにしていなければ、気づかない間に更新されてるというこの挙動に
気づくことはなかっただろう。>>303で書いたDockerやっていてよかったというのはこのこと
だが、こういう理由は"例外的"な事例


な？わかるだろ？この質の違い。やるならここまでやれっていうんだよ。詰めが甘すぎる。
やってみた、（よくわかってないけど）うごいた、共有します。
qiitaにはこんな程度の質の悪い情報ばかりある。うんざりするわ。

分かりづらかったかもしれないので補足

naclsdkのアップデート処理はnaclsdk versionだけでなく
（おそらく）全てのコマンドで実行される。
もちろん naclsdk install pepper_49 でも。

証明書を一回コピーするだけだと

1. naclsdk install pepper_49 実行時に
2. アップデートが走りファイルが巻き戻り
3. その後にpepper_49のインストールが行われる

ので証明書が古いというエラーになる。
naclsdk install pepper_49 実行時にアップデート処理が走らないように
先にnaclsdk versionでアップデート処理だけを行わせている。

説明書を読まずに、でたらめにやって、たまたま出来たとか言ってるからだろ

自分で読むのが嫌だから、
他人に説明書を読まして、解説させようと思ってるのが明らかw

そんなのに付き合う必要もないし、丁寧に解説する必要もない。
「説明書を読め」で終わりw

各アプリの説明書は、Docker の事じゃないから！

お二人様､どうもありがとうございます｡
お二人様のレスバトルのおかげで､無事Mozcのapk作れました｡
NaCl SDKの部分を>>301に書き換えただけで行けました｡

しかし､これ分からないでしょ
普通に考えて､証明書が切れてるとか素人じゃ気づかん
どうやって証明書切れてるって分かったんですか？
SSLのバージョンアップかなんかで昔の証明書全部無効になったとか？

しかも､証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
これもどうやってわかったのですか？

まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！

>>323
SSL関係のエラー ≒ 証明書の有効期限切れｗ
証明書には有効期限がある。どんな証明書も時間が経てば切れる。

ちゃんと読めばわかるが読まなくてもわかる。だいたいそれ。いつもそれ。どうせそれ。古そうだと思ったら特にそう。
2位はSSLライブラリが入ってない、3位はライブラリが古い・バグが有る

> 証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
ちゃんとコードを追っていっても突き止められただろうが、単に「naclsdk install pepper_49」で検索して見つけただけ。
真っ先に https://github.com/google/mozc/issues/437 にたどり着くし、
そこからリンクされてる https://groups.google.com/forum/#!topic/native-client-discuss/ViBofmhWpyM の最後に書いてある。
その人は証明書を再生成したり自分のgithubにアップしてるようだが。
>>297のコメントアウトする方法もこのリンク先に書いてある。

ここまでで頭は使ってない。いつものやつね。でググっておしまい。

証明書の有効期限切れの対策は、証明書を新しくするか証明書を無視すること。

コメントアウトしてるのはソースコードの変更内容から、証明書を無視する方法だろうなとわかるが
>>297では証明書を無視してるのにhttplib2をアップデートしてるのはおかしいと気づく
SSL周りはセキュリティ関連で時代ともに更新されるからなにかの変更に対応してないことも
考えられるが証明書を無視してるのだからその影響は小さい。
バグが有る可能性もゼロではないが有名ライブラリで可能性は低い。

dockerを抜けるとか意味不明なことをやってるし明らかなミスがあるから
こんなの広まったら困るしスレ違いだが重い腰を上げた

ソースコード書き換えはやりたくないし、証明書を新しくできるならその方がいい。よってコメントアウトする方法はなし。
httplib2のアップデートは必要性に懐疑的だったので消してみたらやっぱり動いた。それだけ。
証明書は個人のgithubリポジトリを参照するのは嫌だったのでopenlsslコマンドで再生成しようと思ったが、
opensslをdockerに入れるのも嫌だったので /etc以下にあるやつ使えるんじゃね？と思って試しに使ってみたら動いた。
その後でUbuntu 14.04であっても更新されてるかと気づいた

ただcacerts.txtを新しくしても元に戻ったり意味不明な挙動をしたからその原因追求に時間がかかった。
その理由がわかったから>>297はあんな中途半端なものを出したんだなと理解した。

だが俺は書いてあるものを鵜呑みにはしない。見て理解して変な所や無駄な所は直す。
やってみて動いたからそれでお終い、はい情報共有〜なんてことはしない。

> まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！
スレ違いだからよそでやれ

ID:9LX+LUV7

この手のアホばっかりだな

アホは背伸びしてDockerでやらなくて良いぞ

などとぶつくさ文句をいうだけなのであった

アホというか、単なる暇人だよな。
エラーメッセージ出てりゃ誰だってググればゴールにたどり着く。

宮下剛輔が、テスト駆動開発(TDD)で使う、Ruby のRSpec を真似て作ったツール、
Ruby製のServerspec を使って、

CI/CD ツールのCircleCI, TraviceCI などを使って、Docker のテストをやりまくれば良いのでは？

>>297-298
みたいにゴールじゃなく明後日の方向にたどり着いてるやつもいるけどなｗ

>>330
Dockerのテストは意味不明。

Dockerはアプリに環境を付加しただけだから
アプリのテストをやれば良いんだよ。

>>330
serverspecはなんか違うんだよなって思うところがあって、
名前で訂正するならば、servicespecにするべきだと思っている。

例えば、トップページのこれなんだけど、
describe package('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_installed }
end

httpdパッケージがインストールされてることをテストする必要はないと思ってる。
なぜならhttpdパッケージをインストールするっていうのはansibleなどに
書いてあるわけで単なる二重定義でしかない。
本当にやるべきは、httpdサービスが動いていること。

それに関して、以下のようにやっているから良いだろと思うかもしれない。
describe service('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_enabled }
it { should be_running }
end

でもこれは何を調べているのだろうか？ apache2プロセスがいることだろうか？
もちろん違う。systemdなどの情報をチェックしている。だがsystemdで問題ないからと言ってサービスが必ず動いているとは限らない。
動いているけど正しく設定されていない場合がある。また、標準パッケージをやめてdockerを使うようにするかもしれない。
Linux版homebrewを使うかもしれない。サービスとしてみれば正しく動いてるのにテストで失敗することになる。

これはサービスのテストをしていないのが原因
本当にやるべきテストは特定のポートに接続して想定したレスポンスが返ってくるとか、
特定のコマンドが正しく実行できるかだろう。

serverspecがpackageやserviceで抽象化している理由はわかるが、それにより何のテストをしているのか不明確になり、
そしてテストではなく単なる構成管理ツールとの二重定義になってしまっている。
Dockerに関しても、Dockerのテストをやるのではなく、Dockerで作った"もの"のテストをやるべきである。

5chに長文書き込める情熱は正直ちょっと羨ましい

素人は、Dockerfile さえ、まともに書けていないから、

1行でも追加したら、
まず、httpd がインストールされたことを、Serverspec で確認すればよいのでは？

次に、httpdが起動したら、
また起動したかどうかを、Serverspec で確認する

統合テストは、curl, wget, Selenium WebDriver などで、web サーバーへアクセスして、

実際のDOM を取得するとか、画像を撮影するなど、すれば？

>>334
もっとアツクナレヨ

>>335
それやったことある？

ある大きな欠点のせいで、それ簡単にはいかないよ。

やってみてねってことね。

vagrantfileもそうだけどdockerfileとかはそもそも何に対するソリューションなの？
1000大規模の鯖を迅速にスケールしたいという問題に対しては確かに有効だとは思うけど
それ以外の人には殆ど関係ない。
何か存在しない問題に対するソリューションを提供されて、そのソリューションに対する
テスティングフレームワークも提供されて、仕事としてのWEBサービスのというミッションからは
どんどん離れていく気がするね。
興味在る奴は良くこんな事やるよ。

>>340
またかよｗ何度も言ってるだろ。
一言で言えば可搬性

開発したアプリをあちこちに簡単にデプロイできるようにするもの。
デプロイ先は実機Linuxだけじゃない。
手元のWindowsやMac、仮想マシンでも物理マシンでもOK
大規模なクラスタの上いデプロイすることもできる。

さらに同じPC上に複数デプロイすることもできる。
（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

お前のマシンで俺が作ったアプリ（最新版rubyとソースからビルドする○○が必要です！）を
動かすとき、手順書無しで作れると思うか？ Dockerなら最小一行で動かすことができる。

>>341
まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

>さらに同じPC上に複数デプロイすることもできる。
>（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

これも全く同じ。なんでVMにそれが出来ないと思うの？
まるでVMに問題があってその問題をdockerが解決するの様に宣伝されるから
なんのこっちゃ？となる。

>Dockerなら最小一行で動かすことができる。

OVAを解答してダブルクリックする。
終わり。

>>342
> まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

え？ まさかVMでイメージ作って、
そのイメージをMacやLinuxやクラウドの仮想マシンで動かすって話してるの？

どうやって？

例えば、AWSやGCPは仮想マシンとしてKVMを使ってるけど
その仮想マシンで動くVMイメージの形式って何？
そのVMイメージをMacやLinuxで使えるの？

>>342
> OVAを解答してダブルクリックする。

どうやってAWSやKVMでOVAファイルを使うの？
いや、無理だからさｗ あんた無理しないほうが良いよｗ

Infrastructure as code (IaC)

GUI・コマンド入力などで環境構築すると、再現性がない。
手順書に、手順を書いておかなければいけない

コマンドの打ち間違いも生じるから、
環境構築ツールのコードで書いておくべき！

OVAファイルをmacOSで使うにはどうしたら良いんだろうねｗ

>>343
意味わかんね。
そんな事やる必要ないだろ？クラウド上で動くのは本番機であり検証機であり
公式なもの。しかも1回やったら終わり。
何故そこが問題だと思うのか解からない。
前に言ったように1000大規模なら確かに問題であろうとは思う。
とりあえずウチは２，３０台で運用しているけどそれが問題になった事は無い。

>>347
「やる意味がわからない」っていうはお前の問題だろ。
お前が理解できないだけ。それはお前自信で解決しろ。

で、結局できないんでしょ？
その作ったOVAファイルを、AWSやGCPで動かす。
そしてそのOVAをWindowsやmacOSで動かすってことが

>>345
その弊害としてmozcのような例が在る。
IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
これはdockerの実践ガイドなんかにも書かれていたけど、dockerfileの
パブリックリポジトリ使うときはそのリポジトリのみならず、ubunntuならubuntu
なんかの「外部の」リポジトリに依存するから、ある日突然build出来なるなる事は
ある、だから一度build出来たらイメージをバックアップすべし、的なことを書いて
唖然としたわ。
mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
と思ったんだろうね。

>>346
Macでは動かさない。ESXiだろ？
君が言っているのはDockerfileをvagrantで動かすにはどうしたら良いんだろうね？
と言っているに等しい。

>>348
それがdockerのメリットなの？本当にその程度？
それなら、相当多くの人にとって別にdockerというのは有難がる
モノでも何でもない、という気しかしない。

>>350
ほらもうできなくなったｗ
可搬性無いじゃん。ESXi使わないと動かないだろ。
そのESXiはWindowsのWSLなどと同居できない。
ライセンスの問題でクラウドのVMで使用できない。

>>351
> それがdockerのメリットなの？本当にその程度？
いや、もっとメリットは有る。
だからまず手始めに、そのOVAをイメージを一切変更することなく
WindowsやmacOSで動かす方法書いてみ

>>349
> IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
SSL証明書が古くなって接続先サーバーにに接続できないんだけど
仮想マシンでどうやって解決するの？ｗ

まさかビルド済みのDockerイメージを使えば解決する話を出さないよね？ｗ

> mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
> と思ったんだろうね。

ブーメラン、ブーメラン

つまりVM作る価値がないからOVAファイルがないと？ｗ

>>352
>ほらもうできなくなった

おれ自身が普段使わない、という意味なんですが・・
MacにVMWwareWorkstation入れれば普通に動くだろ。

>>355
普段使わないなら話にならんな。
俺が質問しても的はずれな答えしか来ないだろう。

お前が普段使っているのを言え
お前が俺の質問に正しく答えられると自身があるものを言え。
普段どのOSでOVAファイルを使ってるんだ？

>>356
OVAとかは、これで終わりな。
可搬性がない、という事は当てはまらない。
以上。

>>357
逃げるの？まだ質問の一歩目なんだけど？
その後いろいろとOVAではできないことがあるんだけど

>>358
何つーか君のために、そんな作業するのがだるすぎる。
可搬性の話だよな？じゃあ、もっと手前で、

�@windowsにvmware workstation入れる。
�A何でも良いから適当にOSつくる
�Bそのファイルをマックにコピる。
�Cmacにvmware workstation入れる。
�Cマックで�Bを開く。

自分でやってみれば？

OVAファイルではできないこと。
ブラウザから http://localhost:8080 で接続できない。

できるというのなら、その手順を一行で書いてみてね。

docker run -d -p 8080:8080 image
↑可搬性があるからこんなに簡単にできる。
どのOSでも同じやり方、ポート番号を変えたければ引数を変えるだけ

こんなのは序の口

>>359

�@windowsにvmware workstation入れる。
�A何でも良いから適当にOSつくる ← ここが手動。これ笑う所なｗｗｗｗ
�Bそのファイルをマックにコピる。
�Cmacにvmware workstation入れる。
�Cマックで�Bを開く。

>>340
> それ以外の人には殆ど関係ない。
あなたにとっては、少なくとも関係ないだけですね。
まぁ、頑張ってねっ！

>>360
>OVAファイルではできないこと。
>ブラウザから http://localhost:8080 で接続できない。

Serverspec でテストすれば？

command(コード)で、汎用コマンドも実行できる。
ping, wget, curl とか

Selenium WebDriver を使った、Ruby スクリプトも実行できるかな？

>>361
OSの仮想化技術なんだから当然だろ？
君は何の技術か意味を理解しているの？
何かこういう書き込み見てると、コイツ何処まで理解して話してるんだろうな？と言う気がするね。
2つの全然違う技術をゴチャにしている

>>360
/etc/hosts

IPアドレス 起動したOS
http://起動したOS

> docker run -d -p 8080:8080 image

そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
言ってしまえばDockerが内部にリバースプロキシを持っているだけだけど、
これも、そうだね。存在しない問題に対するソリューション。
君はこれによって、何の問題を解決するんだい？

余程の事が無い限り誰もこんな事を遣りたいとは思わない。
余程の事が在る人は自前でリバースプロキシ構築する。
例えばMozcのDocker作った人がこれを有難がる事は絶対にない。

一方で標準としてネットワークをこの構成にしてしまった為に>>173と言う疑問はすぐに出る。
俺も全く同じ感想。

総じて君の言うdockerの利点はそもそも存在しない問題というか、恐ろしくニッチな何かに対する
利点を鬼の首でも取ったかの様に喧伝するから、こちらに全く伝わらない。

「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、
XXと言う方式にしている、と言う言い方をしなければ、ごく一般的なITのエンジニアや顧客を
納得させることは出来ない。

>>364
＞2つの全然違う技術をゴチャにしている
全くの別物であるdockerと汎用の仮想マシンを比較する意味なんてないからお前の疑問もまるごと解決だな
さようなら

>>364
> ごく一般的なITのエンジニアや顧客を納得させることは出来ない。
別に納得させなくて良いよ。

>>365
いやいや逃げなよ？まだ質問の一歩目なんだろｗ？

まだやってんのかよ。

>>363

> Serverspec でテストすれば？

？ なに使ってもlocalhostで接続できないじゃん

>>364
> OSの仮想化技術なんだから当然だろ？

だからDockerとは違うって言ってるんだろ？
お前意味不明だな。Dockerと同じことができないって言ってるのに

「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

だーかーらー、Dockerと同じことできないじゃんｗ


> そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？
ほらまた一つ。VMではできないことが増えたｗ

仮想マシンを使った問題は、mozcの例でわかる。
仮想マシンじゃ、古いバイナリしか持っておけないんだよ。
最新のソースコードを持ってきてビルドしたいときに
古いOVAファイルは全く役たたない

これもVMでは無理なことの一つ

なぜmozcを作ってる人は、仮想マシンを使わなかったのか？
理由はわかるよね？

> 「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、

だから、可搬性。
作ったイメージをあちこちに持っていける。

OVAファイルを作れば同じことができる？
どうやってawsやgcpで動かすのさ？
KVM使ってるんだぞ。

さて、VMではできないこと＝Dockerが解決してることを一つ追加。

Dockerは最新のソースコードから簡単に素早くビルドしてイメージを作ることができる。

仮想マシンはタダの仮想マシンでしかない。
仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない
新しいソースコードからイメージを生成できない。

>>369
>お前意味不明だな。Dockerと同じことができないって言ってるのに
>「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

お前が意味不明だろｗ
いつの間に何が出来て何が出来ない、と言う話になったのｗ？

>今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？

Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
教育コストが掛かると>>173は言っている。

XXができてYYが出来ないと言う話をするのなら、Dockerは物理マシンA上に立てたAAと言うマシンが
物理B上に立ってたBBと言うマシンと通信したいと言うだけで、スゲー面倒くさいことをしなければならない。

>仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない

逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
実務では、当たり前だが、そういう事は多く存在する。君の指摘は大体実務を無視してるけどね。
出来ないことの列挙もそう。普通に訊いて「だから何？」と思うものばかり。

>>372
>OVAファイルを作れば同じことができる？
>どうやってawsやgcpで動かすのさ？

だから本番機と開発機は別だっていってるでしょ。
相変わらず、実務を無視した指摘ばっかりしている。
そこで可搬性が無いのは寧ろメリットだろ。
仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
動かしたら情報漏洩が簡単すぎて大問題だわ。

とてもあたまがわるそう

亞北ネル

まあネットワーク周りとか、どう見てもデメリットでしかないことを
XXが出来る！スゲーだろｗとか言い出すからね・・・。
自分で問題を作って、その解決策を自分で提供して俺スゲーVMにゃ出来ねーだろとかｗ
訊いてるこっちはポカーンだよ。

>>373
実務じゃ多少古くても動作確認済みのバイナリをとっておいて使うので、
動くか分からない最新ソースコードをネットから拾ってビルドなんて、実験段階のPoC作成ぐらいでしかやらない。

Dockerが好きなのは分かったけど、比較が素人丸出しだから、これ以上の恥の上塗りはやめた方がいいよ。

やらないんじゃなくてできない
開発中に毎日数回ソースコードコミットしたら
新しくしなきゃいかんのに馬鹿じゃないのかこいつｗ

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・新しいソースコードからVMイメージをを作成できない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる

まだまだ増えます。

>>378
ネットワークは仮想マシン弱いよ？

例えばデータベースの仮想マシンを作る
アプリの仮想マシンを作る。
この二台の仮想マシンをどうやって接続する？

dockerは簡単に繋げられるし、変更もできるから
イメージに一切手を加えることなく、
開発時はローカルのMacに２つを動かして
本番環境では、別々の仮想マシン上に配置することができる
柔軟性が高い。

>>374
> 逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
何も大変なことはない。（プライベート）リポジトリにpushするだけ
OVAファイルは？いちいちファイル転送してダブルクリックするの？
dockerならrunするだけで新しいイメージも古いイメージも自由に使えるのに

> 仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
VMはエクスポートするしか無いんだよなｗ
ソースコードからビルドするということができない
dockerでエクスポートなんかシない



リストに追加

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・ソースコードを新しくするたびにVMイメージを作成しなければいけない
・イメージが大きすぎて古いイメージをとっておくのが大変
・docker runのように簡単に新旧のイメージを使う方法がない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる
・本番環境と開発環境で同じものを使えない
・環境を複製するときは既存のものをエクスポートしなければいけない。ゼロからの作り方がわからないから

>>382
だから、何？
結論は？

>>383
レス待ち。

最終的な答えは前から言ってる通り、VMはdockerの代わりにならないし
その逆にdockerもVMの代わりにならない。全く別のもの。

あとdockerないと不便すぎる。VMイメージーのコピーなんてやってられない。

ggrks

>>384
つまり比較すること自体が無意味で
>>382
の書き込みはバカ丸出しということですね。
わかります。

>>387
> つまり比較すること自体が無意味で
最初からそう言ってる。VMはDockerとはぜんぜん違う。

VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ
>>382の書き込みはバカ丸出しに言ってる

> Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
> 無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
> 教育コストが掛かると>>173は言っている。

VMを使うと教育コストが掛からないとバカが言っている。
このことを覚えておこう。バカ丸出しにこれがブーメランとして帰ってくることになるだろう

>>388
「狂人の真似とて大路を走らば、即ち狂人なり」

>>390
もしかしてお前が、バカ丸出しのバカか？
さっさとレスしろ。VMはDockerの代わりにならんだろうが

>>391
他人だよ

いつまで執着してるんだよ。

この話題が出るたびだよｗ

>>388
お前、>>167だろ？日本語読めずに勝手に脳内で変な補完して話すからすぐ分かるよ。

> VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ

誰もこんな事は言ってない。

結論　VMがあろうがなかろうがdockerは必要

Linuxディストリビューション自体の配布には使えないから
VMが無くなる事はない
でもアプリの配布は特にできない理由がない限りdockerイメージだな

Dockerイメージでやりにくいのはカーネル設定の指定
コンテナに特権を与えれば変更は出来るが、同一のマシンで動いているすべてのアプリケーションに影響を与えるので注意が必要

Elasticsearchのhelmチャートが
vm.max_map_countを変更するのに特権付きのコンテナを使うが
それが嫌な場合は自分でOSに設定すればよい

まだやってんのかよ(2回目)。

hyperkubeやk3sを使えばdockerでKubernetesを動かすことさえ可能
他のコンテナを立ち上げたりするので特権が必要だが

>>395
多分君は、自分の出したdockerの利点に対する意見を否定されれた瞬間に
Docker自体を否定されたと感じているんだろうね。
否定しているのは君の意見、というだけだから。

>>375
それは管理ポリシーの問題じゃね？Linuxデスクトップは不便で利用者少ないからウィルスに強いと言っているのと同じだぞ

vmに対するdockerの利点で重要なのは開発者視点ではリソースを食わない＝金がかからないことだろう
これはマンパワーの不足している現在経営的にも重要で
新興国の開発者を取り込むのにvmでは進まないのだ

新興国だけではないぞ
日本の新人開発者の多くはノートを好み貧弱な環境で開発している
vm動かすリソースは無い

dockerはマンパワーを得るためにも有効なのです

>>399
俺が言ってる意見は、Dockerのメリットなのだから
俺の意見を否定することは、Dockerのメリットを否定することになるはずだが？

それとも、俺が言ってることとは別に、Dockerのメリットが他にあるって言いたいの？
俺の意見を否定して、Dockerを否定しないっていうのは、そういうことになるはずだけど

ちなみに俺はDockerのメリットをまだ全て書いてない

あと（あのバカが）「VMでも（頑張れば）できる」って言ってるだけで
俺が言ってるDockerのメリットを否定されたところはないはずだけど？