Docker Part3

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

http://www.docker.io/

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

>>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上で動いてるのかよｗ

アプリ仮想化（）
名前空間で区切ってるだけだぞ

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

https://it-trend.jp/desktop-virtualization/article/249-0009

そもそもアプリの仮想化という言葉はIntelがVT-xを実装した時に「OSの仮想化/アプリの仮想化/デスクトップの仮想化」とセットになって出てきた言葉。
OSの仮想化はVMware ESXi(Hyper Visor）とかMS Hyper-Vの事。OSそのものを仮想化する
アプリの仮想化とはあるアプリを異なるOSで動かすこと。（これが出てきた時に著名になったのはWindows7の頃で、7上でXPでしか動かない筈のIE6が動いていた）
Dockerに例えればカーネルを共用したOSの中でhttpd等のパッケージを、管理システムも含めて「アプリの仮想化」することによって、さまざまな環境として動かしている。
この点は確かに「アプリの仮想化」と言える、が、デバイスの管理を含めるなら、やはりOS仮想化の範疇となる。

>仮想メモリ（技術）の仮想化とはなにを仮想化しているのか？

この点以下の君の記述はコメント不能。パラノイアすぎる。
多分色々な物を大きく誤解している。

物理 → 技術

技術ってなんだよｗ

> そもそもアプリの仮想化という言葉はIntelがVT-xを実装した時に「OSの仮想化/アプリの仮想化/デスクトップの仮想化」とセットになって出てきた言葉。

それとDockerが言ってる言葉の意味が違うってことぐらいわかるよね？ｗ

言葉の意味をわかってないから、こうやって別の用語とごっちゃにするわけだ
まぬけやなー

>>954
さーばーさいどのはなしをしているって何度言っても理解せんのねｗ。
君の脳みそは。
いいか！？本番機を単なるVM上にインストールしたhttpdと
単なるVM上にコンテナランタイムを動かして更にその上にインストールしたhttpdは
どっちが管理が大変か理解できるか？後者の方が大変だろ？当然の話として。
（これが分からなんならもう俺に話しかけるな。）理解できるか？？
だから、コンテナとしてのメリットを謳うならそれ以上のメリットが無ければならないわけだ
それが無いと言っている。少なくとも一般的な情シス部門を納得させるだけの何かが足りないと言っている。

>>957
当然だろ。別にこれは俺が言い出したことでは無いから。
そもそも、Dockerはアプリの仮想化じゃないし。
>>934がこう言っているから、概念に当てはめて、返しているだけだろ。

> さーばーさいどのはなしをしているって何度言っても理解せんのねｗ。

なんでサーバーサイドに限定しないと、何も言い返せないんですか？
開発はサーバーサイドでしてるんですか？


あ、よくあるインフラ専用の人かｗ
自分で開発してないからDockerの本質、Dockerが何を解決しているかをが理解できないのね

httpdサーバーをDockerで〜なんて言ってる時点でわかってないわ
やらないことはないけど、本来は自分（たち）で作ったアプリを配布するためのものなのに

コンテナを使うとインフラ担当者にDockerイメージ作ったからこれ動かしてっていうだけで動く
Dockerの技術によって環境が仮想化されてるからね
どこでも動くDockerイメージを作れる

例えばRailsでブログアプリを作ったとする

Dockerイメージ作ったからこれ動かして！
これだけで動くことが出来る
せいぜい起動するときの環境変数を伝える程度

これがDockerを使わないと
Rubyのバージョンは？必要なライブラリは？
デプロイの手順は？などいろいろ伝えることになる

Rubyのライブラリの最新バージョン使ってるんだ。
え？構築したサーバーではパッケージがない？知らんがな。
そういうのを入れるのもインフラの仕事だろ？お前が頑張れや

こういう大変な管理をなくすのがDocker
それがわからんならもう俺に話しかけるな

>>962>>961
その用途は、コロナのせいではなく、単に失業しているせいで外に出られない、君のとても狭い
世界の用途だ。多分君は趣味で（恐らく一人で）開発を行いDockerに入れ込んで喜んでいるのだろう。
君が理解している本質とやらは、君の、小さな小さな脳みそでのみ使用可能な「本質」でしかない。
広い世界では勿論、それ以外にDockerの「本質」は存在する。

アプリの配布という用途は、無いことは無いし俺も趣味ならそれで遊ぶこともあるけど、
一般的なエンジニアが「仕事」として興味を持つのはTCOを下げたりROIを上げる為であり
ここでまともな質問をしているのは、そういった人達だ。

顧客に提案したいけど、何を売りにすれば良いか迷ってるとかな。そんな人たちに向かって、君の小さな小さな
知識で（おまけに上から目線で）答えられると、大変な迷惑になっていることを自覚した方が良い。
そして就職して、同僚がどの様にDockerを使っているのか、周りを見てみた方が良い。

君の理解している用途で使用しているのは１０から２０あるプロジェクトの１つか２つでしかない事が分かるはずだ。

>>964
その内容と同じことを言ってるサイトを
ググってきてみつっけてきてください
そうすれば信じてあげましょう

>>965
いやｗ就職しろよｗ
みんなマジでアプリの配布なんて用途で使ってないからｗ

なんだろうね。働いてないはずだ！という思い込みで勝ったつもりになるのってｗ
それで同じことを言ってるサイトは？
また逃げるの？何回目かな？

アプリの配布

GitLab Docker images
https://docs.gitlab.com/omnibus/docker/

>>967
OK！分かったよ、じゃあ君の職場でどうやってDocker使っているか教えてくれ。
俺の所じゃ、200人いる開発者は全員Dockerで開発してはいるものの、開発機/検証機/本番機は
８割方VMだ。開発した成果物をgithbubに入れてVMにDeployerでデプロイって形だ。
だからDockerを「アプリの配布の為」に使っている訳じゃないのは明らかだ。
本番機をコンテナ化、マイクロサービス化ってのは諸所の事情でなかなか進まない。
君が同業ならその辺の事情は察することが出来るはずだ。

・・・・・・で、君の会社はどうなんだい？
社員全員が「アプリの配布の為」に使っているのかーーーいｗ？

>>969
開発したアプリをDockerイメージにしてGCPの
GKE (Google Container Engine）で動かしたり
GCEインスタンス起動時の設定にある
コンテナイメージに指定したりしてるが？

それでお前と同じことを言ってるサイトは？
答えないんだね。逃亡回数＋１しといたからねｗ