Docker Part3

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

http://www.docker.io/

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

↑このように
本当にやりたいことは「asciidocのコンパイラ」を作りたいだけ
だけど、それを動かすのにライブラリとかが必要だから
Dockerでまとめる。という使い方をするもの

CIで使うようなビルド用/テスト用の本当に使い捨てのコンテナは十分にコンテナ仮想化の哲学と目的にマッチしてるけどな
上でも書いたがVSCodeで使えるような開発用コンテナも十分に有用

個人的には使い捨て或いは壊れたら作り直すものならアプリも環境もサービスもコンテナが良い
そういう意味では, コンテナ仮想化を選択する前に用途が決まっていないと話にならない

用途が違うこともまぁあるんだろうが, それ以上にコンテナに求めるものが曖昧なのにふわっとした目的で使おうとするからコンテナに柔軟性やら壊れた時に直すやらが必要になるのだと思う
少なくともディスポーザブルな環境としてのコンテナは普通に適応

MS-DOS時代ならOSもアプリも全部フロッピー一枚だったのにな

せやな、Aドライブに起動ディスクを入れて、
Bドライブにシステムディスクを入れるんだよね。

>>754
Dockerfileのビルド時に--network=host入れたらビルド出来たわ…

Docker哲学とかどうでもよすぎてゲロ吐きそう

哲学とかどうでもいいがいい加減ステージング用とプロダクション用でそれぞれ別のイメージ作る馬鹿は絶滅してくれないかな

>>798
そんなばかは放置すればOK
もし仕事を一緒にしているのであれば、そのバカを追放するか、その仕事を止めるか。

馬鹿でも何でもいいから、どう使ってもよい。

やっとnginx、gunicorn、flaskをdocker化できた…
ファイアウォールが原因で動かないとか…

dockerとkubernetesの環境をネットで調べながら作ってるんだけど、
下記のようなエラーが出てるんですが、解決する方法ありますか？

CentOS8
docker-ce 19.03.8
kubernetes GitVersion:"v1.18.2"

kubelet[7677]: E0519 10:42:28.107265 7677 manager.go:1086]
Failed to create existing container: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-
podaなんかID.slice/docker-なんかID.scope: failed to identify the read-write layer ID for
container "なんかID". - open /var/lib/docker/image/overlay2/layerdb/mounts/なんかID
/mount-id: no such file or directory

dockerのイメージ保存先を起動オプションで変えてあります。
ググったら無視してもいいようなことは書いてあったんですがなんか気持ち悪い･･･。


kubelet[7677]: W0519 10:24:35.435700 7677 watcher.go:87] Error while processing event
("/sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR):
inotify_add_watch /sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice:
no such file or directory

dockerのオプションで、cgroupではなく、systemdを使用するようにしてあります。

両方ともディレクトリがないエラーですが、dockerのオプションとkubernetesの認識がずれてるように見えます。

dockerは理解するとめちゃ便利だとわかった。
ただしlinuxカーネル以外で使おうとすると地獄

ランタイムや開発キットのコンテナって、他のコンテナとはどうやって組み合わせて使うものなの？
具体的には、code-server + Swiftで使ってみたいんだけど・・・・やり方が全くわからん
https://hub.docker.com/r/codercom/code-server
https://hub.docker.com/_/swift

64bit OSでDocker使ってるんだけど
ダイジェスト指定以外で32bit用のDockerイメージを使う方法ない？

>>805
ダイジェストとは何？

ハッシュと同じ意味じゃろ

>>807
thx

ホノカチャン

>>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として接続したいからネットワーク名で接続し合うのはなんか違う