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/

インストール方法？
自分で開発したアプリのインストール方法もわからんのか？

いや他人の作ったものも使うだろ

そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろｗ

いやいやそうじゃなくてオープンソースのツールとかあるだろ
ネット遮断でもしてんのかお前んとこ

Dockerfileも拾えよ

>>102
オープンソースのものを自分でDockerfile作る意味は？
殆どのものは公式が用意してるでしょ

>>104
公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ？

いや、自分で「マージしたDockerfile」作れよ
それが自動でできなくてゴネてるの？

めんどくせぇ

go製ツールならバイナリ落としてくればすぐ動くが

Pvthonとかのスクリプト言語を使う系や
C/C++で書かれている物はそうも行かない

パッケージマネージャにあれば良いが
あっても古い、このパッケージもインストール必要とか面倒

glibc使ってるC/C++製ツールで動的リンクしてたら
alpineにそのまま持って行っても動かない
muslで再コンパイルするか
イメージサイズの肥大化を覚悟でglibcを入れる必要がある

OSに最初から入ってるツールの扱いはどうするのか？とか考えたら
自動的にマージできるとか思うわけない
Dockerからしたら全てただのファイルであり
依存関係も把握してないし区別もしない

結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな
方向性としてはsnapなどのほうが正しかった

賢いパッケージマネージャよりdockerが便利

>>105
> それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ

１つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで？
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに

ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか？ｗ

>>110
Dockerはパッケージマネージャーが対応してないような
自分（自社）で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。

snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。

apacheのバーチャルホストで20個のサイトを運営するのと
1つのイメージを使って1コンテナ1サイトを作るのでは
どっちがメモリとCPU使用率が高いですか？

メモリとCPU使用率が重要なら、
1つのイメージを使って1コンテナ20サイトを作れば？

1コンテナ1サイトって発想が出るのもやっぱりいつもの
Dockerを仮想マシンの代わりだと思ってるからなんだろうか？

Dockerはアプリの代わりと考えれば、この場合apacheだとわかる
１つのapacheアプリでバーチャルホストをするのであれば
Dockerの1つのapacheアプリでバーチャルホストをすればいいだけ

そのバーチャルホストの設定を予め終わらせておいた
カスタマイズ済みapacheを簡単にデプロできるのが
Dockerのメリットなわけで

1サイトをバックエンドとフロントエンドとDBに分けても良いよ？

>>112
アホか
何でもかんでもサービスにしたら効率が悪いこともある

何か変なのがいる。この後どうなるか楽しみ。

メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム
業務システムなら普通にあるよなあ

別言語でapi鯖構築してメイン言語と別言語の2コンテナ構成にするって手もないこたないけど
そのためにワザワザ別言語とそのweb apiフレームワークを習得するのはコスパ悪いだろ

こういうときは1つのコンテナに複数の言語ランタイムやパッケージをまとめちゃって素直にサブプロセス呼んだほうが製造コスパがいい

んでそういうときに公式イメージのマージができたら便利なんだがサポートされてないからDockerfileをワザワザ書かなきゃならん
コンテナを分離する間抜けなアイデアよりは遥かに楽だけどそれでもDockerfileを書く手間は残る

>>112
ベストプラクティスは1コンテナ1責務だ

素人は1コンテナ1プロセスと間違って覚える
脱初心者を目指してるぐらいのレベルだと1コンテナ1サービスとか言い始める

docker-in-dockerとかdocker-outside-of- dockerをやれば良いんじゃね？
セキュリティについては知らん

Dockerコンテナ内からDockerを使うことについて
https://esakat.github.io/esakat-blog/posts/docker-in-docker/

この明後日の方向に突っ走る感じ

Dockerだけで云々言っている人は、
オーケストレーションまで頭がまわらないだろうし、
どないしようもないと思う。
CRIだけの世界でせいぜいがんばってください。

COPY --from=some/image /source/path /dest/path

Docddkerfileにこれを書いておけば
some/imageという既存Dockerイメージからファイルをコピー出来るぞ

依存関係が色々あって何をコピーしたいかわからない場合は知らん

マージ君は自動でやってほしいんだからそんなもんお呼びでないだろう

>>125
マージには役に立たんわ
そもそも必要なファイルがどこにあるか探すのめんどくせぇーだろ

欲しいのはレイヤーをコピペする機能だよ
それかdocker最適化されたパッケージマネージャでもいいかな

俺たちが本当に欲しかったのってこれな

FROM alpine:latest

# ディストリ差異対応とか依存関係解決とか環境変数とかボリュームとかキャッシュクリアとかよしなにやってくれる素晴らしいdockerfile専用パッケージマネージャ
PACKAGE openjdk:11 somevendor/somepythonclitool:latest

COPY bin /myapp
ENTRYPOINT /myapp/entrypoint.sh

openjdkイメージとsomepythonclitoolイメージって形式でリリースしちゃったら再利用性が低すぎるんだわ

>>128
Dockerは○○専用に作るものなのに
それをなにに再利用するんだよｗ

>>129
世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない
こんな基本的なことをなんで説明しなきゃわからないんだ

「よしなに」が仕様のツール誰が作るの
トラブったら>>128みたいなのに文句言われるんだろ

>>131
docker公式かツールベンダが作るんだよ当たり前だろ

>>130
反論に全くなってないけど、だから何？

>>133
うーんこの理解力

ほらな、説明できない（笑）
言ってることが不明瞭の場合は聞き返してみるに限るね

はぁ…┐(´д｀)┌ﾔﾚﾔﾚ
>>130だから同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケースが当たり前のように出てくる
そのためにはimageではなくパッケージって単位で再利用できねーと非効率的なんだよ
わかったかなボウヤ

>>136
主張を繰り返せって言ってるんじゃなくて
主張の理由を言えって言ってんの
ほんと会話ができんやつだなｗ

>>137
これがdockefile専用パッケージマネージャが必要な理由に見えないならもう話にならんわ
会話が通じないレベルの差があるってことだ

お前が言ってるのは、ユースケースと主張だけ
理由を言ってない

>>139
>>136

>>139
>>130

「同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケース」
これはユースケース

「imageではなくパッケージって単位で再利用できねーと非効率的」
これは主張

「なぜなら、・・・・」
これが理由

「世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない」
これは事実

「こういう場合に、・・・」
これが理由

>>142
>>141

>>144
>>143

理由をさっさと書きましょう

>>145
書いてある
あとはお前が理解するだけだ
理解する気がないなら無駄な問答が続くだけだからもうレスしなくていいよ
バイバイ

お前が言った言葉の全てに対して「それは理由じゃない」と説明したんだがｗ

>>147
間違った説明だから意味ない
理解する気がないならレスするな
2回目だよ

俺の説明のどこが間違っているか言える？ｗ
主張じゃなくて理由を言え

できたらコテ班付けてくれませんか
誰と誰の主張がぶつかってるのか日が変わるとわからないので

お前らはどのコンテナセキュリティスキャナ使ってるん？

>>149
いつものDocker原理主義者？
傍から見ていると、君が何故そんな下らない方向に持っていくのかスゲー疑問。
君が>>98に対する解決策を知っていれば教えれば良いだけ。知らなきゃ黙ってろよ。
俺はこの人がなぜ欲しががっているのか理解はできるよ。
解決策知らないから黙ってるけど。
確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？

> 何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？

理由を答えないからでは？

> 確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。

思わないな

同じファイルを使うとか同じポートを使うとか
事情がわかってないとイメージだけマージしてもしょうがのにな

>>153
理由を答えてるけど君が理解しないだけだよね？>>136はどこからどう読んでも
理由にしか見えないんだが？しかし別に理由はどうでも良いよ。
知ってるんなら答えろよ。知らないんなら黙っとけ。
スレの無駄だ。

そういう面倒なところを解決するためにスマートなDockerfile専用パッケージマネージャがあるといいなぁって話だろ

それは同一イメージ内でyumやaptを複数回使うのと何が違うの

>>156
じゃあ重要でない言葉をマスクしてみようか？

○○というユースケースが当たり前のように出てくる
そのためには○○できねーと非効率的なんだよ

見ての通り、理由が書いていない

環境変数の設定やインストールの手順がわからないことがあり、
イチイチ調べてDockerfile書かないといけないから、って話じゃなかったの？

>>158
Dockerfile専用パッケージマネージャは
理屈は不明、何をしてくれるかもわからないが
面倒なことを魔法のように解決してくれるのです

どうにかして〜って叫ぶだけで
何かが解決するのです

>>159
もう良いよｗお前は黙っとけ！ｗ

「できねーと非効率的なんだよ」

何でこれが理由だと読めないんだよ！アスペ野郎ｗ

サービス起動するときにあれこれ設定して起動するの面倒だなぁ
↓
Dockerfileの中で基本設定は全部済ませたで、必要最小限の
環境変数を渡すだけで起動可能だ、やったー
↓
Dockerfileの中で設定を済ませるの面倒だな
Dockerfile専用パッケージマネージャがあれば解決するはずだ！
↓
Dockerfile専用パッケージマネージャ
「インストールだけしておいたで、設定は全部Dockerの外でやるんやで」
↓
Docker使ってサービス起動するときにあれこれ設定して起動するの面倒だなぁ
（本末転倒）

>>162
じゃあ同じように"理由"を言うね

「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
これがお前の言う"理由"です
理由を言ったので納得しますよね？ｗ

>>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とか具体的ではない名前しか言えないわけで