[過去ﾛｸﾞ] Docker Part5 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
215: 2021/01/13(水)20:18 AAS
>>213
>>214
なるほやってみる?
216(3): 2021/01/14(木)23:12 ID:Pm6qmODH(1) AAS
>>1
>Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けて
具体的に言うと？
217: 2021/01/15(金)08:17 ID:qYm5MEeF(1) AAS
hypervisord最強おじさんktkr
218: 2021/01/15(金)08:27 ID:IT9cRebK(1/6) AAS
super...
219: 2021/01/15(金)08:28 ID:TKANrLkr(1/21) AAS
>>216
困難は特にないよ
220: 2021/01/15(金)08:30 ID:KcZzwMNW(1) AAS
具体性0
221: 2021/01/15(金)08:32 ID:42ZtZd/z(1/2) AAS
面倒なだけで問題はないよね。
面倒という指標だとk8sは更に最初が面倒なわけで
222: 2021/01/15(金)08:37 ID:TKANrLkr(2/21) AAS
dockerわかってないのにわかった風のおじさんが、僕には困難です、と書いただけだから気にせんでええ
次スレまでいったら、テンプレから削除していいよ
223: 2021/01/15(金)08:41 ID:0MH2boun(1) AAS
説明になってない
224: 2021/01/15(金)08:55 ID:ouI6ZQHD(1/5) AAS
>>216
複数のサービスを起動する場合、systemdが一般に使われるが
systemdを使うのは大変
外部ﾘﾝｸ:stackoverflow.com
可能な限り、コンテナ内のsystemdは避けることをお勧めします。
Systemdは、ファイルシステムをマウントし、いくつかのカーネルパラメータを制御し、
プロセス出力をキャプチャするための独自の内部システムを持ち、システムスワップスペースを構成し、
巨大なページとPOSIXメッセージキューを構成し、プロセス間メッセージバスを開始し、
端末ごとのログインプロンプトを開始し、システムサービスのスワス。
これらの多くは、Dockerがあなたのために行うことです。
その他は、Dockerがデフォルトで防止するシステムレベルのコントロールです（正当な理由があります）。
通常、コンテナに1つのことを実行させたい場合があります。これには、複数の調整プロセスが必要になる場合がありますが、
通常、systemdがプロセスマネージャーを提供する以外のことを実行したくない場合があります。
systemdは非常に多くのホストレベルのパラメーターを変更するため--privileged、
Dockerの分離を破るような実行が必要になることがよくありますが、これは通常は悪い考えです。
質問で言うように、通常、コンテナーごとに1つの「ピース」を実行するのが最適と見なされます。
これができない場合は、DockerとUnixの両方の哲学において、
initプロセスに必要な最小限の処理を実行するsupervisordのような軽量プロセスマネージャーの方が適しています。
225: 2021/01/15(金)09:02 ID:ouI6ZQHD(2/5) AAS
>>216
これとか読むといいかも。公式がVMじゃないと言ってる。
Containers are not VMs
外部ﾘﾝｸ:www.docker.com
> しかし、これを言っても、VMに関する現在の考えやプロセスを適応させ、
> コンテナーに適用しようとしています。
>
> 「コンテナをバックアップするにはどうすればよいですか？」
> 「実行中のコンテナのパッチ管理戦略は何ですか？」
> 「アプリケーションサーバーはどこで実行されますか？」
>
> 私にとって、Dockerは仮想化テクノロジーではなく、アプリケーション配信テクノロジーで
> あることに気付いたとき、電球の瞬間が訪れました。
これとかも
So, You’re Saying Docker Isn’t A Virtual Machine???
外部ﾘﾝｸ:derickbailey.com
A Docker container is not a virtual machine.
A Docker container is application virtualization.
226(1): 2021/01/15(金)09:06 ID:ouI6ZQHD(3/5) AAS
複数のサービスを実行することは可能だが、推奨しないと書いてある。
そしてこの記事に書いてある複数のサービスを実行する方法を見ればわかるように
仮想マシンのように気軽にはできずコードを書く必要がある
Run multiple services in a container
外部ﾘﾝｸ:docs.docker.com
コンテナの主な実行プロセスは、ENTRYPOINTおよび/またはCMDの最後ですDockerfile。
一般に、コンテナごとに1つのサービスを使用して、関心のある領域を分離することをお勧めします。
そのサービスは複数のプロセスに分岐する可能性があります（たとえば、Apache Webサーバーが
複数のワーカープロセスを開始します）。複数のプロセスがあっても問題ありませんが、
Dockerを最大限に活用するには、1つのコンテナーがアプリケーション全体の複数の
側面を担当することを避けてください。ユーザー定義のネットワークと共有ボリュームを使用して、
複数のコンテナーを接続できます。
227: 2021/01/15(金)09:06 ID:42ZtZd/z(2/2) AAS
そもそもコンテナを仮想マシンの代替として使うケースはほぼないだろ。
1に書くような話ではないな
228: 2021/01/15(金)09:09 ID:ouI6ZQHD(4/5) AAS
> Handling such processes this way is superior to using a full-fledged
> init process such as sysvinit, upstart, or systemd to handle process lifecycle within your container.
sysvinit, upstart, or systemd を使うよりも
自分でコンテナのメインプロセスを作ったほうがいい
229: 2021/01/15(金)09:27 ID:IT9cRebK(2/6) AAS
たとえばnginxとphp-fpmを別コンテナにする気もないから自作シェルエントリポイントにしてる
俺はやらないがsupervisordで制御してもいいだろう
systemdまで入れるならlxcかkvmにするけど
230: 2021/01/15(金)09:41 ID:ouI6ZQHD(5/5) AAS
つまりは仮想マシンであれば標準でsystemdなどが起動してるから
サービスを起動させるにはパッケージインストールして
ちょっと設定ファイルを書き換える程度の簡単な作業だが
Dockerでやる場合、systemdなどを使わずに
自分でスクリプト書いて起動と停止を制御しなきゃいかんのよ（Docker推奨の方法）
頑張ればsystemdを動かすことも出来るが、そのために --privileged オプションが
必要になるかもしれないし、その他の調整が必要になるかもしれない
何が必要かは起動するサービスによって違うので試行錯誤が必要になる
だからDockerはsystemdを使わずに自作スクリプトで制御することを推奨してる
systemdを使うぐらいならより軽量のsupervisordを使うほうがいい
もちろんパッケージインストールして終わりではなく
自分で設定ファイルを書く必要がある
231: 2021/01/15(金)11:19 ID:TKANrLkr(3/21) AAS
😫マルチプロセスコンテナ否定派
・1つのサービスのために多数のコンテナイメージをリリース
・イメージ使用者に面倒くさいymlを書かせる
🤗マルチプロセスコンテナ肯定派
・1つのサービスのために1つのコンテナイメージをリリース
・Supervisor等の設定を開発側が書いて出荷するのでイメージ使用者はdocker runするだけ
232: 2021/01/15(金)11:30 ID:S7oMpLHl(1) AAS
じゃあちゃんと責任持って管理してね🤗
233(1): 2021/01/15(金)11:40 ID:u8cDb4A3(1) AAS
仮想マシンみたいなことしたかったらLXCでよくね？
しらんけど
234(1): 2021/01/15(金)11:42 ID:dw4hxnTe(1/10) AAS
・イメージ使用者に面倒くさいymlを書かせる
別に良くね？
235: 2021/01/15(金)11:43 ID:TKANrLkr(4/21) AAS
>>233
仮想マシンみたいなことがしたいならシステムコンテナでいいと思うよ
単にマルチプロセスってだけならアプリケーションコンテナのほうがいい
236: 2021/01/15(金)11:46 ID:IT9cRebK(3/6) AAS
「プロセス」「サービス」を意図的に混同して相手を貶める
237: 2021/01/15(金)11:47 ID:TKANrLkr(5/21) AAS
>>234
良くない
負担を減らせるなら減らしたほうがいい
ホスピタリティの精神だよ
セルフサービスで全部やってねなんてのは二流だ
もちろん分散型のイメージを提供するなと言ってるわけじゃない
分散型をオプションとしてサポートするのも良い事だ
238(1): 2021/01/15(金)11:50 ID:dw4hxnTe(2/10) AAS
マルチプロセス派は配布して終わり！じゃなくてその後の運用まで考えてるのか？
239(1): 2021/01/15(金)11:52 ID:TKANrLkr(6/21) AAS
>>238
運用もシングルコンテナのほうが簡単でしょ
240(1): 2021/01/15(金)12:03 ID:dw4hxnTe(3/10) AAS
>>239
なんで？
241: 2021/01/15(金)12:06 ID:TKANrLkr(7/21) AAS
>>240
1つの物管理するのと多数の物を管理するのじゃ前者のほうがかんたんだ
常識的に考えればいい
242(1): 2021/01/15(金)12:23 ID:dw4hxnTe(4/10) AAS
複数サービスのログ管理はどうする？
まさかファイル出力にしてlogrotatedとかも突っ込むの？
それかコンテナ自体のログを複数のサービスからのログが流れてる状態にするの？
ログ管理のSaaSへログの集約がしたくなったらどうする？
エージェントもコンテナに突っ込むのか？
複数コンテナで
ログは全部コンテナのログにしておけば
dockerのログだけローテーションすれば済むじゃん
ロギングドライバ変えたり
ログ転送のエージェントは別コンテナにしたりできる
243(1): 2021/01/15(金)12:38 ID:uuEHso6B(1/4) AAS
個別に更新するのだから、バラバラの方が管理しやすい。負荷分散も容易。
一箇所にまとめるのは滅多に変えない時だけね。
244(1): 2021/01/15(金)12:39 ID:IT9cRebK(4/6) AAS
そんなもんそれぞれのプロセスがstderrに流すだけ
あとはホスト側でどうにでも
245(2): 2021/01/15(金)12:41 ID:uuEHso6B(2/4) AAS
纏めた方が楽という人は、k8sのメリット関連の文献を読んだほうが良い。基本的に個人でも同じ。
依存関係が原因のレガシー化を防ぐには、細かく分けて疎結合というのがマイクロサービスの基本。
246(1): 2021/01/15(金)12:45 ID:dw4hxnTe(5/10) AAS
supervisord管理下のプロセスの死活監視やリソース使用の監視はどうするんだ？
同じイメージに監視ツールのエージェント突っ込むのか？
もうめちゃめちゃ複雑だし、イメージに汎用性がない
複数アプリがあったら全部これやれってアプデも対応しろって言うの？面倒過ぎ
普通にマルチコンテナで動いてたら
Dockerコンテナが動いてるかどうかや、コンテナのCPU、メモリ使用量などの監視で済む
監視ツール変えたくなってもアプリのイメージをいじる必要がない
アプリ固有のメトリクスを記録監視するならアプリイメージに対応必要だが、
これらの基本的なメトリクスを取りたいだけなら対応不要
247(1): 2021/01/15(金)12:53 ID:dw4hxnTe(6/10) AAS
>>244
ホスト側！？
結局分けるんじゃん
じゃあsupervisordもやめたら良くね？
248: 2021/01/15(金)12:57 ID:TKANrLkr(8/21) AAS
>>242
コンテナのログとして出せばいいだけ
249: 2021/01/15(金)12:57 ID:TKANrLkr(9/21) AAS
>>243
実は他者製のクラスタを個別に更新することは少ない
250: 2021/01/15(金)13:00 ID:TKANrLkr(10/21) AAS
>>245
k8sは大規模すぎるので導入障壁が大きい
1コンテナシステムは小規模から手軽に開始できる
251(2): 2021/01/15(金)13:01 ID:TKANrLkr(11/21) AAS
>>245
なんでもかんでもバラす必要性はない
Spotifyの事例にもあるようにミクロサービスからモジュラーモノリスに回帰した大規模サービスもある
252(1): 2021/01/15(金)13:03 ID:TKANrLkr(12/21) AAS
>>246
昔からやってる事をやるだけ
開発側にばノウハウが大量にあるのでなにも苦にならない
重要なことは利用者側が楽になること
253(1): 2021/01/15(金)13:05 ID:uuEHso6B(3/4) AAS
弊社の勤怠管理システムはIE限定です！
一箇所にまとめるとこうになる。
まあ、慣れてるからそれが良いという人はご自由にどうぞかな
254(1): 2021/01/15(金)13:05 ID:dw4hxnTe(7/10) AAS
>>252
>開発側にばノウハウが大量にあるのでなにも苦にならない
よくわかんない
255(1): 2021/01/15(金)13:05 ID:TKANrLkr(13/21) AAS
>>253
意味不明な論点ずらし乙
256: 2021/01/15(金)13:06 ID:TKANrLkr(14/21) AAS
>>254
わかる
257: 2021/01/15(金)13:06 ID:TKANrLkr(15/21) AAS
仕事に戻るからまた後でな
258: 2021/01/15(金)13:16 ID:dw4hxnTe(8/10) AAS
>>251
Spotifyにsupervisord最強おじさんはいない
259: 2021/01/15(金)13:19 ID:IT9cRebK(5/6) AAS
>>247
supervisord使うなんて一言も言ってないけど
コンテナ別にログ分けるのはホスト側のrsyslogdで十分
260: 2021/01/15(金)13:27 ID:uuEHso6B(4/4) AAS
>>255
まとめるとレガシー化しやすいってこと。
261(1): 2021/01/15(金)13:38 ID:dw4hxnTe(9/10) AAS
1コンテナマルチプロセスにしろってsupervisordにしろってことだろ
そんな事やったらサービス単位で更新できないし、
supervisordの面倒見るのもいやだな
Docker自体がある意味supervisordみたいな物だから
supervisord in supervisordするって事じゃん？
262(1): 2021/01/15(金)14:24 ID:IT9cRebK(6/6) AAS
「プロセス」「サービス」を意図的に混同して話をややこしくする
nginxとphp-fpmを別コンテナにするメリットがあるのかね
263(1): 2021/01/15(金)16:05 ID:cz1NjHRF(1) AAS
>>251
Shopifyじゃなくて？
264: 2021/01/15(金)16:09 ID:6mixkv7d(1/2) AAS
>>262
まあマルチプロセスなベースイメージをそうと知らないまま使っている阿呆も中にはいるだろうね
265(1): 2021/01/15(金)16:11 ID:NRANT14o(1) AAS
バカには疎結合なんか、分からんから、ほっとけほっとけって
266: 2021/01/15(金)16:25 ID:TKANrLkr(16/21) AAS
>>261
オーケストレーションの手間暇を利用者側に押し付けるか、開発側でやってあげるかの違い
小規模のスタートアップなら全部開発側に丸投げしてdocker runするだけのほうがかんたんだ
267: 2021/01/15(金)16:28 ID:TKANrLkr(17/21) AAS
>>265
疎結合と一言で言っても色々ある
ミクロサービスは疎結合の代表だが
別にミクロサービスじゃなきゃ疎結合できないわけじゃない
さっきも言ったように
サービスとしてはモノリスでもコードレベルで高度にモジュール化することで疎結合を達成するモジュラーモノリスのような考え方もある
コンテナは1つでも内部のサービスが疎結合ならなんの問題もないのだ
268: 2021/01/15(金)16:29 ID:TKANrLkr(18/21) AAS
>>263
そうだっけ？正確にはググって
269: 2021/01/15(金)16:35 ID:TKANrLkr(19/21) AAS
で、この1コンテナ、マルチプロセス(サービス)で成功してる代表的なコンテナがGitLabね
薄っぺらい表面的な知識しかない連中と違って、流石にGitLabのエンジニア達は深く理解してる
杓子定規にコンテナを分ける必要はない、背景が不明な不特定多数に配布するなら、むしろバンドルしたほうがいい、と理解してる
270: 2021/01/15(金)16:40 ID:6mixkv7d(2/2) AAS
GitLabはセルフホスティング対応が大前提だからそうなってるんだよ
シングルインスタンスなSaaSとは別次元の話
271: 2021/01/15(金)16:59 ID:TKANrLkr(20/21) AAS
つまり利用者側からは1コンテナのほうがいいってことだ
272: 2021/01/15(金)17:41 ID:TKANrLkr(21/21) AAS
基本は1コンテナなんだよ
ちゃんと利用者のことを考えてるならな
で厳しい要件満たすために、分散管理したい連中のために、いちおうバラ売りコンテナも用意しとく
それがベストプラクティス
さいしょっから分散管理のみサポートします、なあんて、怠惰もいいとこだ
273: 2021/01/15(金)18:55 ID:dw4hxnTe(10/10) AAS
それはご苦労なこった
俺は怠惰だからメインのコンテナ以外はありあわせのイメージ使うぜ
274: 2021/01/15(金)19:21 ID:F2PkWUyM(1) AAS
自社以外に誰も求めてないマイナーサービスは最初からバラ売りでもいい
275: 2021/01/16(土)12:37 ID:iVfNA5oL(1/8) AAS
複数のサービスを一つのコンテナにまとめたほうがいいって言ってるやつは
複数のサービスが一つのコンテナになってるから
"使うのが楽"って言ってるんだよ。
作るのが大変の否定になってない
>>1は作るのが大変と言っている
> Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
Dockerを使ってると言いつつ、自分でDockerfileもyamlも書かずに
ただ誰かが作ったものを使うだけのやつは、Dockerを使ってるとは言えない
んで、使ってるだけのやつが、使うのが楽と言ってる
複数のサービスを一つのコンテナに入れるのがどれだけ大変かわかってない
だって自分で作ってないんだもの
276(1): 2021/01/16(土)12:50 ID:TRxochm9(1/6) AAS
いやいや、作るのもめちゃくちゃ簡単だぞ？
Supervisorとか使うだけ
Dockerfileも既存のchefなんかが、殆どそのまま使える
277(2): 2021/01/16(土)13:00 ID:TRxochm9(2/6) AAS
コンテナを分けないことで、お互いのサービスの提供するコマンドラインツールを使いやすくなるのも、便利だな
ある古いサービスAの、管理者用のコマンドラインがあるんだが、、、
これはサービスAをインストールしたマシンで、ローカル実行する必要があった
もちろん、RPCなどという気の利いたものは、ない
開発者からすると、SSHがあればいいでしょ？みたいな気持ちだったんだろうな
そして、サービスBからこのコマンドラインを実行したい、と、なったわけだ
もし、サービスAとサービスBのコンテナを、分けてしまったら
サービスBから、このコマンドラインを実行するのは、普通の方法では、不可能だ
docker.sockをマウントして、サービスBコンテナからdocker execするか、、、
サービスAを拡張してRPAを追加しなきゃならない
あるいは、サービスAを、マルチサービス、にして、SSHを追加するか、、、
1コンテナだったら簡単なのに！
278: 2021/01/16(土)13:05 ID:d+XwEvch(1/2) AAS
オンプレの延長だな
279: 2021/01/16(土)13:07 ID:5ICFXjQI(1/9) AAS
データベースは既存のサーバーが使えたほうが便利と思うけど
AWSのRDSとか使わせろ
280(1): 2021/01/16(土)13:09 ID:iVfNA5oL(2/8) AAS
>>276
> いやいや、作るのもめちゃくちゃ簡単だぞ？
> Supervisorとか使うだけ
使うだけじゃなくて設定ファイルとか書かないと駄目だろ
ログをどうするかとかさ、永続的なファイルをどうするかとかさ
281(1): 2021/01/16(土)13:10 ID:iVfNA5oL(3/8) AAS
> Dockerfileも既存のchefなんかが、殆どそのまま使える
chefを使うってアホじゃないか
Docker使う意味がなくなってる
282: 2021/01/16(土)13:10 ID:TRxochm9(3/6) AAS
このように、1サービス1コンテナの精神で細かく分離すると
サービス同士が疎結合になり、一見すると良いように思える
しかし、疎結合である、ということは、サービス間の連携のオーバーヘッドが増える、ということだ
サービスはRPCを実装しなければならず、開発者は疲弊する
サービスメッシュの管理コストは増大し、運用者は疲弊する
これはミクロサービスの功罪と同じことだが、なんでもかんでも、小さく分けて、疎にするのが、常に正解なわけじゃない
全てはトレードオフなのだ！
たしか、マーティンファウラーだったと思うが
彼曰く、最初からミクロサービス的な思想に傾倒した案件は、失敗することが多い、らしい
最初はモノリスのほうが、うまく行くのだ
システムが、モノリスでは到底手に負えないほど、巨大化してから初めて、分割することを考えれば、よろしい
283(1): 2021/01/16(土)13:11 ID:TRxochm9(4/6) AAS
>>280
そんなことも出来ないの？
284(1): 2021/01/16(土)13:12 ID:iVfNA5oL(4/8) AAS
>>277
それ、仮想マシン使えって話なんだ
285(1): 2021/01/16(土)13:12 ID:iVfNA5oL(5/8) AAS
>>283
作るのが大変だって話をしてる
出来るできないの話ではない
286(1): 2021/01/16(土)13:12 ID:TRxochm9(5/6) AAS
>>281
あるぞ
GitLab公式コンテナはChefで動いてる
287(1): 2021/01/16(土)13:13 ID:TRxochm9(6/6) AAS
>>285
大変じゃないけど？
288(2): 2021/01/16(土)13:15 ID:iVfNA5oL(6/8) AAS
まあここを読めって話だな
Supervisor と Docker を使う
外部ﾘﾝｸ[html]:docs.docker.jp
289(1): 2021/01/16(土)13:16 ID:iVfNA5oL(7/8) AAS
>>287
apt-getでインストールするだけ vs 設定ファイルを自分で書く
290(1): 2021/01/16(土)13:16 ID:iVfNA5oL(8/8) AAS
>>286
> GitLab公式コンテナはChefで動いてる
それを同じことをお前が作るのは大変だって話をしてる
291: 2021/01/16(土)13:18 ID:7o928iA8(1/7) AAS
>>284
仮想マシンは重いからやだ
292: 2021/01/16(土)13:18 ID:7o928iA8(2/7) AAS
>>289
どっちも大変じゃないけど？
293(1): 2021/01/16(土)13:19 ID:5ICFXjQI(2/9) AAS
supervisordの方が面倒くさい
docker-composeの方が楽
294: 2021/01/16(土)13:19 ID:7o928iA8(3/7) AAS
>>290
大変じゃないけど？
もちろんGitLabほどの製品を作るのは無理だろうけどChefでコンテナを作るのは誰だってできる
295: 2021/01/16(土)13:20 ID:7o928iA8(4/7) AAS
>>293
そりゃ、手間を利用者側に、オシツケテル、からでしょ
296(2): 2021/01/16(土)13:25 ID:5ICFXjQI(3/9) AAS
docker-compose psしたらsupervisordが生きてたらupと表示されるが
設定にミスがあった場合や問題が起きた場合もsupervisordさえ生きてたらupと出る
判定するにはログやsupervisordのあるコンテナ内でコマンド実行が必要
どこが優しいねん
297: 2021/01/16(土)13:32 ID:5ICFXjQI(4/9) AAS
>>288
A container’s main running process is the ENTRYPOINT and/or CMD at the end of the Dockerfile.
It is generally recommended that you separate areas of concern by using one service per container.
That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.
You can connect multiple containers using user-defined networks and shared volumes.
外部ﾘﾝｸ:docs.docker.com
298(1): 2021/01/16(土)13:33 ID:7o928iA8(5/7) AAS
>>296
ミスがある前提なら何やっても駄目だろ
ひでー詭弁だな
299: 2021/01/16(土)13:33 ID:5ICFXjQI(5/9) AAS
avoid one container being responsible for multiple aspects of your overall application.
avoid one container being responsible for multiple aspects of your overall application.
300(1): 2021/01/16(土)13:34 ID:5ICFXjQI(6/9) AAS
>>298
開発や運用でトラブルが一切無いと考える方が頭おかしい
301(1): 2021/01/16(土)13:36 ID:5ICFXjQI(7/9) AAS
dockerやdocker-composeだけでsupervisordのやってる事と同じ事が出来る
余計なコンポーネントを増やすな
302: 2021/01/16(土)13:39 ID:7o928iA8(6/7) AAS
>>300
なら1コンテナ1プロセスでも間違いは起こるなー
303(1): 2021/01/16(土)13:39 ID:7o928iA8(7/7) AAS
>>301
aupervisorだけでdockercomposeがやるようなことはできる
余計なコンポーネントを増やすな
304(1): 2021/01/16(土)13:42 ID:5ICFXjQI(8/9) AAS
>>303
supervisordあったらdocker要らなくね？
305(2): 2021/01/16(土)13:47 ID:5ICFXjQI(9/9) AAS
既存のデータベース使うとかは考えないの？
データベースの入ってないDockerイメージと
入ってるイメージ2種類作るのか？
それか起動時のスクリプトにフラグ追加？
だったら最初から分けとけよ
めんどくさい
306(1): 2021/01/16(土)14:03 ID:Q9Gxtc5G(1/10) AAS
>>304
要る
svに限らず、全ての依存関係を、imageにパッケージングする機能
インスコした物を、キレイサッパリ、廃棄する機能
お手軽サンドボックス
ありがとう、docker！
307(1): 2021/01/16(土)14:05 ID:Q9Gxtc5G(2/10) AAS
>>305
お前さー、少しはレス読みなよ
分散用に、分けたコンテナをオプションで配布する、ことまではヒテイしとらんだろ
言うなれば、マルチサービスコンテナファーストだよ
シングルサービスコンテナはオプションだ
308(1): 2021/01/16(土)14:05 ID:kbdLhinp(1/9) AAS
>>306
LXCか仮想マシンに直接インスコでよくね？
docker使うならsupervisord使わなくても
docker-composeのyml配れば良いじゃん
何も問題ない
309(1): 2021/01/16(土)14:07 ID:kbdLhinp(2/9) AAS
>>307
くそデカイメージと小さいイメージ2種類用意するのが面倒
docker-composeなら簡単にかけて
小さいイメージ1種類で済む
310(1): 2021/01/16(土)14:08 ID:Q9Gxtc5G(3/10) AAS
>>305
それとな、内部DBと外部DBを選択できるコンテナは、わりとよくある
スタンドアロンだとsqlite、そうじゃないとpostgres、mysqlのどっちか
てなわけよ
スタンドアロンファースト
(・∀・)ｲｲﾈ!!
311(1): 2021/01/16(土)14:12 ID:Q9Gxtc5G(4/10) AAS
>>309
小ささにこだわって、オーケストレーションマニフェスト書かせたり、運用の手間を増やすな
カリッカリにチューニングしたい、オタク共に合わせるのは、大半のユーザーにとっては面倒でしかないんだよ
多少、重くていいから、お手軽に使わせろ、ってーの
312: 2021/01/16(土)14:24 ID:kbdLhinp(3/9) AAS
>>310
sqliteはプロセス要らないからいいが
mysqlやpostgresqlを突っ込めというのはキ○ガイの所業
複数DB対応するには普通は対応コストがかかる
DBラッパー使っても特定DBにしか対応してない拡張は使えないし
docker-composeで書いても大した記述量でもあるまいに
意図的に無視してるな
313(1): 2021/01/16(土)14:28 ID:kbdLhinp(4/9) AAS
>>311
docker-compose配ればいいだけだろ
基地外
314: 2021/01/16(土)14:32 ID:Q9Gxtc5G(5/10) AAS
>>313
podmanで動くようにしろ
K8Sで動くようにしろ
Nomadで動くようにしろ
うちの環境はだと動かないんだが？
、、、
お前これ全部対応できんの？
315: 2021/01/16(土)14:34 ID:kbdLhinp(5/9) AAS
手軽に試すなら普通はdocker-compose使うから
そんな特殊なやり方で対応する必要がない。
k8sやらnomadに手軽さは求めてないし。
k8sでやるんだったらhelmチャートあると便利。
316: 2021/01/16(土)14:37 ID:Q9Gxtc5G(6/10) AAS
マルチコンテナだとこうやって、実行環境に会わせて、オーケストレーションマニフェストをたくさん書かなきゃならん
一方でシングルコンテナなら、docker runするだけ
超簡単で、みんなハッピー
しかも、podmanでも、同じように動く
317(1): 2021/01/16(土)14:39 ID:kbdLhinp(6/9) AAS
そんな手軽さ別に求めてないし。馬鹿なの？
docker-compose用意してたら大体想定されている使い方分かるから、
自分でYAMLなり何なり書けば良いだけ
318(1): 2021/01/16(土)14:50 ID:Q9Gxtc5G(7/10) AAS
>>317
ユーザーに、手間をかけさせちゃ、だめだ
GitLabはこれをよくわかってる、から、1コンテナに詰め込んだ
ユーザーはdocker runするだけで、GitLabを使えるようになった
これが、マルチコンテナだったら、まあ、大変だよ
319: 2021/01/16(土)15:03 ID:Q9Gxtc5G(8/10) AAS
自作PCとスマホ、みたいなもんかなー
マルチコンテナ≒自作PC
このパーツ、あのパーツ、色々集めて、ミスしないようにくみたてて、ドライバとかも探して、入れて下さい
ツールは別売りなんで、それも自分で探して、入れてください
組み合せが悪いと、動かないかもしれません
でも、まあ、自己責任です
スマホ≒シングルコンテナ
スマホを購入して、箱から出して、電源を入れて下さい
WIFIとアカウントの入力だけ、お願いします
驚きましたか？そうです、もう使えます！
必要になりそうなアプリケーションも、予め揃えてあります
おめでとうございます！
320(1): 2021/01/16(土)15:03 ID:kbdLhinp(7/9) AAS
>>318
作る側の手間がかかり過ぎるって言ってんだろ馬鹿なの？
だから誰も真似しない
本格運用しないならdocker-composeで動けば十分だろバーカ
321(1): 2021/01/16(土)15:05 ID:kbdLhinp(8/9) AAS
なんでそんなちょっと試して見るだけのくそでかイメージが
あらゆる環境で動く事を気にする必要がある？？？
322(1): 2021/01/16(土)15:06 ID:Q9Gxtc5G(9/10) AAS
>>320
大した手間じゃないよ
一流は自分達の、多少の手間を惜しんで、ユーザーの負担を、増やそうとはしない
二流は自分達が、ほんの少し楽したいからって、ユーザーに手間をオシツケテル
GitLabは超一流だ
だから、シングルコンテナを選んだ
そのほうが、ユーザーが、楽だからだ
323: 2021/01/16(土)15:08 ID:Q9Gxtc5G(10/10) AAS
>>321
世界に公開するイメージなら、どの環境でも、簡単な手順で、動いたほうがいいに、決まってる
324: 2021/01/16(土)15:09 ID:kbdLhinp(9/9) AAS
>>322
そんな物誰も求めてないから真似しないんだと思うよ。
325: 2021/01/16(土)16:14 ID:xgde4k3r(1) AAS
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock my-awesome-app docker-compose up
326: 2021/01/16(土)17:46 ID:A/RioSjd(1) AAS
docker.sockをさらけ出すとあぶない
327: 2021/01/16(土)20:08 ID:agw/Ae5n(1) AAS
>>226でDockerてのは設計としては1コンテナ1プロセスを推奨してますよ、普通は>>308みたいにymlとdocker-compose
で構築してくださいね、でもまあ>>277見たいなケースで複数プロセス動かしたい時は>>288みたいな仕組みは用意して
ますから使ってくださいね、このケースの成功例はGitLabがありますよ。
唯>>296の様なリスクも在りますので気をつけてくださいね。
と、たったこれだけの話なのに一流だ二流だDockerfileもyamlも書かずに使ってるだけだから分かってないと、兎に角
相手をDisらなければDocker原理主義者の皆さんの会話でしたｗ
328: 2021/01/16(土)20:29 ID:xviAIVIh(1) AAS
暇だから適当なこと言ってからかって遊んでるだけだぞ
329: 2021/01/16(土)20:48 ID:hpTtRYug(1) AAS
GitLabは例外でしかないだろ
GitLabのDockerfileみてみろ、めちゃくちゃ大変なことしてるぞ
あれはそこまで頑張ってでも1コンテナにしたほうが
利用者にとっては便利だから、工数かけてやっただけで
作る側にとっては大変だってことの証明になってる
330: 2021/01/16(土)21:13 ID:niX7PYZl(1) AAS
GitLabはDockerが推奨する「普通の」やり方で作った非公式イメージが前からあった
あのやり方に疑問を抱く者は少なくなかった
公式helmチャートも出来たようだ
helmでそんな巨大イメージにする必要ないので
普通のやり方で作られてる
331: 2021/01/16(土)21:17 ID:g9x2r+gF(1/3) AAS
> あのやり方に疑問を抱く者は少なくなかった
それは使う側から見た話だろ？
作る側はどれだけ大変か、Dockerfileを見ればわかる
332(1): 2021/01/16(土)21:20 ID:Vaze8PjO(1) AAS
オーケストレーション前提じゃオペレーターも大変だ
オペレーターはレゴブロック遊びに付き合うほど暇じゃない
333: 2021/01/16(土)21:25 ID:wiSCvGlT(1) AAS
外部ﾘﾝｸ:github.com
GitLab使うならこっちでよくね？
334(1): 2021/01/16(土)21:29 ID:OQ3EdIh9(1) AAS
readmeなっが
お手軽な公式版、使うわ
335: 2021/01/16(土)21:31 ID:g9x2r+gF(2/3) AAS
な？「使うわ」という使う側の立場でしか見てないんだよ
作る側の大変さの話をしてるのにな
336: 2021/01/16(土)21:34 ID:2WB90esU(1) AAS
バカの一つ覚えのように一つのコンテナなら手軽に試せるしか言わねえし
何言っても無駄だろ
337: 2021/01/16(土)21:36 ID:TWWzREgo(1) AAS
>>334
外部ﾘﾝｸ:github.com
338(1): 2021/01/16(土)21:40 ID:pzrp2Yop(1) AAS
redisとpostgresを何らかの手段で起動し
シークレットの暗号化に使う文字列を3つ作れば良い
たったこれだけ
これ以上簡単になりようがない
それを>>332はできないと言って
先程から大騒ぎしている
339(1): 2021/01/16(土)21:43 ID:g9x2r+gF(3/3) AAS
GitLabはウェブサービスも運営してるが
そのGitLabがそのDockerfileを使ってると思うのか？って話だよな
スケールさせるためには、アプリとデータベースを分離させるのは当たり前だし
Dockerを使うっていうのは、そういうウェブサービスも運営するときの
システムを作るために有るのだから、そういうときにどういう構成にしますか？の
話でサービス毎にコンテナを分けるのは当たり前
作る側の視点がかけてる
これはDockerコンテナを動かすだけの
インフラ屋にありがち
340: 2021/01/16(土)21:47 ID:LbH2M5zo(1) AAS
ごった煮イメージが本番運用に堪えないって点に異論は無いらしい
341(1): 2021/01/16(土)22:02 ID:jF/4b5o1(1/3) AAS
>>338
めんどくせー
ポスグレでも、Redisでも、シークレットでもねえ
GitLabを、使いてえんだよ
なんだよこの、野球してえのに、サッカーボールでリフティングの練習しろ、みたいな要求は
上下前次1-新書関写板覧索設栞歴
あと 661 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.035s