Docker Part3

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

http://www.docker.io/

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

>>238
だからWindowsとmacOSではLinux仮想マシンを使ってるんだよ。
結果、Windows（とmacOS）上でもLinux用のDockerコンテナがそのまま使える

それとWindowsのWSL2では仮想マシンでLinuxカーネルをそのまま使うので
Linux用のDockerコンテナが、公式サポートと言っていいレベルになる。
つまり今はDockerが仮想マシンイメージを作っているが、それが不要になる。

それだけかと思うかもしれないが、大きな違いが2つある。
一つはメモリ使用量。一般的には仮想マシンにある一定のメモリを割り振らなければいけないが
WSL2ではMSがカーネルに手を入れているため、Windowsとメモリを共有できる。
Linux上でDockerコンテナを動かしたのと殆ど変わらないメモリ使用量になる。
これは従来の仮想マシンを使うmacOSでは難しい（ある程度は仮想マシンのメモリを開放しているようだが）

そしてもう一つは、これは俺の予測だが、Ubuntuなどのディストロを使わずに
DockerがWSL2上でそのまま動くようになる可能性がある。
今、Dockerが提供しているDockerサーバーはHyperV上でDockerDesktopVMという
Linuxカーネルを使用するための軽量仮想マシンを動かしているが、
WSL2では複数のディストロがLinuxカーネルを共有する。

Dockerが動作するのに必要なのは、原則としてLinuxカーネルだけなので
WSL2でLinuxカーネルがすでに動いているとしたら、理論上はDockerサーバーは
WSL2の/initから直接起動することが可能となる。
将来のDockerは今のUbuntuと同じように、Microsoftストアからインストールする
単体のサーバーアプリ相当になるだろう。

>>238
あと、当たり前だが、どこでも同じように動くというのは
「"Linux用Dockerが動く環境なら"どこでも同じように動く」という意味だ。
さすがにFreeBSDでもSolarisでもPS5でも動くとかそういう話はしてないｗ

mもしかして､Android版Mozcのapk作るのって
ここにあるソースとAndroidStudioだけで出来る？
AndroidStudioならSnapにあるから楽なんだけど
https://github.com/google/mozc/tree/master/src

もう完全なるすれ違い。

Docker 19.03.5リリースされたけど、Mac版でまれにフリーズする問題、まだ直ってないね。

for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done

https://github.com/docker/for-mac/issues/3873

WSL2がWindows10のSlowRingにも来た

不安定で、かつ頻繁にアップデートするFast Ringじゃなくても
dockerが動かせる

ん？前から来てなかったっけ？
別件でfast ringに変えたけど、
ちょっと前までslow ringで試してたはずなんだが

11月11日に来たみたいだ
ちょっと前と言えば前だけど

https://blogs.windows.com/windowsexperience/2019/11/11/releasing-windows-10-insider-preview-build-19013-into-the-slow-ring/

これだな。WSL 2対応のDocker Desktop
https://forest.watch.impress.co.jp/docs/news/1191014.html

なんつーかDockerて誕生してから5年経過してると思うけど
未だこんなレベルなのか・・・。

>>249
お前は5年前から何も変わってないなｗ

>>250
馬鹿じゃね？お前に何が分かるんだよ？
相変わらずこのスレには禄でもない奴が住んでるな
どっか消えろよ。

>>249
未だにWindowsでネイティブ動作しない事？

Windowsにもコンテナはあって、
Dockerはそれに対応してるから
Windowsネイティブで動作する。

わざわざwindows使う必要はないよね

通常はパソコン買ったらWindowsなので、
どちらかと言ったらLinuxを使うほうがわざわざ

それ抜きにしても開発ツールとかオフィスソフトとか
結局Windowsを使うことになるので、
Windowsで何でもできると助かる。

君の事情を前提にされてもね

Windowsは・・つかわんな。
たまに使うと、アップデートが動き出して、そのまま電源ブチッと。
そのうち起動しなくなるんだよな。。

使わんのに文句言ってるのが意味わからんわｗ

使わない理由、参考になるわ

使わない理由なんてどこかに書いてあったっけ？

windowsを使わない理由、参考になるなと。

OSシェア9割のwindowsを使わないと宣うDocker使いｗ
Docker過疎化不可避やなｗ
最も何年経ってもサーバーサイド以外じゃ普及してないけど。

ん？たった一人使わないって人が出てきて、理由も意味不明
それに賛同って自作自演かいな？ｗ

Docker Desktop for Windowsあるんだし普通に使ってるよ。
WSL2に対応したDocker Desktopの登場楽しみ。
いろいろ改善されてるんだろうな。

人間が作業するOS
コンテナが動作する環境としてのOS

分けて

そこは人間が作業するOSじゃなくて
コンテナイメージを作成するOSとした方が分かりやすい。

Windowsでコンテナイメージを作って
Linuxでコンテナを動作させる
典型的なパターン

リポジトリへのpushをトリガにCICDで作りましょう

いや開発中の話。アプリのソースコードを修正するたびに
pushしないといけないとかやってられない。
ローカルで開発しローカルでテストするのが普通

限定しないで

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

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

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

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

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

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

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

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
それやったことある？

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