Docker Part2©2ch.net

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

http://www.docker.io/

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

>>454
C言語とかコンパイル言語使ったことある？
dockerのbuildは、C言語などのビルド（コンパイル）と同じ

言語はソースコードをビルドして実行バイナリを作成する
Dockerはすでにある複数のバイナリをもとに、Dockerイメージを作成する


さて、実行バイナリは、データを保存したらどこに保存されるか？
実行バイナリの中に埋め込まれるわけじゃないよね。実行バイナリの外のファイルに保存する。
実行バイナリ自体は読み取り専用。ビルドしたときに作成したバイナリから変更することはない

Dockerも同じように考える。Dockerイメージっていうのはビルドして作成した状態から変更しない
内部的には変更されていてそのデータはどこかに残っていたりするが、そういうのは内部の話なんで忘れる
Dockerイメージは読み取り専用で、Dockerイメージをrun（実行）するとプロセスが起動する
あ、ここも実行バイナリと同じだね。バイナリを実行するとプロセスが起動する

Dockerイメージをrunして作ったプロセス（＝Dockerコンテナ）はどこにデータを保存するか？
Dockerイメージは読み取り専用なので、当然Dockerコンテナの外のファイルに保存する。


C言語 ・・・ ソースコード -> [Makefileでビルド] -> 実行バイナリ
Docker・・・ソースコード等 -> [DockerfileでDockerビルド] -> Dockerイメージ

Dockerのソースコード等には本当にいろいろ含まれる
アプリのソースコードだったり、nginxだったり。カーネル以外の全て

で、コード消えるのか？っていう疑問の答えは、実行バイナリ消してもソースコードをビルドすれば作れるでしょう？
Dockerも同じでソースコード等をビルドすれば、Dockerイメージができるんだから何も問題ない

で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある

C言語の場合、ビルドしないと動く実行バイナリはできないから
これで納得するかもしれないけど、ウェブ開発とかしてると
ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ

毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある

データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい
Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない
ホームディレクトリ以下のいつもの場所をそのまま参照する
当然エディタもDockerイメージの中に入れない。
今までどおりエディタで編集して、実行環境がDockerイメージなっただけ

ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ

>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう

>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。

インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。

そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ


Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）

そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように
Dockerfile等をインフラチームではなく開発チームがメンテナンスする。

そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば
インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる
開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。
（例えば必要な環境変数など）

理想は
　開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする）
　インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう

今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

Dockerを仮想マシンの代わりとしてとか考えてると

> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ

↑これとかで、混乱する。

Dockerは仮想マシンじゃないんだよ。

Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK）
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない

バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？）
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ？

> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど

virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから

>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ

virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！

例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる

ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける
（パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある）
そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える

バイナリをコピーするだけで動かすことができるように
DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる
こういうのは開発者にとっても便利だよね。

ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから
goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも
Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ

>>462
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる

インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん


開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に
（カーネル以外）依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
物理（or 仮想マシン）のOSが変更になったって？別にOSのパッケージに
依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん


いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや
Ubuntuに乗り換えよう。なんてことも気楽にできちゃう

客先が使ってるマシンがCentOSだって？ Dockerがあれば関係ない。
UbuntuベースのDockerイメージが、そのまま動く

本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね

>>464
ほんとベース理解できたら凄いわこれ
細かいホスト側？の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される！

chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。

は？

クソレスのせいで会話とまったな
466は反省しろよ

シェルのコマンドで-pとか-vとか指定するのと
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ

Dockerコンテナってラベル付ける機能あったんだ
長い事使ってるがそんな機能がある事自体初耳

TraefikというDockerコンテナを自動的に登録してルーティング出来るリバースプロキシがあるんだが
Dockerのラベルでリバースプロキシの設定が出来る

https://docs.traefik.io/v1.7/

以下docker-compose.ymlの抜粋
ホストヘッダーでのルーティングを設定してる
# ...
whoami:
image: containous/whoami # A container that exposes an API to show its IP address
labels:
- "traefik.frontend.rule=Host:whoami.docker.localhost"

>>469
docker-compose.yamlはコマンドのオプションで指定するのと同じ

docker-composeコマンドというのはそもそも、
一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、
複数のコンテナで構成するときに、docker runで適切なオプションつけて
複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等
run以外にbuildとかもできるけどね。


で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として
ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う

docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか
ボリュームをどこのディレクトリに割り当てるのか指定するのに使う

例えば、Dockerイメージとして構成されたものが、どんなポートを公開しているか？
っていうのはDockerfileを見ればわかるわけだ。

で、そのイメージを起動する場合、ポートを変更できる機能がなければ、
同一ホストで複数起動することができなくなるだろ？
実際にどのポートを使用するかは実行時にしか決められない。（ボリュームも同じ）

Dockerfileではそのイメージがどういうものかを書いて、
docker runはイメージを起動するときのオプションというわけ

>>470
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが？

昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな

たとえば、あるソースをコンパイルして、
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。

privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか？？

>>473
なんでソースのコンパイルなんて話が出てくるのかわからん

Dockerのコンテナはsystemctl start serviceから起動する必要はない
通常はDockerそのものがsystemctl start serviceで起動するようになってるから
Dockerでサービスが起動するコンテナを作ってあとはDockerに
OS起動時に、そのコンテナを起動してもらえばいいだけ

どうしても特定のDockerコンテナだけsystemdで制御したければ、
dockerコマンドを実行するserviceファイル書けばいいだけだが

> privilegeを与えて、yumで開発環境投入して、
？？？
意味がわからんが、Dockerの中に入って開発しようとしてないか？
systemctlコマンドを使うのは、もちろんDockerコンテナの外だよな？
通常はDockerコンテナの中で、systemdなんか使わないからな

Dockerの中に開発環境入れて、Dockerの中で開発なんてことはしねーからな
そういうのは仮想マシンとかシステムコンテナでやれ
Dockerのようなアプリケーションコンテナを仮想マシンとかして使うな。
無理やり使おうとしたその結果が、お前のその「どうやればわからない」という状況なんだからな

>>474
レスありがとうございます。

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

ソースで提供されているプログラムをDockerコンテナで使いたい場合、
具体的にどうすればいいでしょうか。

コンテナに入ってから、
コンパイルすることしか想像できない初心者です。

>>475
Dockerfileを使ってビルドするんだよ

コンテナの中に入るのは、ビルドがおかしいが原因がよくわからないとかで
調査するため。手作業でコンパイルとかしない

単純にDockerコンテナ内でビルドすると時間がかかったりイメージサイズが膨れ上がったり
するから工夫が必要なんだが、とりあえずそれは置いといて、一番単純な方法だ。

まずDockerfielを書く。Dockerfileには基本的に次のようなことを書く

・FROMでどのディストリをベースにしたイメージを作るのかを書く
・RUN（RUN yum〜とか）でイメージの中にコンパイルをするのに必要なパッケージを入れていく
・ソースコードをコンテナの中に配置する
　（コンテナの外にあるソースをコピーしたりgitでcloneしたり、場合によってはボリュームを使う）
・プログラムをビルドする
・ビルドされたプログラムを起動するためのCMDやENTRYPOINTを書く

これで、ソースコードからビルドしたプログラムが入った
Dockerイメージが出来上がる。


あとは、dockerコマンドやdocker-composeなどでこれらを起動すれば良い

>>476で書いたように、単純な方法を取ると、
アプリを起動するのに必要ないビルドツールのせいで
イメージサイズが大きく膨れ上がる。

レイヤー（例えばRUN）毎に差分が保存されるため
ビルドが終わってから削除してもイメージサイズは減らない

（一つのRUNの中ですべてを行う方法があるが、
キャッシュも使われなくなるのでイメージのビルド時間が伸びる）

こういう場合に使うのが multi stage build

アプリを使うためには、アプリの実行ファイル（とランタイム環境）さえあればよいので、
ソースコードから実行ファイルを作る所までをビルド専用イメージで行う
そしてその実行ファイルをコピーして使う別のイメージ（ビルドツールなし）を作るという方法

>>476
丁寧なレスをいただき、感謝いたします。
ありがとうございます。しかし、疑問が／／／

環境構築は手探りではダメで、
ビルドなどを含む全ての環境構築手順を、
スクリプト化できていないとダメなようですね。

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

どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。
できたイメージはtarで持ち運ぶつもりでいます。

>>477
脹れ上がりですね。
＞ビルドが終わってから削除してもイメージサイズは減らない
知りませんでした。ありがとうございます。

英文ですが、さっきこれを見つけたところでした。
https://stackoverflow.com/questions/41688748/should-i-compile-my-application-inside-of-a-docker-image

勉強します。丁寧なレス感謝いたします。


脹れ上がり防止と、
dockerfileによるイメージ作成の自動化が焦点になっているという認識であっていますでしょうか。

ありがとうざいました。

>>478
> 環境構築は手探りではダメで、
> ビルドなどを含む全ての環境構築手順を、
> スクリプト化できていないとダメなようですね。

Dockerfileを手探りで書けばいいじゃん。

FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN ./configure
とか書いてビルドして、あれぇ？ビルドできないなぁとかなったら

FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN yum install 足りないパッケージ
RUN ./configure

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

最後にyumとかでまとめておしまい

まあどうしてもわからないなら、コンテナに入りつつ
ビルドしていって試してもいいけど、最終的には
Dockerfileにビルドするためのコマンドを書く

>>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でビルドなんだな…時代が進んで色々凄いコトになってる
つか使い方がよく分からんがｗ