Docker Part4

Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で
アプリケーションのデプロイが用意になります

Docker（アプリ仮想化）は仮想マシンと併用して使うことで最も効果を発揮し
開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます
さらにWindowsとmacOSでも同じDockerイメージが動きます。
（Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。）

Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります

Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう

http://www.docker.io/

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


注意　同じコンテナ技術を使うが異なるアプローチで仮想マシンの
代替を目指しているのがLXC。目的が全く異なるので注意
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

>>164
元の文章：
「imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」

>これがお前の言う"理由"です

×「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
○「imageではなくパッケージって単位で再利用できれば効率的なんだよ」

君はマジでここに粘着するより、病院に行ったほうが良い。

>>165
元の文章が間違ってるから
俺が正しい"理由"を言っただけですが？

俺はこれを"理由"とは認めてないが、
お前は"理由"だというのだから問題ないはずだが？

レス番飛ぶなぁ

>>166
なるほど、君は>>136に、

「俺はそれを理由として認めない、お前はエスパーになって、
　俺の納得いく理由を答えろ、それ以外は会話できると見なさない」

と、こう言いたかったのですね。

>>167
話の九割はDocker関係ないけどな！

>>168
納得がいくかどうかじゃなくて
"理由"そのものになってない。

もしその文章が本当に"理由"であれば、
頭に「なぜなら」や「その理由は」をくっつけて自然な文章になる

「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」

自然な文章になってないので、これは理由ではない
これは単なる主張

文章が逆だったなｗ

「なぜなら、imageではなくパッケージって単位で再利用できれば効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できれば効率的なんだよ」

>>170
わかったから病院に行け。
明日の朝イチですぐに行け。
君は相当、重度の発達障害だぜ。

「なぜなら、imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」

これが理由と読めない理由がさっぱりわからないｗ


他人が述べた理由を
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
と勝手に書き換えるのもわからないｗｗ


実は君は宇宙人で、夏休みで日本に降り立ったのかいｗ？
日本語難しいよな！

>>172
なぜパッケージ単位で再利用できねーと非効率的なんですか？

>>173
なんで俺に理由を聞くの？>>136にレスしろよ。
彼が言っている事で、俺にも思い当たることはあるけど、正確に136が
どのようなケースを想定してこういったのかは知らない。エスパーじゃないからねｗ
俺は>>137の日本語の理解がおかしい、と指摘しているだけだが。

136じゃなかったのかw

何か知らんけど、マージ機能なんか実現するわけないし話しても仕方なくね？
使いたいOSのパッケージマネージャーに入れてもらう方が現実的

>>174
おや？「パッケージ単位で再利用できねーと非効率的」では
理由になってないと認めたのですか？ｗ

それが理由だろって言えばいいだろうｗ

コンテナの安全性をどう保証するのか社内で揉めてる
既存のノウハウが通じない事が多くてこんなんじゃ本番環境での採用に納得してもらえないよ

>>176
謎の技術で面倒なものをよきに計らってくれるものが
作れると思ってるやつに何言っても無駄だろうｗ

>>178
既存のノウハウで安全性を保証すればいいだけでは？
何が通じないのかいいましょう

>>180
新しい試みだから何が足りんかもわからん
訓えて

>>181
既存のノウハウがそのままつかえると言ってるんですが

今どうやってコンテナではないものの
安全性を保証してるんですか？
まずそれを答えてください

>実際、オープンソースセキュリティ企業のSnyk社が、自社のコンテナースキャン機能で最も広く普及している10個のDockerイメージを分析したところ、すべてのイメージに脆弱なシステムライブラリがあることが明らかになりました。
>その中でも群を抜いて最悪だったのはDocker社の公式のNode.jsイメージで、580もの脆弱なシステムライブラリが含まれていました。

ぐぐったらこんなんでてきた
公式イメージでこの体たらくじゃセキュリティガバガバすぎて使い物にならなくねえか？


>>182
君だったら既存の対策で↑の580の脆弱性にどうやって対応する？

あらら即レスくん黙っちゃった
やっぱり既存の対策じゃ難しいのかね？

>>183
> 君だったら既存の対策で↑の580の脆弱性にどうやって対応する？

だからお前はどうやってそれに対応してるのかって聞いてるんだが

Node.jsに脆弱性がったら、アップデートするだけやろ

>>183
これはどうやって安全性を保障するか社内でもめている、って人へのレスなの？
自社で使う場合は「Docker社の公式のNode.jsイメージ」なんて使わないだろ。

「Docker社の公式のNode.jsイメージ」を作るためのDockerfileは
公開されてるんだから自分でビルドしなおせばいいだけの話

Dockerfileがあれば誰でもイメージを再現できるのが
Dockerの特徴の１つ

「Docker社の公式のNode.jsイメージ」なんて手っ取り早く
開発するためのもので、実際にサービスとして運用するなら
自分でDockerfile作るでしょ？難しいって？そんなわけない
Dockerを使わずに開発するときに、自分で動作環境作ってるじゃん

こうやって突き詰めていくとスゲーめんどくせえんだDockerってさ
普通に仮想マシン使えばいいんだよ
そうすりゃ全てがうまくいく

既存の負の遺産があるとそうなのだろう

>>189
だから言ってるだろ

1. Dockerを仮想マシンの代わりとして使おうとする
2. Dockerは仮想マシンの代わりとして使うのは面倒くさいじゃないか！
3. Dockerは仮想マシンの変わりにはならない！
4. つまりDockerはクソ

って言ってるのがお前だろ？

俺は最初から言ってるよな？
Dockerは仮想マシンじゃない。
（必須ではないが）仮想マシンと組み合わせて使うもの。だと

ぶっちゃけ最初からアプリがポーダブルになってればDockerなんて要らんのだよね
snapを始めとしたモダンパッケージマネージャのほうが優れてる

依存関係もまとめて全部塊でわたせるって
一見するとスマートに見えるけど実は筋が悪い

パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い

>>192
アプリがポータブルってどういう事？
例えば何かをRubyで書いたとしてRubyやRubyの
ライブラリのバージョンが違っても動くようにするための
方法が他にあるっていうの？

それをやるのは事実上不可能だからDockerがあるんでしょ
本当にアプリをポータブルにしたいなら
外部コマンドやライブラリを一切使わずに
Linuxカーネルの機能だけを使ったバイナリを作るしかないな

>>193
> パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い

それをやってるのが.NETだけど
Linuxの場合、ライブラリを複数バージョンインストールできるようにして
それらをアプリごとに切り替えて使う仕組みがないんだよ
マニフェストで使うライブラリのバージョンを変更できる機能とかが必要だからな

>>192
> snapを始めとしたモダンパッケージマネージャのほうが優れてる
snapは誰かが作ったアプリを使うためのもの
Dockerは自分でアプリを作るためのもの

>>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のみがロードされる

ぶっちゃけこれだけでいいんだよ
イメージに全てを固めて転送するのは無駄が多すぎる

本当に欲しかったものはスマートなパッケージマネージャと実行時の名前空間管理システムであってイメージじゃない

>>195
.NETにできるならほかでもやろうと思えばできるわな

>>196
お前の定義はどうでもいい

>>197
簡単にできるというのなら、それを使えば解決するのでは？ｗ

「それ」が何のことか言えないから、お前はそうして
アプリXとか具体的ではない名前しか言えないわけで

>>197
それ結局Dockerじゃね？
Dockerのやり方に無駄が多い理由は
・複数のイメージが同一のライブラリを使用する場合に重複が生じる
・使われないコンポーネントがイメージに沢山入っている
だと思うが、君の挙げた例は上の2つの問題とは無関係で、Dockerによって解決できている問題だ

>>197
もう少し具体的な話をしてあげようか？

あるPerlスクリプトがあったとして
シバンに #!/usr/bin/perl と書いてありました

だから/usr/bin/perlが使われます
どうやって解決しろと？

>>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がうごく

「名前空間」は魔法の言葉

>>202
名前空間なんて機能はLinuxにはありません
勝手な機能を作らないでね

Docker 〜地図にない場所〜

>>204
docker使っておいてそんなレスしちゃうのはヤヴァイ

>>206
えぇ？もしかして名前空間って結局の所
Dockerと同じことをすればいいって意味だったんですか（笑）

ならDockerでいいですよね（にっこり

結局アプリケーションの実行環境を仮想化するなら
Dockerが最適解だったってことなんだよな

>>207
やれやれだ
Dockerも名前空間を利用してるがその使い方が下手くそだ
よりスマートに使うにはパッケージマネージャ方式が正解

>>209
お前、名前空間の意味わかってないだろｗ
Linuxカーネルの言葉で言ってみ
そしてパッケージマネージャーが、どこでその機能を使うんだよ

まあ、お前には無理だろうな（笑）

>>210
user namespaceも知らんのかお前
パッケージマネージャで依存関係を管理してそれをもとに特典のパッケージとその依存関係を名前空間で隔離して実行すって何度も言ってるが
名前空間も知らん人には理解が追いつかないかな

はい、ぼけつほったー（笑）

https://gihyo.jp/admin/serial/01/linux_containers/0016

> ユーザ名前空間は3.8カーネルで実装された，現時点では一番新しい名前空間です。
> この機能により名前空間内で独立したUID，GIDを持てるようになります。
> 名前空間内のUID，GIDとホストOS上のUID，GIDの間はマッピングによるひもづけが行われます。

これとファイルシステムに一体何の関係が？ /usr/bin/perl という絶対パスしていを
UIDとGIDのマッピングでどうやって解決すると？
そしてパッケージマネージャーがどうやってUIDとGIDのマッピングをすると？

パッケージマネージャー上でアプリでも動かすんか？
ファイルを配置するだけのパッケージマネージャーでは無理だよなぁｗ

なんかパッケージマネージャーとかいってるけど
こいつのパッケージマネージャーは
サービスとして動いていそうだよなｗ

パッケージマネージャーの機能をDockerに対応させると
Dockerイメージの作成部分だけの機能で
ランタイム部分はないわけだが

こいつのパッケージマネージャーはDockerの
コンテナランタイムのように、アプリ実行時の
プロセス分離やネットワーク分離までやってそうだ

>>212
ぷっ
名前空間がUIDGIDだけだと思ってんのかこいつｗｗｗ

>>213
snapd
パッケージマネージャがデーモンとして動いてるなんてのはもうすでにあんだよ
お前さん取り残されてるぞ

>>214
ユーザー名前空間と言った後
しれっと「ユーザー」を消すとか
卑怯ですねぇ（笑）

>>215
あれあれ？じゃあお前のいうパッケージマネージャーって
Dockerみたいなものだってことですかねぇ
snap？登録に数時間かかるようなものがつかえるわけ無いだろ

だから言ってるDockerは開発者のためのもので
お前のような一般ユーザーはお呼びじゃない

コンテナ配布で同じ環境を猿でも容易に作れたり、スケーリングや冗長化や障害発生時の自動回復で
素早くコンテナの停止と起動を行えるような仕組みがないと同等以上とは言えないんじゃないかと

前々から言ってるように
アプリ開発者が自分のため（例 自社のサービス運用）に使うのがDockerで
エンドユーザーにアプリを配布するのがsnapなどなんだよ

その違いがわからない人がいる。
それはアプリを作らず、自分とは関係のない人が作った
アプリをただDockerイメージにしてるだけの人

そういう人だから既存のパッケージや仮想イメージを
変換してパッケージにできれば便利だって思ってしまう
だって、それらを材料として自分のアプリやシステムを開発してないから
インストールだけしたい人だからね
エンドユーザーと同じなわけさ

じゃあDockerHubに上がっているdocker-composeの公式イメージはどういう扱いになるんだろう

開発ベース用イメージやろ（笑）

【悲報】 DockerHubのイメージが6か月しか持たなくなった……

dockerは存続できるのか?
podmanに移行したほうがいいかもな
redhatなら安心だ

インスコが面倒くさい人のためにDockerイメージが提供されてることはある
php向けの静的解析ツールのphpstanはDockerでも動く
シェルのエイリアス使えば普通にインストールしたのと同じ感覚で利用できる

https://phpstan.org/user-guide/docker

dockerのインスコが面倒くさい場合は?

>>221
6ヶ月pullしてないイメージが消えるだけやろ？ｗ

使ってないイメージが消えてなにか問題があるんか？
作り直せばいいだけだし、それができるのがDockerfile

>>221
dockerhubは着実にsourceforge化が進んでるな。
そのうち何か月かpullされない物はイメージ内に勝手に広告入れてくるぞｗ

>>226
そうだな。広告が入ったらお前が正しい。入らなかったお前は間違い。
今はまだ入ってないから、お前の予想は現在進行系で間違い続けてるってことだ。
これからずっと何年間もお前は間違い続けるだろうｗ

秒読み段階だろ。

コミュ障は冗談が通じなくて大変だなｗ
人付き合いどうしてるのｗ？

殴って言うことをきかせる。

ネットは苦手。

冗談で言ってるといいながらそれが本音だったりするからな
だからマジレスすると答えられなくなる

そりゃ本音だろ。
どう見ても悪い道歩いてる。

冗談といってるのは、相手を追い込まない会話スキルだろね。

「冗談じゃねーか」

これって逃げゼリフだと思うよｗ

Dockerが消えてもPodmanがあるから安心
レジストリはどこかが引き継ぐでしょ

オティンポーヌあわしろｗ

Dockerもロケットとかいうのがあったでしょ？

ところで今話題のドッカーンって何が良いの？

これといって特に

>>215
dockerやってはsnap使ってるって事はmicrok8s使ってるの？

このタイミングで…。

September 1, 2020
Introducing GitHub Container Registry
ttps://github.blog/2020-09-01-introducing-github-container-registry/

>>240
Dockerhub終了のお知らせって事で良い？
こりゃいよいよDockerhubは広告が入りそうだなｗ

>>240
> Docker as the second most popular ecosystem in Packages

Dockerってすごいな。パッケージシステムとしての
デファクトの１つを確立してるじゃん
snapとか言うのオワコン？

>>242
>>192は単に「俺はDockerよりもsnapの考え方の方が気に入っている」
と言っているだけであって、別にシェアのことを言っている訳じゃないね。
話をちゃんと聞き取ろうね。

yumとかaptとかnpmとかが無料ユーザーは
利用回数制限するとか言ったことある？

>>243
「Dockerの役割を知らないから、snapが代わりになると思っている」
じゃねーの？ｗ

Dockerは開発者のものという意味がわからんのだろうね
自分が開発者じゃないから

>>244
Dockerも利用回数制限するとは言ってないですね
なにがいいたんでしょーか？

>>245
この勘違いくんいつまでこの勘違い続けるんだ？
クライアントはDocker使わないとでも思ってんのかね

>>247
クライアントだけに限定するなや

お前が言ってるのは、ハズレを除けば
全部アタリって言ってるだけだ

Docker Hubのプル回数制限の件は
運営側が様子見て
まだ行けそうだったら
徐々に緩和する事に期待するしかない

プル回数制限ってログインしてないユーザーで6時間で100回だろ？
ログインしていれば200回

ローカルにpullしたものはキャッシュされるわけで
ビルドするたびにpullしてるわけじゃない
100回で困るんだろうかね？

>>248
日本語で頼む

>>250
やべーのはCIだろうな
毎回クリーンな環境作って複数のimageをpullするから100回なんてあっという間だ

>>251
なぜ今、6時間で100回のpull制限はキツイかどうかって話をしてるかわかる？
開発者はCIを使ったテストで多数のイメージをpullする必要があるからだよ

これがDockerの主なユースケースの１つ
開発者なら容易に思いつくんだが
snapが代わりとなると思ってるような奴には理解できない

そういうやつがsnapの方が考え方が気に入ってると言ったところで
お前はDockerの使い方を知らんのだとしか言いようがないだろ

>>252
クラウドのCIを使ってるならクリーンな環境を作るときにIPアドレスが変わるはずだよ
IPアドレス固定は有料だから、固定にする必要がないものまで固定にしたりしないだろう
自社でCIサーバー立ててるようなところは苦労するかもしれんがｗ

>>253
本当に意味わからんなお前ちょっと冷静になれ
CIもクライアントの1つだ

>>254
考えが足りなすぎる
脊髄反射でレスするからレスの内容が薄いか間違いだらけ
IPが毎回違うってことは予期せぬ回数制限に引っかかる確率が上がるってことだぞ
CIパイプラインでこの仕様は致命的だ

実務者でdockerhubがコンテナレジストリって人居んの？
アマゾンかグーグルでしょ。
使ってるのカネのない個人だけ。

>>255
> CIもクライアントの1つだ

クライアントの1つだというのなら、
クライアントはCI以外にもあるという話

それ以外のクライアントも考えろと言ってる
例えば開発者だ

>>256
> IPが毎回違うってことは予期せぬ回数制限に引っかかる確率が上がるってことだぞ
考えなしに発言してるのはお前だろ

クラウドの用途はCIだけじゃない。多数のマシンの中でCIに使ってる確率なんて僅かだ
毎回作り直してる＝いろんな用途に使ってるんだから
予期せぬ回数制限（6時間で100回）に引っかかる確率なんてごく僅かだ

>>257
ディストリ含めてOSSで使ってるのはほとんどDockerhubだろ

>>258
そうだ
沢山のクライアントなかの1つが開発者だ
つまりDockerは開発者だけのためのの物じゃない
様々な利用者と利用目的がある
開発者のためのツールなどと言い切るのは見聞が狭すぎる井の中の蛙の意見でしかない

>>259
また考えが足りないぞ
膨大な数のインスタンスが生成されてるから再割り当ての数も多い
インスタンスのプーリングを行っていることも考えればハズレをひく可能性は十分だ

コミュ障患者が一人で延々と会話してるみたいで気味悪い。
コンテナがらみのまともなスレは無いのか？

GitHub(Microsoft), CircleCI, Google などが、DockerHub を援助すべき！