Docker Part3
■ このスレッドは過去ログ倉庫に格納されています
>>205 docker内で実行するのではなく、 Dockerfileを書きましょう。 そういえばみんな手書きでDockerファイル書いてる? バッシュヒストリーとか行動をDockerファイル化するツールとか存在するの? 手作業はたいてい試行錯誤するのにその内容がそのまま使えるわけ無いだろw イメージの構築手順をコード化できるのがDockerのいいところなのに 必要なとこだけメモっとけよ >>205 元々UbuntuとかDebianベースのDockerイメージにはsudoさん入ってなくね? Dockerコンテナ内での実行ならexecする時にユーザー変更出来るからパスワードもない rootユーザーなら須藤さんなしでaptを実行できるが docker execで実行してもコンテナを消した時に消える コンテナって、儚い 普通はベースイメージに何か追加するときはDockerファイルに書いて Dockerfileを配布か CIツールにDockerイメージのビルドとレジストリへのプッシュをさせて レジストリのURLを配布 >>209 execのときにユーザー変更なんてあまりしないなぁ。 普通はユーザー変更するならDockerfileのUSERで変更する。 たまにアプリがrootでは動かないようになってて そういうときにUSERで一般ユーザー権限になるぐらいだな そういうイメージをメンテナンスするときぐらいか? execでユーザー変更するのは。 ともかく、またDockerイメージをVMの代わりに使おうとしてるような臭いがするが DockerっていうのはDockerfileを使ってイメージを作るものだよ アプリの配布を楽にするために、アプリにユーザーランドを全てくっつけるために使う。 sudoが必要になることはまず無い。 >>205 コンテナイメージは何をお使いですか? sudoなしで試してみるとどうですか? 管理者は、CentOS なら、ユーザーをwheel グループに追加するのでは? visudo で、/etc/sudoers を開いて編集するとか、間違えると恐ろしい手順! Debian 系は、知らないけど >>207 ヒストリーは、head .bash_history と入力すると、 以下のように行区切りで、コマンドが表示される だから、こういう単純なテキストファイルを作って、Docker に含めて、コピーすれば? man unzip exit man gunzip | less exit >>212 別にlivebootで /etc/sudoers あたりをいじればいいでしょ。 これやってMozc/Androidをインストールしようとしてます。 https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md Set up Ubuntu 14.04 Docker container $mkdir ubuntu14.04 && cd ubuntu14.04 $curl -O https://raw.githubusercontent.com/google/mozc/master/docker/ubuntu14.04/Dockerfile $sudo docker build --rm -t $USER/mozc_ubuntu14.04 . $sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04 をやりました。 次に、 $sudo docker run -it --name docker1 012345abcde /bin/bash でDockerにコンテナを作り、ログインしました。 Build Mozc for Android: $python build_mozc.py gyp --target_platform=Android $python build_mozc.py build -c Debug android/android.gyp:apk をやりました。 mozc.pyというファイルがないです。 ビルド出来ません。どうしたらいいですか? ちなみにwget使えないのでファイルダウンロードできません。 apt installも出来ません > $sudo docker run -it --name docker1 012345abcde /bin/bash > でDockerにコンテナを作り、ログインしました。 そんな手順があるわけない スレ違いだしリンク先を読む気はさらさらないが、 Dockerを使ったビルドでやることは決まってる。 1. Dockerのインストール。Dockerを使う以上これは自分で準備する必要がある。 2. ビルドスクリプトを動かす言語、つまりその場合はpythonを準備する必要がある。 3. ビルドスクリプト。ソースからのビルドならソースに付いてるだろ。 以上。準備するのはこれだけ。 まともなビルドスクリプトであればDockerを直接触ることはない。 せいぜい不要になったものを削除するぐらいだろう ビルドに必要なものは勝手に準備してくれる。 Dockerコンテナの中に入って作業することなど無い >>214 プログラミング少年? 子供には優しく教えてあげよう。 >Build Mozc for Android: > >python build_mozc.py gyp --target_platform=Android >python build_mozc.py build -c Debug android/android.gyp:apk って書いてあるよ。 中学生以上なら頑張って英語読もうね。 おっと、俺は日本語を読んでなかった。 手順にコンテナに入れなんて書いてないよ。 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++の開発経験しか無いんじゃないだろうか 経験が浅すぎる >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 >>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でも動くとかそういう話はしてないw 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で試してたはずなんだが なんつーかDockerて誕生してから5年経過してると思うけど 未だこんなレベルなのか・・・。 >>250 馬鹿じゃね?お前に何が分かるんだよ? 相変わらずこのスレには禄でもない奴が住んでるな どっか消えろよ。 >>249 未だにWindowsでネイティブ動作しない事? Windowsにもコンテナはあって、 Dockerはそれに対応してるから Windowsネイティブで動作する。 通常はパソコン買ったらWindowsなので、 どちらかと言ったらLinuxを使うほうがわざわざ それ抜きにしても開発ツールとかオフィスソフトとか 結局Windowsを使うことになるので、 Windowsで何でもできると助かる。 Windowsは・・つかわんな。 たまに使うと、アップデートが動き出して、そのまま電源ブチッと。 そのうち起動しなくなるんだよな。。 OSシェア9割のwindowsを使わないと宣うDocker使いw Docker過疎化不可避やなw 最も何年経ってもサーバーサイド以外じゃ普及してないけど。 ん?たった一人使わないって人が出てきて、理由も意味不明 それに賛同って自作自演かいな?w 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専用スレ【周辺ツールの話厳禁】」 とかスレ立てれば?誰も見ないだろうけどw CI/CDの話をしたいなら、専用のスレを建てるべきでは? CI/CDの話がしたい訳ではなく何処から見ても間違った 書込みが在るから突っ込んだだけ。 >>266-272 CI/CDは>>274 の使い方が本筋なのに>>267 はAと言う機能の開発中の話しを しており>>266 は多分それ自体が何の話か分かってない。 >>282 時系列が逆 >>267 はAと言う機能の開発中の話しをしているのに、 そこに後からやってきた>>274 がCI/CDの話を持ち込んだから 関係ない話をするなと言われている。 開発体制にもよるからな ベストプラクティスは現場によって変わるのよね Dockerの使い方然り >>283 いやいや>>266 が最初にCICDの話し振ってるだろ。 読めよ。そこでCICDを念頭に話が進んでるのに それ以降のやり取りが全部トンチンカンだから >>274 と言っている。 >>286 多分これだろうなと言うアタリは在るけど、ビルドに30分以上掛かるから 自分の仕事ならともかく、匿名掲示板の誰かのためにやる気は無いw エンジニア全員に30分以上のビルドを強要するとか、これもDockerのデメリットだろうね。 マジで作者はVM上で作って「sudo docker build --rm -t $USER/mozc_ubuntu14.04 」した 後のイメージをovaでおいとけよ、と思うね。 そうすりゃ未来永劫同じ状態から作業開始できるのに、Dockerfileだとたった2年でもう使えなくなるとかw >>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分待った挙句に失敗して時間を無駄にすると言うことも無い。 と言っているのはビルドの次の作業から開始してビルドをしないんだから 「時間を無駄に」することも無い、と言っている。 ビルド失敗の原因がどうのこうのなんて関係ない もうお前、時間の無駄だから俺にレスするな。 コストの概念の一切無い暇人と会話しても同じ風景見ても出てくる 結論は正反対なだけだw Mozcの人がDockerで困ってるんだろ? 解決してやれよw >>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 コンテナから抜けるとか書いてあるところを見て なにかおかしいと気づけなければいけない。 目が節穴、まだまだやのうw もし解説がほしければ、そのようにレスしてくれれば 解説するよ?推測で良ければだけどw それにしても、これDockerでやっていてよかった"例外的"な事例だな 実機やVMでやっていたら、再現性とれなくて、もっとハマっていたと思う。 >>301 何で俺の書き込み見て必死に追従してんの? 昨日やってやれよw >>304 スレ違いだからやらないと言った。 しかしクソコードが広まるのは世の中のためにならない ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる