[過去ﾛｸﾞ] Docker Part5 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
201(1): 2021/01/11(月)16:38 ID:5exndTNV(2/2) AAS
ところで質問。
docker-compose のサービスをいきなり docker run 相当で起動するんじゃなくて
docker create -> docker cp -> docker start みたいなことってできないのかな？
あるいは swarm や k8s だとどうだろう。
202: 2021/01/11(月)16:40 ID:89OcdB6i(2/3) AAS
なるほど。ただ、podmanであってもdockerfileの置き換えには至ってない雰囲気。
軽くしようとすると途端に難易度が高くなるツールだ
203: 2021/01/11(月)17:42 ID:89OcdB6i(3/3) AAS
Buildahというのがあるようだ。
どの程度の性能か謎ではあるが……。
204: 2021/01/12(火)08:35 ID:KVG+KHkJ(1/2) AAS
>>201
docker-composeなら
ファイルはボリュームでマウントすれば良いし
イメージがshとかbashでのcommand実行に対応してれば何らかの初期化処理も可能だ
scratchイメージでsh入ってなかったら無理だが
205: 2021/01/12(火)21:10 ID:KVG+KHkJ(2/2) AAS
Docker BuildKit: faster builds, new features, and now it’s stable
外部ﾘﾝｸ:pythonspeed.com
206: 2021/01/12(火)21:11 ID:M4v6YD34(1) AAS
直接そういうことができる機能は無いから別の手を考えないとならないということね。ありがとう。
207: 2021/01/13(水)15:47 AAS
docker-composeで独自モジュールをpipでいストールしたけど
その独自モジュールのソースを微妙に変更して、docker-composeやり直しても更新してくれない。。
docker-compose down --rmi all --volumes --remove-orphans
してもコンテナもイメージも残ったままなのがたぶん原因なんだろうけど・・
手動でポチポチ消すしかないのかなぁ
208(1): 2021/01/13(水)16:01 ID:bWUxShca(1/2) AAS
docker-compose build --no-cache
209: 2021/01/13(水)16:17 AAS
>>208
ちょっとだけ構築速度おそくなったけどできた！?クス！
210: 2021/01/13(水)17:51 ID:rA2yTqxj(1) AAS
no cacheオプションだから遅くなるのは当然でしょ
211: 2021/01/13(水)19:38 AAS
メモ
docker image prune
で消えねえと思ったら-aオプションいるのね・・
docker image prune -a
消したくないやつは稼働させたままやったら
稼働してないやつだけ消えてめちゃくちゃ捗った
（稼働中のやつには無影響なのかはわからないけど）
212(1): 2021/01/13(水)19:46 AAS
できれば、pipでインストールする自作ライブラリの訂正部分だけ更新できるようにしたいけど
--no-cacheするかイメージもコンテナも全部消してから再ビルドしないと適用してくれない・・
非公開gitからクローン → python setup.py sdist → pip install ○○
みたいにDockerファイルのRUNでやってるのがだめなのかな
213(1): 2021/01/13(水)20:07 ID:PWUDNnFH(1) AAS
>>212
自作ライブラリをインストールした以降のイメージだけを削除したら。
214(1): 2021/01/13(水)20:07 ID:bWUxShca(2/2) AAS
ARGでタグかブランチを指定するんですよ
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があなたのために行うことです。
省8
225: 2021/01/15(金)09:02 ID:ouI6ZQHD(2/5) AAS
>>216
これとか読むといいかも。公式がVMじゃないと言ってる。
Containers are not VMs
外部ﾘﾝｸ:www.docker.com
> しかし、これを言っても、VMに関する現在の考えやプロセスを適応させ、
> コンテナーに適用しようとしています。
>
> 「コンテナをバックアップするにはどうすればよいですか？」
> 「実行中のコンテナのパッチ管理戦略は何ですか？」
> 「アプリケーションサーバーはどこで実行されますか？」
省8
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つのコンテナーがアプリケーション全体の複数の
省2
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を使うほうがいい
省2
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を使ってるとは言えない
んで、使ってるだけのやつが、使うのが楽と言ってる
省2
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を追加しなきゃならない
省2
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を実装しなければならず、開発者は疲弊する
サービスメッシュの管理コストは増大し、運用者は疲弊する
これはミクロサービスの功罪と同じことだが、なんでもかんでも、小さく分けて、疎にするのが、常に正解なわけじゃない
全てはトレードオフなのだ！
たしか、マーティンファウラーだったと思うが
彼曰く、最初からミクロサービス的な思想に傾倒した案件は、失敗することが多い、らしい
最初はモノリスのほうが、うまく行くのだ
省1
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
開発や運用でトラブルが一切無いと考える方が頭おかしい
上下前次1-新書関写板覧索設栞歴
あと 702 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s