問題タブ [docker-swarm-mode]

現在、Docker Swarm クラスターを構築しています。マネージャー 3 名と作業員 3 名で構成されています。このセットアップでデプロイするアプリは、スケーラビリティのために複数のコンテナーでコードを必要とする laravel バックエンドで構成されています。ボリュームの共有ストレージとして Ceph バックエンドを使用して、GlusterFS ボリュームと rex-ray を既に試しました。GlusterFS は信頼性が低く、私の場合、Ceph は少し過剰で難しすぎます :)

現在の編成はこんな感じ。Docker の外部に Percona クラスターがあり、これらのサーバーで GlusterFS を実行し、それらを Docker ワーカーにマウントするだけです。

次に、これらを次のように php コンテナーにマウントします。

これは機能しますが、非常に遅いです。ページの読み込み時間は約 10 秒です。ファイルがマウントされていない (コンテナーに存在する) 場合、ページの読み込み時間は約 2 ～ 3 秒です。

私は Flocker について調べましたが、これは非常に興味深いように思えますが、flocker ボリュームは 1 つのコンテナーにしかマウントできないと思います。これは本当ですか？

私が現在試しているもう 1 つの解決策は、新しいコンテナーが作成されるたびにコードが git からプルされるというものです。これは実際には良い解決策ですが、コードをプルして composer を実行するのに約 5 分かかり、更新をプッシュするときはすべてのコンテナーを再起動する必要があります。

複数のホスト上の異なるコンテナー間でコードを共有するための最適なソリューションは何ですか? （またはデータセンターでさえ）現在、多くの異なるストレージバックエンド（Ceph、NFS、gluster）にアクセスでき、新しいものを作成することは問題ありません.

編集: この場合、gluster が信頼できないのはなぜですか? 上で間違って言ったかもしれません...ボリュームドライバープラグインを使用して、Glusterでdockerボリュームを使用すると、Glusterは信頼できません。ほとんどの場合、サービスの作成時にボリュームが適切にマウントされますが、swarm で再スケジュールが発生した場合、ボリュームが再びマウントされることはめったにありません。後でこれを調べて何が問題なのかを判断しますが、現時点では自由な時間があまりありません。実際、Gluster はしっかりしています。この場合だけではありません。

docker swarm があり、次を使用してサービス スタックをデプロイします

「docker stack deploy --compose-file mycompose.yaml myservice」.

この yaml ファイルで使用されるいくつかの値を渡したいと思います。コマンドラインから、または他の方法で渡すことはできますか?