X

Docker Part3

■ このスレッドは過去ログ倉庫に格納されています
1login:Penguin
垢版 |
2019/03/08(金) 14:40:20.55ID:VDOvuQ0J
LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/
2020/04/14(火) 10:13:41.02ID:Iur9C4SR
>>773-774
スクリプト書けば一発なのにExcelで何とかするのは純粋に時間のムダだけど、
「Dockerの本来の想定からは外れるかもしれないけどあっさり使える」用途があるなら
実際そういう使い方もできるからいいじゃんとしか言えんわな。

何のために作られたとか、
作った奴の思想はこうだから、とかクソどうでもいい。
2020/04/14(火) 10:23:42.97ID:pFN7AsrW
>>775
実際は「そういう使い方出来るからいいじゃん。
それにしてもDockerって使いづらいですねｗ
こんな事したいんですが出来ないんです。」
ってなってるから言ってんだよ
2020/04/14(火) 10:26:29.13ID:Iur9C4SR
>>776
そこは異論ないよ。
俺のそもそものツッコミも筋違いだったわけだし。
2020/04/15(水) 23:40:26.45ID:rCWj0bNr
>>770
> Dockerはdockerコマンドや
> kubenetes使いこなすんじゃなくて、

買った本はまさにそんな感じの本だった。
このコマンドを打つと、コンテナはこういう状態になりまーす、って感じで
Dockerコマンドとは、Dockerとは何ぞや、どういう仕組みなのかって事が中心で
「どうしたら、Dockerって便利だなーってなるんだよ！！」って雰囲気の本だった

目鱗。ありがとうございます。
2020/04/16(木) 00:38:45.06ID:G9bh7zxQ
「前CentOSで組み立てたこのWebサービス環境だけど今度はUbuntuで動かして！」とかいう指示が来た時にdockerで作っていればもしや楽だったのでは…ってなった事はあった
そういう感じじゃないかなぁ的外れだったらごめん
2020/04/16(木) 01:01:20.33ID:R7a4uuMe
インフラ専業の人が仮想化技術の1つとしてdockerを学ぼうとしているのだとしたら、
たぶんそれはあまり意味がないからやめた方がいい
dockerコンテナはアプリケーションのパッケージ化技術だ
アプリケーションにOSを丸ごとバンドルする、いわばスタティックリンクの一種にすぎない
2020/04/16(木) 08:05:13.05ID:G/grTQ/Z
インフラ屋だけどDocker便利。
Zabbixコンテナを複数環境にそれぞれ独立して作ってるんだけど、
VMではメモリ消費の観点で難しかった。
2020/04/16(木) 09:57:27.46ID:LeyxDGKY
開発者がCPUやコンパイラの技術を知っておくべきなのと同じように
インフラ屋がDockerの内部技術を知っておくのは正しいが、
普段の仕事でそれらの技術は使わないんだよ。

知っておくとトラブル解決が素早く出来るが
インフラ屋にとってのdockerを使う普段の仕事は
作られたDockerイメージをただ起動するだけ
YAMLファイルに一行書けば終わるぐらいのもの

インフラ屋の仕事が楽になるのではなく、
インフラ屋の仕事が無くなるのがDockerの便利さなんだから

世にあるDocker本は「Docker入門」ではなく
「Dockerを実現する内部技術詳細」と言ったほうがいいぐらい
それぐらい普段の使い方と入門書の内容はずれている
2020/04/16(木) 10:55:41.94ID:G/grTQ/Z
いや普段の仕事で使ってるけど
2020/04/17(金) 02:14:26.57ID:feyR70XT
用途を決めつけるんじゃなくこれなら便利だって思ったらどんどん活用すればいいんだよな
このスレ見てるとdockerは将来夢のような快適さを提供してくれる
気がする
2020/04/17(金) 03:29:51.72ID:rfDDVJFy
実際には、間違った用途で使っていて、
これDockerでどうやるの？
こんな事したいんですがどうやるの？
Dockerって使いにくいね
って話になるのでうんざり。

間違った用途で使うと、Docker批判につながる
だから、用途が間違ってると、毎回言ってる。
2020/04/17(金) 05:12:01.13ID:HFgnjVHG
読点とか改行の使い方がアレっぽい
2020/04/17(金) 10:42:32.97ID:7oYmIfK7
>>786
そういうとこだぞ
2020/04/17(金) 12:35:48.07ID:wAVEYBej
正しいか間違ってるかってより
向いてるか向いてないかよね
2020/04/17(金) 15:42:36.23ID:7oYmIfK7
インフラ屋はすぐにDockerの中でsshサーバーを動かそうと考える
Dockerはそういう為のものじゃない
2020/04/17(金) 16:25:02.86ID:6ChcEj62
なんかめんどくさい原理主義荒らしが居着いたね
2020/04/17(金) 17:09:13.75ID:CgHYJGLh
wordでドキュメント書くの面倒だから、dockerでasciidocのコンパイラを作って、
イメージファイルと、バッチファイルを配布した。
なかなか便利に使ってる模様。
2020/04/17(金) 17:42:08.77ID:7oYmIfK7
↑このように
本当にやりたいことは「asciidocのコンパイラ」を作りたいだけ
だけど、それを動かすのにライブラリとかが必要だから
Dockerでまとめる。という使い方をするもの
2020/04/18(土) 06:27:01.12ID:NYuD+o6/
CIで使うようなビルド用/テスト用の本当に使い捨てのコンテナは十分にコンテナ仮想化の哲学と目的にマッチしてるけどな
上でも書いたがVSCodeで使えるような開発用コンテナも十分に有用

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

用途が違うこともまぁあるんだろうが, それ以上にコンテナに求めるものが曖昧なのにふわっとした目的で使おうとするからコンテナに柔軟性やら壊れた時に直すやらが必要になるのだと思う
少なくともディスポーザブルな環境としてのコンテナは普通に適応
2020/04/19(日) 15:28:18.26ID:bBijwdm1
MS-DOS時代ならOSもアプリも全部フロッピー一枚だったのにな
2020/04/19(日) 16:07:47.13ID:HPOtbYXu
せやな、Aドライブに起動ディスクを入れて、
Bドライブにシステムディスクを入れるんだよね。
2020/04/19(日) 21:54:50.91ID:lccAXDHW
>>754
Dockerfileのビルド時に--network=host入れたらビルド出来たわ…
2020/04/20(月) 09:24:11.15ID:xAwp4xc2
Docker哲学とかどうでもよすぎてゲロ吐きそう
2020/04/20(月) 10:40:22.88ID:rTh6fQIt
哲学とかどうでもいいがいい加減ステージング用とプロダクション用でそれぞれ別のイメージ作る馬鹿は絶滅してくれないかな
2020/04/20(月) 19:04:55.39ID:24ShHyns
>>798
そんなばかは放置すればOK
もし仕事を一緒にしているのであれば、そのバカを追放するか、その仕事を止めるか。
2020/04/20(月) 19:05:45.45ID:24ShHyns
馬鹿でも何でもいいから、どう使ってもよい。
2020/05/02(土) 15:16:31.37ID:jS8tZPz1
やっとnginx、gunicorn、flaskをdocker化できた…
ファイアウォールが原因で動かないとか…
802login:Penguin
垢版 |
2020/05/19(火) 10:59:17.55ID:QcEp49ar
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の認識がずれてるように見えます。
2020/05/19(火) 11:31:30.17ID:6YCn6s4v
dockerは理解するとめちゃ便利だとわかった。
ただしlinuxカーネル以外で使おうとすると地獄
804login:Penguin
垢版 |
2020/05/28(木) 10:02:35.43ID:zrnY/ArL
ランタイムや開発キットのコンテナって、他のコンテナとはどうやって組み合わせて使うものなの？
具体的には、code-server + Swiftで使ってみたいんだけど・・・・やり方が全くわからん
https://hub.docker.com/r/codercom/code-server
https://hub.docker.com/_/swift
805login:Penguin
垢版 |
2020/06/20(土) 03:18:22.55ID:7t9SyItv
64bit OSでDocker使ってるんだけど
ダイジェスト指定以外で32bit用のDockerイメージを使う方法ない？
2020/06/20(土) 13:51:10.06ID:NT++DOXx
>>805
ダイジェストとは何？
2020/06/20(土) 18:03:39.31ID:9rcVA94u
ハッシュと同じ意味じゃろ
2020/06/20(土) 22:50:35.72ID:NT++DOXx
>>807
thx
2020/06/22(月) 13:13:57.71ID:bXWnnAW9
ホノカチャン
2020/06/26(金) 14:56:31.79ID:VvU/3pfe
>>798
環境変数サポートの追加がめんどくさい時によくやる
環境ごとに設定ファイル書いてCOPYするほうが楽だもの
2020/07/11(土) 01:37:01.10ID:Go0P4sS+
--mountで存在しないボリューム名を指定して実行したらエラーになるらしいのですが
エラーにならずボリュームが作成されてしまいます。
エラーにならないのが正しい動作ですか？

docker run -dit --name test --mount type=volume,source=volume1,target=/tmp
2020/07/17(金) 12:24:46.81ID:BnfFXp5h
最近触り始めたんだがなんでコレ突然RHEL8からハブられてんの？
Kubernetesからも距離置かれはじめてるみたいだし何かあったんか
2020/07/17(金) 12:46:45.68ID:T42yc9xk
podmanの件はredhatのほうが先走って自滅した感じ
運用環境はコンテナ標準を満たす限り、dockerにこだわる必要はないから、運用向けに機能を削ったり追加したりして最適化したほうがいい、これは正しい
でも、運用環境っていったら普通はk8sだから、podmanが使われる機会は滅多にない
一方で、開発環境はpodmanのエコシステムがまだまだ貧弱すぎて、dockerにはぜんぜん追いついてない
docker社もそれを理解してるから、開発環境でのエクスペリエンス向上に投資を集中し始めた
またpodmanのセールスポイントの1つであるrootlessも本家dockerはとっくに実装済
結果として誰もpodmanを使ってない（そしておそらくそのまま消え去ると俺は予想してる）という状況になってしまった
redhatにしては珍しくマヌケな戦略をとったなといった感想
2020/07/19(日) 16:57:39.80ID:678GlVXn
へー、サンクス。posmanとかはopenshiftやるならって感じなのかね
にしても開発で使う分には裏方が何やっててもちゃんと使えさえすれば関係ないしな…
2020/07/19(日) 18:53:58.25ID:BA4HywGd
PODMANのメリットはデーモンレスってことだけ?
赤帽がなにを目指してるのか正直よくわからない
だけど赤帽のやることだから何かがあるんだろうな
2020/07/19(日) 20:12:48.88ID:Rhy9uZzR
dockerコマンドだけ使う分にはpodmanにエイリアス設定されてるしあんまり意識しない
問題はdocker-composeを使いたいときだなぁ(podman-composeの互換性が大変怪しい)

まぁmicrok8s使っちゃうからdocker-compose使うこと自体減ってるけど
2020/07/19(日) 22:23:14.66ID:D3aNO6tv
docker-composeのメリットがさっぱりわからない
こんなのつかっても結局Dockerfile作らないといけないし意味がない
2020/07/19(日) 23:30:36.97ID:CHBleA4c
Dockerfileはアプリケーションのソース
docker composeはビルドしたアプリケーションをどうデプロイするかを定めたマニフェスト
全く役割が異なるのでどちらかがもう一方の代替になることはない
819login:Penguin
垢版 |
2020/07/20(月) 06:54:27.74ID:fDSiPKdP
docker-composeと比べるのはDockerfileじゃなくてdockerコマンドだよ
DockerfileあったってDockerコマンドは使うだろ？

コンテナ一つだけならDockerコマンドを直接使っても苦労はないが
複数のコンテナを使う時Dockerコマンドを何度も実行して起動するのは大変
Dockerコマンドが面倒になったらdocker-composeを使うんだよ
2020/07/20(月) 14:45:46.51ID:sHuZrd7b
Dockerfileを書かなくてもいいものだと思ってた
勉強になりました
2020/07/20(月) 20:25:51.65ID:2mNwS2JU
書かなくてもいいけど、なにやったか忘れる。
2020/07/20(月) 20:33:40.26ID:ZBQhEHfA
そのまんま手順書になるのがいいとこでは
2020/07/20(月) 21:06:57.55ID:61CQ31O+
docker execは邪道なのかな
824login:Penguin
垢版 |
2020/07/20(月) 21:25:56.42ID:ONUA68Eb
docker execはデバッグ機能
2020/07/20(月) 22:35:22.68ID:2mNwS2JU
docker exec して、動かしながら、Dockerfileを書く。
最後にdocker buildして同じものが出来上がって完成。
って感じじゃない？
2020/07/20(月) 23:19:19.40ID:fTvFRbnb
うちは運用ジョブをdocker execで流してます
docker execを使わない場合、運用ジョブ専用のAPIやWebAppを整備するんでしょうか?
2020/07/20(月) 23:20:30.91ID:sHuZrd7b
データベースをホストにマウントするのとボリュームで管理するのはどっちがいいんでしょうか？
2020/07/21(火) 08:33:15.29ID:nXYHdseE
>>825
そんなことめったにしないなぁ。docker buildはキャッシュが効くんで
（キャッシュが効くように）Dockerfileに追記しながらDockerfileを書く
終わったらDockerfileをシンプルにしたりサイズが膨れ上がらないように調整するって感じ
docker execなんかして作業したら、その作業結果をファイルに保存するの二度手間じゃん
2020/07/21(火) 08:34:31.90ID:nXYHdseE
>>826
そういうのはdocker runやるのが普通
最初docker execなんてなかったんだよ
それなのにそういう用途にも使えたわけ
2020/07/21(火) 08:36:51.02ID:nXYHdseE
>>827
どちらもボリューム。データの保存先のパスが違うだけって知ってる？
Dockerサーバー上の特定のパスに保存するか
Dockerが用意したパスを使うかの違い
2020/07/21(火) 09:34:41.28ID:+NBX9hi+
ホストマウントはホスト環境への明示的な依存なので、どうしても必要でなければ避けてvolumeを使うべき
volumeも内部的にはホスト環境に依存してるといえばそうだけど、抽象化・隠蔽されているのでホストマウントよりBETTER
実例として、Docker for Windowsでのパーミッション、リモートエンドポイントへのコマンド実行、などでvolumeを使用していれば避けられたトラブルが結構あった
2020/07/21(火) 10:07:02.11ID:nXYHdseE
つまりはいろんな種類のホスト、例えばWindowsやMacでも使いたいなら
Docker上のボリュームを使えってことだな。

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

だが相対パスを使えばいいだけじゃないか？
2020/07/21(火) 10:23:04.25ID:iuc4a5Mi
相対パスでマウントできたっけ
2020/07/21(火) 11:16:17.36ID:ZxJULecG
相対パスを変換するだけやろ
2020/07/21(火) 11:16:50.09ID:ZxJULecG
docker-composeはそれを自動でやってくれる
2020/07/21(火) 11:18:02.84ID:ZxJULecG
そもそもDockerのクライアントがどんなOSかなんて関係ない
Dockerはサーバーで動くし、DockerはLinuxでしか動かない
2020/07/21(火) 11:43:13.56ID:+NBX9hi+
>>832
その相対パスが存在するか、適切なパーミッションを持っているか、といった条件はホストへの依存性となる
基本的にホストへの依存性が少ないほどトラブルは減る
2020/07/21(火) 11:54:51.20ID:+NBX9hi+
>>829
docker runで全てが解決するならdocker execは存在しない
docker runはコンテナ外部で解決可能なジョブの実行に適している
docker execはコンテナ内部で行う必要があるジョブのために存在する
2020/07/21(火) 17:20:28.68ID:rF6lL3p5
問題は Windows と Mac でボリュームを使うとファイルシステムの変換が起こるのでとても遅いということですね
2020/07/21(火) 17:24:19.41ID:cvaypvgc
>>838
だからdocker execは主にデバッグ用だって
通常の運用時には使わないもの

コンテナ外部で解決可能とか何のことを言ってるんだかさっぱりわからん
docker runとdocker execで実行できることは全く同じ
違いはdocker runはメインの処理を行うもので、
docker execはメインの処理を行ってる最中に乗り込んでデバッグするもの
2020/07/21(火) 17:32:03.04ID:iuc4a5Mi
runで常時起動してるコンテナに
例えばcronからexecでジョブ実行してもいいと思うがな
2020/07/21(火) 19:56:43.47ID:1Ck3nt75
kubectl exec 経由なら、管理用のコンソールが欲しいときにわりと使ってる
2020/07/21(火) 20:04:49.86ID:5ttvOiMf
>>840
全く違うよ
運用ジョブには大まかに分けてリモート実行可能なものとローカル実行のみ可能なものに分類できる

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

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
具体例はGitlabのバックアップ(gitlab rake)コマンドなど
ローカルで実行される前提のコマンドはdocker execで実行するしかない
2020/07/22(水) 00:03:46.48ID:2kFCswWG
Dropboxにバックアップするのが楽だからホストのボリュームがいいと思ってたけど
Dockerのなかでボリューム作ったほうがはまらないってことですね
勉強になりました
2020/07/22(水) 06:37:22.77ID:DmDy0NhW
>>843
なんか使い方がおかしいな
まさかDockerコンテナの中に永続的な情報を入れてるんじゃないだろうか？
永続的な情報はボリュームに入れるんだぞ
2020/07/22(水) 06:39:34.85ID:DmDy0NhW
>>843
> ローカルで実行される前提のコマンドはdocker execで実行するしかない
何度読んでも全く理解できん
なんでだよ

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
ローカル実行の可能なジョブはコンテナの外で解決できない
と話をループさせてるだけで全く説明してないよ
2020/07/22(水) 08:51:30.32ID:4XcuGSJO
>>845
例として運用ジョブとしてポピュラーなバックアップを挙げたが、今の話題と永続化は別の問題だ
2020/07/22(水) 09:22:02.54ID:4XcuGSJO
>>846
わからないなら、わかるまでよく考えるしかない、としか言えないな
2020/07/22(水) 09:35:40.02ID:ILpdMsPa
では無いということで決着
2020/07/22(水) 09:56:11.99ID:8t2ogVS3
イメージ開発者など実際に運用までしない人には確かに要らない機能だと思う
2020/07/22(水) 12:32:30.91ID:0mhEikFA
イメージ開発してる人は自分でイメージつくからね
今あるイメージでなんとかしなきゃで
バッドノウハウ溜め込む運用とは考え方が違う
2020/07/22(水) 13:10:29.72ID:TaKEPsBL
で、工数がかさんで、メンテナンス範囲が広がる、と
既存のツールセットをうまく使う、ということもできないと後々つらくなる
2020/07/22(水) 13:17:10.14ID:TaKEPsBL
execでコマンドうちゃいいだけなのに、わざわざ工数をかけてメ対象を増やして、アタックサーフェスを広げて、何がしたいのかね一体
2020/07/22(水) 16:09:20.10ID:hHBoQuqj
>>853
よりシンプルになる
2020/07/22(水) 17:21:04.37ID:TaKEPsBL
>>854
execのがシンプルですけど
2020/07/24(金) 11:28:30.42ID:9ctQO3NL
ボリュームも好きなように使えばよかです。
2020/07/24(金) 16:08:44.19ID:PGdrq6O1
データベースはdockerの中にボリュームつくって
htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

メリットとデメリットはよく分かりません
2020/07/24(金) 18:36:20.59ID:wNiJOAd7
せっかくDockerのおかげでリリースが簡単になったのに、
ホストに静的コンテンツをリリースするんじゃ元と変わらない、
どころか静的コンテンツとコンテナでリリースの手間が余計に増えてしまう

静的コンテンツはVOLUMEを使わないでイメージに固めてしまうのが簡単
2020/07/24(金) 18:44:01.00ID:KgUsH74f
>>857
> データベースはdockerの中にボリュームつくって
> htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

どちらでも作るDockerイメージは同じ
2020/07/26(日) 11:46:33.02ID:ZKCP3mGq
ホストからボリュームのマウントってできるんですか？
ホストとDockerか同時に参照して読み書き
2020/07/26(日) 11:53:37.27ID:zOThrt4A
>>860
それが指定したディレクトリをボリューム化して使う方法だろ
2020/07/26(日) 12:41:37.77ID:KbVs3Pw7
-v $PWD/:/home
とか？
2020/07/26(日) 14:27:05.43ID:LYKyG3mp
-vって非推奨じゃないっけ
2020/07/26(日) 19:10:43.31ID:xwiBJJgr
そんなわけねーだろあほか
2020/07/26(日) 23:10:22.02ID:YmgaEoJ6
>.>843が理解できない人が理解できない。。
docker execがデバッグ用に使うものって・・・なにそれｗ
2020/07/27(月) 15:39:45.25ID:16MZ7SLt
-vが非推奨じゃなくて--mountが推奨されてるだけか
ってことは今後-vが非推奨になることもありえるな
2020/07/27(月) 16:17:45.47ID:CekD5d56
ない
2020/07/27(月) 21:43:15.69ID:16MZ7SLt
https://docs.docker.com/storage/bind-mounts/#choose-the--v-or---mount-flag

でも書いてあるね
2020/07/28(火) 09:06:50.60ID:Eo000t12
まあブイって分かりにくいしなボリュームなんだろうけど
2020/07/28(火) 14:33:12.71ID:neJtwKTj
/htdocs/public_html/wordpress
/htdocs/public_html/joomla

サイトの中で複数のCMSを動かしてるのですがこの場合
コンテナはapacheなどのwebサーバを起動して
entrypointでwordpressとjoomlaをgit cloneするのが良いでしょうか？
2020/07/28(火) 14:54:37.04ID:m4hPL3wS
>>870
まず最初に何のためにDockerを使うのか
目的をいえ
2020/07/28(火) 17:25:06.85ID:66gKFktJ
流行だから
2020/07/28(火) 19:53:47.19ID:0ejo3GGx
wordpressとjoomiaをpullするのがいいと思うよ。
2020/07/28(火) 22:42:13.49ID:nHx7byYs
どういう問題を解決したいのかを理解してないで
Docker使おうとするからわからんのだ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況