Docker Part2©2ch.net

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

http://www.docker.io/

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

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

>>954
それはありますね。
ただ、ベンダを最初から持ち出す輩は、
ソースを調べようともせず、丸投げしているのがほとんどだとおもわれ。

>>955
スレチだが、ベンダーに投げれば済むことをアホみたいに時間かけて自分で調査することが許されるのは相当恵まれた環境だと思うぞ
客に工数で金貰ってる仕事ならそんなの夢物語

>>954
ストレージでハマったさくらのクラウドはベンダにリスク移転できたか？

費用って面ならあとから損害賠償請求すればいいだけでしょ？

すべてasisで提供されているのに損害賠償請求できるの？
んで実際ソレやったのか？

そんなもん契約書次第だろ
議論の余地はない

あとリスクって何も損害賠償だけじゃないぞ？
深刻な不具合が発生したときに自分で調査する羽目になった場合の所要工数もリスクだ
それをベンダーに丸投げできるならそれも正真正銘リスク移転だよ

にじさんじの瀬戸メッチァ喋るやん

>>960
結局損害賠償請求はできないってコトじゃん
ダメな時はダメ
そもリスク移転はできないとｗ
上っ面ダケのカッコつけマンばっかだなココｗｗｗ

実例とごちゃまぜにして語るキチガイがいるからなぁ

オマエもパッチ当ててwinが腐ったトキはブツブツ言いながらOS再インスコしてんだろ？ｗ
毎回MSに損害賠償請求してんのか？そも出来んのか？
リスク転移はできない実例だらけじゃねえかｗ

サポートなんて問い合わせ先があるってだけ。責任転嫁なんてできるわけないんじゃん。
自分で調べられるんならいらないよ。

MSのサポートはすごいよな。
客「XXすると、こういう不具合が起きちゃうんだけど？」
MS「そういうことはしないでください。別の方法で実現してください。」
ごめん。元組み込み屋の愚痴でした。

俺 バグがあるんだけど
MS 再現プログラム出してください
俺 はいこれ
MS お問い合わせの製品バージョンはサポート終了です
俺 再現プログラムは最新バージョンで再現するんだけど

で最後の「俺」の発言に対する返答はどうなったんだよ

最新版で出してくれとか、弊社側では再現しませんでしたと切られるのがオチでね

もしくはメール返答なしでバックレ

>>967
戴爾も笑えるぞ
viivロゴ貼ってるならHDDがNCQ対応じゃねえとダメじゃねえの？という質問に調査中のまま逃げ切りｗ

>>970
再現しないとしたら誰がどうやって対応するの
「再現しませんでした」は「こっちとは無関係なお前独自の環境が原因なので何とかできるのはお前だけだ、俺に聞いてどうする？」を優しく言ってるだけ

MS、Officeの不具合パッチ流すのやめてくれ

>>969
最新版でも再現することをMSも確認した
そして最新版の修正もなく打ち切られた

>>975
打ち切られた理由は？

そらMSのツゴーだろうよｗ
聞くだけヤボってもんよ

セキュアなコンテナランタイム「Kata Container」が、AWSのマイクロVM「Firecracker」をサポート。アプリごとに適切なコンテナランタイムを選ぶ時代へ
https://www.publickey1.jp/blog/19/kata_containerawsvmfirecracker.html

kata containerってFirecrackerと同じレイヤーのランタイムだと思ってたけど違うのか

社内にswarmクラスタを組んだのですがvolumeはどのように扱うべきなのでしょうか
node1にappをdeployした場合appはnode1のvolumeをマウントます
ここでなんらかの理由でnode1がクラッシュしnode2でappが再起動した場合node1のvolumeはマウントできないので初期状態でappが起動してしまいます

どこかしらの共有ストレージをマウントするようには設定できねえの？

あとはどこかしらのオブジェクトストアを指定して初期化するような動作を組み込むとか

swarmってオワコンじゃないの？

ドッカーだけでコンテナクラスタ構築するならswarmの方がとっつきやすくね

クラスタ構築は楽だと思う
あとcomposeを再利用できる

https://www.atmarkit.co.jp/ait/articles/1902/27/news062.html

「サイズ約40MBの単一バイナリ」：
Rancher Labs、エッジ向けKubernetes軽量ディストリビューションOSSプロジェクト「k3s」を開始

Rancher Labsは2019年2月26日（米国時間）、IoTなど、コンピューティングリソースへの制限が厳しい環境で動かすためのKubernetesディストリビューションを開発するオープンソースプロジェクト、「k3s」を開始した。

>　「Dockerを使った単一ノードのKubernetes v1.13.3クラスタは1GBを少し超える程度のメモリを使う。k3sの同一構成では260MBを少し超える程度で、これにはアップストリームのクラスタに含まれないingressコントローラーやサービスロードバランサーが含まれている」

260MBのメモリを積んでるIoT（）なの？ｗ

IoTってラズベリーパイとか？
512MB〜1GBはあるみたいだから余裕じゃね？

なるほどな
最低でもラズπレベルがターゲットなんだな

Kubernetesのmanifestの管理ツール「ksonnet」を使ってみた
https://qiita.com/inajob/items/7abe753a7c2c828230f9

これ何？くそねっと？

ひでー名前だな

害人はマイナー言語つかう極東の住民になんか忖度しねえからな

ケーソネットと読めばセーフ