Docker Part2©2ch.net

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

http://www.docker.io/

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

>>775
まあ大抵にわかのセキュリティエンジニア（笑）が設定ミスってノーガードになるのが事故の原因なんだけどな
オンプレでもFWで守られてるから大丈夫なんて余裕ぶっこいてるサーバーほどよく侵入されてる

>>783
コンテナ＝アプリ と言ってない
Dockerコンテナ=アプリ と言ってる
正確に言うならアプリ相当として考えろってことだが

>>784
なんでデフォルトでポート塞がないの？って話だな

クラウドならサーバー外部にある、ファイアウォール相当のものがデフォルトで塞いでいるから
いくらサーバー側で設定ミスっても接続できない。

意図的にファイアウォールの設定をしない限り接続できないように
安全な状態になっている。

>>784
それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
クラウドだとFW相当の設定はサーバー単位だし、その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
その上で更にサーバ内でポート閉じる設定するなんて明らかに冗長なだけ

>>786
デフォで、オールリジェクト？ポリシーはどうなっているの？

awsでもDockerコンテナ使えますか。
使えるなら、Dockerホストと、その外部ファイアウォールの両方でポート開放が必要ということですよね。
いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。

>>787
> それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
セキュリティ突破できたらやり放題って当たり前だろ
何を言ってるのかわからん。

> クラウドだとFW相当の設定はサーバー単位だし
普通はネットワーク単位だが？

> その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
だからそれがデフォルトなのがクライド

>>788
> awsでもDockerコンテナ使えますか。
今の話にDockerコンテナは関係ないから
（パッケージでインストールする）nginxに置き換えるね

> nginxのホストとその外部ファイアウォールの両方でポート開放が必要ということですよね。
> いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。

だからなに？

>>789
いやセキュリティグループはサーバー単位だろ
本当にAWS使ってるのか？

>>791
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

この下の図を見ろ。
インスタンスの外にセキュリティグループが存在している

>>790
0点

>>788をよく読んで答えなさい

>>793
反論できないならレスすんなよｗ

>>792がAWSを使ったことがないことはわかった

セキュリティグループは作ってからEC2インスタンスやロードバランサー、データベースにくっつける

IPアドレスの範囲に加え、
特定のセキュリティグループを持ったインスタンスの接続のみを許可する使い方も出来て便利

AWS使ったことないんだけど、ポートを塞ぐだけでセキュリティ云々言うのは間違ってるよ。
webなんかで言われるセキュリティホールは80とか443を使って侵入するから通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通。

>>797
URLを解析って何すんの？
言ってみ

オンプレの場合、一旦納品したサーバーは
脆弱性があろうともバージョンアップしないんだろう

だから脆弱性があるサーバーを守るために
ファイアウォールを使う。

馬鹿としか言いようがないｗ

自分のアプリのバグで大穴を開けなきゃ普通は大丈夫

>>798
jsが仕込まれたURLじゃないかとか色々

>>794
反論を煽るようなレスをわざわざするなよ

>>798
ストリングクエリとか

>>801
え？なに？ クライアントからサーバーに
jsが仕込まれたURLが送られてくんの？

>>803
え？なに？ストリングクエリに細工されていたら
サーバーに侵入される脆弱性があるの？

>>804
最初からわかっていたら苦労しない。

>>805
テストもレビューもしないってこと？
細工したクエリストリング流してテストすればわかることだよね？

可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、
それ以外は404とかに出すに限る。404も別サーバーでいい。
bashショックもURLだったろ。あれはパッチをできるだけ速く当てるしかないが。

テストとレビューで事足りるならセキュリティは苦労しない。

でもセキュリティあってもテストとレビューで
事足りないものはセキュリティでも漏れるから
意味ないよね

> 可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、

だから限られたURLってなんだ？
お前のサーバーは、自分以外のURLで接続できるのか？

>>810
普通いくらでも通るぞ。getも知らないのか？

>>811
どこのサーバーからgetするの？

>>810
たとえば、基本的なところでは、クエリストリングで、
アプリケーション側で対応するフィールド以外のものは、
排除するとか。

>>797
>webなんかで言われるセキュリティホールは、80とか443を使って侵入するから、
通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通

アプリ製作者が素人で、アプリにバグがあるから、こいつらの技術では自前で実装できないw

SQL 文を文字列でつないで作って、問い合わせる奴。
place holder を使っていない奴は、SQL インジェクションされる

sql文 = "SELECT 列名 FROM 表名 WHERE user_id='$userid';";

この変数に、1 だけなら良いけど、
クラッカーは「1; 文」のように、; を打って、クラッキングする文をつなげてくる

資格も持ってない・勉強していない奴は、当たり前の事も知らない。
place holder を使っていないアプリは、損害賠償請求できる

こういう奴らは、アプリを作っちゃいけない！

>>813
そんなもんWAFで弾ける
クラウドならそれこそ画面でポチるだけ

>>788
>awsでもDockerコンテナ使えますか

aws は、Docker だろ。
CoreOS, Kubernetes とか

コンテナってクラウドに熟達した人が究極のdeployabilityを追求した末に行き着くものだと思ってたけど、意外とそうでもないんだね
クラウドには手が出ないけどなんか新しそうなもの触ってみたいだけな人が多いのかな

マネージドKubernetesサービス対決

比較表見るとアマゾンのEKSはGoogleのGKEと比較してコスト高いだけの劣化版に見える
そしてMSのAKSはどちらにも及ばないクソ
https://kubedex.com/google-gke-vs-microsoft-aks-vs-amazon-eks/

>>815
httpsの場合は？
中間者攻撃が成立しないと解読できないと思うけど。

>>819
wafはCloudFrontやALBと組み合わせて使うよ。
それらはSSLアクセラレーターの機能も兼ねてるのでwafやwebサーバ側に来る時点ではhttp平文状態になります。
この場合、サーバー証明書はCloudFrontやALBに組み込むだけで済みます。AWSはドメイン発行やルート局も持ってるので証明書関連はAWSだけで完結できます。
スレチだけどEntity Framework等の昨今のO/Rマッパーを使っていればSQLインジェクション対応してくれるから余り神経質になる事はないよ。自身でSQL文を組み上げる事はしません。

>>819はまさかコンテナにSSL喋らせてるのか?
そんな足回りの関心は丸投げできるようなインフラでないと上で喚いてる「アプリとしてのコンテナ」なんか程遠いだろ

もうそろそろ飽きてきたな。
インフラ周りの話はDockerコンテナと関係ないし

今時オーケストレーションやインフラの技術を抜きにしてコンテナを語るのは無理があるだろ
ホビーストがチマチマrunして遊ぶ時代はとうの昔に終わったんだよ

>>823
レイヤーが違うんだよ。

Dockerはコンテナに動かすのに必要なものがカーネル以外全て入っている
逆に言えばDockerを動かすものは何でもいい。

Kubernetes使おうがsystemdから起動しようがコマンドで実行しようが関係ない

アプリの話をしているときにOSの話をするのは関係ないだろ？
OSとアプリの連携の話をするならまだわかるけど、
OSそのものの話は関係ないじゃん？今の話はそういうレベル。

インフラそのものの話になってしまって、アプリは全く関係ない話になってる。

アプリとインフラの機能を密結合させるという発想しか持ち合わせてないから
こういう話を続けるのだろうけど

>>824
大いに関係あるよ
なぜコンテナにTLSが必要ないのか?
それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ
コンテナを単なるVMというならともかく、そうじゃないと主張しているんだろ？
だったらそのためのインフラに対する条件は明確にしておかなければ机上の空論でしかないぞ

>>825
お前が言ってるのコンテナと関係ない話じゃん

> なぜウェブアプリにTLSが必要ないのか?
> それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
> レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ

昔からウェブアプリ自身にTLS（SSL）を解く機能は持たせず、
その前に設置しているリバースプロキシ等にやらせるだろ。

例えばRailsを使うにしてもRails自身でSSLを処理するのではなく、
リバースプロキシ等（例 nginx）で行わせる。

このnginxはRailsのプリコンパイルしたCSSやJavaScript等の
静的ファイルの配信でも利用される。静的ファイルの配信は
それが得意なnginxにやらせてRailsはアプリの処理のみを行う。

そういったすみ分けが昔から出来てるわけで、Dockerコンテナだからそうするいう話ではない

>>826
証明書ゲートウェイですね
大手でも、そういう名前のサイトで最初で認証させられるわ。

>>827
なんかそれ違う気がする。
>>826のはSSLアクセラレータとかの方でねぇか？

訂正：SSLアクセラレータとかSSLオフロードとかの方でねか？

WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ

>>830
そうなんだ
又試してみるかな

>>830
バーチャルマシンつかった段階で、負けた感がある。

そこはLinuxをちゃんとつかって、生でDockerしないと。

>>830
何が凄いのか、分からない、良かったら教えてくだしあ
個人的には、Linuxでdocker派です

Dockerって、可搬性
>>833
これまでHyper-VをオンにするとVirtualBoxが使えなかった。
それが6.0から共存して使えるようになると騒いでいる。
でも自分も含め動いていない人も居て、本当に動くのか議論されている。

最初に変な文入った。すまん。

ひょっとしてVMWareとも共存できるようになった？

>>834
公式にはできるってアナウンスないって事？

>>837
公式にアナウンスされているけど、動かない。でも動いてる人も居るんですよね。きっと。

>>838
Windows ハイパーバイザープラットフォームをオンにしたら動いた
https://superuser.com/questions/1208850/why-vitualbox-or-vmware-can-not-run-with-hyper-v-enabled-windows-10

>>839
QEMUの話。動いたとは書かれていない

>>838
Vrtual Boxの方をアプデするのね
Dockerの公式ブログとか見てたw

>>841
6.0にしてWindows ハイパーバイザープラットフォームをオンにし、再起動。

>>842
ありがと
やってみます

素人ながらubuntu16.04にdockerを入れたらネットに接続できなくなりました。ブリッジが勝手にかかっててwifiがつながらない症状が出ています。
操作しようとしたらgot permission denied while trying to connect to the Docker daemon socket at unix 〜〜〜と出てきました
この状態からdockerを削除して元の状態に戻す方法を教えていただけないでしょうか。
sodo gpasswd -a username dockerでグループには追加しました。

>>844
dockerを消す前に、再起動しろ
再起動したら動く

接続できるようになりました。とんだお騒がせをいたしました。

ま、再起動しなくてもネットワークサービスを再起動して
ログインしなおせば動くんだけどなｗｗｗ

今更ながらdocker勉強し始めました
KVMみたいにOSから作るのは理解できるけど、例えばDockerHubからNginxイメージをpullする時は、dockerをインストOS環境に依存するの？
Debian使ってたらDebian環境用のNginx環境ができるの？

そのnginxイメージを作ってるDockerfileを読めばわかることだろ

dockerを使う = Dockerfileを読み書きするってことなんだからな

使用しているベースイメージ次第。環境は関係ない。
dockerは実運用するなら素のベースイメージから上は自分で作るのが基本だから、そのへんの考え方は一度自分でやってみればすぐに理解できる。
出来合いのものはあくまでサンプル。

ありがとう
むぅ理解できないわ
取り敢えず触ってみる

んっnginxより上、ベースイメージでの動作はdockerが担保してくれるってことなのかな

触ってみる

カーネルは共有されるけどそれくらい

LinuxカーネルのABIは安定しているので
カーネルより上の層（libc）とかは
基本どのディストリビューションでも動作する

go言語は他のライブラリが必要ない実行ファイルを作れる
scratchイメージにgoの実行ファイルだけ入ったものを作れば
僅か数MBのDockerイメージすら作れる

>>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は素晴らしいですな！