Docker Part3

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

http://www.docker.io/

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

限定しないで

限定してるのはお前じゃね？

限定しないなら、開発中の話をしてもいいよね。

典型的なビルドパターンの話かと思ったら
いや開発中の話って言い出すから

俺は最初から開発の話しかしてないが？

仮にビルドの話だと思ったとしても、
その後で開発の話だって言ってるんだから、
その後の「限定しないで」はおかしい。

開発の話だと気づいたなら、そこでビルドの話に
限定しようとしてはいけない。

ビルドってイメージのビルドのことだけど、アプリのビルドと思ってるってことはない？

Windows上でLinuxアプリは直接動かないって知ってる？
Dockerイメージにしてから動かすんだよ。
ソースコードを修正するたびにDockerイメージを作るだろ。
そのたびにいちいちpushとかしないって話をしてる。

ここ本当に実務で使ってる人居るの？
CICDはデプロイ、リリースする時の話
開発時ABCDEとかいろんな機能を同時に開発される
このうちBCEだけリリースするとなったらCICDで、と言う話では？
（元のブランチにBCEをインテグレートする）
ABCDEが混在してるローカル環境では当然ローカルで開発して
ローカルでテストする。
単体試験も通らないのにCICDとかある訳無いじゃん。

>典型的なビルドパターンの話かと思ったら
>いや開発中の話って言い出すから

これも意味分かんね。
開発してない時にビルドなんてしないだろ。

>>274
それがDockerの話と何の関係があるの？

Dockerはどこでも使えるんだから、
CI/CDに限定するなよってだけだろ

例えば上の方でうざかった、mozcのビルドでも
Dockerを使ってるわけだが、これはCI/CDですかって話
これは大雑把に言えば、Dockerをビルドツールとして使ってる例

× Dockerはどこでも使えるんだから、
○ Dockerはどこでも色んな用途で使えるんだから、

>>275
じゃあお前だけ「Docker専用スレ【周辺ツールの話厳禁】」
とかスレ立てれば？誰も見ないだろうけどｗ

CI/CDの話をしたいなら、専用のスレを建てるべきでは？

CI/CDの話がしたい訳ではなく何処から見ても間違った
書込みが在るから突っ込んだだけ。

間違っている点を指摘せよ

>>266-272
CI/CDは>>274の使い方が本筋なのに>>267はAと言う機能の開発中の話しを
しており>>266は多分それ自体が何の話か分かってない。

>>282
時系列が逆

>>267はAと言う機能の開発中の話しをしているのに、
そこに後からやってきた>>274がCI/CDの話を持ち込んだから
関係ない話をするなと言われている。

開発体制にもよるからな
ベストプラクティスは現場によって変わるのよね
Dockerの使い方然り

>>283
いやいや>>266が最初にCICDの話し振ってるだろ。
読めよ。そこでCICDを念頭に話が進んでるのに
それ以降のやり取りが全部トンチンカンだから
>>274と言っている。

お前ら､そんなことよりMozc公式のソース使ってMozcのapk絶対にビルド出来ないぞ
やっぱソースがおかしいの？
誰か試してみて

ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
AndoroidStudio使ってもだめだった
https://github.com/google/mozc
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md
https://github.com/google/mozc/blob/master/docker/ubuntu14.04/Dockerfile

>>286
多分これだろうなと言うアタリは在るけど、ビルドに30分以上掛かるから
自分の仕事ならともかく、匿名掲示板の誰かのためにやる気は無いｗ
エンジニア全員に30分以上のビルドを強要するとか、これもDockerのデメリットだろうね。

マジで作者はVM上で作って「sudo docker build --rm -t $USER/mozc_ubuntu14.04 」した
後のイメージをovaでおいとけよ、と思うね。
そうすりゃ未来永劫同じ状態から作業開始できるのに、Dockerfileだとたった2年でもう使えなくなるとかｗ

>>287
ビルドに時間がかかるのはDocker関係ないだろ
ほかスレでDocker使わないでやってやれよ。

>>288
>>287のやり方なら、ビルドに時間をかけるのは作者が1回だけ。
ビルドした「後」のイメージを配るからダウンロードした開発者が
もう一度やる必要は無い。
そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。

>>289
だからDockerは開発者のためだってことだよ。

VMイメージを配布するぐらいなら
ビルド済みのバイナリを配布すればいいだけじゃん。

開発者（そしてビルドしたい人）が楽にビルドするためにDockerがあるんだよ。
開発者がDockerでビルドしたら、同じ手順で他の人もビルドできる。

Dockerのビルドが失敗してる原因は、curlでとってくる外部パッケージの更新に
対応してないからでVMを使ってもビルドは失敗する。
外部パッケージまでVMに含めて配布しろって言うなら、
Dockerでも同じことはできる。

アホか

だいたい、元のやつが

> なにやってもビルドで失敗します｡
> Docker内でやってもUbuntu18.04上でやっても失敗します｡
> AndroidStudioでやってみたけどこれもだめです｡

って言ってるだろw
VMでやっても失敗すると思わなかったのか？

>>291
平日に連投できると思ったら、君はきっとニートなんだろうね。

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。

ポイントはここだろ？
時間単価のクソ高いエンジニアにこんな強要するなよって話でしかない。

>対応してないからでVMを使ってもビルドは失敗する。

リビルドして失敗するのは別にかまわない。
先ず動いてるところを見せろよって話。
30分以上時間つぶして動きもしないとかクソ以外の何者でもない。
総じて「コスト」と言う概念を一切無視して話するから、話が全く通じてない。

>>292
30分待った挙げ句失敗するのは、
VM使っても同じだって言ってるんだが？

もしかして失敗する原因わかってない？
curlでとってくるzipが新しくなって、ビルドできなくなってるんだよ。
VMでもcurlでzipをとってくるなら同じように失敗するし、
そのzipをVMに入れて配布すればいいって言うなら、
Dockerでもリポジトリに入れて配布すればいい

>>293
マジ馬鹿なの？

>リビルドして失敗するのは別にかまわない。

と言ってるじゃん。

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。

と言っているのはビルドの次の作業から開始してビルドをしないんだから
「時間を無駄に」することも無い、と言っている。
ビルド失敗の原因がどうのこうのなんて関係ない
もうお前、時間の無駄だから俺にレスするな。
コストの概念の一切無い暇人と会話しても同じ風景見ても出てくる
結論は正反対なだけだｗ
Mozcの人がDockerで困ってるんだろ？
解決してやれよｗ

>>294

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
ポイントはここなんだろ？

リビルドして失敗するのは構わないなら、
お前が言った30分は何の問題もないだろ

VMでも30待った挙げく失敗するってのわかってるか？

それともDockerはキャッシュがあるから、途中で失敗したら
そこから再開できるので時間が無駄にならないのを知らんのか？

> ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
と書いてあるから、最初からDockerの話題じゃない。
だからこのスレでやるのは間違いだって言ってる。

>>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

※コンテナから抜ける

> 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$

｢有能と無能｣っていうタイトルの現代アートの展示会場はここですか？

>>297
> L69はコメントアウト
> #RUN cd nacl_sdk && ./naclsdk install pepper_49

それだと、pepper_49 インストールされてねーだろ

あとそんな手順書くぐらいなら全部Dockerfileでやれ
まあ理由はわかるがな。ググって適当にやって
動いたのはいいがDockerfileにできなかったんだろう？

これが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 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
ENV NACL_SDK_ROOT /home/mozc_builder/work/nacl_sdk/pepper_49

>>299
コンテナから抜けるとか書いてあるところを見て
なにかおかしいと気づけなければいけない。
目が節穴、まだまだやのうｗ



もし解説がほしければ、そのようにレスしてくれれば
解説するよ？推測で良ければだけどｗ

それにしても、これDockerでやっていてよかった"例外的"な事例だな
実機やVMでやっていたら、再現性とれなくて、もっとハマっていたと思う。

>>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
いやいや逃げなよ？まだ質問の一歩目なんだろｗ？