Docker-mailman: Composição da janela de encaixe Full stack

Criado em 4 jan. 2019 · 7Comentários · Fonte: maxking/docker-mailman

antes de mais nada, obrigado pelos incríveis contêineres, eles tornaram minha instalação muito mais fácil. Recentemente, criei uma configuração docker-compose de produção completa. Gostaria de propor / discutir algumas alterações / acréscimos a este projeto que aprendi durante a configuração.

fornecer um docker-compose completo, incluindo MTA e SSL Termination (basicamente # 174)
- mover variáveis específicas do site para um arquivo .env (segredos e domínios)
- adicione um contêiner postfix com a configuração específica do mailman e uma sub-rede local configurável (ajudaria com # 282)
- adicione um contêiner nginx que já inclui os arquivos estáticos e proxies ao soquete uwsgi (não lida com terminação SSL, já existem contêineres suficientes por aí), relacionado ao # 144, mas provavelmente poderia ser resolvido por um dockerfile de vários estágios
- dividir configuração sobrescrever pastas de pastas de dados
- logar no stdout (# 2, # 134)
remover entradas padrão do docker-compose (hostname, container-name, links)
tente remover a sub-rede codificada e usar roteamento baseado em dns (não tenho certeza se viável, mas seria incrível) (relacionado # 44)

Ficaria feliz em fornecer RP para os pontos acima, mas gostaria de receber seu feedback primeiro, depois de escrever este tíquete e encontrar todos os tíquetes relacionados, tenho certeza de que todas as alterações também são de seu interesse, principalmente criá-lo como uma lista de tarefas para mim.

Fonte

morbidick

👍3

Comentários muito úteis

Veja https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/

pgeorgi em 12 jan. 2019

❤4

Todos 7 comentários

Obrigado pelo seu interesse nisso, eu adoraria que isso acontecesse!

Acho que devemos manter a composição de pilha completa como uma opção separada da atual, principalmente para as pessoas que precisam de seu MTA / servidor Web no host para fazer outras coisas além de servir ao Mailman.
Mover variáveis de ambiente para o arquivo .env realmente não faz muito sentido para mim, eu entendo que você provavelmente deseja manter seus segredos mais seguros, mas a menos que alguém esteja usando algumas permissões do Linux para negar acesso a .env file, mas não para docker-compose.yaml , é meio inútil, certo? E não tenho certeza de como alguém faria isso.
Adicionar um contêiner Postfix deve ser uma grande ajuda, não está relacionado ao # 282, mas podemos lidar com isso em um MR separado.
Acho que adicionar um contêiner Nginx que compartilha um volume com mailman-web seria o melhor. Não estou muito interessado no # 144 no momento, especialmente porque ele realmente não nos acelera muito nem nada. Geralmente, a geração de arquivos estáticos na inicialização deve funcionar.
Logar no stdout deve ser ótimo, o Django provavelmente pode fazer isso facilmente, o Core pode fazer.
Por que queremos remover as entradas padrão para hostname, container-name, links?
Remover as coisas de rede embutidas em código é algo que eu realmente quero fazer, que pode ter alguns desafios com base em como o Hyperkitty autentica solicitações do Core, mas podemos consertar isso no upstream também.

No geral, gosto da maioria das ideias. O ideal é que cada alteração seja feita em sua própria solicitação pull separada e, em seguida, possamos discutir com mais detalhes em seus respectivos PRs.

maxking em 10 jan. 2019

👍1

Sobre o arquivo .env :

deixa claro para o usuário final quais variáveis devem ser alteradas sem pesquisar, jogando o docker-compose.yml inteiro
remove definições duplicadas (como a chave de API de hyperkitty)
poderia / deveria tornar mais fácil atualizar um docker-compose.yml (já que se está usando o upstream) e só precisa adicionar / modificar as variáveis alteradas no local .env
usuários finais podem fazer check-in do docker-compose.yml em execução no controle de origem sem expor segredos

Acho que um RP deixará isso mais claro, não dá muito trabalho, então não se incomode se deixarmos isso de lado.

Os links são um recurso obsoleto; por padrão, todos os contêineres em uma seção de serviço estão em uma rede, portanto, vinculados de qualquer maneira. O nome do host e o nome do contêiner são padronizados para a seção atual na definição do serviço, então o mesmo que o definido explicitamente atualmente e acho que removê-los torna o arquivo inteiro menor e, portanto, mais fácil de entender.

morbidick em 10 jan. 2019

Algo relacionado, eu integrei esses contêineres no Mailu (https://github.com/Mailu/Mailu) que fornece o resto da pilha. Existe interesse em tal configuração?

pgeorgi em 11 jan. 2019

@pgeorgi Se você já tem essa integração que gostaria de manter usando essas imagens, ficaria feliz em adicionar um link para seu repositório / postagem na documentação.

maxking em 12 jan. 2019

@pgeorgi definitivamente

morbidick em 12 jan. 2019

Veja https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/

pgeorgi em 12 jan. 2019

❤4

Concordo com @morbidick sobre o arquivo .env , principalmente porque torna a atualização muito mais fácil.
Você pode simplesmente fazer um git pull sem poluir seu repo.
Além disso, o arquivo .env deve estar em .gitignore

Exemplo : Veja como o Sentry faz isso:
https://github.com/getsentry/onpremise

Eles também fornecem um arquivo env.example que você pode copiar para seu próprio arquivo .env .