Docker Part2©2ch.net

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

http://www.docker.io/

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

>>747
クラウドの客が犬糞使いたがってる影響だな
まぁ色々やむを得ずなんだろ

>>750
そもそもライセンスが面倒

>>752
だから必然的にクラウドを使うんだよ
AzureもAWSもGCPもWindowsインスタンスが用意されていて
そこにライセンスも使用料も含まれてる

もしかして知らなかった？
オンプレで自前サーバーとかて立ててる
時代のやり方してる所は知らなそうだよね

windowsを使おうと思わないから、インスタンスがあっても知らんよ。。

awsとか使ったことあるならwindows使わなくてもインスタンスあることくらい知ってるだろ

クラウド使ってないのがバレた瞬間w

インスタンス料金表とか見たらデカデカと載ってるからね
知らないのはさすがにありえないわ

ふとAWSのダッシュボードみてみたら、Linuxなんかよりも先にあるねWindows

アイウエオ順だからね

ダッシュボードほとんどつかわねーもん。

そりゃクラウド使ってなきゃ、
「必ず使わないとその他のメニューに行けないダッシュボード」を
使わないことだってあるだろうなぁｗ

えっ、お前マネージメントコンソールやリファレンスを一切見ることなくCLIを使いこなし、
適切なインスタンスタイプ名を一発で引き当てることができないの？w

何にいくらコストがかかるって
CLIで見れたっけ？

引き当てるって書いてあるし、ガチャ方式でやるってことか
使ったことがないからネタに走ったってことね

クラウドのインスタンスって、最初からOSが組み込まれているのか？
どんな設定されているかわからないものを使うって不安でない？
最初からiptableが開かれているとかさ？

根本的なところがずれてるな

自分でOSを組み込んだら、どんな設定になるのかわかるのか？
iptableの状態がどうなってるのか、安心できるのか？

>>765
そもそもクラウドにiptableの設定なんか必要ない
そういうのはインフラ側の設定で制御するんだよ
オンプレ脳の人間はインフラを「容易には弄れないもの」と考えて何でもサーバー内で完結しようとする
しかしクラウドにおいてはむしろそれは逆で、サーバーよりもインフラの設定の方が柔軟に変更でき、構成管理も極めて容易だ
iptableのような脆弱な仕組みに頼ることなくデザインによってセキュリティ等の要件を担保できる
これがクラウドの強みだ

説明下手だなｗ

デザインによってセキュリティ等の要件を担保できるとか
意味不明な説明じゃなくて単純に言えばいいだけだろ

クラウドではサーバーの外にあるファイアウォールで制御する
そのファイアウォールは、設定画面やCLIコマンドやAPIから設定できる

多層防御やんないの？

>>768
わかりやすい。

でも、手作業による設定と違って、
柔軟な設定はできなさそう。

Dockerならフォワードチェインから、
サブチェインに飛ばして、そこでフィルタやパケットの統計をとったり、
あるいは、ポート開放のために、-t nat にフォワードの設定が必要になるだろうけど、
クラウドはそういうのは使わないの？

> でも、手作業による設定と違って、
> 柔軟な設定はできなさそう。

手作業ってなんだ？ どうせコマンドうつだけだろ

> Dockerならフォワードチェインから、
Dockerコンテナ = アプリ

お前、アプリの中に、ファイアウォールの設定入れるのか？
Dockerコンテナは仮想マシンじゃないって言ってるだろ

>>770
> クラウドはそういうのは使わないの？
だからそれらは全てサーバーの外にあるファイアウォールで設定できる

実際はiptableなんかに頼ることなく、ハード込みで売ってるファイヤウォール使ってるってことだろ。

>>769
やりたいならやればいいのでは？

>>769
お前はリスクマネジメントというものを分かってない
AWSが俺を信じて任せろと言ってるんだからリスクは完全にAWSに転嫁されていて、それで十分なんだよ
もしもAWSの不具合で事故るようなことがあれば、そのときはAWSに損害賠償請求すればよい

>>775への反論は

そんな無責任が通用するわけがないだろう

自前で実装して、不具合で事故るようなことがあれば、損害賠償してやる！と
男らしく言うべきだ。

自前で実装する＝事故る可能性が高い わけだけど、
損害賠償するのが男らしいんだ！

という感じでお願いねｗ

AWSのインフラはCloudFormationかTerraformを使って設定するのが今どき

全てGitリポジトリに入れて管理すれば誰が何を変えたか分からないって事はなくなる

AWSの場合、接続出来るIPやポートの制限はセキュリティグループで行う

手動で変更されてもEvident.ioを使えば自動で検出して修復できる

Evident.ioを使ってセキュリティオートメーションしてみた
https://dev.classmethod.jp/cloud/aws/security-automation-using-evident-io/

Evident.io使わなくても
CloudTrailとSNS、Lambdaを使えば同じことできそうだが
めんどい

http://connect.uh-oh.jp/

現実の人の繋がりに疲れた人に

宣伝です。

コンテナとJSフロント関係は
進歩早すぎてついていけん...

>>771
でも、Dockerコンテナ起動したら、
ポートが開くじゃない？
たとえば、ソースIPアドレスで絞り込んだり、
iptablesが必要だと思うけど？
そういうこともawsセンター側できるの？

> でも、Dockerコンテナ起動したら、
> ポートが開くじゃない？

開かないが？

>>780
例えば、nginxを起動するとポート80番が開く
って話してるのか？

Dockerと関係ない話だよね

>>771

コンテナはアプリを動作させるための環境であって、
コンテナ＝アプリという式は間違っている。

>>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は実運用するなら素のベースイメージから上は自分で作るのが基本だから、そのへんの考え方は一度自分でやってみればすぐに理解できる。
出来合いのものはあくまでサンプル。