[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
781: 2018/12/12(水)00:43 ID:Zb7agEVB(1/6) AAS
> でも、Dockerコンテナ起動したら、
> ポートが開くじゃない？
開かないが？
782: 2018/12/12(水)00:43 ID:Zb7agEVB(2/6) AAS
>>780
例えば、nginxを起動するとポート80番が開く
って話してるのか？
Dockerと関係ない話だよね
783(1): 2018/12/12(水)02:56 ID:JHof8k11(2/7) AAS
>>771
コンテナはアプリを動作させるための環境であって、
コンテナ＝アプリという式は間違っている。
784(2): 2018/12/12(水)02:57 ID:oUbBeYcM(1) AAS
>>775
まあ大抵にわかのセキュリティエンジニア（笑）が設定ミスってノーガードになるのが事故の原因なんだけどな
オンプレでもFWで守られてるから大丈夫なんて余裕ぶっこいてるサーバーほどよく侵入されてる
785: 2018/12/12(水)10:49 ID:Zb7agEVB(3/6) AAS
>>783
コンテナ＝アプリ と言ってない
Dockerコンテナ=アプリ と言ってる
正確に言うならアプリ相当として考えろってことだが
786(1): 2018/12/12(水)10:51 ID:Zb7agEVB(4/6) AAS
>>784
なんでデフォルトでポート塞がないの？って話だな
クラウドならサーバー外部にある、ファイアウォール相当のものがデフォルトで塞いでいるから
いくらサーバー側で設定ミスっても接続できない。
意図的にファイアウォールの設定をしない限り接続できないように
安全な状態になっている。
787(1): 2018/12/12(水)12:46 ID:rkj8vXTd(1/3) AAS
>>784
それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
クラウドだとFW相当の設定はサーバー単位だし、その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
その上で更にサーバ内でポート閉じる設定するなんて明らかに冗長なだけ
788(3): 2018/12/12(水)12:53 ID:JHof8k11(3/7) AAS
>>786
デフォで、オールリジェクト？ポリシーはどうなっているの？
awsでもDockerコンテナ使えますか。
使えるなら、Dockerホストと、その外部ファイアウォールの両方でポート開放が必要ということですよね。
いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。
789(1): 2018/12/12(水)13:33 ID:Zb7agEVB(5/6) AAS
>>787
> それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
セキュリティ突破できたらやり放題って当たり前だろ
何を言ってるのかわからん。
> クラウドだとFW相当の設定はサーバー単位だし
普通はネットワーク単位だが？
> その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
だからそれがデフォルトなのがクライド
790(1): 2018/12/12(水)13:34 ID:Zb7agEVB(6/6) AAS
>>788
> awsでもDockerコンテナ使えますか。
今の話にDockerコンテナは関係ないから
（パッケージでインストールする）nginxに置き換えるね
> nginxのホストとその外部ファイアウォールの両方でポート開放が必要ということですよね。
> いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。
だからなに？
791(1): 2018/12/12(水)14:03 ID:rkj8vXTd(2/3) AAS
>>789
いやセキュリティグループはサーバー単位だろ
本当にAWS使ってるのか？
792(1): 2018/12/12(水)14:18 ID:LrMZOP1V(1/9) AAS
>>791
外部ﾘﾝｸ[html]:docs.aws.amazon.com
この下の図を見ろ。
インスタンスの外にセキュリティグループが存在している
793(1): 2018/12/12(水)14:20 ID:JHof8k11(4/7) AAS
>>790
0点
>>788をよく読んで答えなさい
794(1): 2018/12/12(水)14:34 ID:LrMZOP1V(2/9) AAS
>>793
反論できないならレスすんなよｗ
795: 2018/12/12(水)14:53 ID:rkj8vXTd(3/3) AAS
>>792がAWSを使ったことがないことはわかった
796: 2018/12/12(水)15:21 ID:kA2tO+1p(1/2) AAS
セキュリティグループは作ってからEC2インスタンスやロードバランサー、データベースにくっつける
IPアドレスの範囲に加え、
特定のセキュリティグループを持ったインスタンスの接続のみを許可する使い方も出来て便利
797(2): 2018/12/12(水)15:21 ID:afrcY71M(1/5) AAS
AWS使ったことないんだけど、ポートを塞ぐだけでセキュリティ云々言うのは間違ってるよ。
webなんかで言われるセキュリティホールは80とか443を使って侵入するから通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通。
798(2): 2018/12/12(水)15:24 ID:LrMZOP1V(3/9) AAS
>>797
URLを解析って何すんの？
言ってみ
799: 2018/12/12(水)15:25 ID:LrMZOP1V(4/9) AAS
オンプレの場合、一旦納品したサーバーは
脆弱性があろうともバージョンアップしないんだろう
だから脆弱性があるサーバーを守るために
ファイアウォールを使う。
馬鹿としか言いようがないｗ
800: 2018/12/12(水)15:26 ID:kA2tO+1p(2/2) AAS
自分のアプリのバグで大穴を開けなきゃ普通は大丈夫
801(1): 2018/12/12(水)15:32 ID:afrcY71M(2/5) AAS
>>798
jsが仕込まれたURLじゃないかとか色々
802: 2018/12/12(水)15:39 ID:JHof8k11(5/7) AAS
>>794
反論を煽るようなレスをわざわざするなよ
803(1): 2018/12/12(水)15:41 ID:JHof8k11(6/7) AAS
>>798
ストリングクエリとか
804(1): 2018/12/12(水)15:43 ID:LrMZOP1V(5/9) AAS
>>801
え？なに？ クライアントからサーバーに
jsが仕込まれたURLが送られてくんの？
>>803
え？なに？ストリングクエリに細工されていたら
サーバーに侵入される脆弱性があるの？
805(1): 2018/12/12(水)15:44 ID:JHof8k11(7/7) AAS
>>804
最初からわかっていたら苦労しない。
806: 2018/12/12(水)15:50 ID:LrMZOP1V(6/9) AAS
>>805
テストもレビューもしないってこと？
細工したクエリストリング流してテストすればわかることだよね？
807: 2018/12/12(水)15:50 ID:afrcY71M(3/5) AAS
可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、
それ以外は404とかに出すに限る。404も別サーバーでいい。
bashショックもURLだったろ。あれはパッチをできるだけ速く当てるしかないが。
808: 2018/12/12(水)15:51 ID:afrcY71M(4/5) AAS
テストとレビューで事足りるならセキュリティは苦労しない。
809: 2018/12/12(水)15:55 ID:LrMZOP1V(7/9) AAS
でもセキュリティあってもテストとレビューで
事足りないものはセキュリティでも漏れるから
意味ないよね
810(2): 2018/12/12(水)15:56 ID:LrMZOP1V(8/9) AAS
> 可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、
だから限られたURLってなんだ？
お前のサーバーは、自分以外のURLで接続できるのか？
811(1): 2018/12/12(水)16:02 ID:afrcY71M(5/5) AAS
>>810
普通いくらでも通るぞ。getも知らないのか？
812: 2018/12/12(水)16:14 ID:LrMZOP1V(9/9) AAS
>>811
どこのサーバーからgetするの？
813(1): 2018/12/13(木)01:38 ID:eanokFZt(1) AAS
>>810
たとえば、基本的なところでは、クエリストリングで、
アプリケーション側で対応するフィールド以外のものは、
排除するとか。
814: 2018/12/13(木)08:28 ID:WRDxjQMU(1/2) AAS
>>797
>webなんかで言われるセキュリティホールは、80とか443を使って侵入するから、
通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通
アプリ製作者が素人で、アプリにバグがあるから、こいつらの技術では自前で実装できないw
SQL 文を文字列でつないで作って、問い合わせる奴。
place holder を使っていない奴は、SQL インジェクションされる
sql文 = "SELECT 列名 FROM 表名 WHERE user_id='$userid';";
この変数に、1 だけなら良いけど、
クラッカーは「1; 文」のように、; を打って、クラッキングする文をつなげてくる
資格も持ってない・勉強していない奴は、当たり前の事も知らない。
place holder を使っていないアプリは、損害賠償請求できる
こういう奴らは、アプリを作っちゃいけない！
815(1): 2018/12/13(木)08:31 ID:+yv1dYA8(1) AAS
>>813
そんなもんWAFで弾ける
クラウドならそれこそ画面でポチるだけ
816: 2018/12/13(木)08:35 ID:WRDxjQMU(2/2) AAS
>>788
>awsでもDockerコンテナ使えますか
aws は、Docker だろ。
CoreOS, Kubernetes とか
817: 2018/12/13(木)14:47 ID:XsbRAMI5(1) AAS
コンテナってクラウドに熟達した人が究極のdeployabilityを追求した末に行き着くものだと思ってたけど、意外とそうでもないんだね
クラウドには手が出ないけどなんか新しそうなもの触ってみたいだけな人が多いのかな
818: 2018/12/13(木)15:26 ID:j2qkztX7(1) AAS
マネージドKubernetesサービス対決
比較表見るとアマゾンのEKSはGoogleのGKEと比較してコスト高いだけの劣化版に見える
そしてMSのAKSはどちらにも及ばないクソ
外部ﾘﾝｸ:kubedex.com
819(2): 2018/12/14(金)00:56 ID:yXt9E1ve(1) AAS
>>815
httpsの場合は？
中間者攻撃が成立しないと解読できないと思うけど。
820: 2018/12/14(金)08:26 ID:E4qeknD0(1) AAS
>>819
wafはCloudFrontやALBと組み合わせて使うよ。
それらはSSLアクセラレーターの機能も兼ねてるのでwafやwebサーバ側に来る時点ではhttp平文状態になります。
この場合、サーバー証明書はCloudFrontやALBに組み込むだけで済みます。AWSはドメイン発行やルート局も持ってるので証明書関連はAWSだけで完結できます。
スレチだけどEntity Framework等の昨今のO/Rマッパーを使っていればSQLインジェクション対応してくれるから余り神経質になる事はないよ。自身でSQL文を組み上げる事はしません。
821: 2018/12/14(金)11:45 ID:BtHCLjdt(1/2) AAS
>>819はまさかコンテナにSSL喋らせてるのか?
そんな足回りの関心は丸投げできるようなインフラでないと上で喚いてる「アプリとしてのコンテナ」なんか程遠いだろ
822: 2018/12/14(金)11:50 ID:Wd54hADz(1/2) AAS
もうそろそろ飽きてきたな。
インフラ周りの話はDockerコンテナと関係ないし
823(1): 2018/12/14(金)12:17 ID:BtHCLjdt(2/2) AAS
今時オーケストレーションやインフラの技術を抜きにしてコンテナを語るのは無理があるだろ
ホビーストがチマチマrunして遊ぶ時代はとうの昔に終わったんだよ
824(1): 2018/12/14(金)12:28 ID:Wd54hADz(2/2) AAS
>>823
レイヤーが違うんだよ。
Dockerはコンテナに動かすのに必要なものがカーネル以外全て入っている
逆に言えばDockerを動かすものは何でもいい。
Kubernetes使おうがsystemdから起動しようがコマンドで実行しようが関係ない
アプリの話をしているときにOSの話をするのは関係ないだろ？
OSとアプリの連携の話をするならまだわかるけど、
OSそのものの話は関係ないじゃん？今の話はそういうレベル。
インフラそのものの話になってしまって、アプリは全く関係ない話になってる。
アプリとインフラの機能を密結合させるという発想しか持ち合わせてないから
こういう話を続けるのだろうけど
825(1): 2018/12/14(金)23:41 ID:94bz9H8n(1) AAS
>>824
大いに関係あるよ
なぜコンテナにTLSが必要ないのか?
それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ
コンテナを単なるVMというならともかく、そうじゃないと主張しているんだろ？
だったらそのためのインフラに対する条件は明確にしておかなければ机上の空論でしかないぞ
826(2): 2018/12/15(土)00:12 ID:AVLQNiPu(1) AAS
>>825
お前が言ってるのコンテナと関係ない話じゃん
> なぜウェブアプリにTLSが必要ないのか?
> それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
> レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ
昔からウェブアプリ自身にTLS（SSL）を解く機能は持たせず、
その前に設置しているリバースプロキシ等にやらせるだろ。
例えばRailsを使うにしてもRails自身でSSLを処理するのではなく、
リバースプロキシ等（例 nginx）で行わせる。
このnginxはRailsのプリコンパイルしたCSSやJavaScript等の
静的ファイルの配信でも利用される。静的ファイルの配信は
それが得意なnginxにやらせてRailsはアプリの処理のみを行う。
そういったすみ分けが昔から出来てるわけで、Dockerコンテナだからそうするいう話ではない
827(1): 2018/12/15(土)15:15 ID:cWutNvKe(1) AAS
>>826
証明書ゲートウェイですね
大手でも、そういう名前のサイトで最初で認証させられるわ。
828: 2018/12/15(土)15:44 ID:K1K5tkNg(1/2) AAS
>>827
なんかそれ違う気がする。
>>826のはSSLアクセラレータとかの方でねぇか？
829: 2018/12/15(土)15:46 ID:K1K5tkNg(2/2) AAS
訂正：SSLアクセラレータとかSSLオフロードとかの方でねか？
830(3): 2018/12/19(水)14:48 ID:MXoPEPIu(1) AAS
WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ
831: 2018/12/19(水)15:26 ID:ChoPuE2E(1) AAS
>>830
そうなんだ
又試してみるかな
832: 2018/12/19(水)16:34 ID:RugaoNC3(1) AAS
>>830
バーチャルマシンつかった段階で、負けた感がある。
そこはLinuxをちゃんとつかって、生でDockerしないと。
833(1): 2018/12/20(木)23:54 ID:XN4/V/I5(1) AAS
>>830
何が凄いのか、分からない、良かったら教えてくだしあ
個人的には、Linuxでdocker派です
834(1): 2018/12/21(金)01:14 ID:Nv7/v6TH(1/3) AAS
Dockerって、可搬性
>>833
これまでHyper-VをオンにするとVirtualBoxが使えなかった。
それが6.0から共存して使えるようになると騒いでいる。
でも自分も含め動いていない人も居て、本当に動くのか議論されている。
835: 2018/12/21(金)01:15 ID:Nv7/v6TH(2/3) AAS
最初に変な文入った。すまん。
836: 2018/12/21(金)01:24 ID:XG5mmZ9I(1) AAS
ひょっとしてVMWareとも共存できるようになった？
837(1): 2018/12/21(金)01:53 ID:uGD7jju5(1/2) AAS
>>834
公式にはできるってアナウンスないって事？
838(2): 2018/12/21(金)06:49 ID:Nv7/v6TH(3/3) AAS
>>837
公式にアナウンスされているけど、動かない。でも動いてる人も居るんですよね。きっと。
839(1): 2018/12/21(金)11:28 ID:gbcTPeq+(1/2) AAS
>>838
Windows ハイパーバイザープラットフォームをオンにしたら動いた
外部ﾘﾝｸ:superuser.com
840: 2018/12/21(金)13:33 ID:l/z2KMXK(1) AAS
>>839
QEMUの話。動いたとは書かれていない
841(1): 2018/12/21(金)17:10 ID:uGD7jju5(2/2) AAS
>>838
Vrtual Boxの方をアプデするのね
Dockerの公式ブログとか見てたw
842(1): 2018/12/21(金)17:47 ID:gbcTPeq+(2/2) AAS
>>841
6.0にしてWindows ハイパーバイザープラットフォームをオンにし、再起動。
843: 2018/12/22(土)09:20 ID:XGn7oEU9(1) AAS
>>842
ありがと
やってみます
844(1): 2018/12/23(日)05:24 ID:qY0IrDwI(1/2) AAS
素人ながらubuntu16.04にdockerを入れたらネットに接続できなくなりました。ブリッジが勝手にかかっててwifiがつながらない症状が出ています。
操作しようとしたらgot permission denied while trying to connect to the Docker daemon socket at unix 〜〜〜と出てきました
この状態からdockerを削除して元の状態に戻す方法を教えていただけないでしょうか。
sodo gpasswd -a username dockerでグループには追加しました。
845: 2018/12/23(日)05:53 ID:HJ+H2evR(1/5) AAS
>>844
dockerを消す前に、再起動しろ
再起動したら動く
846: 2018/12/23(日)06:59 ID:qY0IrDwI(2/2) AAS
接続できるようになりました。とんだお騒がせをいたしました。
847: 2018/12/23(日)07:11 ID:HJ+H2evR(2/5) AAS
ま、再起動しなくてもネットワークサービスを再起動して
ログインしなおせば動くんだけどなｗｗｗ
848: 2018/12/23(日)14:58 ID:yfLE2NmO(1) AAS
今更ながらdocker勉強し始めました
KVMみたいにOSから作るのは理解できるけど、例えばDockerHubからNginxイメージをpullする時は、dockerをインストOS環境に依存するの？
Debian使ってたらDebian環境用のNginx環境ができるの？
849: 2018/12/23(日)15:09 ID:HJ+H2evR(3/5) AAS
そのnginxイメージを作ってるDockerfileを読めばわかることだろ
dockerを使う = Dockerfileを読み書きするってことなんだからな
850: 2018/12/23(日)15:11 ID:Sp1piTzY(1) AAS
使用しているベースイメージ次第。環境は関係ない。
dockerは実運用するなら素のベースイメージから上は自分で作るのが基本だから、そのへんの考え方は一度自分でやってみればすぐに理解できる。
出来合いのものはあくまでサンプル。
851: 2018/12/23(日)15:18 ID:nk+HmfrL(1/2) AAS
ありがとう
むぅ理解できないわ
取り敢えず触ってみる
852: 2018/12/23(日)15:20 ID:nk+HmfrL(2/2) AAS
んっnginxより上、ベースイメージでの動作はdockerが担保してくれるってことなのかな
触ってみる
853: 2018/12/23(日)15:23 ID:B+bc3dl4(1) AAS
カーネルは共有されるけどそれくらい
854(2): 2018/12/23(日)20:16 ID:JFyTQrTf(1) AAS
LinuxカーネルのABIは安定しているので
カーネルより上の層（libc）とかは
基本どのディストリビューションでも動作する
go言語は他のライブラリが必要ない実行ファイルを作れる
scratchイメージにgoの実行ファイルだけ入ったものを作れば
僅か数MBのDockerイメージすら作れる
855(1): 2018/12/23(日)20:27 ID:QVRCwsb4(1/2) AAS
>>854
何ヶ月か前に別スレでその最初の3行にまつわる話したら袋叩き似合った
856: 2018/12/23(日)20:28 ID:a3X0TqIZ(1) AAS
だってウソだもんで>LinuxカーネルのABIは安定している
857: 2018/12/23(日)20:53 ID:HJ+H2evR(4/5) AAS
>>854
> go言語は他のライブラリが必要ない実行ファイルを作れる
でもライブラリ相当の機能が実行ファイルに含まれてるから、
goのバイナリはサイズがデカイんだよね
858: 2018/12/23(日)20:56 ID:HJ+H2evR(5/5) AAS
お、あったｗ やっぱりでかい
外部ﾘﾝｸ:d.hatena.ne.jp
言語 ファイル名 大きさ（byte）
C言語 hello_c 5516
C++ hello_cpp 5588
D言語 hello_d 360500
Go言語 hello_go 1091428
859: 2018/12/23(日)21:00 ID:QVRCwsb4(2/2) AAS
goはでかいよ
Archやってるとでかいサイズのgoの更新が頻繁に来るからうざい
860(1): 2018/12/23(日)22:03 ID:jSNMCGZQ(1) AAS
Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
つまり安定性が高い。
一方、Windowsは動作が変わると名前にサフィックスが付く。
従って新しいAPIに自動的にリンクされることはないし、APIの数はドンドン増え続ける。
861: 2018/12/23(日)22:06 ID:UzZijvxD(1) AAS
>>860
？
Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
Windowsは動作が変わると名前にサフィックスが付く。
以前の名前は変わらないので必ずリンクができるし、以前の名前の動作が変わることがない
だから高い互換性が保てる
といいたいのかな
Linuxはカーネルのシステムコールの数が増えなくても
ライブラリとは関係ない話なので、APIの数の代わりにライブラリの関数が増え続けるよ
862: 2018/12/23(日)22:39 ID:5Q1rOqA5(1) AAS
>>855
読んでみたい、どこか覚えてる？
863: 2018/12/24(月)11:43 ID:ZQ/dJl6b(1) AAS
Debianにインスコ開始ー
864(2): 2018/12/24(月)12:15 ID:wEpk+PBH(1) AAS
GoのシングルバイナリってGPL汚染はないの？
というかDocker自体、上の方で猿が喚いてる「コンテナはアプリだ！」との主張がもし世間一般に通るなら、
単なる集積物であってアプリにGPLは感染しない理論はかなり無理があるんじゃないかな
865: 2018/12/24(月)12:32 ID:3ljC1xCs(1/2) AAS
自分で入れた癖して汚染したとか騒ぐのは笑えるぜ
866(1): 2018/12/24(月)12:37 ID:3ljC1xCs(2/2) AAS
>>864
そもそもGoはBSDライセンスだし
gccgoを使う場合はGPLのコンポーネント（gcc）を含むが
生成したバイナリはGPLの対象外
gccのランタイムライブラリは例外にしないと
Linuxにクローズドソースのソフトウェアが一切存在出来なくなるから
まさかクローズドソースのは一切無いと思ってた？
867(4): 2018/12/24(月)12:54 ID:FVAjhLvH(1) AAS
>>866
LinuxのアプリがGPLに感染しないのは、GPLの「単なる集積」と「システムコール」の例外条項による
自分で条項を読んでみたらいい
Dockerコンテナを単なるアプリケーションパッケージと解釈するなら、これらの例外が適用されるかはかなり怪しいよ
まあGoの場合は解釈論を云々するまでもなくGPLライブラリをスタティックリンクした時点で完全アウトだが
868: 2018/12/24(月)13:26 ID:n0J+hQ60(1/2) AAS
>>867
意味不明
Dockerで使う時だけ対象になるとか何処に書いてある？
869: 2018/12/24(月)13:36 ID:n0J+hQ60(2/2) AAS
>>867はDockerイメージは全てオープンソースにしないと違法って言ってんのか？
そんなこと言ってんのお前だけだろw
870: 2018/12/24(月)14:05 ID:sB1miyd2(1/3) AAS
Linuxはソース文化なのでコンテナがないとアプリケーションの配布がきつい。
871(1): 2018/12/24(月)16:44 ID:0ONmT3Cp(1/4) AAS
>>867
お前、その主張は、DVDにGPLとそうでないものを
一緒に焼いたら（つまりRedHat Linux状態）
ライセンス違反になると言ってることになってるんだが
気づいているか？
872: 2018/12/24(月)16:46 ID:0ONmT3Cp(2/4) AAS
>>867じゃなくて>>864あて
873: 2018/12/24(月)18:34 ID:sB1miyd2(2/3) AAS
Redhatは倫理規定違反で死刑になってもおかしくないけどな。
874: 2018/12/24(月)19:52 ID:fOFd4UE9(1) AAS
そもヨゴレのIBMと喜んでくっつかってんだから相当なド底辺クズ野郎どもだろ>RH
大喜びで開発協力してきた日本の大手ITベンダのアホ情弱どもはそれ以下のマヌケだろうけどな
875: 2018/12/24(月)22:18 ID:Hg8v6tOU(1) AAS
>>871
>>871
それがいわゆる「単なる集積」
特定のアプリのために同梱してるんじゃなくて本当に単なる寄せ集めだから派生物と見做されない
一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで、例外条項の趣旨を考えれば完全にアウトだ
だからDocker使うなら間違っても「コンテナはアプリだ」なんて言っちゃいけない
876: 2018/12/24(月)23:37 ID:0ONmT3Cp(3/4) AAS
> 一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで
事実上スタティックリンクってことは
本質上スタティックリンクじゃないってことだよね
877(1): 2018/12/24(月)23:39 ID:0ONmT3Cp(4/4) AAS
Dockerコンテナはスタティックリンクしてないからアプリと言えるわけである
スタティックリンクしていれば1バイナリになる。
878: 2018/12/24(月)23:52 ID:Y3lrr8FC(1) AAS
>>877
GPLはスタティックリンクか動的リンクかに関わらず感染するよ
879: 2018/12/24(月)23:54 ID:sB1miyd2(3/3) AAS
LGPLなら良かったのにな。
880(1): 2018/12/25(火)00:01 ID:XGHDmrXH(1/4) AAS
ちなみにAndroidアプリだと、LGPLライブラリ(.so)をアプリのパッケージ(ZIP形式)に入れて配布するのはスタティックリンクに該当し、
アプリがLGPLに感染するという解釈が一般的だ
Dockerイメージは言うまでもないよね
881: 2018/12/25(火)00:04 ID:MqCJ7mUS(1/4) AAS
いつのまに、アプリと呼ぶだけでGPLに感染することになったんだ？ｗ
本質的にアプリだが、アプリと呼ばなければOKって意味不明
俺が「あれ」と「これ」を含んだDockerコンテナ=アプリを作ったとして
他人が作った「あれ」と「これ」のライセンスを、赤の他人の俺がGPLに変更できるわけないし
Dockerfileはただの数行のファイルでしか無いし、
俺がGPLのものを作ってなにか作ったからと言って、それを不特定の人に公開する義務もない
Docker=アプリに反論したいができなくて、とりあえず言ってみたんだろうが
穴がありすぎて、大丈夫かこいつ？
882: 2018/12/25(火)00:05 ID:MqCJ7mUS(2/4) AAS
>>880
良い皮肉だｗ
Googleストアにあるやつは全部GPLになっちゃうよなｗ
883: 2018/12/25(火)00:09 ID:MqCJ7mUS(3/4) AAS
Dockerイメージを配布せずに、
Dockerfileだけ配布すれば
完全にGPL（LGPL）を回避できる
Dockerは素晴らしいですな！
884: 2018/12/25(火)00:10 ID:MqCJ7mUS(4/4) AAS
ということで、DockerがGPL違反になるとか言ってるアホは徹底的にコテンパンにされました。おしまい。
885: 2018/12/25(火)00:11 ID:XGHDmrXH(2/4) AAS
いやイメージを配布するのは普通にGPL違反よ
配布しなけりゃいいだけだし、誰もそれは否定してないでしょ
886: 2018/12/25(火)00:23 ID:FPaj6kyi(1/6) AAS
まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。
887: 2018/12/25(火)00:24 ID:DAdBnaIi(1/18) AAS
> いやイメージを配布するのは普通にGPL違反よ
1. そもそもイメージ配布しなければGPL違反でないし
イメージ配布する人を社内に限れば、社内の人だけにソースを配布すれば良い
2. GPLはバイナリを入手した人がソースを入手できればいいので
バイナリを手に入れてない人にソースを配布する必要はない
3. DockerイメージのソースとはDockerfileのこと
4. もちろんDockerイメージの不特定の人に配布したら、
その中に入っているバイナリのソースも渡さないといけない
888(2): 2018/12/25(火)00:25 ID:DAdBnaIi(2/18) AAS
> まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。
その理屈だと、ISOイメージにして配布しているRedHatなんかも
ライセンス違反ということになってしまうので、間違ってるのは明らか
889: 2018/12/25(火)00:26 ID:DAdBnaIi(3/18) AAS
一言で言うならば、GPL感染した所で、プライベートイメージなら
何ら問題ないってことよ。
890: 2018/12/25(火)00:26 ID:FPaj6kyi(2/6) AAS
>>888
Redhatは裁判になったら死刑判決受けるだろ。
891(1): 2018/12/25(火)00:26 ID:3aFn9L6f(1/4) AAS
>>888
だからそれは単なる集積
DockerもVMだから単なる集積だと強弁してしまえばイメージの配布も限りなく黒に近いグレーにできなくもない
892: 2018/12/25(火)00:27 ID:DAdBnaIi(4/18) AAS
>>891
Dockerのイメージも単なる集積だけど？
893: 2018/12/25(火)00:28 ID:FPaj6kyi(3/6) AAS
見る人が見れば真っ黒に近い黒だろうな。
例えばGNUの尊師が見たら完全にアウツだろ。
894(1): 2018/12/25(火)00:29 ID:DAdBnaIi(5/18) AAS
Dockerのイメージがどういうふうに展開されてるのか知らないのかな？
単なるファイルとしてディスクに展開されてるんだけど
最終的にはLinuxのコンテナとして動いていて、コンテナがchrootを発展させたものって知っていれば
以下のリンク先の説明にあるように、とあるディレクトリ以下に展開されてるファイルを実行するだけって
わかるはずなんだが？
外部ﾘﾝｸ:deeeet.com
895: 2018/12/25(火)00:32 ID:3aFn9L6f(2/4) AAS
>>894
仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ
誰がどう見ても派生物だよ
896(1): 2018/12/25(火)00:33 ID:DAdBnaIi(6/18) AAS
> 仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ
だからその理屈を言ってしまうと、RedHatのISOイメージも
同じことになってしまうので、その矛盾を解決してから出直してきなって話
897(1): 2018/12/25(火)00:33 ID:3aFn9L6f(3/4) AAS
>>896
だからGPLの「単なる集積」の条項を読んできなさい
898: 2018/12/25(火)00:34 ID:DAdBnaIi(7/18) AAS
そもそもLinuxでパッケージが提供されているものだけを
使用すればGPL違反になりようがないんだよね
だからDockerコンテナ＝アプリ
899: 2018/12/25(火)00:34 ID:DAdBnaIi(8/18) AAS
>>897
読んで問題がないことがはっきりしている
900(2): 2018/12/25(火)00:38 ID:DAdBnaIi(9/18) AAS
はいどうぞ
「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?
外部ﾘﾝｸ[html]:www.gnu.org
「集積物」はいくつかの別々のプログラムからなり、それらは同じCD-ROMやそのほかのメディアや "Dockerイメージ" に
いっしょに入れられて配布されます。GPLは集積物を作成し配布することを認めています。
たとえ、ほかのソフトウェアが不自由あるいはGPLと両立しないものである場合でもです。
ただ一つの条件は、あなたは、それぞれのプログラムの個別のライセンスが許す権限を
ユーザが行使することを妨げるような、あるライセンスのもとで集積物をリリースすることはできないということです。
二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか?
これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、
適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)と
コミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。
モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。
CD-ROMやそのほかのメディアやDockerイメージは実行ファイルではありません
もしモジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、
それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。
逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で
使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションの
ために使われるときには、モジュールは通常別々のプログラムです。
しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
901: 2018/12/25(火)00:42 ID:DAdBnaIi(10/18) AAS
個々のファイルをあつめて、Dockerイメージにするだけでは
単なる集積物だろう。
902(1): 2018/12/25(火)00:43 ID:3aFn9L6f(4/4) AAS
>>900
えっと、君のアプリはDockerイメージ内のGPLライブラリと動的リンクしてないの?w
903: 2018/12/25(火)00:46 ID:DAdBnaIi(11/18) AAS
>>902
GPLライブラリとは動的リンクしてないけど？
動的リンクが許されるLGPLライセンスのものばかりだなぁ
GPLのものとは以下の分離したプログラム間でのコミュニケーションメカニズムを使うから問題ないし
> 逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離した
> プログラムの間で使われるコミュニケーションメカニズムです。
これで結論出たよね？
904: 2018/12/25(火)00:51 ID:DAdBnaIi(12/18) AAS
そもそもGPLのものを作ってるのであれば
別にGPLに感染した所で何の問題もないよね。
それから本当の目的は「Dockerコンテナ=アプリ」を否定したかったんじゃなかったの？
Dockerコンテナをアプリと読んでしまったらGPL感染する！とかいう謎理論でさ
905: 2018/12/25(火)00:57 ID:DAdBnaIi(13/18) AAS
Dockerコンテナ＝アプリが気に食わなかったんだろうけど
結局、DockerイメージにするだけでGPL感染させられるか？という
話にしかなってなくて、そんなもんGPLライセンス読めば単なる集積物でしかない
Dockerイメージ（Linuxの機能のコンテナを実行するのに必要なファイルをまとめたもの）は
集積物として扱われるに決まってるし
最初のDockerコンテナ=アプリと何の関係もないし
どんな結論を目指したくてこの話を持ち出してきたのかわからんわ
┐(´ー｀)┌ﾔﾚﾔﾚ
906(1): 2018/12/25(火)01:05 ID:XGHDmrXH(3/4) AAS
>>900
そのDockerイメージについての言及がリンク先に見当たらないんだけど、参考までにどこにあるか教えてほしい
907(1): 2018/12/25(火)01:12 ID:DAdBnaIi(14/18) AAS
>>906
じゃあ君は、Dockerイメージがリンクに相当する言及するところを持ってきてくれ。
言い出しっぺなのだから、それぐらいやってから言うべきことだからな。
上下前次1-新書関写板覧索設栞歴
あと 95 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s