Docker Part2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>541 Dockerはシステムコンテナじゃなくて アプリケーションコンテナなんだから、 普通のアプリを起動したのと同じ挙動をするのが一番正しい姿なんだよ やっとコンテナできた。疲れた。12時間ぶっとおし、徹夜した。 同じ挙動ってなんだ? iptablesいじられるのは無しってこと? >>537 ネットワーク繋がなきゃつながらないのが当たり前だろw >>542 「同じ挙動」がどういう挙動か言ってみろよ。 ポート競合するのが正しいと思ってんのか? >>545 > ネットワーク繋がなきゃつながらないのが当たり前だろw デフォルトだと、どのポートでも受け付けてないはずだが? > 「同じ挙動」がどういう挙動か言ってみろよ。 ポート競合するのが正しいと思ってんのか? 同一マシンでポート80で起動するサービスが複数あったら競合するのが正しいですが? 最近俺が見たのはこんな奴だった 公式ドキュメント読まない ヘルプ読まない ぐぐらない ぐぐれない とりあえずやってみない 手順に書いてあることをなぞるだけ コンテナとVMの区別がつかない Docker無しでLA(E)MP環境が建てらんない iptablesを手動でいじれない どうやってDockerを知って、動かすことができたんだ? >手順に書いてあることをなぞるだけ 多分ハケンか何かの業務でとか… [速報]AWS、独自のセキュアなコンテナ実行用マイクロVM「Firecracker」、オープンソースで公開。AWS re:Invent 2018 https://www.publickey1.jp/blog/18/awsvmfirecrackeraws_reinvent_2018.html >>551 コンテナがrootkitなウイルスにやられても 他のコンテナに侵入できない なのに仮想マシンより軽量 普通のコンテナはroot取れば脱出出来る可能性はある 仮想マシンの脱出はそれよりは困難 これぐらいなら馬鹿は出てこないと思って放置していたが ほんとなんにでもくだらないレスするやつ来るな まじでやってるなら本当の馬鹿だな >>550 とりまビルドしてみたらサクっと通った 今時のツールはdockerでビルドなんだな…時代が進んで色々凄いコトになってる つか使い方がよく分からんがw >>554 Dockerねぇぞって弾かれるよなワロタ 大容量のダウソ始まったからビルドやめたわ >>552 それはいいですね。 ハニーポットも運用できる? >>555 つか何をするにもひたすらDLやでw quickstart guide見ながらやってるけどうまく動かんわ >set the guest kernel: ココでハマってる 誰か上手く動かせたヤシ居る? hello-rootfs.ext4 hello-vmlinux.binはDLしたし AppendixにあるKVM Accessのチェックも全部パスした エラーメッセージは↓ HTTP/1.1 400 Bad Request Content-Type: application/json Transfer-Encoding: chunked Date: Fri, 30 Nov 2018 07:20:20 GMT { "fault_message": "The kernel file cannot be opened due to invalid kernel path or invalid permissions." releaseからバイナリ落としてもダメなんで今回は諦めるワ コッチはローカルビルドと違ったメッセージ出てたんでイケそうだったんだが 腐ってやがる早すぎたんだ HTTP/1.1 204 No Content Date: Fri, 30 Nov 2018 07:45:56 GMT つか尼損犬糞でしか動きま千円って書いとけやヴォケ害人どもガイジか? >Linux 4.14+ >KVM 動作環境とは何の関係もありませんが何か?w >>561 今KVM上でDockerホスト運用しているけど。 両方CentOS7でね。 DockerはKVMなどの仮想マシンと組み合わせて 使うのが想定される使い方なんだから最初から動いて当然 KVMなどの仮想マシンで、コンテナ専用の軽いディストリを起動して その上で、Dockerコンテナを起動するんだよ。 Dockerコンテナ(=アプリ)にカーネル以外の動作に必要なものが 全てまとまっており、ディストリ自体にパッケージが不要になることで 実現できる設計 >>563 なるほど。 そのうちDockerホスト専用のディス鳥がでるかもね そんなもんとっくの昔からあるよ で最近になってKVMの上でコンテナ動かすのがバズってきたのは、AWSがコンテナ専用の "KVMホスト" OSをリリースしたことに端を発している これは小数の大きな仮想マシンでクラスタを組んでその上で沢山のコンテナを動かすという従来のやり方とは考え方が大きく違っていて、 コンテナの数だけKVM上で軽量なVMを立ち上げてその中でコンテナを隔離して動かすの でコンテナは本当に単なるパッケージ化技術と成り下がる コンテナによる分離はセキュリティ面でガバガバであり使い物にならない玩具である、というのがITビジネス界の結論というわけ > というのがITビジネス界の結論というわけ という結論を語ってる所はITビジネス界には無いんで 安心して、生暖かく見てやってくださいw コンテナごとにセキュリティソフト入れてますます重くなる未来 そういや仮想マシンごとにセキュリティソフト買ってるらしいな パッケージソフトをウッキウキでクラウドで動かそうとしたら、 ライセンスがコピー単位でオンプレと何ら変わらない運用をするしかないというのはよくある話 だからソフトウェア自体を売るんじゃなくて クラウドサービスとして売る方向になってるのでは? >>565 >パッケージ化技術と成り下がる いいたい事はわかるが、成り下がってはないと思う。 >>570 自分で構築、保守してこそのコンテナの有難味だと思う だからDockerはアプリ開発者が 自分のアプリを配布するのに使うものなんだよ アプリ開発してないやつにとっては豚に真珠 >>574 えー俺にも技術分けて下さいよ dockerでドヤ顔したい 仮想化環境であるが、仮想マシンではない。 仮想化環境であるが、アプリではない。 dockerはコンテナ型の仮想化環境を作成するソフトです。 それ以上でもそれ以下でもないだろ。 >>576 アプリの組み合わせ(=環境)をコンテナにまとめるのもありですよね その場合、127.0.0.1で内部でアプリを連携させるのも良いですよね。 >>577 そうそう、VMみたいにして使うときは目的に合わせてカスタムすればいい。 目的を定めて既存のサービスに組み合わせてdockerファイルを書く。 例えば開発環境にするなら同期をとファイル群をローカルネットワークのgitにするとかね。 dockerはクラウドと連携すると割と柔軟に何でもできる。 環境依存のファイルをクラウドに置いておく発想で。 dockerは本来はアイソレーションやシステムリソース有効活用も担ってたはずでしょ 例のFirecracker的な思想だとそこはコンテナから切り離そうってことだよね ここまでくると仮想化環境というより単なるポータブルなVMのディスクイメージと考えたほうが素直だと思うわ >>579 いや、環境だよ。どのPCでも同じ環境を再現できるってこと。javaの発想に近い。 静的なファイルだけ突っ込むってとこはいい理解だけど、それが環境なんだよ。 dockerfileって環境構築用のバッチファイルみたいなものだと理解しても良い? コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。 仕上がりのイメージファイルの容量が少なくなったりする? >>581 chrootに依存してるって意味なら同じだろうけど、ディストリのパッケージに依存してるからそれが違うかな。 コマンド手打ちでも構築できるけど、不便だろ。 マイクロVMが主流になるならもうコンテナいらなくね? カーネルだけホストのものを使うことって無駄な環境依存を増やしてるだけで、従来のコンテナ技術との互換性以外にはもはやメリットがないような 環境依存部分を吸収するのはそれこそ本質的にはハイパーバイザー型仮想化の方が遥かに得意なわけだし そういうの解決するために各企業が新しいコンテナ技術生み出してる gvisorみたいにコンテナとVMの中間みたいな物とかね KataContainersもgvisorと似たような思想だな やり方はだいぶ違うみたいだが コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな VMが重いのが問題なら軽くすればよい、それができないのは技術が未熟だっただけ 浸透し切る前に正しい方向に戻ってくれそうでよかった >>582 dockerfile作る時も手打では? しかもレスポンスが直ちに得られないので、 試行錯誤に時間がかかりそうに思う。 いまば、プログラム買いてその場で実行できるBASICインタプリタと、 cコンパイラを通す必要のあるC言語みたいな違いがあると思うんだけど。 一度完璧に書いてしまえば、後者の方がいいに決まっているけどね。 >>583 各VMごとにOSレベルのメモリ割り当てがいるから、 大量のメモリを消費するのでは? コンテナを動かすためのサーバーを管理したくないけど AWS Fargateはまだまだ高い Lambdaで無理やりやるとか つか安ければイイならSpotFleet以外の選択肢が(ry Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある >>588 firecrackerの場合1VMあたり5MBらしい。 >>587 あー、そういう見方あるか。chroot手打ちしなくていいってことだよ。 言いたいことはjvmとlinuxカーネルが実行環境に含まれてるってことよ。 linux環境じゃなくてもdockerは公式環境があるから。 >>591 やっとdocker-composeわかりかけて きたとこなのに(>_<) >>595 いやいや、docker理解できないと使えないから安心して そもそも、個人開発でkuburnetes必要なくない? なんで個人開発限定? そもそも個人開発でdockerなんか何に使うの? コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ PaaSへのデプロイに使うくらいか? >>591 > Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある KubernetsってDockerを使うんだけど、なんで役割終えたの? >583 > マイクロVMが主流になるならもうコンテナいらなくね? またいつもの仮想マシンとアプリケーションコンテナをごっちゃにしてるやつだなw マイクロVMが主流になったとして、じゃあどうやってこそにアプリをデプロイするんだ? マイクロVMにRailsの実行環境入れ込むんか? ローカルの開発マシンで動いているものを、そのままマイクロVMで動かすにはどうするんだ? そういった問題が解決できてないだろ コンテナは仮想マシンと組みあわせて使うということが全くわかってない コンテナがあるからこそ、VMはマイクロで十分になったというのに コンテナのおかげやで?マイクロVMが登場したのは >>581 > コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。 依存パッケージの更新とか手動でやりたくなくないだろ お前は旧式のやり方しかしてないかもしれんがな、 こちとらDockerfileで1日に何度もイメージをビルドしてるんや アプリが更新するたびにイメージ作り直してるし カーネルや依存パッケージにセキュリティ対応が入ったら、 それを取り入れてまたアプリのイメージを作り直すんだよ >>586 > コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな マイクロVMがなにをそぎ落としてるのか知らんの? 様々なコマンドが入ってないんだが。 各言語の実行環境はもちろんのことpsコマンドすら入ってないだろうな マイクロVMではサーバーは起動していない。NFSサーバーになる機能すらないだろう パッケージマネージャーもないだろう。必要ないからね マイクロVMはDockerコンテナを動かすのに必要な 最小限の機能まで縮小しているし、Dockerコンテナを動かすこと以外を やることを想定してないから、単体では何も使えない それわかってるのか? >>599 君こそコンテナ仮想化とパッケージとしてのコンテナを混同してない? >>583 は前者のことを言っていて、従来のLinuxカーネルを共有したハック(現在一般的にコンテナ仮想化と呼ばれるもの)がもはや役割を終えつつあるのは事実だ 一方でパッケージとしてのコンテナはもちろん必要だけど、それ自体はもはや仮想化技術でも何でもなく、文字通り単なるアーカイブだ >>602 > それ自体はもはや仮想化技術でも何でもなく 「仮想化技術ではない」というのは具体的に 何ができないっていってんの? それをお前が言えば、お前が間違ってることがはっきりするよ 「仮想化」という言葉の正しい意味をわかってないやつは、 仮想メモリと聞くと、ソフトウェアでメモリを作ることだって勘違いするからな >>602 はそのパターン パッケージとしてのコンテナとか意味不明だし 仮想化しなければ、可搬性は実現できないだろうが 仮想化せずにどうやって、他のマシンで動かすことができるというのか っていっても理解できないんだろうなw >>583 > マイクロVMが主流になるならもうコンテナいらなくね? apt-getもyumもついてこないよ systemdも入ってないよ libなんたらパッケージも入ってないよ 例えばnginxを動かそうと思っても、パッケージないし パッケージの依存関係を解決してくれたりしないよ コンテナ使わないでどうやってサービス動かす気? 苦労する気? だからパッケージングとしてのコンテナを否定してるわけじゃないんだけど、そんなに難しいこと言ってるかなあ 少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、 依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ 従来のコンテナ仮想化の仕組みを大きく見直す時期に来てるんだよ >>599 マイクロVMって普通の仮想マシンとどう違うの? >>593 OSは入れなくていいのか? >>607 > 少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ 呼べるんだけど? 仮想化したコンテナを動かしてるんだから コンテナ仮想化に決まってる 仮想化しなかったら、その仮想マシンでしか動かないものになるんだけど? やっぱり仮想化の意味を知らないようだね >>608 > http://www.atmarkit.co.jp/ait/articles/1811/27/news146.html ここに簡潔に書いてある > Firecrackerは最低限の機能だけを搭載したマイクロVM > FirecrackerはKVM上で動作。その上で動くコンテナなどのために、 > ネットワーク/ストレージを中心としたシンプルなI/Oインタフェースを提供する。 > OSは入れなくていいのか? 通常のディストリではカーネルとユーザーランドを含めてOSとなるのだが マイクロVMはカーネル(とメンテナンス用のわずかなツール)のみの提供と考えていい。 コンテナを動かすことしかしないのだから、 マイクロVMに(コンテナ以外)のものを入れる必要がない 逆に言えば、コンテナ以外を動かすのは不可能に近い。 >>607 > そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、 > 依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ 意味不明。マイクロVMはKVM(仮想マシンエミュレータ)で動く コンテナ専用のディストリの一種に過ぎない マイクロVMのカーネル=ホストのカーネル マイクロVM上のコンテナ=マイクロVMのカーネルを使う どちらも同じカーネルを使うことにななってるんだが? ホストのカーネルってなんだよ? マイクロVMは可搬性が高いわけじゃない これは単なるディストリの過ぎないんだから マイクロVMを他のPCで動かそうと思ったら 仮想マシンエミュレータが必要になる Dockerコンテナは仮想化されてるから、 マイクロVMでも通常のLinuxでも動かすことができる。 コンテナ(=アプリ)が仮想化されてるから、 例えばローカルのLinuxマシンで複数のコンテナを起動することだってできる そしてそのコンテナをそのまま変更せずに、マイクロVMで動かすこともできる。 "コンテナをそのまま変更せずに" ってところが重要。 マイクロVMで動かす時は、ポート番号を変更したり、 CPUの割り当て数を変更したりできる "コンテナをそのまま変更せずに" これができるのは、"仮想化されている"から >>607 は仮想化をプロセス分離の技術の名前だとでも思っているかのようだw "メモリの"仮想化は、ハードウェアのメモリをエミュレータで エミュレートするものでもないし、プロセス分離の技術でもない メモリの仮想化は物理的なメモリ配置を隠して、どういうハードウェアでも同じように見せることを言う もちろん"PCの"仮想化はハードウェアをソフトウェアでエミュレートすること 同じ仮想化でも、"何の"仮想化であるかで意味が違う。 マイクロVMというのはディストリの名前なので何も仮想化してない 仮想化しているのはエミュレータ(KVM)の方 もちろんこの場合の仮想化とは"PCの"仮想化 そして(Dockerの)コンテナが提供するのは、アプリケーション実行環境の仮想化 UbuntuでもマイクロVMでもCentOSでも同じLinuxであれば どこでも同じように動かせるようにするアプリケーション実行環境の仮想化は コンテナが提供している。このアプリケーションの仮想化がなければ ディストリごとに専用に、セットアップ手順を書かないといけない、 aptを使ったりyumを使ったり。コンテナでアプリケーション実行環境の仮想化を手に入れたことで Dockerを使うだけで簡単にコンテナを動かせるようになった。 そうすることで、ディストリ専用(例マイクロVM専用)のセットアップ手順を 作らなくて良くなったからこそ、マイクロVMという軽量のディストリができたんだよ >>598 KubernetsでDockerは使えるけど必須ではなくなったからな 将来的には使われなくなるでしょ VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。 >>615 マイクロVMが一般的になれば次第にカーネルはコンテナ側に寄っていく形になるよ VMベースの仮想化に移行すれば、特殊なバージョンのカーネルやLinux以外のコンテナを動かそうという試みはビジネスの要請によって確実に出てくる ちょうど言語処理系が辿った道と同じで、最初は完全にホスト側によって使用するランタイムが決められていたのが アプリ側の設定ファイルに基いてランタイムを選択するようになり、最終的にはアプリケーションに吸収される そんな銀の弾丸があるなら もっとAWS Fargateを安くしろや! めんどくさいから結論が出て使いやすいソリューションが出てきたらでいいや まーたいつものガイジ2匹がレスバ繰り返してたのかよ よく飽きねぇなぁ >>614 知ってる知ってる。rktとかいうやつな あれどうなったんだ?w 結局、Docker以外も使えると言う状況に満足して 終わりなんだよ。本気出してないからDocker以外普及しない >>615 > VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。 そういうこと、マイクロVMは何かの機能を搭載するのではなく コンテナに任せることで限りなく機能を削減する方向を目指してる。 だからマイクロVMがコンテナになることはありえない。 マイクロVMはコンテナを使うという前提 >>616 って結局コンテナを使いますって言ってるだけだよ。 マイクロVM関係ない。だってマイクロじゃないVMでもできることなんだから マイクロVMは単に今のVMを置き換えるもので軽いってだけでしかない。 それ以外は今と全く変わないわけだから、コンテナ使いますよねって話 「Kubernetes」に深刻な脆弱性 https://japan.zdnet.com/article/35129584/ > この脆弱性は深刻なものであり、共通脆弱性評価システム(CVSS)による深刻度は9.8(最大値は10.0)となっている。 dockerの特色はリソースを節約しつつ環境を切り分けて管理しやすくするってことだから docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。 リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。 >>624 それな。WinnyとかP2P世代のバカは仮想マシンを 「ウイルスに感染しても安全」な技術だと思ってる。(もちろん間違い) ここで仮想化をセキュリティのためのものと思ってる奴がそうだろう 仮想マシン(VM)と仮想化は別のもの 仮想マシンは"ハードウェアを"仮想化したもの コンテナはハードウェアを仮想化してないので、明らかに違うものを仮想化してるんだが 仮想マシンで仮想化してるから、コンテナで仮想化する意味がないという理屈のようだ >>626 お前も、Docker世代のバカと呼ばれるんだろうな >>626 さすがに頭悪すぎ どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない これがAWSが仮想化技術に対して要求する最低限のセキュリティだよ クラウドベンダー各社がDockerをサポートし始めてもなかなかFargateのようなサーバーレスサービスが出なかった理由もそこにある つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある >どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない こういうのまるっとガン無視して犬糞の鳥間バージョン間各種パッチ適用ごとの糞そのものの互換性のなさを 思考停止してとりまお気楽極楽に乗り越えて便利に使いましょいっていうのがドッカー()だと思ってたんだがw >FaaSやCaaSの先駆者であるAWSがマイクロVMを必要 どこまでいっても業者のツゴーってコトだよなwww >>631 企業内の専有クラスタでもコンテナが乗っ取られたときの影響範囲とか部門間のアクセス制御とかあるからね ウェーイwww系Webからビジネスへと足を踏み入れた途端に、Docker世代のバカには想像もできない複雑で広大な世界が広がっている 頭の悪さは > つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ この一文に集約されてる。 Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を 実現するためのものではない。それがわかってないと自白したようなもんだ それからもう一つ言うと、コンテナ間の分離機能というのは カーネルが搭載しているコンテナの機能を使ってるだけなので Dockerの問題じゃないんだわ。カーネルの問題 最初から俺が言ってるように「Dockerは仮想マシンと組み合わせて使うもの」 なんだから、そういう分離は仮想マシンでやるからいいんだよ。 DockerはDockerの本質であるアプリケーション実行環境の仮想化に 特化すれば良い。こればかりは仮想マシンでは実現できないんだから。 結局いつもの、Dockerを理解してない or 仮想マシンの代わりだと思ってる 理解の浅いやつが叫んでるだけでしたね。 >>632 solarisはdockerやるって言ってたけど今のところ見送りだからな 流石に長くOSやってるトコロはセキュリティに関する意識が全然違う >>633 >Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を >実現するためのものではない。 ありとあらゆるトコロに地雷のように埋まってる腐れOSSの非互換性を解決するための 単なるお遊びレベルのコンテナシェア取り合戦なんだよなw 分かる分かるww >>634 >カーネルが搭載しているコンテナの機能を使ってるだけなので >Dockerの問題じゃないんだわ。カーネルの問題 いやいやいや下のレイヤに何を選ぶかはドッカ〜の実装の問題だろw カーネルの責任に転嫁するのはさすがに無責任極まりないwww まぁOSS界隈のやり取りらしくて大変結構なんだがwww >>637 だから下のレイヤー(コンテナ機能)に問題があるってことですよねw Linuxカーネル標準のコンテナ機能以外に コンテナってありましたっけ? それともDockerが選んだLinuxに問題があると言いたいのかな?w Solarisはもう未来ないから・・・ 米オラクルがSolaris関連の従業員をほぼ全員レイオフしたとの報道(追記あり) https://www.publickey1.jp/blog/17/solaris.html >>638 分離したいなら仮想マシン使えは現状そうするしかないんだが >FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある 何度も言うように業者のツゴーでそう言ってるバヤイじゃないってコトだろ 課金も絡むだろうからクラウド()に縛られてる情弱貧乏ユーザーどもにとっても死活問題だろうし >>638 >>639 >Dockerが選んだLinuxに問題があると言いたいのかな 問題アリアリだからドッカ〜が必要になったんだろwww つかソコをトボケてどうしたいのさ 犬糞ageっすか?w ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる