公式文書によると:
<ブロック引用>
CMD は 1 つしか存在できません Dockerfile の命令 .複数の CMD をリストする場合 最後の CMD のみ
Dockerfile には 2 つの CMD コマンドがあるため、コマンド php-fpm は オーバーライドします
/usr/bin/supervisord
PHP コマンドを実行できますが、コンテナーに作成されたスーパーバイザーのソケットが見つからないようにします。
最後の CMD を削除することで問題を解決できます PHP-FPM に関連するコマンド supervisor をすでに構成しているため それを開始するには、Dockerfile に CMD が 1 つ必要です。 コマンド:
CMD ["/usr/bin/supervisord"]
ここでの考え方は、スーパーバイザーを排除し、代わりにスーパーバイザーがいくつかの異なるコンテナーで実行していたものを実行することです。これは docker-compose で簡単に調整できます 、たとえば、すべてが異なる CMD で同じコンテナを実行しています オーバーライド、または異なる CMD を持つ同じコンテナ 最後にレイヤーを重ねて分割します。ここでの問題は、スーパーバイザーが管理するプロセスのステータスを Docker に伝えることができないことです。すべてのプロセスが完全に破棄されたとしても、常に「生きている」状態になります。それらを直接公開するということは、それらがクラッシュしたことを確認できるということです。
最良の方法は、これらのサービスをそれぞれ別のコンテナーに分割することです。 MySQL などには公式にビルド済みのものがあるため、自分でビルドする理由はまったくありません。あなたがしたいことは、その supervisord を翻訳することです docker-compose に設定
個別のコンテナを使用すると、 docker ps のようなことができます サービスが正しく実行されているかどうかを確認するために、それらはすべて個別に一覧表示されます。 1 つをアップグレードする必要がある場合は、簡単に行うことができます。すべてをプルダウンする必要はなく、その 1 つのコンテナーで作業するだけです。
ここであなたが攻撃しているのは、Docker を派手な VM のように扱っていることですが、実際にはそうではありません。代わりに、プロセス マネージャー
単一プロセスのコンテナーから環境を構成すると、メンテナンスの観点からも監視の観点からも、生活がずっと楽になります。
この構成を何か docker-compose で表現できる場合 対処できれば、Kubernetes のようなより洗練された管理レイヤーへの移行に一歩近づき、この特定の移行の論理的な結論となる可能性があります。