‫検証か戻ってきました｡
‫スーパーバイザーDの使用感について､ どのようにお考えですか｡
‫ということで､ いい質問ですね｡
‫Supervisor D コンテナにsupervisorを入れて､ そのコンテナの中でPID 1またはルートプロセスとして実行することを指しているのだと思います｡
‫ちゃんと必要ならそれでいいんです｡
‫Dockerのベストプラクティスは､ 1つのコンテナに1つ以上のアプリを入れないことだと知っています｡
‫私は､ この考えをもとに､ 1つの容器に1つ以上の懸念がないことを示したいと思っています｡
‫そして､ 場合によってはその懸念が複数の実行ファイルになるかもしれないとき｡
‫そのため､ 他のものから始める必要があります｡
‫そしてそれは､ ある種の空想的なシェルスクリプトである可能性があります｡
‫スーパーバイザーDを使うのが好きです｡
‫実際､ 私のHPのレポを見ると､ levelのP HPレポは恐ろしく古いので､
‫最新のDockerの新機能を使うためには､
‫いくつかのアップデートが必要ですが､ ユニークな点がいくつかあります｡
‫ガイドラインに従っていたとしても､ ガイドラインはあくまでベストプラクティスのようなものです｡
‫しかし､ 自分が何をしているのか､ なぜそれをするのかがわかっていれば､ そこにとどまる必要はありません｡
‫この例では､ エンジンXとHP FGMの両方を同じコンテナイメージに統合し､
‫両方をスーパーバイザDで実行しています｡
‫私は､ 多くの地域で運営されている非常に大規模なグローバルウェブサイトで､ この機能を使用したことがあります｡
‫ですから､ このデザインは間違いなくタイムテスト済みで､ ヘビーヘビーなシナリオで使用されています｡
‫なぜなら､ Dockerやswarmにはポッドという概念がないからです｡
‫キューバや80年代の世界であればポッドの概念があり､ その場合､ エンジンXとPSPを同じポッドの中にそれぞれのコンテナで並べて動かし､
‫そのポッドを一緒にデプロイすることが可能です｡
‫PSPの場合はソケットを使ってやり取りするので､
‫とても効率的なのですが､ Docker Swarmの場合はTGPでやり取りすることになるので､
‫ラグが大きくなってしまいます｡
‫でも､ 同じカーネル内のローカルソケットで通信するのではなく､
‫サーバーを越えて通信するとなると､ 数ミリ秒､ いや数十ミリ秒の遅延が発生する可能性があるわけです｡
‫ですから､ 私は両方を同じコンテナで実行するのが好きで､ そのためにスーパーバイザーDを使用しています｡
‫だから､ その例をチェックしてみてください｡
‫それをチャットに投げる｡
‫もう誰かが投稿しているのを見たような気がします｡
‫というわけで､ 質問の答えになっていれば幸いです｡
‫ちなみに､ 私がスーパーバイザーDを使うのは数カ所だけで､ そのうちのひとつです｡
‫もうひとつは､ コールドフュージョンのように､ フロントエンドにパッチか何かを貼らないと機能しない､
‫あるいはエリアジェネリックのようなものでしょうか｡
‫ですから､ コードを実行するためにAmulに接続するバックインバイナリがあり､
‫その前にあるウェブサーバが必要な場合はいつでも､ サービスを提供するために両者が一緒に動作する必要があります｡
‫この場合､ 同じイメージの中に一緒に入れるのは完全に理にかなっています｡ 特に､ 常に1対1でスケーリングする場合は､
‫コンテナで多くのことを別の方法でスケーリングしたいでしょうから､ APIの数をスケーリングするのと､ データベースコンテナの数をスケーリングするのでは意味が違ってきます｡
‫そのような場合､ 柔軟性を持たせて､ 別々にアップデートできるように構築したいのです｡
‫今回は､ アプリのアップデートとコンテナの交換を同時に行うので､ これらを一緒に行うことは非常に理にかなっていると思いますので､
‫ご参考になれば幸いです｡