Docker Part2©2ch.net

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

http://www.docker.io/

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

>>702
OSの起動速度が重要なのは、一時的なアクセス数増加に
迅速に対応するためだろ

> 犬糞はバイナリ互換性ガチ無視だからドッカ〜みたいなキワモノに依存せざるを得ないんだろ
バイナリ互換性があれば、デプロイが簡単になるという理屈をどうぞ
やっぱりDockerの目的がわかっちゃいねぇｗ

> 犬糞はドッカーが必要になるぐらいすぐにドコでも動かなくなる可能性が高い不安定なOS環境ってコトだろ
Dockerがあれば不安定なOS環境でも安定できるって
それ逆にすごくねｗ

Dockerの凄さをまざまざと見せつけられたｗ

>>703
>OSの起動速度が重要なのは、一時的なアクセス数増加に
>迅速に対応するためだろ

awsでも客数の増減でイチイチ鯖をageたり落としたりしてんのかよ
連中のやってんのは課金上げて乞食ユーザーをスポットインスタンスから振り落とすコトだけだろうがｗ

>バイナリ互換性があれば、デプロイが簡単になる
バイナリ互換性がないからデプロイするたびにドッカーが必要になるってコトだろ

>Dockerがあれば不安定なOS環境でも安定できるって
ドッカーによって稼働中のシステム全体がコケるってオチだろｗ
まさにそびえ立つクソの山

論理展開ができない人間と真面目に議論しても得るものなんかないぞ。さわるなさわるな。

>>705
ホントだなｗ

What is the runtime performance cost of a Docker container?
https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container

It doesn't work with Docker, K8s right now, but everyone's going nuts anyway for AWS's Firecracker microVMs
https://www.theregister.co.uk/2018/11/27/aws_sets_firecracker/

Firecrackerは今までのVMより速くなったとは言え、ベアメタルの95%を超える程度のCPUパフォーマンス
たかが5%されど5%

コンテナはCPUのオーバーヘッドはほぼ0
セキュリティよりパフォーマンスを優先したい場合や
セキュリティが必要ない開発環境では
今まで通りコンテナが使われるだろう

FirecrakerはKVMベースで、それぞれのVMにカーネルが必要だが、
先の記事によればエミュレートする周辺機器を4つに限定してオーバーヘッドを削減している

ブロックデバイス
ネットワークインターフェイス
シリアルコンソール
VMを停止するためのボタンとして使うキーボードコントローラー

またVMの話か。何度言っても理解できないようだな

Dockerが解決するのはアプリのデプロイであ
そのためにコンテナという技術を使い、
アプリケーション実行環境を仮想化することで
実現してるんだよ。

VMとDockerコンテナはそれぞれ役目が違うから
組み合わせて使うのがよくあるユースケースだ
Dockerコンテナ（＝アプリケーションコンテナ）の有用性が
明らかになったから、コンテナ専用のマイクロVMが作られたわけだが
このマイクロVMで通常のOSを動かすのは難しいだろうな

Firecrackerで果たしてSolarisが動くかどうか
Linuxしか動かないVMになるだろう

やっぱり想像通りだった。現状ではLinuxしか対応してない。
Linuxは組み込みとかにも対応してるから、最小限そういった
限られたハードウェアでも動く実績があるんだよ

でもSolarisのようなサーバー向けOSは、一定レベルのハードウェアを
前提にしてるから、いろんなところが依存してるんだろうな

https://firecracker-microvm.github.io/

What operating systems are supported by Firecracker?
Firecracker supports Linux host and guest operating systems with kernel versions 4.14 and above.
The long-term support plan is still under discussion. A leading option is
to support Firecracker for the last two Linux stable branch releases.

Solarisとか言うオワコンwwwwww
あんたいつの時代から来たの？

>>705
オマエは論理的なのではなく単に長い物に巻かれるのを良しとしているダケだろうがｗ

>>712
悲しいかな、長いものが何一つ登場していないが、意味わかって使ってるか？

>>713
自分が何をやってるのか(やらされてるのか)すら分かってないんだなｗ
アワレなやっちゃな

>>711
だってUnix系ってSolaris以外オワコンじゃんｗ

痛ニウム(とhp-ux)は無事死亡
ヨゴレIBMのキモイAIXは確実に客に避けられるのでエサ撒いたうえでRHを買収
バカを見たのは血道上げてRHのバグ潰しやってた不治痛とボラクルかｗ
あと散々販促活動してた五橋研究所ｗｗｗ

Solarisは既にOracleに殺された
もう先はない

hp-uxはCiRCUSであんなに大成功したのに
それをシステムとして売り込んでも
ワールドワイドでの採用実績がほとんどゼロだったというのは逆に凄いと言えば凄い
日本的なITモノって白豚どもの拒否反応を引き出す何かがあるというか
ぶっちゃけどっかコワレてるんだろうな
やってる連中が島国根性だからなのか知らんがｗ
この辺のネット系サービスはチョンコや支那畜も成功例聞かないので
アジア系全体の問題かもだが

ボラクルに頃されたというよりはいわゆるリーマンショックに頃された＞Sun
中の人が言うには突然カネ入ってこなくなったらしいからな
ボラクルは一式揃って案外安かったので拾ったダケと言ってるな
まぁそれでも買ったのだからどうしようが連中の自由ってこった

>>717
知ってる。採用候補になり得る最後のUNIXだった
あとはベンダーロックインされてしまって
抜け出せない所がUNIXを使ってる

わざわざクラウド移行時にUNIXを採用することもないし
そもそも大半のクラウドはIntel互換CPUなので
Solaris以外のUnixが動かないというのもある

結果、マイクロVMもLinuxに対応すれば十分という考えに行き着く

>あとはベンダーロックインされてしまって
>抜け出せない所がUNIXを使ってる

それはLinuxを採用しても同じコト
RHと糞淫にベンダーロックインされてるダケ
それこそまさにawsにベンダーロックインされたがってるトコロすらあるｗ

自分ダケはベンダーロックインから逃れられていると思ってる痛いコは居るかな？ｗ

ttp://www.eweek.com/security/linux-kernel-developer-criticizes-intel-for-meltdown-spectre-response

"Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other."

ググるもPOWER採用でキモイやつら(666)のお仲間だってのはトックにバレちゃってるから
そっこらじゅうユダ公の息のかかったキモイ汚いモノだらけｗ

Firecrackerってオンプレミスでも無い限り
自分で使う事は無いよな
FargateかLambdaを通して使うスタイル

>>724
使う流れとしては

デプロイをもっと簡単にしたい
1. Dockerコンテナ化する

それを動かすディストリは、コンテナさえ動けばいいよね
2. コンテナ専用の軽量ディストリ採用

VMもコンテナ動けば十分だよね
3. FirecrackerなどのマイクロVM採用

という流れだよ。

Dockerコンテナ化は目的があって行うことだが、
それ以外は、必要ないから減らすという考え

ドッカー野郎がPC使って調子こいてられるのもSunがvboxに投資してたからだろ
docker toolboxなんてまさにまんまそれだ
MySQLもそうだ
イケてないライセンスのvmware(player含む)だと何もできない
翻ってRHはどうだ？win上で動く実用的なx86仮想化の技術なんて何も持たねえだろ
これだけ見てもSunがドンだけ先見て投資してたのかってハナシだよ
自社開発したチップの外販すらできんグズで消費するしか能のないググるとは比較にならない

なんでvbox？ LinuxでDocker使うのに仮想マシンはいらないし、
WindowsとmacOSでは仮想マシン使ってるけど
もうvboxは使ってないくて、両方共OS標準の仮想マシン使ってるし
特にWindowsではvboxはDockerと同居できなくなったんで
もう数年使ってないよ。

口だけのエアプだから知らないんだろう

Fargateは自動的にVMを確保してくれて
便利だが比較的高い
従来からあるEC2の方が安いが、コンテナを動かすVMは自分で管理する必要がある
ジレンマ

>WindowsではvboxはDockerと同居できなくなったんで
フツーに同居してるけどな
問題なくdocker machineも動いてるし
何かの間違いなのかな

Solaris同梱のkshのバージョンがが古いとのたまい乍ら
サポ切れバージョンの犬糞をドッカープル（）することにはダンマリ
こういう手合いをダブスタ野郎と言うｗ

Hyper-Vを利用しているとVT-xは利用出来ない
同時に利用はできず、片方だけ使える
そしてVT-xはVirtualBoxに必要

>>731
意味不明
ちゃんと更新すれば良いだけだろ？

もう相手にするなよマジで

Docker for WindowsはHyper-Vを利用し
Docker ToolboxはVirtualBoxを利用する

さらに、最近ではWindows Subsystem for LinuxでVMなしで動かせるようになったようだ
WSLのcgroupsやiptablesなどのサポートが改善された事による成果だ

https://github.com/Microsoft/WSL/issues/2291#issuecomment-438388987

「pullして使う」っていうのも発想が
アプリ開発者じゃないって感じるよな

dockerはビルドして使うものだからね
そもそもアプリ開発者が、自分で開発したアプリをデプロイするために
アプリと実行環境をイメージとしてまとめるっていうのが主な使い方なんだから

ベースとなるディストリは、更新すりゃいいだけ
それがすぐに簡単にできるようにDockerfileがあって
新しいディストリへの更新は数分程度で終わってしまう

それがVMやコンテナ単体では出来ないことで、Dockerが解決している問題

アプリ開発者のためだけのものではないぞ。念の為に言っておくが。

>>734
WSL凄いよな。パフォーマンスの点でDocker for Windowsを（WSLから）使うけど
その問題が解決するならば、仮想マシンで動かさなくて良くなるからもっと便利になる

具体的には仮想マシンにメモリを割り当てなくて良くなるから、アプリが使用する
必要最小限のメモリだけで良くなる

macOSもそうなってほしいね。macOSはUNIXだけどLinuxではないので
仮想マシンを使わないとDockerが使えない

>>734
>Windows Subsystem for Linux
動作が遅いんだよなソレ

>>738
エアプ乙wwwwwwwww

WSLはCPU速度はVMと同等かそれ以上に速いが
I/OはNTFSを使う都合上遅い
後一年も経てば解決するかも

>>740
なんで一年なの？もしよかったら。

>>741
一応問題視はしてるらしいので
https://news.mynavi.jp/article/20180815-676572/

いつまで掛かるかは分からん
1年？2年？3年？

cygwinの時も同じ問題があって、それは解決できなかったんだけど、
MSの場合はカーネルやファイルシステムに手を入れることも視野に入れられるからな

これまでWindowsのアップデートのたびにWSLの互換性は上がっていってるので
MSの本気度はかなり高いことがわかってる。例えばこれとか

マイクロソフト、Windows 10にUNIX系OSと似た擬似コンソール実装
https://news.mynavi.jp/article/20180817-679662/

パフォーマンスを上げるためにカーネルに手を入れる可能性も十分あると思うわ

> I/OはNTFSを使う都合上遅い
NTFSが遅いんじゃなくて、NTFSでLinuxのファイルシステムに求められる機能
（パーミッションなど）をエミュレートするから遅いんだけどな

NTFSのファイルシステム自体は高速
Windowsから触ってる時、何も遅く無いだろ？

ちょっとドッカ行ってくる！

>>737
>>737
Windowsという再起動OSなんて使いたくない。
勝手に通信するし、あんなものをLinuxの代わりなどならない。

どうせ、終コンになる。
Edgeなんて使わなくて良かった。

生のLinux使えばいい。

最近のM$のLinuxへの擦り寄り方が気持ち悪い・・

EdgeもChromiumベースになるらしい
もともとユーザー数少ないし、下手に独自のエンジン作られても非互換の部分が増えるだけだし
良いんじゃね？
もっとOSSに擦り寄れよ

>>742
ニュースなってたんだ。ありがと。あとはデーモン管理できるようになれば実用段階だね。

>>747
Windowsはクラウドでの運用に適さないからね
Azure使ってみたらよく分かるけど、MSのAzureチームもWindows使うの苦痛なんだろう

>>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
反論を煽るようなレスをわざわざするなよ