Docker-mailman: Создание докеров с полным стеком

Спасибо за проявленный интерес, я бы хотел, чтобы это произошло!

• Я думаю, что мы должны сохранить составление полного стека как отдельную опцию по сравнению с текущим, в основном для людей, которым нужен их MTA / веб-сервер на хосте, чтобы делать другие вещи, а не просто обслуживать Mailman.
• Перенос переменных среды в файл .env самом деле не имеет для меня большого смысла, я понимаю, что вы, вероятно, хотите сохранить свои секреты в большей безопасности, но если вы не используете некоторые разрешения Linux для запрета доступа к .env file, а не docker-compose.yaml , это бесполезно, верно? И я не уверен, как это сделать.
• Добавление контейнера постфикса должно быть большим подспорьем, это не имеет отношения к # 282, но мы можем обработать это в отдельном MR.
• Я думаю, что лучше всего было бы добавить контейнер Nginx, который разделяет том с mailman-web . На данный момент меня не очень интересует # 144, особенно потому, что он не дает нам большого ускорения или чего-то подобного. Создание статических файлов при запуске обычно нормально.
• Ведение журнала в stdout должно быть отличным, Django, вероятно, справится с этим легко, Core может .
• Почему мы хотим удалить записи по умолчанию для имени хоста, имени контейнера и ссылок?
• Удаление жестко запрограммированных сетевых вещей - это то, чем я действительно хочу заниматься, это может иметь некоторые проблемы, связанные с тем, как Hyperkitty аутентифицирует запросы от Core, но мы можем исправить это и в восходящем направлении.

В целом идеи мне нравятся. В идеале мы бы хотели, чтобы каждое изменение было отдельным запросом на слияние, а затем мы могли бы обсудить более подробную информацию в их соответствующих PR.

О файле .env :

• он дает понять конечному пользователю, какие переменные следует изменить без поиска, выбросил весь docker-compose.yml
• он удаляет повторяющиеся определения (например, ключ api hyperkitty)
• он может / должен упростить обновление docker-compose.yml (так как один использует исходный) и должен только добавить / изменить измененные переменные в локальном .env
• конечные пользователи могут зарегистрировать свой запущенный docker-compose.yml в исходном элементе управления, не раскрывая секретов.

Я думаю, что PR прояснит это, это не так много работы, так что никаких проблем, если мы его бросим.

Ссылки являются устаревшей функцией, по умолчанию все контейнеры в разделе службы находятся в одной сети, поэтому все равно связаны. Имя хоста и имя контейнера по умолчанию соответствуют текущему разделу в определении службы, так что они такие же, как в настоящее время явно определены, и я думаю, что их удаление делает весь файл меньше и, следовательно, более легким для понимания.

В некотором роде я интегрировал эти контейнеры в Mailu (https://github.com/Mailu/Mailu), который обеспечивает остальную часть стека. Есть ли интерес в такой установке?

@pgeorgi Если у вас уже есть

@pgeorgi определенно

См. Https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/

Я согласен с @morbidick насчет .env , главным образом потому, что он значительно упрощает обновление.
Вы можете просто сделать git pull не загрязняя свое репо.
Кроме того, файл .env должен находиться в .gitignore

Пример : посмотрите, как это делает Sentry:
https://github.com/getsentry/onpremise

Они также предоставляют файл env.example который вы можете скопировать в свой собственный файл .env .