[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
99: 2020/08/28(金)12:33 ID:zYE9gZVL(2/8) AAS
インストール方法？
自分で開発したアプリのインストール方法もわからんのか？
100: 2020/08/28(金)14:11 ID:PXYaUzYG(1/2) AAS
いや他人の作ったものも使うだろ
101: 2020/08/28(金)14:53 ID:zYE9gZVL(3/8) AAS
そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろｗ
102(1): 2020/08/28(金)15:05 ID:PXYaUzYG(2/2) AAS
いやいやそうじゃなくてオープンソースのツールとかあるだろ
ネット遮断でもしてんのかお前んとこ
103: 2020/08/28(金)15:41 ID:e8Ic+DMZ(1) AAS
Dockerfileも拾えよ
104(1): 2020/08/28(金)16:42 ID:zYE9gZVL(4/8) AAS
>>102
オープンソースのものを自分でDockerfile作る意味は？
殆どのものは公式が用意してるでしょ
105(1): 2020/08/28(金)17:18 ID:O2BsRo2K(1) AAS
>>104
公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ？
106: 2020/08/28(金)17:54 ID:MXNSOP9Y(1/2) AAS
いや、自分で「マージしたDockerfile」作れよ
それが自動でできなくてゴネてるの？
107: 2020/08/28(金)18:41 ID:jq9YEzpA(1) AAS
めんどくせぇ
108: 2020/08/28(金)18:56 ID:NRktIr3W(1/2) AAS
go製ツールならバイナリ落としてくればすぐ動くが
Pvthonとかのスクリプト言語を使う系や
C/C++で書かれている物はそうも行かない
パッケージマネージャにあれば良いが
あっても古い、このパッケージもインストール必要とか面倒
glibc使ってるC/C++製ツールで動的リンクしてたら
alpineにそのまま持って行っても動かない
muslで再コンパイルするか
イメージサイズの肥大化を覚悟でglibcを入れる必要がある
109: 2020/08/28(金)18:58 ID:NRktIr3W(2/2) AAS
OSに最初から入ってるツールの扱いはどうするのか？とか考えたら
自動的にマージできるとか思うわけない
Dockerからしたら全てただのファイルであり
依存関係も把握してないし区別もしない
110(1): 2020/08/28(金)19:30 ID:D6h6IbAl(1/2) AAS
結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな
方向性としてはsnapなどのほうが正しかった
111: 2020/08/28(金)19:36 ID:MXNSOP9Y(2/2) AAS
賢いパッケージマネージャよりdockerが便利
112(2): 2020/08/28(金)19:51 ID:zYE9gZVL(5/8) AAS
>>105
> それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ
１つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで？
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに
ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか？ｗ
113: 2020/08/28(金)19:54 ID:zYE9gZVL(6/8) AAS
>>110
Dockerはパッケージマネージャーが対応してないような
自分（自社）で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。
snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。
114: 2020/08/28(金)20:05 ID:a9bICJj+(1) AAS
apacheのバーチャルホストで20個のサイトを運営するのと
1つのイメージを使って1コンテナ1サイトを作るのでは
どっちがメモリとCPU使用率が高いですか？
115: 2020/08/28(金)20:09 ID:zYE9gZVL(7/8) AAS
メモリとCPU使用率が重要なら、
1つのイメージを使って1コンテナ20サイトを作れば？
116: 2020/08/28(金)20:18 ID:zYE9gZVL(8/8) AAS
1コンテナ1サイトって発想が出るのもやっぱりいつもの
Dockerを仮想マシンの代わりだと思ってるからなんだろうか？
Dockerはアプリの代わりと考えれば、この場合apacheだとわかる
１つのapacheアプリでバーチャルホストをするのであれば
Dockerの1つのapacheアプリでバーチャルホストをすればいいだけ
そのバーチャルホストの設定を予め終わらせておいた
カスタマイズ済みapacheを簡単にデプロできるのが
Dockerのメリットなわけで
117: 2020/08/28(金)20:33 ID:pZN+Qti3(2/3) AAS
1サイトをバックエンドとフロントエンドとDBに分けても良いよ？
118: 2020/08/28(金)21:09 ID:D6h6IbAl(2/2) AAS
>>112
アホか
何でもかんでもサービスにしたら効率が悪いこともある
119: 2020/08/28(金)21:24 ID:MSjqCkB+(1) AAS
何か変なのがいる。この後どうなるか楽しみ。
120: 2020/08/28(金)21:44 ID:7j4VCa1Z(1/2) AAS
メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム
業務システムなら普通にあるよなあ
別言語でapi鯖構築してメイン言語と別言語の2コンテナ構成にするって手もないこたないけど
そのためにワザワザ別言語とそのweb apiフレームワークを習得するのはコスパ悪いだろ
こういうときは1つのコンテナに複数の言語ランタイムやパッケージをまとめちゃって素直にサブプロセス呼んだほうが製造コスパがいい
んでそういうときに公式イメージのマージができたら便利なんだがサポートされてないからDockerfileをワザワザ書かなきゃならん
コンテナを分離する間抜けなアイデアよりは遥かに楽だけどそれでもDockerfileを書く手間は残る
121: 2020/08/28(金)21:50 ID:7j4VCa1Z(2/2) AAS
>>112
ベストプラクティスは1コンテナ1責務だ
素人は1コンテナ1プロセスと間違って覚える
脱初心者を目指してるぐらいのレベルだと1コンテナ1サービスとか言い始める
122: 2020/08/28(金)22:54 ID:pZN+Qti3(3/3) AAS
docker-in-dockerとかdocker-outside-of- dockerをやれば良いんじゃね？
セキュリティについては知らん
Dockerコンテナ内からDockerを使うことについて
外部ﾘﾝｸ:esakat.github.io
123: 2020/08/28(金)23:55 ID:wNNnqhGV(1) AAS
この明後日の方向に突っ走る感じ
124: 2020/08/29(土)00:15 ID:kVmc/kdt(1) AAS
Dockerだけで云々言っている人は、
オーケストレーションまで頭がまわらないだろうし、
どないしようもないと思う。
CRIだけの世界でせいぜいがんばってください。
125(1): 2020/08/29(土)12:47 ID:74MbloCF(1) AAS
COPY --from=some/image /source/path /dest/path
Docddkerfileにこれを書いておけば
some/imageという既存Dockerイメージからファイルをコピー出来るぞ
依存関係が色々あって何をコピーしたいかわからない場合は知らん
126: 2020/08/29(土)12:53 ID:Qqt2hfOB(1/2) AAS
マージ君は自動でやってほしいんだからそんなもんお呼びでないだろう
127: 2020/08/29(土)14:16 ID:n8QTuXNc(1/4) AAS
>>125
マージには役に立たんわ
そもそも必要なファイルがどこにあるか探すのめんどくせぇーだろ
欲しいのはレイヤーをコピペする機能だよ
それかdocker最適化されたパッケージマネージャでもいいかな
128(2): 2020/08/29(土)14:43 ID:n8QTuXNc(2/4) AAS
俺たちが本当に欲しかったのってこれな
FROM alpine:latest
# ディストリ差異対応とか依存関係解決とか環境変数とかボリュームとかキャッシュクリアとかよしなにやってくれる素晴らしいdockerfile専用パッケージマネージャ
PACKAGE openjdk:11 somevendor/somepythonclitool:latest
COPY bin /myapp
ENTRYPOINT /myapp/entrypoint.sh
openjdkイメージとsomepythonclitoolイメージって形式でリリースしちゃったら再利用性が低すぎるんだわ
129(1): 2020/08/29(土)15:25 ID:CyY7ymQE(1) AAS
>>128
Dockerは○○専用に作るものなのに
それをなにに再利用するんだよｗ
130(3): 2020/08/29(土)15:44 ID:n8QTuXNc(3/4) AAS
>>129
世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない
こんな基本的なことをなんで説明しなきゃわからないんだ
131(1): 2020/08/29(土)15:49 ID:Qqt2hfOB(2/2) AAS
「よしなに」が仕様のツール誰が作るの
トラブったら>>128みたいなのに文句言われるんだろ
132: 2020/08/29(土)16:01 ID:n8QTuXNc(4/4) AAS
>>131
docker公式かツールベンダが作るんだよ当たり前だろ
133(1): 2020/08/29(土)20:04 ID:MO1Uvs8e(1/9) AAS
>>130
反論に全くなってないけど、だから何？
134: 2020/08/29(土)22:32 ID:lTv/US4g(1/8) AAS
>>133
うーんこの理解力
135: 2020/08/29(土)23:00 ID:MO1Uvs8e(2/9) AAS
ほらな、説明できない（笑）
言ってることが不明瞭の場合は聞き返してみるに限るね
136(5): 2020/08/29(土)23:05 ID:lTv/US4g(2/8) AAS
はぁ…┐(´д｀)┌ﾔﾚﾔﾚ
>>130だから同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケースが当たり前のように出てくる
そのためにはimageではなくパッケージって単位で再利用できねーと非効率的なんだよ
わかったかなボウヤ
137(2): 2020/08/29(土)23:07 ID:MO1Uvs8e(3/9) AAS
>>136
主張を繰り返せって言ってるんじゃなくて
主張の理由を言えって言ってんの
ほんと会話ができんやつだなｗ
138: 2020/08/29(土)23:09 ID:lTv/US4g(3/8) AAS
>>137
これがdockefile専用パッケージマネージャが必要な理由に見えないならもう話にならんわ
会話が通じないレベルの差があるってことだ
139(2): 2020/08/29(土)23:10 ID:MO1Uvs8e(4/9) AAS
お前が言ってるのは、ユースケースと主張だけ
理由を言ってない
140: 2020/08/29(土)23:11 ID:lTv/US4g(4/8) AAS
>>139
>>136
141(1): 2020/08/29(土)23:12 ID:lTv/US4g(5/8) AAS
>>139
>>130
142(1): 2020/08/29(土)23:13 ID:MO1Uvs8e(5/9) AAS
「同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケース」
これはユースケース
「imageではなくパッケージって単位で再利用できねーと非効率的」
これは主張
「なぜなら、・・・・」
これが理由
143(1): 2020/08/29(土)23:14 ID:MO1Uvs8e(6/9) AAS
「世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない」
これは事実
「こういう場合に、・・・」
これが理由
144(1): 2020/08/29(土)23:14 ID:lTv/US4g(6/8) AAS
>>142
>>141
145(1): 2020/08/29(土)23:15 ID:MO1Uvs8e(7/9) AAS
>>144
>>143
理由をさっさと書きましょう
146: 2020/08/29(土)23:17 ID:lTv/US4g(7/8) AAS
>>145
書いてある
あとはお前が理解するだけだ
理解する気がないなら無駄な問答が続くだけだからもうレスしなくていいよ
バイバイ
147(1): 2020/08/29(土)23:18 ID:MO1Uvs8e(8/9) AAS
お前が言った言葉の全てに対して「それは理由じゃない」と説明したんだがｗ
148: 2020/08/29(土)23:20 ID:lTv/US4g(8/8) AAS
>>147
間違った説明だから意味ない
理解する気がないならレスするな
2回目だよ
149(1): 2020/08/29(土)23:33 ID:MO1Uvs8e(9/9) AAS
俺の説明のどこが間違っているか言える？ｗ
主張じゃなくて理由を言え
150: 2020/08/30(日)00:00 ID:ZAOk4Rrf(1) AAS
できたらコテ班付けてくれませんか
誰と誰の主張がぶつかってるのか日が変わるとわからないので
151: 2020/08/30(日)11:03 ID:MLxBHRb9(1) AAS
お前らはどのコンテナセキュリティスキャナ使ってるん？
152: 2020/08/30(日)13:50 ID:Qpr/sPeC(1/9) AAS
>>149
いつものDocker原理主義者？
傍から見ていると、君が何故そんな下らない方向に持っていくのかスゲー疑問。
君が>>98に対する解決策を知っていれば教えれば良いだけ。知らなきゃ黙ってろよ。
俺はこの人がなぜ欲しががっているのか理解はできるよ。
解決策知らないから黙ってるけど。
確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？
153(1): 2020/08/30(日)14:58 ID:4F5aYT1J(1/9) AAS
> 何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？
理由を答えないからでは？
154: 2020/08/30(日)14:58 ID:4F5aYT1J(2/9) AAS
> 確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
思わないな
155: 2020/08/30(日)15:05 ID:UMRfRZsn(1/2) AAS
同じファイルを使うとか同じポートを使うとか
事情がわかってないとイメージだけマージしてもしょうがのにな
156(1): 2020/08/30(日)15:18 ID:Qpr/sPeC(2/9) AAS
>>153
理由を答えてるけど君が理解しないだけだよね？>>136はどこからどう読んでも
理由にしか見えないんだが？しかし別に理由はどうでも良いよ。
知ってるんなら答えろよ。知らないんなら黙っとけ。
スレの無駄だ。
157: 2020/08/30(日)15:21 ID:pNBhhLmO(1) AAS
そういう面倒なところを解決するためにスマートなDockerfile専用パッケージマネージャがあるといいなぁって話だろ
158(1): 2020/08/30(日)15:39 ID:UMRfRZsn(2/2) AAS
それは同一イメージ内でyumやaptを複数回使うのと何が違うの
159(1): 2020/08/30(日)15:55 ID:4F5aYT1J(3/9) AAS
>>156
じゃあ重要でない言葉をマスクしてみようか？
○○というユースケースが当たり前のように出てくる
そのためには○○できねーと非効率的なんだよ
見ての通り、理由が書いていない
160: 2020/08/30(日)15:58 ID:Qpr/sPeC(3/9) AAS
環境変数の設定やインストールの手順がわからないことがあり、
イチイチ調べてDockerfile書かないといけないから、って話じゃなかったの？
161: 2020/08/30(日)15:58 ID:4F5aYT1J(4/9) AAS
>>158
Dockerfile専用パッケージマネージャは
理屈は不明、何をしてくれるかもわからないが
面倒なことを魔法のように解決してくれるのです
どうにかして〜って叫ぶだけで
何かが解決するのです
162(1): 2020/08/30(日)16:00 ID:Qpr/sPeC(4/9) AAS
>>159
もう良いよｗお前は黙っとけ！ｗ
「できねーと非効率的なんだよ」
何でこれが理由だと読めないんだよ！アスペ野郎ｗ
163: 2020/08/30(日)16:04 ID:4F5aYT1J(5/9) AAS
サービス起動するときにあれこれ設定して起動するの面倒だなぁ
↓
Dockerfileの中で基本設定は全部済ませたで、必要最小限の
環境変数を渡すだけで起動可能だ、やったー
↓
Dockerfileの中で設定を済ませるの面倒だな
Dockerfile専用パッケージマネージャがあれば解決するはずだ！
↓
Dockerfile専用パッケージマネージャ
「インストールだけしておいたで、設定は全部Dockerの外でやるんやで」
↓
Docker使ってサービス起動するときにあれこれ設定して起動するの面倒だなぁ
（本末転倒）
164(1): 2020/08/30(日)16:05 ID:4F5aYT1J(6/9) AAS
>>162
じゃあ同じように"理由"を言うね
「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
これがお前の言う"理由"です
理由を言ったので納得しますよね？ｗ
165(1): 2020/08/30(日)16:19 ID:Qpr/sPeC(5/9) AAS
>>164
元の文章：
「imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
>これがお前の言う"理由"です
×「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
○「imageではなくパッケージって単位で再利用できれば効率的なんだよ」
君はマジでここに粘着するより、病院に行ったほうが良い。
166(1): 2020/08/30(日)16:23 ID:4F5aYT1J(7/9) AAS
>>165
元の文章が間違ってるから
俺が正しい"理由"を言っただけですが？
俺はこれを"理由"とは認めてないが、
お前は"理由"だというのだから問題ないはずだが？
167(1): 2020/08/30(日)16:30 ID:pgAkspfe(1) AAS
レス番飛ぶなぁ
168(1): 2020/08/30(日)16:42 ID:Qpr/sPeC(6/9) AAS
>>166
なるほど、君は>>136に、
「俺はそれを理由として認めない、お前はエスパーになって、
俺の納得いく理由を答えろ、それ以外は会話できると見なさない」
と、こう言いたかったのですね。
169: 2020/08/30(日)16:43 ID:Qpr/sPeC(7/9) AAS
>>167
話の九割はDocker関係ないけどな！
170(1): 2020/08/30(日)16:50 ID:4F5aYT1J(8/9) AAS
>>168
納得がいくかどうかじゃなくて
"理由"そのものになってない。
もしその文章が本当に"理由"であれば、
頭に「なぜなら」や「その理由は」をくっつけて自然な文章になる
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
自然な文章になってないので、これは理由ではない
これは単なる主張
171: 2020/08/30(日)16:51 ID:4F5aYT1J(9/9) AAS
文章が逆だったなｗ
「なぜなら、imageではなくパッケージって単位で再利用できれば効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できれば効率的なんだよ」
172(1): 2020/08/30(日)16:57 ID:Qpr/sPeC(8/9) AAS
>>170
わかったから病院に行け。
明日の朝イチですぐに行け。
君は相当、重度の発達障害だぜ。
「なぜなら、imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
これが理由と読めない理由がさっぱりわからないｗ
他人が述べた理由を
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
と勝手に書き換えるのもわからないｗｗ
実は君は宇宙人で、夏休みで日本に降り立ったのかいｗ？
日本語難しいよな！
173(1): 2020/08/30(日)17:13 ID:N0JftUYO(1/4) AAS
>>172
なぜパッケージ単位で再利用できねーと非効率的なんですか？
174(1): 2020/08/30(日)17:35 ID:Qpr/sPeC(9/9) AAS
>>173
なんで俺に理由を聞くの？>>136にレスしろよ。
彼が言っている事で、俺にも思い当たることはあるけど、正確に136が
どのようなケースを想定してこういったのかは知らない。エスパーじゃないからねｗ
俺は>>137の日本語の理解がおかしい、と指摘しているだけだが。
175: 2020/08/30(日)17:41 ID:Hfipjr9d(1) AAS
136じゃなかったのかw
176(1): 2020/08/30(日)19:53 ID:NuTsilhE(1) AAS
何か知らんけど、マージ機能なんか実現するわけないし話しても仕方なくね？
使いたいOSのパッケージマネージャーに入れてもらう方が現実的
177: 2020/08/30(日)23:57 ID:N0JftUYO(2/4) AAS
>>174
おや？「パッケージ単位で再利用できねーと非効率的」では
理由になってないと認めたのですか？ｗ
それが理由だろって言えばいいだろうｗ
178(1): 2020/08/30(日)23:58 ID:IuMrdEpr(1) AAS
コンテナの安全性をどう保証するのか社内で揉めてる
既存のノウハウが通じない事が多くてこんなんじゃ本番環境での採用に納得してもらえないよ
179: 2020/08/30(日)23:58 ID:N0JftUYO(3/4) AAS
>>176
謎の技術で面倒なものをよきに計らってくれるものが
作れると思ってるやつに何言っても無駄だろうｗ
180(1): 2020/08/30(日)23:59 ID:N0JftUYO(4/4) AAS
>>178
既存のノウハウで安全性を保証すればいいだけでは？
何が通じないのかいいましょう
181(1): 2020/08/31(月)00:01 ID:vF14AGtx(1/3) AAS
>>180
新しい試みだから何が足りんかもわからん
訓えて
182(1): 2020/08/31(月)00:03 ID:iWhhhfgj(1/11) AAS
>>181
既存のノウハウがそのままつかえると言ってるんですが
今どうやってコンテナではないものの
安全性を保証してるんですか？
まずそれを答えてください
183(2): 2020/08/31(月)00:10 ID:vF14AGtx(2/3) AAS
>実際、オープンソースセキュリティ企業のSnyk社が、自社のコンテナースキャン機能で最も広く普及している10個のDockerイメージを分析したところ、すべてのイメージに脆弱なシステムライブラリがあることが明らかになりました。
>その中でも群を抜いて最悪だったのはDocker社の公式のNode.jsイメージで、580もの脆弱なシステムライブラリが含まれていました。
ぐぐったらこんなんでてきた
公式イメージでこの体たらくじゃセキュリティガバガバすぎて使い物にならなくねえか？
>>182
君だったら既存の対策で↑の580の脆弱性にどうやって対応する？
184: 2020/08/31(月)00:20 ID:vF14AGtx(3/3) AAS
あらら即レスくん黙っちゃった
やっぱり既存の対策じゃ難しいのかね？
185: 2020/08/31(月)00:26 ID:iWhhhfgj(2/11) AAS
>>183
> 君だったら既存の対策で↑の580の脆弱性にどうやって対応する？
だからお前はどうやってそれに対応してるのかって聞いてるんだが
186: 2020/08/31(月)00:27 ID:iWhhhfgj(3/11) AAS
Node.jsに脆弱性がったら、アップデートするだけやろ
187: 2020/08/31(月)01:12 ID:yjVyiQZJ(1) AAS
>>183
これはどうやって安全性を保障するか社内でもめている、って人へのレスなの？
自社で使う場合は「Docker社の公式のNode.jsイメージ」なんて使わないだろ。
188: 2020/08/31(月)01:32 ID:iWhhhfgj(4/11) AAS
「Docker社の公式のNode.jsイメージ」を作るためのDockerfileは
公開されてるんだから自分でビルドしなおせばいいだけの話
Dockerfileがあれば誰でもイメージを再現できるのが
Dockerの特徴の１つ
「Docker社の公式のNode.jsイメージ」なんて手っ取り早く
開発するためのもので、実際にサービスとして運用するなら
自分でDockerfile作るでしょ？難しいって？そんなわけない
Dockerを使わずに開発するときに、自分で動作環境作ってるじゃん
189(1): 2020/08/31(月)08:58 ID:eDtSpI/f(1/2) AAS
こうやって突き詰めていくとスゲーめんどくせえんだDockerってさ
普通に仮想マシン使えばいいんだよ
そうすりゃ全てがうまくいく
190: 2020/08/31(月)09:00 ID:0JAMU07V(1) AAS
既存の負の遺産があるとそうなのだろう
191: 2020/08/31(月)09:44 ID:iWhhhfgj(5/11) AAS
>>189
だから言ってるだろ
1. Dockerを仮想マシンの代わりとして使おうとする
2. Dockerは仮想マシンの代わりとして使うのは面倒くさいじゃないか！
3. Dockerは仮想マシンの変わりにはならない！
4. つまりDockerはクソ
って言ってるのがお前だろ？
俺は最初から言ってるよな？
Dockerは仮想マシンじゃない。
（必須ではないが）仮想マシンと組み合わせて使うもの。だと
192(3): 2020/08/31(月)10:06 ID:eDtSpI/f(2/2) AAS
ぶっちゃけ最初からアプリがポーダブルになってればDockerなんて要らんのだよね
snapを始めとしたモダンパッケージマネージャのほうが優れてる
193(1): 2020/08/31(月)11:14 ID:JF0Gj41+(1) AAS
依存関係もまとめて全部塊でわたせるって
一見するとスマートに見えるけど実は筋が悪い
パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い
194(1): 2020/08/31(月)12:36 ID:iWhhhfgj(6/11) AAS
>>192
アプリがポータブルってどういう事？
例えば何かをRubyで書いたとしてRubyやRubyの
ライブラリのバージョンが違っても動くようにするための
方法が他にあるっていうの？
それをやるのは事実上不可能だからDockerがあるんでしょ
本当にアプリをポータブルにしたいなら
外部コマンドやライブラリを一切使わずに
Linuxカーネルの機能だけを使ったバイナリを作るしかないな
195(1): 2020/08/31(月)12:37 ID:iWhhhfgj(7/11) AAS
>>193
> パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い
それをやってるのが.NETだけど
Linuxの場合、ライブラリを複数バージョンインストールできるようにして
それらをアプリごとに切り替えて使う仕組みがないんだよ
マニフェストで使うライブラリのバージョンを変更できる機能とかが必要だからな
196(1): 2020/08/31(月)12:38 ID:iWhhhfgj(8/11) AAS
>>192
> snapを始めとしたモダンパッケージマネージャのほうが優れてる
snapは誰かが作ったアプリを使うためのもの
Dockerは自分でアプリを作るためのもの
197(3): 2020/08/31(月)14:45 ID:/EQn80AW(1/5) AAS
>>194
いやいや簡単にできるぞ
アプリXが言語Aのバージョン1
アプリYが言語Aのバージョン2
アプリZが言語Bのバージョン1
をそれぞれ使ってるとする
パッケージX,Y,Zを入れると自動でパッケージX,Y,Z,A1,A2,B1がインストールされる
Xを実行するときには隔離された名前空間にX,A1のみがロードされる
Yを実行するときには隔離された名前空間にY,A2のみがロードされる
Zを実行するときには隔離された名前空間にZ,B1のみがロードされる
ぶっちゃけこれだけでいいんだよ
イメージに全てを固めて転送するのは無駄が多すぎる
本当に欲しかったものはスマートなパッケージマネージャと実行時の名前空間管理システムであってイメージじゃない
198: 2020/08/31(月)14:47 ID:/EQn80AW(2/5) AAS
>>195
.NETにできるならほかでもやろうと思えばできるわな
>>196
お前の定義はどうでもいい
199(1): 2020/08/31(月)15:35 ID:iWhhhfgj(9/11) AAS
>>197
簡単にできるというのなら、それを使えば解決するのでは？ｗ
「それ」が何のことか言えないから、お前はそうして
アプリXとか具体的ではない名前しか言えないわけで
200(1): 2020/08/31(月)15:42 ID:bli2P+Al(1) AAS
>>197
それ結局Dockerじゃね？
Dockerのやり方に無駄が多い理由は
・複数のイメージが同一のライブラリを使用する場合に重複が生じる
・使われないコンポーネントがイメージに沢山入っている
だと思うが、君の挙げた例は上の2つの問題とは無関係で、Dockerによって解決できている問題だ
201(1): 2020/08/31(月)15:44 ID:iWhhhfgj(10/11) AAS
>>197
もう少し具体的な話をしてあげようか？
あるPerlスクリプトがあったとして
シバンに #!/usr/bin/perl と書いてありました
だから/usr/bin/perlが使われます
どうやって解決しろと？
202(1): 2020/08/31(月)18:18 ID:/EQn80AW(3/5) AAS
>>199
俺がやっても意味ない
Docker社なり公式がエコシステムとして提供しないと
>>200
Dockerは重複を解決できていないよ
単純な構成のアプリならベースイメージを共有することができるが
複数のパッケージに依存するアプリはもうだめだ
個別にDockerfileを書かなきゃならんので重複が生じる
>>201
だから名前空間だよ
パッケージXがpython:3.1パッケージに依存してたとする
パッケージXをインストールするとpython3.1がインストールされる(もし既に在るならスキップ)
実行時にはパッケージXのための名前空間が切られて
そこにパッケージXとpython3.1がロードされる
パッケージXから見えてるpythonは3.1だけなので/usr/bin/pythonは3.1がうごく
203: 2020/08/31(月)19:38 ID:TX10L3Te(1) AAS
「名前空間」は魔法の言葉
204(1): 2020/08/31(月)21:31 ID:iWhhhfgj(11/11) AAS
>>202
名前空間なんて機能はLinuxにはありません
勝手な機能を作らないでね
205: 2020/08/31(月)22:19 ID:SMZJ52hH(1) AAS
Docker 〜地図にない場所〜
206(1): 2020/08/31(月)22:26 ID:/EQn80AW(4/5) AAS
>>204
docker使っておいてそんなレスしちゃうのはヤヴァイ
207(1): 2020/08/31(月)22:27 ID:s2vRPnz6(1/3) AAS
>>206
えぇ？もしかして名前空間って結局の所
Dockerと同じことをすればいいって意味だったんですか（笑）
ならDockerでいいですよね（にっこり
208: 2020/08/31(月)22:29 ID:s2vRPnz6(2/3) AAS
結局アプリケーションの実行環境を仮想化するなら
Dockerが最適解だったってことなんだよな
209(1): 2020/08/31(月)22:37 ID:/EQn80AW(5/5) AAS
>>207
やれやれだ
Dockerも名前空間を利用してるがその使い方が下手くそだ
よりスマートに使うにはパッケージマネージャ方式が正解
210(1): 2020/08/31(月)22:39 ID:s2vRPnz6(3/3) AAS
>>209
お前、名前空間の意味わかってないだろｗ
Linuxカーネルの言葉で言ってみ
そしてパッケージマネージャーが、どこでその機能を使うんだよ
まあ、お前には無理だろうな（笑）
211: 2020/08/31(月)22:51 ID:9IgB2+87(1) AAS
>>210
user namespaceも知らんのかお前
パッケージマネージャで依存関係を管理してそれをもとに特典のパッケージとその依存関係を名前空間で隔離して実行すって何度も言ってるが
名前空間も知らん人には理解が追いつかないかな
212(1): 2020/09/01(火)00:05 ID:XiTY3BGm(1/6) AAS
はい、ぼけつほったー（笑）
外部ﾘﾝｸ:gihyo.jp
> ユーザ名前空間は3.8カーネルで実装された，現時点では一番新しい名前空間です。
> この機能により名前空間内で独立したUID，GIDを持てるようになります。
> 名前空間内のUID，GIDとホストOS上のUID，GIDの間はマッピングによるひもづけが行われます。
これとファイルシステムに一体何の関係が？ /usr/bin/perl という絶対パスしていを
UIDとGIDのマッピングでどうやって解決すると？
そしてパッケージマネージャーがどうやってUIDとGIDのマッピングをすると？
パッケージマネージャー上でアプリでも動かすんか？
ファイルを配置するだけのパッケージマネージャーでは無理だよなぁｗ
213(1): 2020/09/01(火)00:13 ID:XiTY3BGm(2/6) AAS
なんかパッケージマネージャーとかいってるけど
こいつのパッケージマネージャーは
サービスとして動いていそうだよなｗ
パッケージマネージャーの機能をDockerに対応させると
Dockerイメージの作成部分だけの機能で
ランタイム部分はないわけだが
こいつのパッケージマネージャーはDockerの
コンテナランタイムのように、アプリ実行時の
プロセス分離やネットワーク分離までやってそうだ
214(1): 2020/09/01(火)00:17 ID:WKQMSmMI(1/3) AAS
>>212
ぷっ
名前空間がUIDGIDだけだと思ってんのかこいつｗｗｗ
215(2): 2020/09/01(火)00:19 ID:WKQMSmMI(2/3) AAS
>>213
snapd
パッケージマネージャがデーモンとして動いてるなんてのはもうすでにあんだよ
お前さん取り残されてるぞ
216: 2020/09/01(火)00:36 ID:XiTY3BGm(3/6) AAS
>>214
ユーザー名前空間と言った後
しれっと「ユーザー」を消すとか
卑怯ですねぇ（笑）
>>215
あれあれ？じゃあお前のいうパッケージマネージャーって
Dockerみたいなものだってことですかねぇ
snap？登録に数時間かかるようなものがつかえるわけ無いだろ
だから言ってるDockerは開発者のためのもので
お前のような一般ユーザーはお呼びじゃない
217: 2020/09/01(火)00:40 ID:vyoUBDj8(1) AAS
コンテナ配布で同じ環境を猿でも容易に作れたり、スケーリングや冗長化や障害発生時の自動回復で
素早くコンテナの停止と起動を行えるような仕組みがないと同等以上とは言えないんじゃないかと
218: 2020/09/01(火)00:45 ID:XiTY3BGm(4/6) AAS
前々から言ってるように
アプリ開発者が自分のため（例 自社のサービス運用）に使うのがDockerで
エンドユーザーにアプリを配布するのがsnapなどなんだよ
その違いがわからない人がいる。
それはアプリを作らず、自分とは関係のない人が作った
アプリをただDockerイメージにしてるだけの人
そういう人だから既存のパッケージや仮想イメージを
変換してパッケージにできれば便利だって思ってしまう
だって、それらを材料として自分のアプリやシステムを開発してないから
インストールだけしたい人だからね
エンドユーザーと同じなわけさ
219: 2020/09/01(火)03:47 ID:Xa34Xx+v(1) AAS
じゃあDockerHubに上がっているdocker-composeの公式イメージはどういう扱いになるんだろう
220: 2020/09/01(火)06:37 ID:XiTY3BGm(5/6) AAS
開発ベース用イメージやろ（笑）
221(2): 2020/09/01(火)13:29 ID:A1mCLrFH(1) AAS
【悲報】 DockerHubのイメージが6か月しか持たなくなった……
222: 2020/09/01(火)13:58 ID:WKQMSmMI(3/3) AAS
dockerは存続できるのか?
podmanに移行したほうがいいかもな
redhatなら安心だ
223: 2020/09/01(火)18:23 ID:muXUjtx4(1) AAS
インスコが面倒くさい人のためにDockerイメージが提供されてることはある
php向けの静的解析ツールのphpstanはDockerでも動く
シェルのエイリアス使えば普通にインストールしたのと同じ感覚で利用できる
外部ﾘﾝｸ:phpstan.org
224: 2020/09/01(火)19:36 ID:B8XCrqjk(1) AAS
dockerのインスコが面倒くさい場合は?
225: 2020/09/01(火)23:18 ID:XiTY3BGm(6/6) AAS
>>221
6ヶ月pullしてないイメージが消えるだけやろ？ｗ
使ってないイメージが消えてなにか問題があるんか？
作り直せばいいだけだし、それができるのがDockerfile
上下前次1-新書関写板覧索設栞歴
あと 777 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.042s