[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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のみがロードされる
省3
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によって解決できている問題だ
上下前次1-新書関写板覧索設栞歴
あと 802 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.015s