[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
215: 2019/11/18(月)05:11 ID:526otgY3(1/2) AAS
> $sudo docker run -it --name docker1 012345abcde /bin/bash
> でDockerにコンテナを作り､ログインしました｡
そんな手順があるわけない
216: 2019/11/18(月)06:33 ID:526otgY3(2/2) AAS
スレ違いだしリンク先を読む気はさらさらないが、
Dockerを使ったビルドでやることは決まってる。
1. Dockerのインストール。Dockerを使う以上これは自分で準備する必要がある。
2. ビルドスクリプトを動かす言語、つまりその場合はpythonを準備する必要がある。
3. ビルドスクリプト。ソースからのビルドならソースに付いてるだろ。
以上。準備するのはこれだけ。
まともなビルドスクリプトであればDockerを直接触ることはない。
せいぜい不要になったものを削除するぐらいだろう
ビルドに必要なものは勝手に準備してくれる。
Dockerコンテナの中に入って作業することなど無い
217: 2019/11/18(月)07:56 ID:ESYqS5lO(1/2) AAS
>>214
プログラミング少年？
子供には優しく教えてあげよう。
>Build Mozc for Android:
>
>python build_mozc.py gyp --target_platform=Android
>python build_mozc.py build -c Debug android/android.gyp:apk
って書いてあるよ。
中学生以上なら頑張って英語読もうね。
218: 2019/11/18(月)07:57 ID:ESYqS5lO(2/2) AAS
おっと、俺は日本語を読んでなかった。
手順にコンテナに入れなんて書いてないよ。
219(1): 2019/11/18(月)10:46 ID:C4AZd6Pu(1) AAS
Dockerの利点のlibに依らないってスタティックビルドすりゃええやんって気もする
220(1): 2019/11/18(月)10:54 ID:NkkjQGwg(1) AAS
>>219
ウェブサービスで使われるスクリプト言語は
ソースファイルがそのまま必要だし、
バイナリにできるとは限らないし、例えバイナリにできたとしても、
ffmpegコマンドを呼び出すなんてのはスタティックビルドにできないし
考えが浅すぎるよ
221: 2019/11/18(月)12:48 ID:yWgPvH2u(1) AAS
>>220
全体的に同意だが
ffmpegはバイナリ置いとけば呼び出せるのでは？
222: 2019/11/18(月)12:52 ID:rYgoyQ9U(1/7) AAS
そのffmpegが依存しているものは？
apt-getで簡単に入るものに対して頑張ってスタティックビルドするの？
ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが
223(1): 2019/11/18(月)13:39 ID:3lFA7L7g(1/4) AAS
いやそもそもDockerという環境の為に普通のビルド方法を変更すること自体
どうかと思うが？Docker以外の環境ではMakefile書き直すの？
224(1): 2019/11/18(月)14:33 ID:3lFA7L7g(2/4) AAS
>>214
そもそもこれ、最初のビルドは上手くいくの？
gitにアップしたのが2017年12月？
ssl絡みでdocker buildがエラーになるはずだけど？
225(1): 2019/11/18(月)15:38 ID:rYgoyQ9U(2/7) AAS
>>223
Dockerは環境じゃないんだが？
この場合は、buildってやったら、ビルドバイナリを生成するツールってだけ
226(1): 2019/11/18(月)16:43 ID:3lFA7L7g(3/4) AAS
>>225
dockerが環境で在るかどうかなんて、どうでも良い話。
単にDockerのためにMakefileを書き換えるというなら違和感を感じる
といっているだけ。
227: 2019/11/18(月)16:58 ID:rYgoyQ9U(3/7) AAS
>>226
わざとやってんのか本気で馬鹿なのか
後者なんだろうけど、お前の言うMakefileの中で
Dockerを使ってビルドしてるだけの話
228: 2019/11/18(月)17:00 ID:rYgoyQ9U(4/7) AAS
スタティックビルドの話でもそうだが
C/C++の開発経験しか無いんじゃないだろうか
経験が浅すぎる
229: 2019/11/18(月)17:01 ID:rYgoyQ9U(5/7) AAS
makeだけがビルドツールではない。
ヒントな
230: 2019/11/18(月)17:07 ID:3lFA7L7g(4/4) AAS
>ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが
こんな紛らわしい書き方するからだろ。
configure一発でいけるなら別に大変でも何でもない。
231: 2019/11/18(月)17:09 ID:rYgoyQ9U(6/7) AAS
> configure一発でいけるなら別に大変でも何でもない。
configure一発でいけないから大変
232(1): 2019/11/18(月)17:14 ID:rYgoyQ9U(7/7) AAS
Docker使えば普通にapt-get使って、それをそのまま一つのイメージにすることができる。
このイメージを使えばどの環境でも同じように動く。
どの環境でも動くようにするために、スタティックビルドすればいいじゃんと言うが、
オレオレビルドなんて、今の時代はやらない上に、
スタティックビルドにするために、いろんなライブラリをかき集めて
configureを通すとか時間の無駄。
Dockerなら普通にapt-get使って、どこでも動くイメージが作れる。
233: 214 2019/11/18(月)20:55 ID:fwqLgOPw(2/5) AAS
みなさんありがとうございます
>>224
これですね､多分
なんか赤文字連発したり途中で終わってる感抜群だしで､
Dockerfileのビルド自体失敗してるくさい
234: 214 2019/11/18(月)20:56 ID:fwqLgOPw(3/5) AAS
これUbuntu18.04LTS使用だとDockerfile書き直せばいけるの？
てか､Dockerの中身をそのままDocker使わずに普通にコマンドラインで打っても行ける？
235(1): 214 2019/11/18(月)21:00 ID:fwqLgOPw(4/5) AAS
dockerfile見るとこうなってるじゃん
$ apt install -y clang python pkg-config git curl bzip2 unzip make
やっぱ､これらのコマンドすらインストールされてないから､ビルド失敗してるわ
コマンド打ってもコマンドなしになるもん
236: 214 2019/11/18(月)21:04 ID:fwqLgOPw(5/5) AAS
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
237: 2019/11/19(火)00:19 ID:TB1GOjb/(1/4) AAS
>>235
それは全く関係ない
238(2): 2019/11/19(火)01:50 ID:H229ozOy(1) AAS
>>232
windows とlinuxでコンテナの互換性ないよ。同一OS上は可能だが、何処でもは無理
239: 2019/11/19(火)02:00 ID:TB1GOjb/(2/4) AAS
>>238
だからWindowsとmacOSではLinux仮想マシンを使ってるんだよ。
結果、Windows（とmacOS）上でもLinux用のDockerコンテナがそのまま使える
240: 2019/11/19(火)02:19 ID:TB1GOjb/(3/4) AAS
それと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ストアからインストールする
単体のサーバーアプリ相当になるだろう。
241: 2019/11/19(火)02:22 ID:TB1GOjb/(4/4) AAS
>>238
あと、当たり前だが、どこでも同じように動くというのは
「"Linux用Dockerが動く環境なら"どこでも同じように動く」という意味だ。
さすがにFreeBSDでもSolarisでもPS5でも動くとかそういう話はしてないｗ
242: 214 2019/11/19(火)21:32 ID:BbWOlht1(1) AAS
mもしかして､Android版Mozcのapk作るのって
ここにあるソースとAndroidStudioだけで出来る？
AndroidStudioならSnapにあるから楽なんだけど
外部ﾘﾝｸ:github.com
243: 2019/11/19(火)21:56 ID:4mU598Ua(1) AAS
もう完全なるすれ違い。
244: 2019/11/19(火)22:18 ID:bNC5wdZW(1) AAS
Docker 19.03.5リリースされたけど、Mac版でまれにフリーズする問題、まだ直ってないね。
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
外部ﾘﾝｸ:github.com
245: 2019/11/20(水)08:58 ID:S7eWFdSu(1/2) AAS
WSL2がWindows10のSlowRingにも来た
不安定で、かつ頻繁にアップデートするFast Ringじゃなくても
dockerが動かせる
246: 2019/11/20(水)09:05 ID:Ea4P6MqO(1/2) AAS
ん？前から来てなかったっけ？
別件でfast ringに変えたけど、
ちょっと前までslow ringで試してたはずなんだが
247: 2019/11/20(水)09:07 ID:S7eWFdSu(2/2) AAS
11月11日に来たみたいだ
ちょっと前と言えば前だけど
外部ﾘﾝｸ:blogs.windows.com
248: 2019/11/20(水)09:25 ID:Ea4P6MqO(2/2) AAS
これだな。WSL 2対応のDocker Desktop
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
249(2): 2019/11/20(水)12:28 ID:CdtAMkQV(1/2) AAS
なんつーかDockerて誕生してから5年経過してると思うけど
未だこんなレベルなのか・・・。
250(1): 2019/11/20(水)12:31 ID:ggOPHuIR(1) AAS
>>249
お前は5年前から何も変わってないなｗ
251: 2019/11/20(水)13:11 ID:CdtAMkQV(2/2) AAS
>>250
馬鹿じゃね？お前に何が分かるんだよ？
相変わらずこのスレには禄でもない奴が住んでるな
どっか消えろよ。
252: 2019/11/20(水)14:53 ID:/X658f56(1) AAS
>>249
未だにWindowsでネイティブ動作しない事？
253: 2019/11/20(水)15:03 ID:3GvUfUkB(1) AAS
Windowsにもコンテナはあって、
Dockerはそれに対応してるから
Windowsネイティブで動作する。
254: 2019/11/20(水)21:23 ID:sHwSvmkR(1/2) AAS
わざわざwindows使う必要はないよね
255: 2019/11/20(水)21:31 ID:LkT1k2Et(1) AAS
通常はパソコン買ったらWindowsなので、
どちらかと言ったらLinuxを使うほうがわざわざ
それ抜きにしても開発ツールとかオフィスソフトとか
結局Windowsを使うことになるので、
Windowsで何でもできると助かる。
256: 2019/11/20(水)23:51 ID:sHwSvmkR(2/2) AAS
君の事情を前提にされてもね
257: 2019/11/21(木)01:09 ID:vRlrhYkO(1) AAS
Windowsは・・つかわんな。
たまに使うと、アップデートが動き出して、そのまま電源ブチッと。
そのうち起動しなくなるんだよな。。
258: 2019/11/21(木)01:23 ID:ad2tUsdT(1) AAS
使わんのに文句言ってるのが意味わからんわｗ
259: 2019/11/21(木)06:51 ID:WFHWRF4b(1/7) AAS
使わない理由、参考になるわ
260: 2019/11/21(木)07:14 ID:GapdKj+E(1) AAS
使わない理由なんてどこかに書いてあったっけ？
261: 2019/11/21(木)07:28 ID:WFHWRF4b(2/7) AAS
windowsを使わない理由、参考になるなと。
262: 2019/11/21(木)07:35 ID:N+RiIX1p(1/6) AAS
OSシェア9割のwindowsを使わないと宣うDocker使いｗ
Docker過疎化不可避やなｗ
最も何年経ってもサーバーサイド以外じゃ普及してないけど。
263: 2019/11/21(木)07:37 ID:65iJLiNO(1/4) AAS
ん？たった一人使わないって人が出てきて、理由も意味不明
それに賛同って自作自演かいな？ｗ
Docker Desktop for Windowsあるんだし普通に使ってるよ。
WSL2に対応したDocker Desktopの登場楽しみ。
いろいろ改善されてるんだろうな。
264: 2019/11/21(木)07:49 ID:WFHWRF4b(3/7) AAS
人間が作業するOS
コンテナが動作する環境としてのOS
分けて
265: 2019/11/21(木)08:01 ID:65iJLiNO(2/4) AAS
そこは人間が作業するOSじゃなくて
コンテナイメージを作成するOSとした方が分かりやすい。
Windowsでコンテナイメージを作って
Linuxでコンテナを動作させる
典型的なパターン
266(2): 2019/11/21(木)08:06 ID:WFHWRF4b(4/7) AAS
リポジトリへのpushをトリガにCICDで作りましょう
267(2): 2019/11/21(木)08:07 ID:65iJLiNO(3/4) AAS
いや開発中の話。アプリのソースコードを修正するたびに
pushしないといけないとかやってられない。
ローカルで開発しローカルでテストするのが普通
268: 2019/11/21(木)08:10 ID:WFHWRF4b(5/7) AAS
限定しないで
269: 2019/11/21(木)08:16 ID:65iJLiNO(4/4) AAS
限定してるのはお前じゃね？
限定しないなら、開発中の話をしてもいいよね。
270: 2019/11/21(木)08:18 ID:WFHWRF4b(6/7) AAS
典型的なビルドパターンの話かと思ったら
いや開発中の話って言い出すから
271: 2019/11/21(木)08:31 ID:A30K4AWa(1) AAS
俺は最初から開発の話しかしてないが？
仮にビルドの話だと思ったとしても、
その後で開発の話だって言ってるんだから、
その後の「限定しないで」はおかしい。
開発の話だと気づいたなら、そこでビルドの話に
限定しようとしてはいけない。
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なら最小一行で動かすことができる。
上下前次1-新書関写板覧索設栞歴
あと 661 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s