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

Созданный на 4 янв. 2019 · 7Комментарии · Источник: maxking/docker-mailman

Прежде всего, спасибо за прекрасные контейнеры, они намного упростили мою установку. Недавно я создал полную производственную установку для создания докеров . Я хотел бы предложить / обсудить несколько изменений / дополнений к этому проекту, о которых я узнал в процессе настройки.

предоставить полную докер-компоновку, включая MTA и SSL Termination (в основном # 174)
- переместить специфичные для сайта переменные в файл .env (секреты и домены)
- добавить контейнер постфикса с конкретной конфигурацией почтальона и настраиваемой локальной подсетью (помогло бы с # 282)
- добавить контейнер nginx, который уже включает статические файлы и прокси в сокет uwsgi (не обрабатывает завершение ssl, там уже достаточно контейнеров), связанный с # 144, но, вероятно, может быть решен с помощью многоступенчатого файла докеров
- разделить конфигурацию перезаписать папки из папок с данными
- войти в стандартный вывод (# 2, # 134)
удалить записи по умолчанию из docker-compose (имя хоста, имя контейнера, ссылки)
попробуйте удалить жестко закодированную подсеть и использовать маршрутизацию на основе DNS (не уверен, возможно ли это, но было бы здорово) (связанный # 44)

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

Источник

morbidick

👍3

Самый полезный комментарий

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

pgeorgi 12 янв. 2019

❤4

Все 7 Комментарий

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

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

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

maxking 10 янв. 2019

👍1

О файле .env :

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

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

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

morbidick 10 янв. 2019

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

pgeorgi 11 янв. 2019

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

maxking 12 янв. 2019

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

morbidick 12 янв. 2019

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

pgeorgi 12 янв. 2019

❤4

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

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

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