[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
272: 2019/11/21(木)08:57 ID:WFHWRF4b(7/7) AAS
ビルドってイメージのビルドのことだけど、アプリのビルドと思ってるってことはない？
273: 2019/11/21(木)09:11 ID:/owMVVXl(1/5) AAS
Windows上でLinuxアプリは直接動かないって知ってる？
Dockerイメージにしてから動かすんだよ。
ソースコードを修正するたびにDockerイメージを作るだろ。
そのたびにいちいちpushとかしないって話をしてる。
274(4): 2019/11/21(木)09:29 ID:N+RiIX1p(2/6) AAS
ここ本当に実務で使ってる人居るの？
CICDはデプロイ、リリースする時の話
開発時ABCDEとかいろんな機能を同時に開発される
このうちBCEだけリリースするとなったらCICDで、と言う話では？
（元のブランチにBCEをインテグレートする）
ABCDEが混在してるローカル環境では当然ローカルで開発して
ローカルでテストする。
単体試験も通らないのにCICDとかある訳無いじゃん。
>典型的なビルドパターンの話かと思ったら
>いや開発中の話って言い出すから
これも意味分かんね。
開発してない時にビルドなんてしないだろ。
275(1): 2019/11/21(木)09:42 ID:/owMVVXl(2/5) AAS
>>274
それがDockerの話と何の関係があるの？
Dockerはどこでも使えるんだから、
CI/CDに限定するなよってだけだろ
276: 2019/11/21(木)09:45 ID:/owMVVXl(3/5) AAS
例えば上の方でうざかった、mozcのビルドでも
Dockerを使ってるわけだが、これはCI/CDですかって話
これは大雑把に言えば、Dockerをビルドツールとして使ってる例
277: 2019/11/21(木)09:47 ID:/owMVVXl(4/5) AAS
× Dockerはどこでも使えるんだから、
○ Dockerはどこでも色んな用途で使えるんだから、
278: 2019/11/21(木)10:20 ID:N+RiIX1p(3/6) AAS
>>275
じゃあお前だけ「Docker専用スレ【周辺ツールの話厳禁】」
とかスレ立てれば？誰も見ないだろうけどｗ
279: 2019/11/21(木)10:24 ID:/owMVVXl(5/5) AAS
CI/CDの話をしたいなら、専用のスレを建てるべきでは？
280: 2019/11/21(木)10:59 ID:N+RiIX1p(4/6) AAS
CI/CDの話がしたい訳ではなく何処から見ても間違った
書込みが在るから突っ込んだだけ。
281: 2019/11/21(木)11:18 ID:HDHYI6wX(1/2) AAS
間違っている点を指摘せよ
282(1): 2019/11/21(木)11:39 ID:N+RiIX1p(5/6) AAS
>>266-272
CI/CDは>>274の使い方が本筋なのに>>267はAと言う機能の開発中の話しを
しており>>266は多分それ自体が何の話か分かってない。
283(1): 2019/11/21(木)12:12 ID:HDHYI6wX(2/2) AAS
>>282
時系列が逆
>>267はAと言う機能の開発中の話しをしているのに、
そこに後からやってきた>>274がCI/CDの話を持ち込んだから
関係ない話をするなと言われている。
284: 2019/11/21(木)13:20 ID:RlDz2JW5(1) AAS
開発体制にもよるからな
ベストプラクティスは現場によって変わるのよね
Dockerの使い方然り
285: 2019/11/21(木)16:33 ID:N+RiIX1p(6/6) AAS
>>283
いやいや>>266が最初にCICDの話し振ってるだろ。
読めよ。そこでCICDを念頭に話が進んでるのに
それ以降のやり取りが全部トンチンカンだから
>>274と言っている。
286(2): 214 2019/11/22(金)06:39 ID:V7Ju8Agz(1) AAS
お前ら､そんなことよりMozc公式のソース使ってMozcのapk絶対にビルド出来ないぞ
やっぱソースがおかしいの？
誰か試してみて
ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
AndoroidStudio使ってもだめだった
外部ﾘﾝｸ:github.com
外部ﾘﾝｸ[md]:github.com
外部ﾘﾝｸ:github.com
287(2): 2019/11/22(金)07:06 ID:QgSJ5ulH(1/4) AAS
>>286
多分これだろうなと言うアタリは在るけど、ビルドに30分以上掛かるから
自分の仕事ならともかく、匿名掲示板の誰かのためにやる気は無いｗ
エンジニア全員に30分以上のビルドを強要するとか、これもDockerのデメリットだろうね。
マジで作者はVM上で作って「sudo docker build --rm -t $USER/mozc_ubuntu14.04 」した
後のイメージをovaでおいとけよ、と思うね。
そうすりゃ未来永劫同じ状態から作業開始できるのに、Dockerfileだとたった2年でもう使えなくなるとかｗ
288(1): 2019/11/22(金)07:17 ID:uIlZ/kOu(1/6) AAS
>>287
ビルドに時間がかかるのはDocker関係ないだろ
ほかスレでDocker使わないでやってやれよ。
289(1): 2019/11/22(金)07:48 ID:QgSJ5ulH(2/4) AAS
>>288
>>287のやり方なら、ビルドに時間をかけるのは作者が1回だけ。
ビルドした「後」のイメージを配るからダウンロードした開発者が
もう一度やる必要は無い。
そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
290: 2019/11/22(金)08:11 ID:uIlZ/kOu(2/6) AAS
>>289
だからDockerは開発者のためだってことだよ。
VMイメージを配布するぐらいなら
ビルド済みのバイナリを配布すればいいだけじゃん。
開発者（そしてビルドしたい人）が楽にビルドするためにDockerがあるんだよ。
開発者がDockerでビルドしたら、同じ手順で他の人もビルドできる。
Dockerのビルドが失敗してる原因は、curlでとってくる外部パッケージの更新に
対応してないからでVMを使ってもビルドは失敗する。
外部パッケージまでVMに含めて配布しろって言うなら、
Dockerでも同じことはできる。
アホか
291(1): 2019/11/22(金)08:12 ID:uIlZ/kOu(3/6) AAS
だいたい、元のやつが
> なにやってもビルドで失敗します｡
> Docker内でやってもUbuntu18.04上でやっても失敗します｡
> AndroidStudioでやってみたけどこれもだめです｡
って言ってるだろw
VMでやっても失敗すると思わなかったのか？
292(1): 2019/11/22(金)08:33 ID:QgSJ5ulH(3/4) AAS
>>291
平日に連投できると思ったら、君はきっとニートなんだろうね。
> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
ポイントはここだろ？
時間単価のクソ高いエンジニアにこんな強要するなよって話でしかない。
>対応してないからでVMを使ってもビルドは失敗する。
リビルドして失敗するのは別にかまわない。
先ず動いてるところを見せろよって話。
30分以上時間つぶして動きもしないとかクソ以外の何者でもない。
総じて「コスト」と言う概念を一切無視して話するから、話が全く通じてない。
293(1): 2019/11/22(金)08:36 ID:uIlZ/kOu(4/6) AAS
>>292
30分待った挙げ句失敗するのは、
VM使っても同じだって言ってるんだが？
もしかして失敗する原因わかってない？
curlでとってくるzipが新しくなって、ビルドできなくなってるんだよ。
VMでもcurlでzipをとってくるなら同じように失敗するし、
そのzipをVMに入れて配布すればいいって言うなら、
Dockerでもリポジトリに入れて配布すればいい
294(1): 2019/11/22(金)08:46 ID:QgSJ5ulH(4/4) AAS
>>293
マジ馬鹿なの？
>リビルドして失敗するのは別にかまわない。
と言ってるじゃん。
> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
と言っているのはビルドの次の作業から開始してビルドをしないんだから
「時間を無駄に」することも無い、と言っている。
ビルド失敗の原因がどうのこうのなんて関係ない
もうお前、時間の無駄だから俺にレスするな。
コストの概念の一切無い暇人と会話しても同じ風景見ても出てくる
結論は正反対なだけだｗ
Mozcの人がDockerで困ってるんだろ？
解決してやれよｗ
295: 2019/11/22(金)08:49 ID:uIlZ/kOu(5/6) AAS
>>294
> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
ポイントはここなんだろ？
リビルドして失敗するのは構わないなら、
お前が言った30分は何の問題もないだろ
VMでも30待った挙げく失敗するってのわかってるか？
それともDockerはキャッシュがあるから、途中で失敗したら
そこから再開できるので時間が無駄にならないのを知らんのか？
296: 2019/11/22(金)08:52 ID:uIlZ/kOu(6/6) AAS
> ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
と書いてあるから、最初からDockerの話題じゃない。
だからこのスレでやるのは間違いだって言ってる。
297(5): 2019/11/24(日)10:15 ID:gVQp9hOZ(1/5) AAS
>>286
※亀
※プロンプト>はホスト、$はコンテナ内
> vim Dockerfile
L69はコメントアウト
#RUN cd nacl_sdk && ./naclsdk install pepper_49
※一旦これでBuildして最後まで抜ける
> sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
※rootでログイン
> sudo docker run -u root --interactive --tty --rm $USER/mozc_ubuntu14.04
$ apt install python-pip
$ pip install --upgrade httplib2
$ su - mozc_builder
$ 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)
$ exit
$ exit
298(2): 2019/11/24(日)10:18 ID:gVQp9hOZ(2/5) AAS
※コンテナから抜ける
> sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
> sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04
※これで「Build Mozc for Android:」も「python build_mozc.py build -c Debug android/android.gyp:apk」も通る
mozc_builder@14a128067269:~/work/mozc/src$ python build_mozc.py gyp --target_platform=Android
INFO: Generating version definition file...
INFO: Version string is 2.23.2815.103
INFO: Running: /usr/bin/python /home/mozc_builder/work/mozc/src/build_tools/ensure_gyp_module_path.py --expected=/home/mozc_builder/work/mozc/src/third_party/gyp/pylib/gyp
INFO: Building GYP command line...
INFO: Android home is set from ANDROID_HOME: /home/mozc_builder/work/android-sdk-linux
INFO: Android NDK home is set from PATH: /home/mozc_builder/work/android-ndk-r16b
INFO: Running GYP...
(略)
INFO: Done
mozc_builder@14a128067269:~/work/mozc/src$ python build_mozc.py build -c Debug android/android.gyp:apk
INFO: Running: ninja -C out_android/Debug apk
ninja: Entering directory `out_android/Debug'
[7/13] ACTION protobuf_jar: run_javac_d762657663869817d24e7174f8f37e98
（略）
BUILD SUCCESSFUL
Total time: 16 seconds
mozc_builder@14a128067269:~/work/mozc/src$
299(1): 2019/11/24(日)10:27 ID:ydYnxOIh(1/2) AAS
｢有能と無能｣っていうタイトルの現代アートの展示会場はここですか？
300: 2019/11/24(日)14:43 ID:9LX+LUV7(1/15) AAS
>>297
> L69はコメントアウト
> #RUN cd nacl_sdk && ./naclsdk install pepper_49
それだと、pepper_49 インストールされてねーだろ
あとそんな手順書くぐらいなら全部Dockerfileでやれ
まあ理由はわかるがな。ググって適当にやって
動いたのはいいがDockerfileにできなかったんだろう？
301(4): 2019/11/24(日)14:53 ID:9LX+LUV7(2/15) AAS
これがDockerfile修正の差分な。
python build_mozc.pyまではしとらんが、pepper_49 インストールできたし動くやろ？
httplib2 もいらん、L18-19のコメントアウトもいらん
もう少し解析すれば、こんな意味不明な修正じゃなくてもっとマシなやり方がありそうだが。
$ diff -u Dockerfile.old Dockerfile
--- Dockerfile.old 2019-11-24 14:48:42.027977900 +0900
+++ Dockerfile 2019-11-24 14:46:08.989689200 +0900
@@ -66,6 +66,9 @@
## NaCl SDK
RUN curl -LO 外部ﾘﾝｸ[zip]:storage.googleapis.com && 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
ENV NACL_SDK_ROOT /home/mozc_builder/work/nacl_sdk/pepper_49
302(1): 2019/11/24(日)14:57 ID:9LX+LUV7(3/15) AAS
>>299
コンテナから抜けるとか書いてあるところを見て
なにかおかしいと気づけなければいけない。
目が節穴、まだまだやのうｗ
もし解説がほしければ、そのようにレスしてくれれば
解説するよ？推測で良ければだけどｗ
303(1): 2019/11/24(日)14:59 ID:9LX+LUV7(4/15) AAS
それにしても、これDockerでやっていてよかった"例外的"な事例だな
実機やVMでやっていたら、再現性とれなくて、もっとハマっていたと思う。
304(1): 2019/11/24(日)15:22 ID:gVQp9hOZ(3/5) AAS
>>301
何で俺の書き込み見て必死に追従してんの？
昨日やってやれよｗ
305(1): 2019/11/24(日)15:29 ID:9LX+LUV7(5/15) AAS
>>304
スレ違いだからやらないと言った。
しかしクソコードが広まるのは世の中のためにならない
306(1): 2019/11/24(日)15:35 ID:gVQp9hOZ(4/5) AAS
>>305
君はエネルギーの使い方が間違ってるね。
しかも結局スレ違いじゃ無いじゃんｗ
307(1): 2019/11/24(日)15:40 ID:9LX+LUV7(6/15) AAS
>>306
意味不ｗ
お前が最初からまともなものを出してれば
俺が無駄なエネルギー使うことはなかったんだよ。
qiitaとか下手にSEOが高いからクソコードが広まりすぎて
うんざりするわ。世の中のためになることにエネルギーを使う
クソコードの排除は世の中のためだ。
> しかも結局スレ違いじゃ無いじゃんｗ
修正内容見ろよ。Dockerと関係ないだろ。物理 or 仮想マシンでも
同じ修正が必要だ。俺はお前のクソコードを修正しただけで
Dockerに関するレスをしたわけじゃない。スレ違いだが
さすがにクソコードは看過できん
308(1): 2019/11/24(日)15:44 ID:gVQp9hOZ(5/5) AAS
>>307
分かったから涙拭けよｗ
お前がどう言い繕うとも、俺のコード見て動き
始めた事はなんら変わりは無いｗｗｗ
ハズカシーｗ
309(1): 2019/11/24(日)15:47 ID:9LX+LUV7(7/15) AAS
>>308
そんなことよりお前のコードのバグ（pepper_49がインストールされてない）
というのを指摘するほうが重要。
お前のコードは一行たりとも利用してない。
お前のコードは役に立たない
310: 2019/11/24(日)15:51 ID:ydYnxOIh(2/2) AAS
どっちもありがとうやで(*‘ω‘*)
311: 2019/11/24(日)15:54 ID:9LX+LUV7(8/15) AAS
なあにいいってことよ。
シンプルかつ無駄のない正しいコードを書くのが好きだからなｗ
312(1): 2019/11/24(日)15:55 ID:8A3uNLLu(1/3) AAS
>>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 やなとかそれ位分れよｗ
それ関連のファイル修正したんだからｗ
313: 2019/11/24(日)15:57 ID:9LX+LUV7(9/15) AAS
あほやなぁｗ
> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)
というエラーで、証明書の問題だなんてすぐわかるだろ。
その時点でDockerと関係ないことは明らかだったから、
関係ないからよそに行けって最初から言ってるんだがｗ
↓
196 自分：login:Penguin[sage] 投稿日：2019/11/15(金) 04:45:41.79 ID:E8h29lNR
どっかーとかんけいないので
どっかーにいってください
314: 2019/11/24(日)15:58 ID:9LX+LUV7(10/15) AAS
> あ、ここで ./naclsdk install pepper_49 やなとかそれ位分れよｗ
やればわかるが、それ失敗する。
315(1): 2019/11/24(日)15:59 ID:9LX+LUV7(11/15) AAS
なぜかと言うと、コメントアウトしたという事実が消えてなくなるから
316(1): 2019/11/24(日)16:05 ID:8A3uNLLu(2/3) AAS
>>315
Dockerを消すなよｗ
317(1): 2019/11/24(日)16:07 ID:9LX+LUV7(12/15) AAS
>>316
Dockerのせいではない。
お前、やっぱりわかってないんだな。
俺のDockerfileの修正内容見て、疑問に思わなかったのか？
318: 2019/11/24(日)16:44 ID:8A3uNLLu(3/3) AAS
>>317
ドヤ顔で師匠面すんなよｗ
やっぱお前、俺の書込みにレスするなｗ
悪いけどお前が何を言おうと、俺の中で丸二日何もしなかった癖に
俺が書き込んだ瞬間に、必死に追従する恥ずかしい奴、と言う印象以外何も無い。
俺にとっては、>>298で
「BUILD SUCCESSFUL」これを見た瞬間にタスク（と言うか懸案）は終わり。
もう一切の興味は無い。お前が余りにもハズカシーからレスしてあげてるだけ。
じゃーなｗ
319: 2019/11/24(日)17:37 ID:9LX+LUV7(13/15) AAS
師匠面（笑） お前が、俺のことを師匠に見えてしまってるから
そんな発想が出てくるんだぞｗ
さて>>301の解説するか
まず実行して表示されるエラーの内容から証明書に問題があることはすぐにわかる。
Ubuntu 14.04だから証明書が古いんだろうなと最初は思ったが、実際は、nacl_sdkに入ってる cacerts.txt が古い（2015年）
Ubuntu自体はアップデートされてるので問題なかった。なのでファイルをコピーするだけで解決。
そう解決するはずだった。それが解決しなかった。
> RUN curl -LO 外部ﾘﾝｸ[zip]:storage.googleapis.com && 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 というファイルだから多分あってるだろう。
320: 2019/11/24(日)17:40 ID:9LX+LUV7(14/15) AAS
つまり、
1. naclsdk version で行われている（であろう）アップデートによる
証明書エラーを回避するために、新しい証明書をcpする。
2. naclsdk version でアップデートを行う。
3. 証明書が巻き戻ったので、再度新しい証明書をcpする。
4. naclsdk install pepper_49
という流れになってる。
>>301で言った意味不明な修正というのはこのこと。
ちゃんと調べれば、アップデート処理をスキップする方法があるかもしれない。
という意味で、マシなやり方がありそうだがと書いた。
もしDockerfileにしていなければ、気づかない間に更新されてるというこの挙動に
気づくことはなかっただろう。>>303で書いたDockerやっていてよかったというのはこのこと
だが、こういう理由は"例外的"な事例
な？わかるだろ？この質の違い。やるならここまでやれっていうんだよ。詰めが甘すぎる。
やってみた、（よくわかってないけど）うごいた、共有します。
qiitaにはこんな程度の質の悪い情報ばかりある。うんざりするわ。
321: 2019/11/24(日)17:51 ID:9LX+LUV7(15/15) AAS
分かりづらかったかもしれないので補足
naclsdkのアップデート処理はnaclsdk versionだけでなく
（おそらく）全てのコマンドで実行される。
もちろん naclsdk install pepper_49 でも。
証明書を一回コピーするだけだと
1. naclsdk install pepper_49 実行時に
2. アップデートが走りファイルが巻き戻り
3. その後にpepper_49のインストールが行われる
ので証明書が古いというエラーになる。
naclsdk install pepper_49 実行時にアップデート処理が走らないように
先にnaclsdk versionでアップデート処理だけを行わせている。
322: 2019/11/24(日)23:45 ID:OMG53Vpn(1) AAS
説明書を読まずに、でたらめにやって、たまたま出来たとか言ってるからだろ
自分で読むのが嫌だから、
他人に説明書を読まして、解説させようと思ってるのが明らかw
そんなのに付き合う必要もないし、丁寧に解説する必要もない。
「説明書を読め」で終わりw
各アプリの説明書は、Docker の事じゃないから！
323(1): 214 2019/11/27(水)15:33 ID:pWzU57rW(1) AAS
お二人様､どうもありがとうございます｡
お二人様のレスバトルのおかげで､無事Mozcのapk作れました｡
NaCl SDKの部分を>>301に書き換えただけで行けました｡
しかし､これ分からないでしょ
普通に考えて､証明書が切れてるとか素人じゃ気づかん
どうやって証明書切れてるって分かったんですか？
SSLのバージョンアップかなんかで昔の証明書全部無効になったとか？
しかも､証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
これもどうやってわかったのですか？
まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！
324: 2019/11/27(水)19:47 ID:e2a81Xjm(1/2) AAS
>>323
SSL関係のエラー ≒ 証明書の有効期限切れｗ
証明書には有効期限がある。どんな証明書も時間が経てば切れる。
ちゃんと読めばわかるが読まなくてもわかる。だいたいそれ。いつもそれ。どうせそれ。古そうだと思ったら特にそう。
2位はSSLライブラリが入ってない、3位はライブラリが古い・バグが有る
> 証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
ちゃんとコードを追っていっても突き止められただろうが、単に「naclsdk install pepper_49」で検索して見つけただけ。
真っ先に 外部ﾘﾝｸ:github.com にたどり着くし、
そこからリンクされてる 外部ﾘﾝｸ:groups.google.com の最後に書いてある。
その人は証明書を再生成したり自分のgithubにアップしてるようだが。
>>297のコメントアウトする方法もこのリンク先に書いてある。
ここまでで頭は使ってない。いつものやつね。でググっておしまい。
325: 2019/11/27(水)19:48 ID:e2a81Xjm(2/2) AAS
証明書の有効期限切れの対策は、証明書を新しくするか証明書を無視すること。
コメントアウトしてるのはソースコードの変更内容から、証明書を無視する方法だろうなとわかるが
>>297では証明書を無視してるのにhttplib2をアップデートしてるのはおかしいと気づく
SSL周りはセキュリティ関連で時代ともに更新されるからなにかの変更に対応してないことも
考えられるが証明書を無視してるのだからその影響は小さい。
バグが有る可能性もゼロではないが有名ライブラリで可能性は低い。
dockerを抜けるとか意味不明なことをやってるし明らかなミスがあるから
こんなの広まったら困るしスレ違いだが重い腰を上げた
ソースコード書き換えはやりたくないし、証明書を新しくできるならその方がいい。よってコメントアウトする方法はなし。
httplib2のアップデートは必要性に懐疑的だったので消してみたらやっぱり動いた。それだけ。
証明書は個人のgithubリポジトリを参照するのは嫌だったのでopenlsslコマンドで再生成しようと思ったが、
opensslをdockerに入れるのも嫌だったので /etc以下にあるやつ使えるんじゃね？と思って試しに使ってみたら動いた。
その後でUbuntu 14.04であっても更新されてるかと気づいた
ただcacerts.txtを新しくしても元に戻ったり意味不明な挙動をしたからその原因追求に時間がかかった。
その理由がわかったから>>297はあんな中途半端なものを出したんだなと理解した。
だが俺は書いてあるものを鵜呑みにはしない。見て理解して変な所や無駄な所は直す。
やってみて動いたからそれでお終い、はい情報共有〜なんてことはしない。
> まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！
スレ違いだからよそでやれ
326: 2019/11/28(木)20:53 ID:P2UjCEfy(1/2) AAS
ID:9LX+LUV7
この手のアホばっかりだな
327: 2019/11/28(木)20:55 ID:P2UjCEfy(2/2) AAS
アホは背伸びしてDockerでやらなくて良いぞ
328: 2019/11/28(木)21:00 ID:hVuKTC+d(1) AAS
などとぶつくさ文句をいうだけなのであった
329: 2019/11/28(木)21:48 ID:HhHInLOm(1) AAS
アホというか、単なる暇人だよな。
エラーメッセージ出てりゃ誰だってググればゴールにたどり着く。
330(4): 2019/11/29(金)00:00 ID:ebGLF78J(1/3) AAS
宮下剛輔が、テスト駆動開発(TDD)で使う、Ruby のRSpec を真似て作ったツール、
Ruby製のServerspec を使って、
CI/CD ツールのCircleCI, TraviceCI などを使って、Docker のテストをやりまくれば良いのでは？
331: 2019/11/29(金)03:33 ID:58TiTLbK(1/2) AAS
>>297-298
みたいにゴールじゃなく明後日の方向にたどり着いてるやつもいるけどなｗ
332: 2019/11/29(金)03:36 ID:58TiTLbK(2/2) AAS
>>330
Dockerのテストは意味不明。
Dockerはアプリに環境を付加しただけだから
アプリのテストをやれば良いんだよ。
333: 2019/11/29(金)12:06 ID:/RGupnOb(1) AAS
>>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で作った"もの"のテストをやるべきである。
334(1): 2019/11/29(金)13:10 ID:CKNktXx+(1) AAS
5chに長文書き込める情熱は正直ちょっと羨ましい
335(1): 330 2019/11/29(金)23:02 ID:ebGLF78J(2/3) AAS
素人は、Dockerfile さえ、まともに書けていないから、
1行でも追加したら、
まず、httpd がインストールされたことを、Serverspec で確認すればよいのでは？
次に、httpdが起動したら、
また起動したかどうかを、Serverspec で確認する
336: 330 2019/11/29(金)23:07 ID:ebGLF78J(3/3) AAS
統合テストは、curl, wget, Selenium WebDriver などで、web サーバーへアクセスして、
実際のDOM を取得するとか、画像を撮影するなど、すれば？
337: 2019/11/30(土)00:12 ID:PJxRldUs(1) AAS
>>334
もっとアツクナレヨ
338: 2019/11/30(土)00:29 ID:yJBQSrj9(1/2) AAS
>>335
それやったことある？
ある大きな欠点のせいで、それ簡単にはいかないよ。
339: 2019/11/30(土)00:36 ID:yJBQSrj9(2/2) AAS
やってみてねってことね。
340(2): 2019/11/30(土)11:37 ID:Se1bf1fg(1/14) AAS
vagrantfileもそうだけどdockerfileとかはそもそも何に対するソリューションなの？
1000大規模の鯖を迅速にスケールしたいという問題に対しては確かに有効だとは思うけど
それ以外の人には殆ど関係ない。
何か存在しない問題に対するソリューションを提供されて、そのソリューションに対する
テスティングフレームワークも提供されて、仕事としてのWEBサービスのというミッションからは
どんどん離れていく気がするね。
興味在る奴は良くこんな事やるよ。
341(1): 2019/11/30(土)11:48 ID:wFtP+/8O(1/12) AAS
>>340
またかよｗ何度も言ってるだろ。
一言で言えば可搬性
開発したアプリをあちこちに簡単にデプロイできるようにするもの。
デプロイ先は実機Linuxだけじゃない。
手元のWindowsやMac、仮想マシンでも物理マシンでもOK
大規模なクラスタの上いデプロイすることもできる。
さらに同じPC上に複数デプロイすることもできる。
（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）
お前のマシンで俺が作ったアプリ（最新版rubyとソースからビルドする○○が必要です！）を
動かすとき、手順書無しで作れると思うか？ Dockerなら最小一行で動かすことができる。
342(2): 2019/11/30(土)11:55 ID:Se1bf1fg(2/14) AAS
>>341
まるでそれはVMに可搬性がないかのように言っているけど実際は在る。
>さらに同じPC上に複数デプロイすることもできる。
>（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）
これも全く同じ。なんでVMにそれが出来ないと思うの？
まるでVMに問題があってその問題をdockerが解決するの様に宣伝されるから
なんのこっちゃ？となる。
>Dockerなら最小一行で動かすことができる。
OVAを解答してダブルクリックする。
終わり。
343(1): 2019/11/30(土)12:21 ID:wFtP+/8O(2/12) AAS
>>342
> まるでそれはVMに可搬性がないかのように言っているけど実際は在る。
え？ まさかVMでイメージ作って、
そのイメージをMacやLinuxやクラウドの仮想マシンで動かすって話してるの？
どうやって？
例えば、AWSやGCPは仮想マシンとしてKVMを使ってるけど
その仮想マシンで動くVMイメージの形式って何？
そのVMイメージをMacやLinuxで使えるの？
344: 2019/11/30(土)12:22 ID:wFtP+/8O(3/12) AAS
>>342
> OVAを解答してダブルクリックする。
どうやってAWSやKVMでOVAファイルを使うの？
いや、無理だからさｗ あんた無理しないほうが良いよｗ
345(1): 2019/11/30(土)12:23 ID:vSs97oU5(1/2) AAS
Infrastructure as code (IaC)
GUI・コマンド入力などで環境構築すると、再現性がない。
手順書に、手順を書いておかなければいけない
コマンドの打ち間違いも生じるから、
環境構築ツールのコードで書いておくべき！
346(1): 2019/11/30(土)12:25 ID:wFtP+/8O(4/12) AAS
OVAファイルをmacOSで使うにはどうしたら良いんだろうねｗ
347(1): 2019/11/30(土)12:31 ID:Se1bf1fg(3/14) AAS
>>343
意味わかんね。
そんな事やる必要ないだろ？クラウド上で動くのは本番機であり検証機であり
公式なもの。しかも1回やったら終わり。
何故そこが問題だと思うのか解からない。
前に言ったように1000大規模なら確かに問題であろうとは思う。
とりあえずウチは２，３０台で運用しているけどそれが問題になった事は無い。
348(1): 2019/11/30(土)12:32 ID:wFtP+/8O(5/12) AAS
>>347
「やる意味がわからない」っていうはお前の問題だろ。
お前が理解できないだけ。それはお前自信で解決しろ。
で、結局できないんでしょ？
その作ったOVAファイルを、AWSやGCPで動かす。
そしてそのOVAをWindowsやmacOSで動かすってことが
349(1): 2019/11/30(土)12:36 ID:Se1bf1fg(4/14) AAS
>>345
その弊害としてmozcのような例が在る。
IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
これはdockerの実践ガイドなんかにも書かれていたけど、dockerfileの
パブリックリポジトリ使うときはそのリポジトリのみならず、ubunntuならubuntu
なんかの「外部の」リポジトリに依存するから、ある日突然build出来なるなる事は
ある、だから一度build出来たらイメージをバックアップすべし、的なことを書いて
唖然としたわ。
mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
と思ったんだろうね。
350(1): 2019/11/30(土)12:37 ID:Se1bf1fg(5/14) AAS
>>346
Macでは動かさない。ESXiだろ？
君が言っているのはDockerfileをvagrantで動かすにはどうしたら良いんだろうね？
と言っているに等しい。
351(1): 2019/11/30(土)12:39 ID:Se1bf1fg(6/14) AAS
>>348
それがdockerのメリットなの？本当にその程度？
それなら、相当多くの人にとって別にdockerというのは有難がる
モノでも何でもない、という気しかしない。
352(1): 2019/11/30(土)12:49 ID:wFtP+/8O(6/12) AAS
>>350
ほらもうできなくなったｗ
可搬性無いじゃん。ESXi使わないと動かないだろ。
そのESXiはWindowsのWSLなどと同居できない。
ライセンスの問題でクラウドのVMで使用できない。
>>351
> それがdockerのメリットなの？本当にその程度？
いや、もっとメリットは有る。
だからまず手始めに、そのOVAをイメージを一切変更することなく
WindowsやmacOSで動かす方法書いてみ
353: 2019/11/30(土)12:51 ID:wFtP+/8O(7/12) AAS
>>349
> IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
SSL証明書が古くなって接続先サーバーにに接続できないんだけど
仮想マシンでどうやって解決するの？ｗ
まさかビルド済みのDockerイメージを使えば解決する話を出さないよね？ｗ
354: 2019/11/30(土)12:53 ID:wFtP+/8O(8/12) AAS
> mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
> と思ったんだろうね。
ブーメラン、ブーメラン
つまりVM作る価値がないからOVAファイルがないと？ｗ
355(1): 2019/11/30(土)13:00 ID:Se1bf1fg(7/14) AAS
>>352
>ほらもうできなくなった
おれ自身が普段使わない、という意味なんですが・・
MacにVMWwareWorkstation入れれば普通に動くだろ。
356(1): 2019/11/30(土)13:05 ID:wFtP+/8O(9/12) AAS
>>355
普段使わないなら話にならんな。
俺が質問しても的はずれな答えしか来ないだろう。
お前が普段使っているのを言え
お前が俺の質問に正しく答えられると自身があるものを言え。
普段どのOSでOVAファイルを使ってるんだ？
357(1): 2019/11/30(土)13:06 ID:Se1bf1fg(8/14) AAS
>>356
OVAとかは、これで終わりな。
可搬性がない、という事は当てはまらない。
以上。
358(1): 2019/11/30(土)13:09 ID:wFtP+/8O(10/12) AAS
>>357
逃げるの？まだ質問の一歩目なんだけど？
その後いろいろとOVAではできないことがあるんだけど
359(1): 2019/11/30(土)13:12 ID:Se1bf1fg(9/14) AAS
>>358
何つーか君のために、そんな作業するのがだるすぎる。
可搬性の話だよな？じゃあ、もっと手前で、
?windowsにvmware workstation入れる。
?何でも良いから適当にOSつくる
?そのファイルをマックにコピる。
?macにvmware workstation入れる。
?マックで?を開く。
自分でやってみれば？
360(2): 2019/11/30(土)13:13 ID:wFtP+/8O(11/12) AAS
OVAファイルではできないこと。
ブラウザから 外部ﾘﾝｸ:localhost:8080で接続できない。
できるというのなら、その手順を一行で書いてみてね。
docker run -d -p 8080:8080 image
↑可搬性があるからこんなに簡単にできる。
どのOSでも同じやり方、ポート番号を変えたければ引数を変えるだけ
こんなのは序の口
361(1): 2019/11/30(土)13:14 ID:wFtP+/8O(12/12) AAS
>>359
?windowsにvmware workstation入れる。
?何でも良いから適当にOSつくる ← ここが手動。これ笑う所なｗｗｗｗ
?そのファイルをマックにコピる。
?macにvmware workstation入れる。
?マックで?を開く。
362: 2019/11/30(土)14:12 ID:wMw6KZO2(1/2) AAS
>>340
> それ以外の人には殆ど関係ない。
あなたにとっては、少なくとも関係ないだけですね。
まぁ、頑張ってねっ！
363(1): 2019/11/30(土)14:21 ID:vSs97oU5(2/2) AAS
>>360
>OVAファイルではできないこと。
>ブラウザから 外部ﾘﾝｸ:localhost:8080で接続できない。
Serverspec でテストすれば？
command(コード)で、汎用コマンドも実行できる。
ping, wget, curl とか
Selenium WebDriver を使った、Ruby スクリプトも実行できるかな？
364(3): 2019/11/30(土)14:30 ID:Se1bf1fg(10/14) AAS
>>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のエンジニアや顧客を
納得させることは出来ない。
365(1): 2019/11/30(土)15:23 ID:3P4mm8Mh(1/2) AAS
>>364
＞2つの全然違う技術をゴチャにしている
全くの別物であるdockerと汎用の仮想マシンを比較する意味なんてないからお前の疑問もまるごと解決だな
さようなら
366: 2019/11/30(土)15:52 ID:wMw6KZO2(2/2) AAS
>>364
> ごく一般的なITのエンジニアや顧客を納得させることは出来ない。
別に納得させなくて良いよ。
367: 2019/11/30(土)15:56 ID:Se1bf1fg(11/14) AAS
>>365
いやいや逃げなよ？まだ質問の一歩目なんだろｗ？
368: 2019/11/30(土)18:35 ID:hmmzT75Z(1) AAS
まだやってんのかよ。
369(1): 2019/11/30(土)19:03 ID:yxXUcR2F(1/5) AAS
>>363
> Serverspec でテストすれば？
？ なに使ってもlocalhostで接続できないじゃん
>>364
> OSの仮想化技術なんだから当然だろ？
だからDockerとは違うって言ってるんだろ？
お前意味不明だな。Dockerと同じことができないって言ってるのに
「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」
だーかーらー、Dockerと同じことできないじゃんｗ
> そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？
ほらまた一つ。VMではできないことが増えたｗ
370: 2019/11/30(土)19:04 ID:yxXUcR2F(2/5) AAS
仮想マシンを使った問題は、mozcの例でわかる。
仮想マシンじゃ、古いバイナリしか持っておけないんだよ。
最新のソースコードを持ってきてビルドしたいときに
古いOVAファイルは全く役たたない
これもVMでは無理なことの一つ
371: 2019/11/30(土)19:05 ID:yxXUcR2F(3/5) AAS
なぜmozcを作ってる人は、仮想マシンを使わなかったのか？
理由はわかるよね？
372(1): 2019/11/30(土)19:06 ID:yxXUcR2F(4/5) AAS
> 「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、
だから、可搬性。
作ったイメージをあちこちに持っていける。
OVAファイルを作れば同じことができる？
どうやってawsやgcpで動かすのさ？
KVM使ってるんだぞ。
373(1): 2019/11/30(土)19:10 ID:yxXUcR2F(5/5) AAS
さて、VMではできないこと＝Dockerが解決してることを一つ追加。
Dockerは最新のソースコードから簡単に素早くビルドしてイメージを作ることができる。
仮想マシンはタダの仮想マシンでしかない。
仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない
新しいソースコードからイメージを生成できない。
374(1): 2019/11/30(土)21:36 ID:Se1bf1fg(12/14) AAS
>>369
>お前意味不明だな。Dockerと同じことができないって言ってるのに
>「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」
お前が意味不明だろｗ
いつの間に何が出来て何が出来ない、と言う話になったのｗ？
>今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？
Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
教育コストが掛かると>>173は言っている。
XXができてYYが出来ないと言う話をするのなら、Dockerは物理マシンA上に立てたAAと言うマシンが
物理B上に立ってたBBと言うマシンと通信したいと言うだけで、スゲー面倒くさいことをしなければならない。
>仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない
逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
実務では、当たり前だが、そういう事は多く存在する。君の指摘は大体実務を無視してるけどね。
出来ないことの列挙もそう。普通に訊いて「だから何？」と思うものばかり。
375(1): 2019/11/30(土)21:38 ID:Se1bf1fg(13/14) AAS
>>372
>OVAファイルを作れば同じことができる？
>どうやってawsやgcpで動かすのさ？
だから本番機と開発機は別だっていってるでしょ。
相変わらず、実務を無視した指摘ばっかりしている。
そこで可搬性が無いのは寧ろメリットだろ。
仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
動かしたら情報漏洩が簡単すぎて大問題だわ。
376: 2019/11/30(土)21:55 ID:3P4mm8Mh(2/2) AAS
とてもあたまがわるそう
377: 2019/11/30(土)22:01 ID:kFO69wK3(1) AAS
亞北ネル
378(1): 2019/11/30(土)22:01 ID:Se1bf1fg(14/14) AAS
まあネットワーク周りとか、どう見てもデメリットでしかないことを
XXが出来る！スゲーだろｗとか言い出すからね・・・。
自分で問題を作って、その解決策を自分で提供して俺スゲーVMにゃ出来ねーだろとかｗ
訊いてるこっちはポカーンだよ。
379: 2019/11/30(土)23:15 ID:ncKkDOM9(1) AAS
>>373
実務じゃ多少古くても動作確認済みのバイナリをとっておいて使うので、
動くか分からない最新ソースコードをネットから拾ってビルドなんて、実験段階のPoC作成ぐらいでしかやらない。
Dockerが好きなのは分かったけど、比較が素人丸出しだから、これ以上の恥の上塗りはやめた方がいいよ。
380: 2019/12/01(日)01:38 ID:J+24ZJpj(1/3) AAS
やらないんじゃなくてできない
開発中に毎日数回ソースコードコミットしたら
新しくしなきゃいかんのに馬鹿じゃないのかこいつｗ
ここまで出たVMではできないこと・不便なこと
・VMイメージ（OVAファイル）を手動で作成する必要がある
・新しいソースコードからVMイメージをを作成できない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる
まだまだ増えます。
381: 2019/12/01(日)01:42 ID:J+24ZJpj(2/3) AAS
>>378
ネットワークは仮想マシン弱いよ？
例えばデータベースの仮想マシンを作る
アプリの仮想マシンを作る。
この二台の仮想マシンをどうやって接続する？
dockerは簡単に繋げられるし、変更もできるから
イメージに一切手を加えることなく、
開発時はローカルのMacに２つを動かして
本番環境では、別々の仮想マシン上に配置することができる
柔軟性が高い。
382(3): 2019/12/01(日)01:54 ID:J+24ZJpj(3/3) AAS
>>374
> 逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
何も大変なことはない。（プライベート）リポジトリにpushするだけ
OVAファイルは？いちいちファイル転送してダブルクリックするの？
dockerならrunするだけで新しいイメージも古いイメージも自由に使えるのに
> 仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
VMはエクスポートするしか無いんだよなｗ
ソースコードからビルドするということができない
dockerでエクスポートなんかシない
リストに追加
ここまで出たVMではできないこと・不便なこと
・VMイメージ（OVAファイル）を手動で作成する必要がある
・ソースコードを新しくするたびにVMイメージを作成しなければいけない
・イメージが大きすぎて古いイメージをとっておくのが大変
・docker runのように簡単に新旧のイメージを使う方法がない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる
・本番環境と開発環境で同じものを使えない
・環境を複製するときは既存のものをエクスポートしなければいけない。ゼロからの作り方がわからないから
383(1): 2019/12/01(日)07:42 ID:OfIPuRU/(1/4) AAS
>>382
だから、何？
結論は？
384(1): 2019/12/01(日)08:25 ID:qT+FNDQS(1/13) AAS
>>383
レス待ち。
最終的な答えは前から言ってる通り、VMはdockerの代わりにならないし
その逆にdockerもVMの代わりにならない。全く別のもの。
385: 2019/12/01(日)08:28 ID:qT+FNDQS(2/13) AAS
あとdockerないと不便すぎる。VMイメージーのコピーなんてやってられない。
386: 2019/12/01(日)08:51 ID:rd9VBfP6(1) AAS
ggrks
387(1): 2019/12/01(日)09:03 ID:OfIPuRU/(2/4) AAS
>>384
つまり比較すること自体が無意味で
>>382
の書き込みはバカ丸出しということですね。
わかります。
388(2): 2019/12/01(日)09:07 ID:qT+FNDQS(3/13) AAS
>>387
> つまり比較すること自体が無意味で
最初からそう言ってる。VMはDockerとはぜんぜん違う。
VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ
>>382の書き込みはバカ丸出しに言ってる
389: 2019/12/01(日)09:12 ID:qT+FNDQS(4/13) AAS
> Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
> 無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
> 教育コストが掛かると>>173は言っている。
VMを使うと教育コストが掛からないとバカが言っている。
このことを覚えておこう。バカ丸出しにこれがブーメランとして帰ってくることになるだろう
390(1): 2019/12/01(日)09:15 ID:OfIPuRU/(3/4) AAS
>>388
「狂人の真似とて大路を走らば、即ち狂人なり」
391(1): 2019/12/01(日)09:23 ID:qT+FNDQS(5/13) AAS
>>390
もしかしてお前が、バカ丸出しのバカか？
さっさとレスしろ。VMはDockerの代わりにならんだろうが
392: 2019/12/01(日)09:33 ID:OfIPuRU/(4/4) AAS
>>391
他人だよ
いつまで執着してるんだよ。
393: 2019/12/01(日)09:37 ID:qT+FNDQS(6/13) AAS
この話題が出るたびだよｗ
394: 2019/12/01(日)09:53 ID:fdPwLs/X(1/4) AAS
>>388
お前、>>167だろ？日本語読めずに勝手に脳内で変な補完して話すからすぐ分かるよ。
> VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ
誰もこんな事は言ってない。
395(1): 2019/12/01(日)09:55 ID:qT+FNDQS(7/13) AAS
結論 VMがあろうがなかろうがdockerは必要
396: 2019/12/01(日)09:55 ID:Cg6x2/4w(1/2) AAS
Linuxディストリビューション自体の配布には使えないから
VMが無くなる事はない
でもアプリの配布は特にできない理由がない限りdockerイメージだな
Dockerイメージでやりにくいのはカーネル設定の指定
コンテナに特権を与えれば変更は出来るが、同一のマシンで動いているすべてのアプリケーションに影響を与えるので注意が必要
Elasticsearchのhelmチャートが
vm.max_map_countを変更するのに特権付きのコンテナを使うが
それが嫌な場合は自分でOSに設定すればよい
397: 2019/12/01(日)10:08 ID:eVvGELNq(1) AAS
まだやってんのかよ(2回目)。
398: 2019/12/01(日)10:10 ID:Cg6x2/4w(2/2) AAS
hyperkubeやk3sを使えばdockerでKubernetesを動かすことさえ可能
他のコンテナを立ち上げたりするので特権が必要だが
上下前次1-新書関写板覧索設栞歴
あと 604 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s