Docker Part3

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

http://www.docker.io/

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

ホノカチャン

>>798
環境変数サポートの追加がめんどくさい時によくやる
環境ごとに設定ファイル書いてCOPYするほうが楽だもの

--mountで存在しないボリューム名を指定して実行したらエラーになるらしいのですが
エラーにならずボリュームが作成されてしまいます。
エラーにならないのが正しい動作ですか？

docker run -dit --name test --mount type=volume,source=volume1,target=/tmp

最近触り始めたんだがなんでコレ突然RHEL8からハブられてんの？
Kubernetesからも距離置かれはじめてるみたいだし何かあったんか

podmanの件はredhatのほうが先走って自滅した感じ
運用環境はコンテナ標準を満たす限り、dockerにこだわる必要はないから、運用向けに機能を削ったり追加したりして最適化したほうがいい、これは正しい
でも、運用環境っていったら普通はk8sだから、podmanが使われる機会は滅多にない
一方で、開発環境はpodmanのエコシステムがまだまだ貧弱すぎて、dockerにはぜんぜん追いついてない
docker社もそれを理解してるから、開発環境でのエクスペリエンス向上に投資を集中し始めた
またpodmanのセールスポイントの1つであるrootlessも本家dockerはとっくに実装済
結果として誰もpodmanを使ってない（そしておそらくそのまま消え去ると俺は予想してる）という状況になってしまった
redhatにしては珍しくマヌケな戦略をとったなといった感想

へー、サンクス。posmanとかはopenshiftやるならって感じなのかね
にしても開発で使う分には裏方が何やっててもちゃんと使えさえすれば関係ないしな…

PODMANのメリットはデーモンレスってことだけ?
赤帽がなにを目指してるのか正直よくわからない
だけど赤帽のやることだから何かがあるんだろうな

dockerコマンドだけ使う分にはpodmanにエイリアス設定されてるしあんまり意識しない
問題はdocker-composeを使いたいときだなぁ(podman-composeの互換性が大変怪しい)

まぁmicrok8s使っちゃうからdocker-compose使うこと自体減ってるけど

docker-composeのメリットがさっぱりわからない
こんなのつかっても結局Dockerfile作らないといけないし意味がない

Dockerfileはアプリケーションのソース
docker composeはビルドしたアプリケーションをどうデプロイするかを定めたマニフェスト
全く役割が異なるのでどちらかがもう一方の代替になることはない

docker-composeと比べるのはDockerfileじゃなくてdockerコマンドだよ
DockerfileあったってDockerコマンドは使うだろ？

コンテナ一つだけならDockerコマンドを直接使っても苦労はないが
複数のコンテナを使う時Dockerコマンドを何度も実行して起動するのは大変
Dockerコマンドが面倒になったらdocker-composeを使うんだよ

Dockerfileを書かなくてもいいものだと思ってた
勉強になりました

書かなくてもいいけど、なにやったか忘れる。

そのまんま手順書になるのがいいとこでは

docker execは邪道なのかな

docker execはデバッグ機能

docker exec して、動かしながら、Dockerfileを書く。
最後にdocker buildして同じものが出来上がって完成。
って感じじゃない？

うちは運用ジョブをdocker execで流してます
docker execを使わない場合、運用ジョブ専用のAPIやWebAppを整備するんでしょうか?

データベースをホストにマウントするのとボリュームで管理するのはどっちがいいんでしょうか？

>>825
そんなことめったにしないなぁ。docker buildはキャッシュが効くんで
（キャッシュが効くように）Dockerfileに追記しながらDockerfileを書く
終わったらDockerfileをシンプルにしたりサイズが膨れ上がらないように調整するって感じ
docker execなんかして作業したら、その作業結果をファイルに保存するの二度手間じゃん

>>826
そういうのはdocker runやるのが普通
最初docker execなんてなかったんだよ
それなのにそういう用途にも使えたわけ

>>827
どちらもボリューム。データの保存先のパスが違うだけって知ってる？
Dockerサーバー上の特定のパスに保存するか
Dockerが用意したパスを使うかの違い

ホストマウントはホスト環境への明示的な依存なので、どうしても必要でなければ避けてvolumeを使うべき
volumeも内部的にはホスト環境に依存してるといえばそうだけど、抽象化・隠蔽されているのでホストマウントよりBETTER
実例として、Docker for Windowsでのパーミッション、リモートエンドポイントへのコマンド実行、などでvolumeを使用していれば避けられたトラブルが結構あった

つまりはいろんな種類のホスト、例えばWindowsやMacでも使いたいなら
Docker上のボリュームを使えってことだな。

Dockerイメージ自体は同じものを使える。
必要に応じてDockerのボリュームを使おうがサーバー上の
パスを使おうが自由に選択できる。

だが相対パスを使えばいいだけじゃないか？

相対パスでマウントできたっけ

相対パスを変換するだけやろ

docker-composeはそれを自動でやってくれる

そもそもDockerのクライアントがどんなOSかなんて関係ない
Dockerはサーバーで動くし、DockerはLinuxでしか動かない

>>832
その相対パスが存在するか、適切なパーミッションを持っているか、といった条件はホストへの依存性となる
基本的にホストへの依存性が少ないほどトラブルは減る

>>829
docker runで全てが解決するならdocker execは存在しない
docker runはコンテナ外部で解決可能なジョブの実行に適している
docker execはコンテナ内部で行う必要があるジョブのために存在する

問題は Windows と Mac でボリュームを使うとファイルシステムの変換が起こるのでとても遅いということですね

>>838
だからdocker execは主にデバッグ用だって
通常の運用時には使わないもの

コンテナ外部で解決可能とか何のことを言ってるんだかさっぱりわからん
docker runとdocker execで実行できることは全く同じ
違いはdocker runはメインの処理を行うもので、
docker execはメインの処理を行ってる最中に乗り込んでデバッグするもの

runで常時起動してるコンテナに
例えばcronからexecでジョブ実行してもいいと思うがな

kubectl exec 経由なら、管理用のコンソールが欲しいときにわりと使ってる

>>840
全く違うよ
運用ジョブには大まかに分けてリモート実行可能なものとローカル実行のみ可能なものに分類できる

コンテナの外で解決可能なジョブはこの分類で言うとリモート実行可能なジョブに当たる
具体例はデータベースのバックアップ、バグデータの修正など
データベースコンテナとは別にジョブ専用のコンテナを同じネットワークでrunすれば良い

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
具体例はGitlabのバックアップ(gitlab rake)コマンドなど
ローカルで実行される前提のコマンドはdocker execで実行するしかない

Dropboxにバックアップするのが楽だからホストのボリュームがいいと思ってたけど
Dockerのなかでボリューム作ったほうがはまらないってことですね
勉強になりました

>>843
なんか使い方がおかしいな
まさかDockerコンテナの中に永続的な情報を入れてるんじゃないだろうか？
永続的な情報はボリュームに入れるんだぞ

>>843
> ローカルで実行される前提のコマンドはdocker execで実行するしかない
何度読んでも全く理解できん
なんでだよ

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
ローカル実行の可能なジョブはコンテナの外で解決できない
と話をループさせてるだけで全く説明してないよ

>>845
例として運用ジョブとしてポピュラーなバックアップを挙げたが、今の話題と永続化は別の問題だ

>>846
わからないなら、わかるまでよく考えるしかない、としか言えないな

では無いということで決着

イメージ開発者など実際に運用までしない人には確かに要らない機能だと思う

イメージ開発してる人は自分でイメージつくからね
今あるイメージでなんとかしなきゃで
バッドノウハウ溜め込む運用とは考え方が違う

で、工数がかさんで、メンテナンス範囲が広がる、と
既存のツールセットをうまく使う、ということもできないと後々つらくなる

execでコマンドうちゃいいだけなのに、わざわざ工数をかけてメ対象を増やして、アタックサーフェスを広げて、何がしたいのかね一体

>>853
よりシンプルになる

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