Docker Part3

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

http://www.docker.io/

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

>>173
>docker自体にログがドカドカ出す機能はないし
いつものなにか勘違いしてる系だよｗ

「あなたが作った開発アプリのログ出力機能」を
Dockerのせいにするのはおかしいと気づかなきゃいけない。

開発アプリのログを出す責任は、アプリ開発者にあるでしょ？
標準出力と、標準出力エラー出力（あとファイル）を出せるんだから
ドカドカだすのはアプリ開発者の仕事だよ

> 立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
そういう基本を理解してない人が、間違った話をした上で、難しいと言っても説得力がない

>>174
> Dockerは何故ルーター噛ます事がデフォルトになっているのか？
ルータを噛まさないで可搬性が作れるなら、提案してみれば？

ともかく、どんなサーバーでも動かせるということは、
そのサーバーで他のコンテナが動いてる可能性もある。
だからアプリがポート番号決め打ちだとかぶって困るよね。
つまりDocker自身がポート番号の変更機能を持ってなきゃいけないんだよ。

アプリ側で変更可能にしておくのが常識だけど、それだとアプリごとにやり方が異なる
そういうのをコンテナとしてまとめて、Dockerが可搬性をもたせると主張してるのだから
Dockerの仕事になる。そこでルーティング機能がでてくる。

>>175
>ルータを噛まさないで可搬性が作れるなら、提案してみれば？

ESXiのゲストOSは（AmazonのEC2も）ルータなんか噛まさないだろ。

>>176
なんでアプリの可搬性と関係ない
ゲストOSの話なんか出てくるの？

どこでも（俺の手元のMacでも）そのゲストOSとやらが動くとでも言うのか？

それにゲストOSだけ動いてもしょうがないんだけどなｗ
アプリがなければただのOS

>>178
お前のレスは兎に角、的外れ。
それしか感想は無い。
俺以外にもそう思っている奴はいる筈

的外れと言うばかりで、具体的な指摘なし

それは馬鹿にしゃべってもしょうがないから♪

という書き込みを見た人がどう思うか？
反論できな人という烙印だよ

一向に構わんね。
妄想して変なレッテルを前提に、判っても居ない癖に
禄でもない話する奴に教えてあげる必要は無い。
俺さえ分かっていればそれで良い。

>>120
ライブラリーやヘッダの依存関係が衝突するツールチェーンの環境作ってビルドするのにいいよ(´･ω･`)
例えば、MinGW-w64クロスツールチェーンとMinGW向けのビルドをする、llvmクロスツールチェーン(´･ω･`)

本番環境でも開発環境でも
同じDockerイメージを使えるのは便利だね

>>175
アプリケーションじゃなくてシステム運用保守の点でdocker自体の挙動の話。
>>174
すまん。logs -fは忘れていた。。。

もしdockerで管理するんだったらSNMPはホスト側で見とくんか？
あとグラフィカルな管理をお願いされたらportainerとかは限界あるけどみんなどう考えているんだ？

>>186
Dockerで作ったものはアプリだってわかってるか？

お前が言ってるのは、exeを実行した時のSNMPをどうすればいいんだとか
いうわけがわからん話をしてるんだが

お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
アプリが動いているかを確かめたいなら、
そのアプリに対してヘルスチェックでもすればいいだろ

Ubuntu18.04でAndroid版Mozcのapk作ろうと思ってるんだけど､
なんでDockerが必要なの?
C++だけで出来ないの？

Build Instructions
How to build Mozc in Docker: Android, NaCl, and Linux desktop builds.
How to build Mozc in OS X: OS X build.
How to build Mozc in Windows: Windows build.

>>188
Dockerの中にまとまってる「構築手順」を
お前がそのまま実行すればできるよｗ

構築が簡単にできるように
Dockerでビルド環境を整えてるんだろ
そういうときに使う道具なんだから

つくづくDockerはアプリ開発者のための道具だってわかるよなｗ

仮想マシンの代替だと思ってると、こういう使い方が思いつかない。

なんか知らんが､いっぱいインストールして
環境ぐちゃぐちゃにならないように､Docker使ってるの？

まあ､Dockerインストしてやったほうが楽なのかな？

Docker自体は、デーモン常駐させるのにあんまし向いてないような気がする…

ちょっと質問なのですが､
Dockerの中でやったほうがいいというのはわかったのですが､
mozc.pyというのはどこにあるのですか？
ファイルが見当たりません
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md

海のもずくとなったのだ

ありました､すみません｡
mozc-master/srcにありました｡

Docker使わずにPythonコマンドうったら

$ python build_mozc.py gyp --target_platform=Android
INFO: Generating version definition file...
INFO: Version string is 2.23.2815.103
CRITICAL:
==========

CRITICAL: GYP does not exist at /home/user_name/mozc-master/src/third_party/gyp/gyp_main.py.
Please run "git submodule update --init" to check out GYP.
If you want to use system-installed GYP, use --gypdir option to specify its location.
e.g. "python build_mozc.py gyp --gypdir=/usr/bin"

CRITICAL:
==========

となりました｡
どうすればいいですか？

どっかーとかんけいないので
どっかーにいってください

>>187
相変わらずズレた事言ってんなコイツは・・・。

>>197
じゃあお前が反論しろ
何も言い返せないのにグチグチレスだけしなくていい

>>198
ズレている、が反論以外の何者でもない。

>お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
>アプリが動いているかを確かめたいなら、
>そのアプリに対してヘルスチェックでもすればいいだろ

何を言ってるんだお前は・・・。

なるほど。その内容が反論できる限界ってわけだ。

>>195
そういうふうにならないためにdockerがあるんですがね

Docker Hub から、好きなコンテナを探せば良いだけだろ

そしたら、その中に環境一式が入っている

好きなコンテナ探して使うとか、そういう使い方じゃないよ。

Docker Hubのコンテナの正しい使い方は
1. Docker公式が用意しているものを使う
2. ディストリ公式が用意してるものを使う
3. 何らかのアプリであれば、そのアプリの公式が用意してるものを使う

それ以外は、参考イメージに過ぎない。
そんな環境が入ってるかもしれないとか思って探すものじゃないｗ

$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> aaaaaaaaa 10 minutes ago 5GB

となってしまってるのだが､

$ sudo docker run -it --name nonedocker none /bin/bash

だと起動しない｡
ImageID指定して起動する方法ないの？

出来ました
なぜnoneになってしまってたのだろう･･･

あと､ググっても出てこないのだが､
docker内でsudo apt install unzipやろうとしても
パスワードが分からなくて出来ません｡

デフォルトパスワードってなんですか？
パス設定してないのだが

>>205
docker内で実行するのではなく、
Dockerfileを書きましょう。

そういえばみんな手書きでDockerファイル書いてる？
バッシュヒストリーとか行動をDockerファイル化するツールとか存在するの？

手作業はたいてい試行錯誤するのにその内容がそのまま使えるわけ無いだろｗ
イメージの構築手順をコード化できるのが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++の開発経験しか無いんじゃないだろうか
経験が浅すぎる

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とかある訳無いじゃん。

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

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