Docker Part2©2ch.net

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

http://www.docker.io/

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

>>514
その表を見る限りCentOS7が動いてるのはKVMだけ見たいだしホストがRHEL6なOpenVZでもCentOS7は動くよ(kernelに実装されてない機能は使えないが

最新のstable採用してるとこんな感じでもちろんdockerは動かない
3.10ベースのtesting使ってサービス提供してるとこがあれば使えるはず
Ubuntu 16.04.5 LTS
Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

KVMやXenはデバイスまで分離されてるからいいが、コンテナ環境を他人に貸すってすげぇな

>>517
共有サーバーだって貸していただろｗ

>>514
国内で360は安い、ありがとー

>>519
安過ぎて、客が殺到して、
詰め詰めのサーバーのために性能が悪いとかないのかな？

>>520
あるかもだけど、サービスの初期開発、プログラムの練習には持ってこいじゃないですか？
もしかして、time4vpsより安い？これ

そういう用途ならvps使うよりクラウドのほうが安く抑えられると思うけど

少し分かった
https://blog.arena.ne.jp/vps/891

使う時だけ起動する感じなら、GoogleComputeEngineのプリエンプティブインスタンスが安く上がりそう

Docker上で仮想マシンを動かせるって本当？

そりゃまあ仮想マシンなんてアプリに過ぎないので動くやろうな

>>526
動くやろうなじゃなくて、
これから主流になるらしいよ

Dockerの上で仮想マシンとか
これもうわけわかんねえな

>>527
ならんよ。嘘ついてもバレる（嘲笑）

仮想マシンをアプリケーション化する意味がない

仮想マシンによって、仮想マシンの中のアプリと外のアプリの
連携が分断されるから、やる価値がない

Dockerって、勝手にiptablesの設定を変更するのが気に入らない。
安易に使うとセキュリティーホールだらけになると思う。

Xen+libvirtやLXCもiptablesの設定を勝手に変更するよ(deb系しか試してないけど)
でも合ってる設定だし、ポリシーがACCEPTのままなので自分でも設定しなればならないのに変わりがないから異論は無いけど

>>531
レスありがとう。

どうせなら、docker runコマンドのポート解放のところで、
パス可能なソースIPでも指定できるようにすればいいのにと思う。

>>532
それはファイアウォールの仕事
Dockerの仕事ではない

>>533
だけど、ポートの解放はdocker runで行うよね

だけどやっぱりフィルタリングはDockerの仕事じゃないよね。

>>535
せめて、デフォルトで外部から接続させないようにファイアホールを構成していればいいのにと思う。
ユーザーが必要に応じてフィルタリングルールを調整してはじめて、
外部からアクセスできるようにすればいいのにと思う。
フィルタリングが分かっている人が明示的にパスするようにするのがいい。

docker runでポート解放したら無条件でどこからでも通すなんて変だと思う。

>>536
Dockerは仮想マシンじゃないと何度言ったらわかるんだ？

Linuxでウェブサーバー起動したら、外部から接続できるのは
当たり前の話だろ

>>530
＞Dockerって、勝手にiptablesの設定を変更するのが気に入らない。

オプション付けろよ

>>538
ん？どんなオプションだったっけ。
iptablesのNAT設定を変更しないやつってあるの？

>>539
サーバー系の設定したこと無いんか？

MySQLのbind-addressはなんのためにあるのか知らないのか？
127.0.0.1 と 0.0.0.0 の違いを言えるか？

>>540
コンテナをホストのプライベートIPに結合するやつかな？

>>541
Dockerはシステムコンテナじゃなくて
アプリケーションコンテナなんだから、

普通のアプリを起動したのと同じ挙動をするのが一番正しい姿なんだよ

やっとコンテナできた。疲れた。12時間ぶっとおし、徹夜した。

同じ挙動ってなんだ？
iptablesいじられるのは無しってこと?

>>537
ネットワーク繋がなきゃつながらないのが当たり前だろｗ

>>542
「同じ挙動」がどういう挙動か言ってみろよ。　ポート競合するのが正しいと思ってんのか？

>>545
> ネットワーク繋がなきゃつながらないのが当たり前だろｗ
デフォルトだと、どのポートでも受け付けてないはずだが？

> 「同じ挙動」がどういう挙動か言ってみろよ。　ポート競合するのが正しいと思ってんのか？
同一マシンでポート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

>>550
なにがすごいのか？

>>551
コンテナがrootkitなウイルスにやられても
他のコンテナに侵入できない
なのに仮想マシンより軽量

普通のコンテナはroot取れば脱出出来る可能性はある
仮想マシンの脱出はそれよりは困難

これぐらいなら馬鹿は出てこないと思って放置していたが
ほんとなんにでもくだらないレスするやつ来るな
まじでやってるなら本当の馬鹿だな

>>550
とりまビルドしてみたらサクっと通った
今時のツールはdockerでビルドなんだな…時代が進んで色々凄いコトになってる
つか使い方がよく分からんがｗ

>>554
Dockerねぇぞって弾かれるよなワロタ
大容量のダウソ始まったからビルドやめたわ

>>552
それはいいですね。
ハニーポットも運用できる？

>>555
つか何をするにもひたすらDLやでｗ

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."

kernelは4.19

releaseからバイナリ落としてもダメなんで今回は諦めるワ
コッチはローカルビルドと違ったメッセージ出てたんでイケそうだったんだが
腐ってやがる早すぎたんだ

HTTP/1.1 204 No Content
Date: Fri, 30 Nov 2018 07:45:56 GMT

つか尼損犬糞でしか動きま千円って書いとけやヴォケ害人どもガイジか？
>Linux 4.14+
>KVM

動作環境とは何の関係もありませんが何か？ｗ

いまKVMでDocker動くようになったん？

>>561
今KVM上でDockerホスト運用しているけど。
両方CentOS7でね。

DockerはKVMなどの仮想マシンと組み合わせて
使うのが想定される使い方なんだから最初から動いて当然

KVMなどの仮想マシンで、コンテナ専用の軽いディストリを起動して
その上で、Dockerコンテナを起動するんだよ。

Dockerコンテナ（＝アプリ）にカーネル以外の動作に必要なものが
全てまとまっており、ディストリ自体にパッケージが不要になることで
実現できる設計

>>563
なるほど。
そのうちDockerホスト専用のディス鳥がでるかもね

そんなもんとっくの昔からあるよ
で最近になってKVMの上でコンテナ動かすのがバズってきたのは、AWSがコンテナ専用の "KVMホスト" OSをリリースしたことに端を発している
これは小数の大きな仮想マシンでクラスタを組んでその上で沢山のコンテナを動かすという従来のやり方とは考え方が大きく違っていて、
コンテナの数だけKVM上で軽量なVMを立ち上げてその中でコンテナを隔離して動かすの
でコンテナは本当に単なるパッケージ化技術と成り下がる
コンテナによる分離はセキュリティ面でガバガバであり使い物にならない玩具である、というのがITビジネス界の結論というわけ

> というのがITビジネス界の結論というわけ

という結論を語ってる所はITビジネス界には無いんで
安心して、生暖かく見てやってくださいｗ

コンテナごとにセキュリティソフト入れてますます重くなる未来

そういや仮想マシンごとにセキュリティソフト買ってるらしいな

パッケージソフトをウッキウキでクラウドで動かそうとしたら、
ライセンスがコピー単位でオンプレと何ら変わらない運用をするしかないというのはよくある話

だからソフトウェア自体を売るんじゃなくて
クラウドサービスとして売る方向になってるのでは？

そしてそれにはコンテナが適してるわけだよね

>>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以外の選択肢が（ｒｙ

Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

CRIだよね？>ORI

>>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は使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ