Docker-mailman: フルスタックDocker構成

これに興味を持ってくれてありがとう、私はこれが起こるのが大好きです！

• フルスタックの作成は、現在のオプションとは別のオプションとして維持する必要があると思います。主に、ホスト上でMTA / Webサーバーを使用して、Mailmanにサービスを提供する以外のことを行う必要がある場合です。
• 環境変数を.envファイルに移動することは、私にはあまり意味がありません。おそらく秘密をより安全に保ちたいと思うでしょうが、Linuxのアクセス許可を使用して.envへのアクセスを拒否しない限りdocker-compose.yamlではありません、それはちょっと役に立たないですよね？ そして、私はそれをどのように行うのかわかりません。
• 後置コンテナを追加することは大きな助けになるはずです。それは＃282とは無関係ですが、別のMRで処理できます。
• mailman-webとボリュームを共有するNginxコンテナを追加するのが最善だと思います。 現時点では、＃144にはあまり興味がありません。特に、スピードアップなどがあまり得られないためです。 通常、起動時に静的ファイルを生成することは問題ありません。
• stdoutへのロギングは素晴らしいはずです、Djangoはおそらくそれを簡単に行うことができます、Coreはできる
• ホスト名、コンテナ名、リンクのデフォルトエントリを削除したいのはなぜですか？
• ハードコードされたネットワークのものを削除することは私が本当にやりたいことです。HyperkittyがCoreからの要求を認証する方法に基づいていくつかの課題があるかもしれませんが、アップストリームでも修正できます。

全体的に、私はほとんどのアイデアが好きです。 理想的には、各変更を個別のプルリクエストに含めてから、それぞれのPRで詳細に話し合うことができます。

.envファイルについて：

• docker-compose.yml全体を検索せずに、どの変数を変更する必要があるかをエンドユーザーに明確にします。
• 重複する定義を削除します（hyperkitty apiキーなど）
• docker-compose.ymlのアップグレードが簡単になる可能性があります（アップストリームのものを使用しているため）。ローカルの.env変更された変数を追加/変更するだけで済みます。
• エンドユーザーは、シークレットを公開せずに、実行中のdocker-compose.ymlをソースコントロールにチェックインできます

PRはそれをより明確にするだろうと思います、それはあまり仕事ではないので、私たちがそれを落としても面倒はありません。

リンクは非推奨の機能です。デフォルトでは、サービスセクション内のすべてのコンテナが1つのネットワーク内にあるため、とにかくリンクされています。 ホスト名とコンテナ名はデフォルトでサービス定義の現在のセクションに設定されるため、現在明示的に定義されているものと同じです。これらを削除すると、ファイル全体が小さくなり、理解しやすくなると思います。

やや関連して、スタックの残りの部分を提供するMailu（https://github.com/Mailu/Mailu）にこれらのコンテナーを統合しました。 そのような設定に興味はありますか？

@pgeorgiこれらの画像を使用して維持したい統合がすでにある場合は、ドキュメントにリポジトリ/投稿へのリンクを追加させていただきます。

@pgeorgiは間違いなく

https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/を参照して

.envファイルについては@morbidickに同意します。これは、主に更新がはるかに簡単になるためです。
リポジトリを汚染することなく、 git pullできます。
また、 .envファイルは.gitignore必要があります

例：Sentryがこれをどのように行うかを見てください。
https://github.com/getsentry/onpremise

また、独自の.envファイルにコピーできるenv.exampleファイルも提供します。