Docker Part2©2ch.net

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

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

>>854
何ヶ月か前に別スレでその最初の3行にまつわる話したら袋叩き似合った

だってウソだもんで>LinuxカーネルのABIは安定している

>>854
> go言語は他のライブラリが必要ない実行ファイルを作れる

でもライブラリ相当の機能が実行ファイルに含まれてるから、
goのバイナリはサイズがデカイんだよね

お、あったｗ やっぱりでかい
http://d.hatena.ne.jp/eel3/20150627/1435402293

言語 ファイル名 大きさ（byte）
C言語 hello_c 5516
C++ hello_cpp 5588
D言語 hello_d 360500
Go言語 hello_go 1091428

goはでかいよ
Archやってるとでかいサイズのgoの更新が頻繁に来るからうざい

Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
つまり安定性が高い。
一方、Windowsは動作が変わると名前にサフィックスが付く。
従って新しいAPIに自動的にリンクされることはないし、APIの数はドンドン増え続ける。

>>860
？

Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
Windowsは動作が変わると名前にサフィックスが付く。
以前の名前は変わらないので必ずリンクができるし、以前の名前の動作が変わることがない
だから高い互換性が保てる

といいたいのかな

Linuxはカーネルのシステムコールの数が増えなくても
ライブラリとは関係ない話なので、APIの数の代わりにライブラリの関数が増え続けるよ

>>855
読んでみたい、どこか覚えてる？

Debianにインスコ開始ー

GoのシングルバイナリってGPL汚染はないの？
というかDocker自体、上の方で猿が喚いてる「コンテナはアプリだ！」との主張がもし世間一般に通るなら、
単なる集積物であってアプリにGPLは感染しない理論はかなり無理があるんじゃないかな

自分で入れた癖して汚染したとか騒ぐのは笑えるぜ

>>864
そもそもGoはBSDライセンスだし

gccgoを使う場合はGPLのコンポーネント（gcc）を含むが
生成したバイナリはGPLの対象外

gccのランタイムライブラリは例外にしないと
Linuxにクローズドソースのソフトウェアが一切存在出来なくなるから
まさかクローズドソースのは一切無いと思ってた？

>>866
LinuxのアプリがGPLに感染しないのは、GPLの「単なる集積」と「システムコール」の例外条項による
自分で条項を読んでみたらいい
Dockerコンテナを単なるアプリケーションパッケージと解釈するなら、これらの例外が適用されるかはかなり怪しいよ
まあGoの場合は解釈論を云々するまでもなくGPLライブラリをスタティックリンクした時点で完全アウトだが

>>867
意味不明
Dockerで使う時だけ対象になるとか何処に書いてある？

>>867はDockerイメージは全てオープンソースにしないと違法って言ってんのか？
そんなこと言ってんのお前だけだろw

Linuxはソース文化なのでコンテナがないとアプリケーションの配布がきつい。

>>867
お前、その主張は、DVDにGPLとそうでないものを
一緒に焼いたら（つまりRedHat Linux状態）
ライセンス違反になると言ってることになってるんだが
気づいているか？

>>867じゃなくて>>864あて

Redhatは倫理規定違反で死刑になってもおかしくないけどな。

そもヨゴレのIBMと喜んでくっつかってんだから相当なド底辺クズ野郎どもだろ>RH
大喜びで開発協力してきた日本の大手ITベンダのアホ情弱どもはそれ以下のマヌケだろうけどな

>>871
>>871
それがいわゆる「単なる集積」
特定のアプリのために同梱してるんじゃなくて本当に単なる寄せ集めだから派生物と見做されない
一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで、例外条項の趣旨を考えれば完全にアウトだ
だからDocker使うなら間違っても「コンテナはアプリだ」なんて言っちゃいけない

> 一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで

事実上スタティックリンクってことは
本質上スタティックリンクじゃないってことだよね

Dockerコンテナはスタティックリンクしてないからアプリと言えるわけである
スタティックリンクしていれば1バイナリになる。

>>877
GPLはスタティックリンクか動的リンクかに関わらず感染するよ

LGPLなら良かったのにな。

ちなみにAndroidアプリだと、LGPLライブラリ(.so)をアプリのパッケージ(ZIP形式)に入れて配布するのはスタティックリンクに該当し、
アプリがLGPLに感染するという解釈が一般的だ
Dockerイメージは言うまでもないよね

いつのまに、アプリと呼ぶだけでGPLに感染することになったんだ？ｗ
本質的にアプリだが、アプリと呼ばなければOKって意味不明

俺が「あれ」と「これ」を含んだDockerコンテナ=アプリを作ったとして
他人が作った「あれ」と「これ」のライセンスを、赤の他人の俺がGPLに変更できるわけないし

Dockerfileはただの数行のファイルでしか無いし、
俺がGPLのものを作ってなにか作ったからと言って、それを不特定の人に公開する義務もない

Docker=アプリに反論したいができなくて、とりあえず言ってみたんだろうが
穴がありすぎて、大丈夫かこいつ？

>>880
良い皮肉だｗ
Googleストアにあるやつは全部GPLになっちゃうよなｗ

Dockerイメージを配布せずに、
Dockerfileだけ配布すれば
完全にGPL（LGPL）を回避できる

Dockerは素晴らしいですな！

ということで、DockerがGPL違反になるとか言ってるアホは徹底的にコテンパンにされました。おしまい。

いやイメージを配布するのは普通にGPL違反よ
配布しなけりゃいいだけだし、誰もそれは否定してないでしょ

まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。

> いやイメージを配布するのは普通にGPL違反よ

1. そもそもイメージ配布しなければGPL違反でないし
イメージ配布する人を社内に限れば、社内の人だけにソースを配布すれば良い

2. GPLはバイナリを入手した人がソースを入手できればいいので
バイナリを手に入れてない人にソースを配布する必要はない

3. DockerイメージのソースとはDockerfileのこと

4. もちろんDockerイメージの不特定の人に配布したら、
その中に入っているバイナリのソースも渡さないといけない

> まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。

その理屈だと、ISOイメージにして配布しているRedHatなんかも
ライセンス違反ということになってしまうので、間違ってるのは明らか

一言で言うならば、GPL感染した所で、プライベートイメージなら
何ら問題ないってことよ。

>>888
Redhatは裁判になったら死刑判決受けるだろ。

>>888
だからそれは単なる集積
DockerもVMだから単なる集積だと強弁してしまえばイメージの配布も限りなく黒に近いグレーにできなくもない

>>891
Dockerのイメージも単なる集積だけど？

見る人が見れば真っ黒に近い黒だろうな。
例えばGNUの尊師が見たら完全にアウツだろ。

Dockerのイメージがどういうふうに展開されてるのか知らないのかな？
単なるファイルとしてディスクに展開されてるんだけど

最終的にはLinuxのコンテナとして動いていて、コンテナがchrootを発展させたものって知っていれば
以下のリンク先の説明にあるように、とあるディレクトリ以下に展開されてるファイルを実行するだけって
わかるはずなんだが？

https://deeeet.com/writing/2013/12/16/where-are-docker-images-storede/

>>894
仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ
誰がどう見ても派生物だよ

> 仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ

だからその理屈を言ってしまうと、RedHatのISOイメージも
同じことになってしまうので、その矛盾を解決してから出直してきなって話

>>896
だからGPLの「単なる集積」の条項を読んできなさい

そもそもLinuxでパッケージが提供されているものだけを
使用すればGPL違反になりようがないんだよね

だからDockerコンテナ＝アプリ

>>897
読んで問題がないことがはっきりしている

はいどうぞ

「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?
https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation

「集積物」はいくつかの別々のプログラムからなり、それらは同じCD-ROMやそのほかのメディアや "Dockerイメージ" に
いっしょに入れられて配布されます。GPLは集積物を作成し配布することを認めています。
たとえ、ほかのソフトウェアが不自由あるいはGPLと両立しないものである場合でもです。
ただ一つの条件は、あなたは、それぞれのプログラムの個別のライセンスが許す権限を
ユーザが行使することを妨げるような、あるライセンスのもとで集積物をリリースすることはできないということです。

二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか?
これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、
適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)と
コミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。

モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。
CD-ROMやそのほかのメディアやDockerイメージは実行ファイルではありません
もしモジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、
それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。

逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で
使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションの
ために使われるときには、モジュールは通常別々のプログラムです。
しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。

個々のファイルをあつめて、Dockerイメージにするだけでは
単なる集積物だろう。

>>900
えっと、君のアプリはDockerイメージ内のGPLライブラリと動的リンクしてないの?w

>>902
GPLライブラリとは動的リンクしてないけど？
動的リンクが許されるLGPLライセンスのものばかりだなぁ

GPLのものとは以下の分離したプログラム間でのコミュニケーションメカニズムを使うから問題ないし
> 逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離した
> プログラムの間で使われるコミュニケーションメカニズムです。

これで結論出たよね？

そもそもGPLのものを作ってるのであれば
別にGPLに感染した所で何の問題もないよね。

それから本当の目的は「Dockerコンテナ=アプリ」を否定したかったんじゃなかったの？
Dockerコンテナをアプリと読んでしまったらGPL感染する！とかいう謎理論でさ

Dockerコンテナ＝アプリが気に食わなかったんだろうけど

結局、DockerイメージにするだけでGPL感染させられるか？という
話にしかなってなくて、そんなもんGPLライセンス読めば単なる集積物でしかない
Dockerイメージ（Linuxの機能のコンテナを実行するのに必要なファイルをまとめたもの）は
集積物として扱われるに決まってるし

最初のDockerコンテナ=アプリと何の関係もないし

どんな結論を目指したくてこの話を持ち出してきたのかわからんわ
┐(´ー｀)┌ﾔﾚﾔﾚ

>>900
そのDockerイメージについての言及がリンク先に見当たらないんだけど、参考までにどこにあるか教えてほしい

>>906
じゃあ君は、Dockerイメージがリンクに相当する言及するところを持ってきてくれ。
言い出しっぺなのだから、それぐらいやってから言うべきことだからな。

>>907
あなたの提示した捏造元のFAQがコンテナを想定して書かれたものではない以上、可能性は排除できないでしょ
モジュール同士の結合が強すぎる場合は通信方式に関わらず単一の大きなプログラムを構成していると見做されるとも書いてあるよね
Dockerは単一の大きなアプリじゃなかったのかな

Dockerは単一の大きなアプリだよ？

そしてスタティックリンクしてないし、動的リンクは
LGPLのものだけだからGPLの話と何の関係もないけど

二つの無関係な話をごっちゃにして何が目的なの？

おまえらはGNUの精神を誤解してるよ。
お前のものは俺のもの、俺のものは俺のもの。
それがGNUだろ。

GPLは俺のもの、バイナリ渡さなければソース公開の義務もないので
ウェブアプリでとっても便利に使えるもの

GPL感染を免れるためにリンクを行わずに
パイプでやり取りするのもよく使うテクニック

秋元はAKBがオープンソースとか言ってたのに、AKBは全然GNUじゃないんだよな。
握手券をCDと偽って売りつけるのがオープンソースっぽいと言われれば、確かにそんな感じもするが。

>>911
GPL感染を防ぐのにパイプでなんか渡す必要ないよ。アプリとして独立していればいいだけ。

>>913
アプリじゃなくてプログラムな。↓こうかいてあるだろ

https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
> しかし多くの場合、GPLの及ぶソフトウェアをプロプライエタリ・システムと一緒に
> 配布することは可能です。これを妥当な形で行うには、自由なプログラムと
> 自由ではないプログラムとがそれぞれ独立を保った形でコミュニケートし、
> それらが事実上単一のプログラムとなってしまうような方法で結合されていないことを確認しなければなりません。

そして「プログラムとして独立」していると見なして良いものの一つが
（GPLのものと）パイプでやり取りするってことだろ

あー、言っとくけど、ばれてないだろうと考えての無駄な努力はしなくていい。
「Dockerコンテナ = アプリ」をどうにか崩そうとして
なにかを「アプリ」に結びつけようとしてるのには気づいてるから
バレてる時点でその努力は無駄よ。

GPLに感染したら村ごと焼き払わないと人類滅亡するからな。

もうボケナスと腐れIBMのお陰で滅亡し掛かってるじゃん＞人類

焼き払え！
どうした！それでも世界で最も邪悪な一族の末裔か！

なりきりトークはしんどい

( ﾟдﾟ)====>☆

Docker周りを調べてからWebサービス作ってみようかと思ってたけど後回しにする
小規模だし最初サービス作ってからでも遅くない気がしてきた

ても開発環境だけでも幸せになれるかなぁ
まぁ後にしよう

同時にすれば？
今日はこれ、明日はこれ。

いっちょまえに開発開発いわないでWebページ制作といえ
それしかやってないんだからお前らわ

Webページ制作なら大企業でもやるでしょう？

いやWebサイトなんか外部委託が普通だろ
自社でWebサービスやってる会社ですら、Webサイト制作などという底辺仕事を自社エンジニアにやらせるのは損失だから外部委託してたりするぞ

ん？ お前の会社はエンジニアしかいない小さい会社なの？

500人くらいの会社だけど、コアでない業務を外部委託するのなんて普通だろ?
前にいた1000人くらいのSIerも当然外部委託だったよ

ほーら言ってることが変わったｗ

Webサイトなんか外部委託が普通だろ
↓
コアでない業務を外部委託するのなんて普通だろ?


> それしかやってないんだからお前らわ
それしかやってないというのなら、それがコア業務ってことだよねｗ
矛盾している

>>929
そりゃWeb制作がコア業務の会社もあるだろう
で、Web制作を主業とする大企業ってどこ?

Web制作を主業とする大企業が今の話とどうつながるの？

webサイトとwebサービスを一緒くたにしてると底辺と思われても仕方ないぞ。
webサイトにしても外注ですますって事は諸々の技術が賄えないってことだからwebサイト職人は高年収なんだなこれが。
ちなみにどこにでも底辺がある業界なのでブラックで雇われてるタイプ打ちの事は知らん。

Web制作業界はゴミみたいな単価の案件を奪い合う地獄絵図やぞ
典型的なSIerのブラックなんかとは次元が違う

キノトロープ。

あなたが落としたのは、
キンノロープ ですか？それとも
キノロープですか？

>>935
人月100万のゆるゆる案件です！

Redhat製のdocker互換
rootやデーモン無しで動く
https://github.com/containers/libpod

>>937
コレってRH系ならyumで入れられんだな

>>937
いきなりKubernetesにも対応してるのか
さようならDocker
このスレもこれで終わりだな

>>937
これってCoreOSの系譜？

>>940
違う
cri-oから分離したプロジェクト

じゃあCoreOSチームはよくて合流悪くて放逐か
浮かばれねえな

Dockerは売り時を逃したな
もう二束三文でMSに買収されてWindowsのコンポーネントになるしかない

どっかー買いたいって言ってたトコあったんか？

買えるならAWSでもGoogleでもMSでもIBMでもどこでも買ってたでしょ
今となっては地獄の値下がりチキンレース不可避

コンテナはdocker以外にも沢山あるからな
docker社の価値のメインはdockerよりdocker hubだろう

>>945
MSは自社鯖製品にドッカー組み込んでるみたいだから買収するとしたら合理的かもだな
ホストwinなら他社と違ってかならずこの手のグルーコードが必要になるし

デーモンを使わずにコンテナやポッドを実行可能：
Docker互換のオープンソースコンテナエンジン「Podman 1.0.0」が公開
http://www.atmarkit.co.jp/ait/articles/1901/25/news055.html

podmanってrktとはどう違うの？

>>948
どっかのオタクが気紛れにつくったものなんてビジネスでは使い物になりません
その点、RedHat(IBM)ならエンタープライズクォリティの長期的なサポートが期待できます

>>949
自分の責任では調査も満足にできず、
ベンダサポートが無いとダメなんでしょうね。

>>948
>>937と同じモノだぬ
つかrktはKubernetes1.10でDeprecatedらしんで（ｒｙ

>>937
rootなしで、privilleged できるのか？

>>950
まさに給料ドロボーだなｗ

>>950
自己責任で済む業態ならいいが、不具合起こしたときに客に損害賠償請求される仕事もあるんやで
ベンダーサポートを利用するのは、自分で調べればいいとかそういう問題ではなくてリスク移転が目的