Docker Part3

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

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

>>854
execのがシンプルですけど

ボリュームも好きなように使えばよかです。

データベースはdockerの中にボリュームつくって
htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

メリットとデメリットはよく分かりません

せっかくDockerのおかげでリリースが簡単になったのに、
ホストに静的コンテンツをリリースするんじゃ元と変わらない、
どころか静的コンテンツとコンテナでリリースの手間が余計に増えてしまう

静的コンテンツはVOLUMEを使わないでイメージに固めてしまうのが簡単

>>857
> データベースはdockerの中にボリュームつくって
> htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

どちらでも作るDockerイメージは同じ

ホストからボリュームのマウントってできるんですか？
ホストとDockerか同時に参照して読み書き

>>860
それが指定したディレクトリをボリューム化して使う方法だろ

-v $PWD/:/home
とか？

-vって非推奨じゃないっけ

そんなわけねーだろあほか

>.>843が理解できない人が理解できない。。
docker execがデバッグ用に使うものって・・・なにそれｗ

-vが非推奨じゃなくて--mountが推奨されてるだけか
ってことは今後-vが非推奨になることもありえるな

ない

https://docs.docker.com/storage/bind-mounts/#choose-the--v-or---mount-flag

でも書いてあるね

まあブイって分かりにくいしなボリュームなんだろうけど

/htdocs/public_html/wordpress
/htdocs/public_html/joomla

サイトの中で複数のCMSを動かしてるのですがこの場合
コンテナはapacheなどのwebサーバを起動して
entrypointでwordpressとjoomlaをgit cloneするのが良いでしょうか？

>>870
まず最初に何のためにDockerを使うのか
目的をいえ

流行だから

wordpressとjoomiaをpullするのがいいと思うよ。

どういう問題を解決したいのかを理解してないで
Docker使おうとするからわからんのだ

joomlaからwordpressのapiを使いたいのです

>>875
1.ホスト側に両方のサービスを登録しておく（動作確認用）
127.0.0.1 wordpress
127.0.0.1 joomla

2. joomla側にwordpressのアドレスを登録しておく

172.18.0.x wordpress とか。

3. joomla側からWPのAPIたたく。

http://wprdpress/wp/v2/posts?status=draft

おわり。

マックユーザーは知ってる単語を総動員して俺スゲーアピールするからな。
意味は滅茶苦茶。

Mac ユーザーはどれですか？

無料でプライベートリポジトリが持てるとこありませんか？

Gitlab.com

GitHub

>>877
は誤爆ね。
ARMマックのスレ住人のこと。

docker engine apiに認証認可を加えるプラグインはあるか？
docker swarmクラスタを複数のチームで共同利用してる
作成したリソースを他人に削除されないように保護したいんだがそういうのは難しいかな

https://docs.docker.com/engine/extend/plugins_authorization/
とかは？

1日で〜のDocker本買ったけど後半の章雑すぎて購入して損
いいことも書いてあるから全く参考にならないってわけじゃないんだけど
後半からtypoが異様に多い
尼損のレビューがヤサクラに見えてしまう
買うなら初版はおすすめしない

チャプター５はDockerfileのサンプルコードが入ってなくて動作確認できないとかね
サンプルコードなら出版社からダウンロードできるが、本を読み進めてできるよう書いてほしかった

さわって学ぶ〜のほうはレビューついてないが初心者にはこっちがわかりやすかった
この本を読んでから、1日で〜の本を読むと理解力が進むかな

まず、たった一日でDockerとKubernetesが身につく訳が無い。

なんとなく使うぐらいなら1日もいらん

まあエアプならそう言えるけどな。

アプリケーションコンテナがどういう問題を解決するツールかってのを
ちゃんと理解してる人なら1日もいらんだろうが
大抵の人はコンテナって何？から入るので無理

ネットワークの使い方がよくわからないんだよね
同じネットワークに所属するコンテナ同士はお互い通信できるけど
本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う

>>892
> 本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う
どこからlocalhostでつなぎたいと言ってるんだ？
コンテナ同士はコンテナ名（コンテナのホスト名）で接続するものだ
localhostで接続するのはホスト（Dockerを起動してるマシン）から特定のコンテナに接続するときだけだ
そして外部マシンからはからはホスト名（Dockerを起動してるマシンのホスト名）で接続する

あとコンテナから接続先のコンテナは（一般的には）設定変更できるように作るもんだぞ
多分それがわかってないんだと思うが

例えばそのコンテナがWordpressだったとして
接続先のMySQLはコンテナを使うかもしれないし
AWSやGCPのMySQLを使うかもしれない

「コンテナ同士がお互いに通信できる」場合の通信相手のホスト名は変更可能にしておく
通信先ホスト名はコンテナを起動するときに環境変数などで指定するのが一般的
イメージに埋め込んでしまったら、同じイメージを使えなくなるからね

例えばWordpressを起動する wordpress.exe コマンドがあったとして
そのWordpressはおそらくどのポート番号で待ち受けするか？という --portオプションや
どのMySQLに接続するか？という--db-addressというオプションを持っているはずだろ？

それと一緒なんだよ。 dockerで起動するときも
docker run wordpress --待受ポート番号 --接続先データベースサーバー
のような感覚

Dockerイメージ=一つのアプリとして考える

「同じネットワークに所属する」というのはどちらかといったら便利機能
本来は外部に立てたデータベースサーバーへのIPアドレスを指定する所を
コンテナにつけた短いホスト名で簡単にアクセスできますよってだけ

長い
12 factor appでググれ、で済む話だろ

12 factor appにコンテナの話は書いてない
読み直してこい

DNS サーバーがhostsで名前解決するのはどうかな？

コンテナAの/tmp/time.txtを、コンテナBから読み込みたいんですが
これはコンテナ同士でボリュームを共有しないと見えないでしょうか？

NFSでマウントすれば？

これからDocker入門する初心者ですがWindows上でも、MacでもDocker上のコンテナは同じ環境に出来るので、OSを意識しなくて良いというのがメリットでしょうか？

はい

>>900
それはアホなやり方です

>>892
ネットワークがよくわからんは同意。
k8sにしても理解に苦しむというか、もう少し工夫できんかったのか不満は多いな。

>>904
Dockerの役割をそもそも理解してないんだと思う

>>905
dockerの理解とネットワークは関係ないね。
役割を理解したからネットワークが理解できるわけじゃない。

>>906
Dockerの役割っていうのは、そういうネットワークを仮想化して
意識せずに使えるようになってるってことだよ

Dockerの具体的なネットワーク実装を意識してしまうのは
まだ抽象化して考えれるようになっていない

>>907
>>892がそもそもいっているのは「ネットワーク名で接続し合うのはなんか違う」
だから、「Dockerだから（したくないのに）ネットワークを意識する」と、言っている。
実際クラスタリング組むとPodを管理するネットワークとコンテナ通信用のネットワーク
とかバラバラなので、余計に意識はする。
それを何とかでできんかったのか？と、俺は言っている。
docker使ってネットワークをあまり意識する必要がないのは１台で動いているときだけ。
そして本番機が１台で動くことは滅多にない。

>>908
「ネットワーク名で接続し合う」っていうのが意味不明
それぞれのDockerはホスト名で接続し合う

その接続先のホスト名というのは、Dockerコンテナ起動時に指定した
（同じネットワークに属している）シンプルな名前かもしれないし
外部サーバーのホスト名かもしれない

いずれにしろ、Dockerコンテナ起動時に指定するもの
同じネットワークに属していれば、ホスト名がシンプルな名前でよくなるというだけ

全部localhostにしたらしたで余計わけわからなくなりそうなもんだが
物理ネットワークを意識せずに仮想ネットワーク上に構築できるならそれでおｋ

>>909
わからないなら、しったかで答えるなよ。
https://docs.docker.jp/engine/userguide/networking/dockernetworks.html#id4

デフォルト・ネットワーク以外は「ネットワーク名で接続し合う」のは当然だろ？

>>911
それ読んだのにネットワーク名で接続し合うなんて読むのか？
同じネットワークに属させるだけ
同じネットワークが複数のホストにあっても構わない
だからDockerコンテナからはネットワーク名なんて意識する必要がない
起動時のオプションに過ぎない

>>910
何の話をしてるのか知らんが、
物理・仮想マシンでアプリ（Dockerコンテナ）を起動した時
同じマシンからはlocalhostでアプリ（Dockerコンテナ）に接続でき
外部からはその物理・仮想マシンのアドレスで接続するだろ
そこは単純なアプリと何も変わらんのだが

>>912
同じネットワークに属した結果、そのネット―ワークで接続してるだろ。
ブリッジであれ、オーバーレイであれ、自分で作らなければならないんだから
「起動時のオプションに過ぎない」訳が無いだろう。

>>914
どこの話だよ。引用してみ。

あー、なんとなくわかったわｗ
「ネットワークを作る」っていうのを聞いて
ネットワーク設定を変更してるんだなって思ってるんだな

まあ実際にはそういう事をやってるんだろうが意識することではない
知らなければいけないのは、グループを作って
其のグループに属していれば、普通に通信できるってだけの話

変に内部の仕組みまで理解しなければいけないって考えるから
理解できないんだよ。単に使う分には必要のない知識

使うときに必要な知識と、トラブルシューティングに必要な知識は分けて考えれ
普段使いしているときはトラブルシューティング用の知識は使わずに
Dockerで抽象化されてるものだけを考えればいいんだよ
脳容量が少ないんだから混ぜるな。混ぜるからいっぱいいっぱいになって
脳がついてこれないんだよｗ

>>913
コンテナ同士の通信の話では？

発端のレスは>>892
その後のレスの文脈まで踏まえるとPOD内通信と同じようにPOD間の通信もlocalhostで繋ぎたいってのがネットワークわからん派の主張
それに対して全部localhostで繋いだらわけがわからなくなるってのが俺の主張

>>915
892の話してるんだろ。
「本番ではlocalhostとして接続したい」なんて言っているのは単に開発機から
本番機に移行する時の良くある無理解と思われるので、そこは触れない。
が>>892が、「ネットワークの使い方がよくわからないんだよね」と言う結論に至るのは
結局Dockerのあのダルイネットワークの仕組みのせいだろう。

話戻るけど、これほんと意味不明なんだよね

>>892
> 本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う

どこから「localhostとして接続したい」なんて要件が出てきたのやら

Docker使わずにnginx起動するとするだろ？
このnginxに「localhostとして接続したい」なんていうか？

いうなら同一マシンからなら「localhostで接続できます」だろ
違うマシンからならホスト名で接続するし
同じマシンならlocalhostで接続する。
このlocalhostもホスト名の一つでもあるんだがな

（同一マシンという）条件が揃えばlocalhostで「接続できます」という話であって
本番ではlocalhostで「接続したい」なんて要件はありえないんだが

>>918
なんで引用してって書いたのに、引用しないの？

>>920
何の話をしてるのさｗ？何を引用しろと言っているのｗ？

>>920
あー、なんか君の言っていることが分かった気がするよ。
俺はある程度>>892の雰囲気を読んであげてるつもりだけど、
君はまるで読んであげてないんだろうね。

>>918
よくわからんのはバカだから
Dockerを理解してないからだろ

>>922
勝手に解釈してます。本人が言ったことと違う前提の話を
思い込みでしてますって堂々といわれてもなぁｗ

>>923
それに対して俺は「もう少し工夫できんかったのか不満は多いな。」
と感想を言っている。これはDockerの役割なぞとは関係ない。

>>924
まあいいよ！粘着KYは本当に雰囲気読むのが下手ね！

Dockerの役割っていうのは仮想化
仮想化っていうと仮想マシン（仮想機械）のことだと勘違いしてるやつがいるが
仮想メモリと同じ意味の仮想化
実際の物理的なものを隠蔽化して仮想的なものを作り出すというしくみ

Dockerは仮想化を提供することでDocker上で動いているコンテナが
それを動かしてる物理的なインフラ（ネットワーク含む）を意識しないですむようにしている
Dockerコンテナからすればどこで動いてるかなんて意識する必要はないし
動かす方は単にDockerコンテナを起動する時にオプションを与えてるだけ

ID:+jHSMkRj
罵倒マウント常習犯
NGしたいからコテハンつけてくれ頼む

>>925
Dockerの役割を理解しないで
工夫しろとか言っても的外れにしかならんだろｗ

>>928
IDの所にコテハンつけたぞ
これでいいか？

おっと間違えた。IDが変わってしまったぞ！

過疎スレなのに盛り上がりすぎｗ
でもいいことだよ、人が増えすぎて議論もできない荒れてるスレもたくさんあるからね
C#スレみたいに

>Dockerは仮想化を提供することでDocker上で動いているコンテナが
>それを動かしてる物理的なインフラ（ネットワーク含む）を意識しないですむようにしている

そのDocker自身がECSであれEKSであれ、VMの上で動いていしまっている事によって、仮想化の上に仮想化
を提供するという馬鹿げたソリューションになっている。

物理鯖の上でDockerコンテナを動かしているというならともかく、物理の上で動くVM１台の上で動くNIC
を仮想化したからと言って何の意味があるというのだ？

サーバの仮想化とアプリケーションの仮想化は別だから馬鹿げてない
ごっちゃになってるのは頭が弱いだけでは

>>934
頭が弱いのはお前だろｗ
サーバーサイドで動くアプリ＝サーバーその物だろｗ

VMは文字通りマシンの仮想化
その中で動くアプリケーションと区別ができないのは頭が弱いだけでは

>>936
いや、間違いなく言えるのは実務と実需が分かっていないのはお前だ。

>>933
仮想マシンの上で仮想メモリを使っていてさらに仮想化してるから
3重の仮想化だ！とか言わんの？ｗ

「仮想」の意味が全部違うのに、何が馬鹿げてるというのか

> 物理鯖の上でDockerコンテナを動かしているというならともかく、物理の上で動くVM１台の上で動くNIC
> を仮想化したからと言って何の意味があるというのだ？

物理サーバーでもMacでもWindowsでも同じDockerイメージが動くという意味があるよ

そうだよね？違うかい？ｗ

>>939
MacやWindowsはサーバーにはならないよねｗ
サーバーの話してるんだがｗ

なるでしょ
ならないと思い込んでるのは頭が弱いだけでは

>>940
つまりサーバー以外で意味があると認めたということ？
サーバー限定にしないと、言い返せない？

>>938
仮想メモリの意味をまず理解しろよｗ
意味不明すぎだろｗ

>>934
>サーバの仮想化とアプリケーションの仮想化は別だから馬鹿げてない
>ごっちゃになってるのは頭が弱いだけでは

君の言うようにサーバーの仮想化とアプリの仮想化が別で、Dockerが提供しているのがアプリの仮想化と言うのなら、
>>927が言うような「物理的なインフラ（ネットワーク含む）を意識しないですむようにしている」を提供する必要は無いよな？
アプリにとってインフラは関係ないし。でも現実には提供してるよな？つまりDockerが提供してるのはサーバーの仮想化含めてるよな？
にも関わらず下にVM無きゃ動かないというのは、詰る所、Dockerが不完全だからって事にしかなってない
一体何時VMから独立してくれるんだとｗｗ

次スレ

Docker Part4
https://mao.5ch.net/test/read.cgi/linux/1597591176/

>>944

> >>927が言うような「物理的なインフラ（ネットワーク含む）を意識しないですむようにしている」を提供する必要は無いよな？

あるだろ。というかそれこそが重要なことだろ
アプリにとってインフラは関係ない

関係ないというのは、どういう構成でのインフラでも動くということ
つまりインフラ（物理サーバーやネットワーク）の違いを吸収するそうが必要

それをDockerが提供している

> 下にVM無きゃ動かないというのは、
LinuxでVMは必須じゃない

VMを使ってもVMを使わなくても、同じDockerイメージが動く
それはDockerがその違いを吸収してアプリからすれば全く違いがないからだ

例えばapacheとngixの2つのhttpサーバーを起動する時
どちらもポート80番を使っていれば起動できない

同じDockerイメージを使うということは
どちらも同じ80番ポートを使うかもしれない
他のDockerイメージが使ってるポート番号なんて知る余地がない

だからDockerでは、Dockerイメージがポート80番を使っていても
Dockerサーバーの力で、そのポート番号のリマップを行っている

その他のいろいろなリソースに対しても同じでリマップの機能を提供している
これがDockerがもつ仮想化という機能の本質

Linux上でDockerはVMなしで動くに
このアホは何を言ってるんだ
アーホ

>>946
>つまりインフラ（物理サーバーやネットワーク）の違いを吸収するそうが必要

普通それを「アプリの仮想化」とは言わない。

>LinuxでVMは必須じゃない

そのLinuxはVMとして動いているだろ。EC2のインスタンスなんだから。

>>948
本番機じゃそのLinuxがVMだっつーの！

>>950
本番機がVMなのはお前の場合の話だろ
Dockerイメージはどこでも動くんだから
その証拠の一つが「VM上でも動く」だろうが
アーホ

>>949
> 普通それを「アプリの仮想化」とは言わない。

じゃあ何がアプリの仮想化なのか言ってみ

仮想化の意味を知らんやつが多いよな
仮想メモリ（技術）の仮想化とはなにを仮想化しているのか？

物理 → 技術 → 仮想 → アプリ

このように技術、テクノロジーによってによって
アプリから物理的なものではなく仮想化されたものを見せてる
それが仮想化の意味だよ

・物理メモリ → 仮想メモリ技術 → 仮想メモリ → アプリ
・物理マシン → 仮想マシン技術 → 仮想マシン → アプリ実行環境（OS）
・アプリ実行環境（OS） → アプリ仮想化技術（Docker） → 仮想化されたアプリ実行環境 → アプリ

こういう流れな
アプリ実行環境、インフラが異なっていても
Dockerによって全く同じインフラで動いているように見える
それがアプリ仮想化技術

>>951
実務やらない馬鹿に話すのはマジ疲れるなｗ
クラウドで何かのサービスを提供している法人の3社に1社はアマゾン。
君はそれ以外を使ってるのw？
多分家で引きこもって碌でもない事ばかりしてるから、こういう話にピンとこないんだろう？
で無きゃここ迄、話がずれることは無いｗ。
この話にピンとこないって何でよ！？

>>953
お前の手元のノートパソコン、MacBookは
AWS上で動いてるのかよｗ