Docker Part2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
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 オマエは論理的なのではなく単に長い物に巻かれるのを良しとしているダケだろうがw >>712 悲しいかな、長いものが何一つ登場していないが、意味わかって使ってるか? >>713 自分が何をやってるのか(やらされてるのか)すら分かってないんだなw アワレなやっちゃな >>711 だってUnix系ってSolaris以外オワコンじゃんw 痛ニウム(とhp-ux)は無事死亡 ヨゴレIBMのキモイAIXは確実に客に避けられるのでエサ撒いたうえでRHを買収 バカを見たのは血道上げてRHのバグ潰しやってた不治痛とボラクルかw あと散々販促活動してた五橋研究所www Solarisは既にOracleに殺された もう先はない hp-uxはCiRCUSであんなに大成功したのに それをシステムとして売り込んでも ワールドワイドでの採用実績がほとんどゼロだったというのは逆に凄いと言えば凄い 日本的なITモノって白豚どもの拒否反応を引き出す何かがあるというか ぶっちゃけどっかコワレてるんだろうな やってる連中が島国根性だからなのか知らんがw この辺のネット系サービスはチョンコや支那畜も成功例聞かないので アジア系全体の問題かもだが ボラクルに頃されたというよりはいわゆるリーマンショックに頃された>Sun 中の人が言うには突然カネ入ってこなくなったらしいからな ボラクルは一式揃って案外安かったので拾ったダケと言ってるな まぁそれでも買ったのだからどうしようが連中の自由ってこった >>717 知ってる。採用候補になり得る最後のUNIXだった あとはベンダーロックインされてしまって 抜け出せない所がUNIXを使ってる わざわざクラウド移行時にUNIXを採用することもないし そもそも大半のクラウドはIntel互換CPUなので Solaris以外のUnixが動かないというのもある 結果、マイクロVMもLinuxに対応すれば十分という考えに行き着く >あとはベンダーロックインされてしまって >抜け出せない所がUNIXを使ってる それはLinuxを採用しても同じコト RHと糞淫にベンダーロックインされてるダケ それこそまさにawsにベンダーロックインされたがってるトコロすらあるw 自分ダケはベンダーロックインから逃れられていると思ってる痛いコは居るかな?w 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)のお仲間だってのはトックにバレちゃってるから そっこらじゅうユダ公の息のかかったキモイ汚いモノだらけw 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のバージョンがが古いとのたまい乍ら サポ切れバージョンの犬糞をドッカープル()することにはダンマリ こういう手合いをダブスタ野郎と言うw 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 動作が遅いんだよなソレ WSLはCPU速度はVMと同等かそれ以上に速いが I/OはNTFSを使う都合上遅い 後一年も経てば解決するかも 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 クラウドの客が犬糞使いたがってる影響だな まぁ色々やむを得ずなんだろ >>752 だから必然的にクラウドを使うんだよ AzureもAWSもGCPもWindowsインスタンスが用意されていて そこにライセンスも使用料も含まれてる もしかして知らなかった? オンプレで自前サーバーとかて立ててる 時代のやり方してる所は知らなそうだよね windowsを使おうと思わないから、インスタンスがあっても知らんよ。。 awsとか使ったことあるならwindows使わなくてもインスタンスあることくらい知ってるだろ インスタンス料金表とか見たらデカデカと載ってるからね 知らないのはさすがにありえないわ ふとAWSのダッシュボードみてみたら、Linuxなんかよりも先にあるねWindows そりゃクラウド使ってなきゃ、 「必ず使わないとその他のメニューに行けないダッシュボード」を 使わないことだってあるだろうなぁw えっ、お前マネージメントコンソールやリファレンスを一切見ることなくCLIを使いこなし、 適切なインスタンスタイプ名を一発で引き当てることができないの?w 何にいくらコストがかかるって CLIで見れたっけ? 引き当てるって書いてあるし、ガチャ方式でやるってことか 使ったことがないからネタに走ったってことね クラウドのインスタンスって、最初からOSが組み込まれているのか? どんな設定されているかわからないものを使うって不安でない? 最初からiptableが開かれているとかさ? 根本的なところがずれてるな 自分でOSを組み込んだら、どんな設定になるのかわかるのか? iptableの状態がどうなってるのか、安心できるのか? >>765 そもそもクラウドにiptableの設定なんか必要ない そういうのはインフラ側の設定で制御するんだよ オンプレ脳の人間はインフラを「容易には弄れないもの」と考えて何でもサーバー内で完結しようとする しかしクラウドにおいてはむしろそれは逆で、サーバーよりもインフラの設定の方が柔軟に変更でき、構成管理も極めて容易だ iptableのような脆弱な仕組みに頼ることなくデザインによってセキュリティ等の要件を担保できる これがクラウドの強みだ 説明下手だなw デザインによってセキュリティ等の要件を担保できるとか 意味不明な説明じゃなくて単純に言えばいいだけだろ クラウドではサーバーの外にあるファイアウォールで制御する そのファイアウォールは、設定画面やCLIコマンドやAPIから設定できる >>768 わかりやすい。 でも、手作業による設定と違って、 柔軟な設定はできなさそう。 Dockerならフォワードチェインから、 サブチェインに飛ばして、そこでフィルタやパケットの統計をとったり、 あるいは、ポート開放のために、-t nat にフォワードの設定が必要になるだろうけど、 クラウドはそういうのは使わないの? > でも、手作業による設定と違って、 > 柔軟な設定はできなさそう。 手作業ってなんだ? どうせコマンドうつだけだろ > Dockerならフォワードチェインから、 Dockerコンテナ = アプリ お前、アプリの中に、ファイアウォールの設定入れるのか? Dockerコンテナは仮想マシンじゃないって言ってるだろ >>770 > クラウドはそういうのは使わないの? だからそれらは全てサーバーの外にあるファイアウォールで設定できる 実際はiptableなんかに頼ることなく、ハード込みで売ってるファイヤウォール使ってるってことだろ。 >>769 お前はリスクマネジメントというものを分かってない AWSが俺を信じて任せろと言ってるんだからリスクは完全にAWSに転嫁されていて、それで十分なんだよ もしもAWSの不具合で事故るようなことがあれば、そのときはAWSに損害賠償請求すればよい >>775 への反論は そんな無責任が通用するわけがないだろう 自前で実装して、不具合で事故るようなことがあれば、損害賠償してやる!と 男らしく言うべきだ。 自前で実装する=事故る可能性が高い わけだけど、 損害賠償するのが男らしいんだ! という感じでお願いねw 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を使えば同じことできそうだが めんどい コンテナと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使ってるのか? >>790 0点 >>788 をよく読んで答えなさい >>792 がAWSを使ったことがないことはわかった セキュリティグループは作ってからEC2インスタンスやロードバランサー、データベースにくっつける IPアドレスの範囲に加え、 特定のセキュリティグループを持ったインスタンスの接続のみを許可する使い方も出来て便利 AWS使ったことないんだけど、ポートを塞ぐだけでセキュリティ云々言うのは間違ってるよ。 webなんかで言われるセキュリティホールは80とか443を使って侵入するから通信の中身やURLを解析して弾かなきゃいけない。 こんなのは自前で実装するのが普通。 オンプレの場合、一旦納品したサーバーは 脆弱性があろうともバージョンアップしないんだろう だから脆弱性があるサーバーを守るために ファイアウォールを使う。 馬鹿としか言いようがないw >>798 jsが仕込まれたURLじゃないかとか色々 >>794 反論を煽るようなレスをわざわざするなよ >>801 え?なに? クライアントからサーバーに jsが仕込まれたURLが送られてくんの? >>803 え?なに?ストリングクエリに細工されていたら サーバーに侵入される脆弱性があるの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる