Docker Part3

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

http://www.docker.io/

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

Dockerの利点のlibに依らないってスタティックビルドすりゃええやんって気もする

>>219
ウェブサービスで使われるスクリプト言語は
ソースファイルがそのまま必要だし、
バイナリにできるとは限らないし、例えバイナリにできたとしても、
ffmpegコマンドを呼び出すなんてのはスタティックビルドにできないし
考えが浅すぎるよ

>>220
全体的に同意だが
ffmpegはバイナリ置いとけば呼び出せるのでは？

そのffmpegが依存しているものは？
apt-getで簡単に入るものに対して頑張ってスタティックビルドするの？
ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが

いやそもそもDockerという環境の為に普通のビルド方法を変更すること自体
どうかと思うが？Docker以外の環境ではMakefile書き直すの？

>>214
そもそもこれ、最初のビルドは上手くいくの？
gitにアップしたのが2017年12月？
ssl絡みでdocker buildがエラーになるはずだけど？

>>223
Dockerは環境じゃないんだが？
この場合は、buildってやったら、ビルドバイナリを生成するツールってだけ

>>225
dockerが環境で在るかどうかなんて、どうでも良い話。
単にDockerのためにMakefileを書き換えるというなら違和感を感じる
といっているだけ。

>>226
わざとやってんのか本気で馬鹿なのか
後者なんだろうけど、お前の言うMakefileの中で
Dockerを使ってビルドしてるだけの話

スタティックビルドの話でもそうだが
C/C++の開発経験しか無いんじゃないだろうか
経験が浅すぎる

makeだけがビルドツールではない。
ヒントな

>ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが

こんな紛らわしい書き方するからだろ。
configure一発でいけるなら別に大変でも何でもない。

> configure一発でいけるなら別に大変でも何でもない。

configure一発でいけないから大変

Docker使えば普通にapt-get使って、それをそのまま一つのイメージにすることができる。
このイメージを使えばどの環境でも同じように動く。

どの環境でも動くようにするために、スタティックビルドすればいいじゃんと言うが、
オレオレビルドなんて、今の時代はやらない上に、
スタティックビルドにするために、いろんなライブラリをかき集めて
configureを通すとか時間の無駄。

Dockerなら普通にapt-get使って、どこでも動くイメージが作れる。

みなさんありがとうございます

>>224
これですね､多分
なんか赤文字連発したり途中で終わってる感抜群だしで､
Dockerfileのビルド自体失敗してるくさい

これUbuntu18.04LTS使用だとDockerfile書き直せばいけるの？
てか､Dockerの中身をそのままDocker使わずに普通にコマンドラインで打っても行ける？

dockerfile見るとこうなってるじゃん

$ apt install -y clang python pkg-config git curl bzip2 unzip make

やっぱ､これらのコマンドすらインストールされてないから､ビルド失敗してるわ
コマンド打ってもコマンドなしになるもん

mozcのDockerfileは､2018年1月更新となってますが､やっぱり古すぎですか？

Update the copyright year to 2018

REF_BUG=
REF_CL=180466480
REF_TIME=2018-01-01T00:00:18-08:00
REF_TIME_RAW=1514793618 -0800

>>235
それは全く関係ない

>>232
windows とlinuxでコンテナの互換性ないよ。同一OS上は可能だが、何処でもは無理

>>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 というファイルだから多分あってるだろう。