Docker Part2©2ch.net

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

http://www.docker.io/

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

>>474
＞Dockerでサービスが起動するコンテナを作ってあとはDockerに
＞OS起動時に、そのコンテナを起動してもらえばいいだけ

ソースのreadmeは、Dockerコンテナを想定していないです。
すると、dockerコンテナ内で、systemctl enable serviceをセットして、
コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。

とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、
仮想マシンみたいにコンテナを動かすしか手が見つからないんです。

>>480
＞そうすれば、RUN yum install パッケージが
＞終わった段階のキャッシュの続きから実行されるから、
＞手探りでやってるのと大差ない作業になる

続きから継続されるという仕組みがいまひとつピンとこないんですが、
知らなかったです。書籍も読んでいるんですが、あまり実践的ではないものが多いように思います。

最後にyumとかでまとめて御仕舞いというのは、
ワンライナーでかけるところはまとめて、dockerfileを作れということですね。

>>478
> Dockerfileでも、yumコマンドが扱われていることから、
> ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
> 何が本質的に違うのかなと素朴に疑問です。

Dockerは動作確認するためのツールじゃねーし。何かを作るためのもの。
その何かっていうのはDockerイメージでありそこから起動するDockerコンテナ

そのDockerイメージやDockerコンテナを作るために、最終的にDockerfileを書くんだよ。

Dockerイメージ = 実行ファイル
Dockerコンテナ = 実行ファイルを起動したもの
と考える

アプリの実行ファイルの中にデータファイルを作成しないのと同様に
Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない

つまり、Dockerコンテナ（イメージも）は壊してDockerfileから
作り直してもなんの問題もないわけだ
なんの問題もないし、実際にそうする。

>>481
ありがとうございます。

ずっと、どうしてコンテナに入って作業してはいけないのかが、
謎だったんですが、入って作業するのもアリなわけですね。
ホッとしました。

>>484
なるほど。

＞Dockerイメージ = 実行ファイル
＞Dockerコンテナ = 実行ファイルを起動したもの

とてもわかりやすい喩えです。

＞つまり、Dockerコンテナ（イメージも）は壊してDockerfileから
＞作り直してもなんの問題もないわけだ
＞なんの問題もないし、実際にそうする。

Dockerfileさえあればいいってことがよくわかりました！


＞アプリの実行ファイルの中にデータファイルを作成しないのと同様に
＞Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない

ボリューム（あるいはボリュームを用いたデータ専用コンテナ）を使えってことですね。

>>482

> ソースのreadmeは、Dockerコンテナを想定していないです。
> すると、dockerコンテナ内で、systemctl enable serviceをセットして、
> コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。

無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
起動するやり方を調べろ。普通はその方法で起動する。


うん、だから、俺はDockerはインフラのためのツールと言うより
アプリ開発者のためのツールだって言ってるんだよ

インフラはアプリを作らない。だからDockerでアプリを起動しようと思ったら
そのアプリの起動方法を調べないといけない。よく知らないアプリの
起動方法やどこにどういうデータが保存されるかなんて調べるのは面倒だろ
仮想マシンでパッケージ使って起動すりゃいいんだよ。
パッケージ使ってりゃ依存関係とかディストリが解決してくれてんだろ
アップデートもやってくれるだろ

アプリ開発者の場合はアプリを作る。アプリ開発者ならsystemd使わない起動方法だって知ってる。
むしろsystemd使うほうが面倒。どこにデータを保存するかもわかってる。
アプリはディストリが用意するパッケージには依存したくない。アプリを動かすのに必要なものは全部管理したい
だからDocker使ってイメージを作るんだよ。あとはインフラにこのイメージ起動してって
ぽんと渡すだけでよくなる。

>>485
> ずっと、どうしてコンテナに入って作業してはいけないのかが、
> 謎だったんですが、入って作業するのもアリなわけですね。
> ホッとしました。

それを作業って言うのが謎。調査だよ。作業じゃない。
コンテナでやった作業（ではないもの）は全て破棄されるんだから

コンテナに入るのは調査するためだけ

>>487
＞無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
＞起動するやり方を調べろ。普通はその方法で起動する。

目が覚めました！ありがとうございます。直接起動する方法を調べないと駄目ですね。
Linuxは柔軟ですね。（WindowsならSQL SERVERはフォアグランドで動かせなさそうだもの。）
いわば、クリスマスツリーの電飾から、一つだけ豆球を取り外して、乾電池につないで動かすようなもののように感じます。


＞うん、だから、俺はDockerはインフラのためのツールと言うより
＞アプリ開発者のためのツールだって言ってるんだよ
＞あとはインフラにこのイメージ起動してってぽんと渡すだけでよくなる。

>>484の喩えを使って言えば、
スーパーアプリみたいな感じなのかな。


＞アプリ開発者ならsystemd使わない起動方法だって知ってる。

冒頭でいいましたが、これはDockerと付き合う今の私に必要な言葉でした。


＞アプリはディストリが用意するパッケージには依存したくない。
＞アプリを動かすのに必要なものは全部管理したい
＞だからDocker使ってイメージを作るんだよ。

Dockerとは、解体、原点に戻れですね。


丁寧にご指南いただき、本当にありがとございました。
とても勉強になりました！

>>488
よくわかります！

> アプリ開発者ならsystemd使わない起動方法だって知ってる。
っていうのは、

自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味無

アプリ開発者はすげーから、なんでも知ってるぜーって意味ではないので

訂正（意味無ってなんだよ？）

自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味な

>>491
＞自分で開発しているアプリなら、systemd使わない起動方法だって知ってるっていう意味な

あー、よかった、そうですか。
ちょっと大変そうだと心折れかかっていました。
自分で作るプログラムならよく把握できていますものね。

MySQLとかデータを大切に扱う必要があるものは
どこにデータが保存されてるかとかもしっかり明記されてるから
（クラウド使えよって思うが）Docker化するのは比較的楽だけど

WordPressとかウェブアプリとか、どこに何を保存しているのか
よくわからんものを、Docker化しようと思うよなって
インフラ屋がせっせと既存アプリをDocker化してるのを見てると思うよ

お前それ、信頼できるの？記事データはデータベースに保存されるから大丈夫みたいだが、
アップロードした画像とかデータベースサーバーじゃなくて
ディレクトリに保存されるじゃん？ ちゃんと共有ストレージ使うようなってんの？
管理画面からプラグインの導入できるけど、プラグインははデータディレクトリじゃない所に
保存されてるよね？そっちの対応は大丈夫？とか気になってしょうがない

補足だけど、systemdはパソコンの起動時に自動的に起動させるのが主な役目だからDockerのコンテナでも
起動時に起動させるのにsystemdを使ってもいいんですよ。
そのためには起動コマンドを調べる必要があるってことです。*.serviceのファイルを作成するだけで
systemd管理はできますが、*.serviceには当然起動コマンドを書く必要があるので。

>>495
今の話は、Dockerコンテナの中でsystemd使うなって話な

Dockerはそういう用途で使うためのもんじゃないから
そんな事をしようとすると、ハマるんだぞ
追加権限が必要なのが何よりの証拠

>>496
あり、レス読み間違えてたわすまん。
Dockerで中身いじるとしたらgitで遠隔操作するか、DBの永続化ぐらいで対応するのが常套だけど、
コンテナ内ならsystemdじゃなくてSupervisorがdocker公式になかった？

LXC, LXD（Linux Containers）だと、コンテナ内に入って、
アプリのインストールなど、環境構築できる

AWS でも使っている

>>498
Dockerと、Linux Containerとは、
何が大きく違いますか？
Dockerはネットワークやコンテナの管理が便利だけどなあ。

>>498
DockerもLinux Containerも、共にLinuxの独立分離機能を用いていると言うし。

使ってる機能が同じでも、目的のために最適化されたツールになってる
だから、なにが目的かを正しく理解する必要がある。

Dockerはアプリケーションを仮想化することで
アプリケーションに可搬性をもたせるのが目的
Docker化したアプリはどこでも動かせる
その目的のために使う道具

LXCやLXDだとそれをやるのはとても大変だろう？

https://qiita.com/Surgo/items/709a07d68c6eafbad267

ありがとうございます。

>>501
LXCや、LXDだと、別のホストでは動作しないのでしょうか？

>>502
すみません参考になります。

> LXCや、LXDだと、別のホストでは動作しないのでしょうか？

頑張ればできるんじゃね？
とてつもなく頑張ればｗ

18.09.0 が来た

>>504
とてつもなく頑張ればｗ
条件付きだがライブマイグレーションできる>LXD

>>506
マイグレーションが一番の魅力だから、
やっぱりDockerがいいなあ。

OpenVZでdocker動くかもと見たんだか、ほんと？

Linuxカーネルに互換性があるなら動くんじゃないの？

6使ってたら2.6で当然動かないよ
見たことないけど7使ってるとこなら動くはず

>>510
仮想マシンとは違うものね

7ですね
あまり需要ないかと思いますが、格安vpsで動くと嬉しい

格安VPSで7ってどこ？
普通に知りたい

テケトーにググったら
>NTTPCコミュニケーションズ WebARENA VPSクラウド プラン10
ttps://web.arena.ne.jp/pdf/vpscloud_spec.pdf
コレでcentos7動いてるみたいだが
月額\360〜

>>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に依存してるって意味なら同じだろうけど、ディストリのパッケージに依存してるからそれが違うかな。
コマンド手打ちでも構築できるけど、不便だろ。