Docker-mailman: 전체 스택 도커 작성

관심을 가져주셔서 감사합니다.

• 저는 전체 스택 작성을 현재 옵션과 별도의 옵션으로 유지해야 한다고 생각합니다. 주로 Mailman을 제공하는 것 외에 다른 작업을 수행하기 위해 호스트에서 MTA/웹 서버가 필요한 사람들을 위한 것입니다.
• 환경 변수를 .env 파일로 이동하는 것은 나에게 그다지 의미가 없습니다. 귀하의 비밀을 더 안전하게 유지하기를 원할 수 있지만 .env 대한 액세스를 거부하기 위해 일부 Linux 권한을 사용하지 않는 한 docker-compose.yaml , 그것은 일종의 쓸모없는 것입니까? 그리고 그 일을 어떻게 할 것인지 잘 모르겠습니다.
• 접미사 컨테이너를 추가하는 것은 큰 도움이 될 것입니다. 이것은 #282 와 관련이 없지만 별도의 MR에서 처리할 수 있습니다.
• 나는 주식과 볼륨한다는 Nginx에 컨테이너 추가 생각 mailman-web 가장 좋은 것입니다. 나는 현재 #144에 별로 관심이 없습니다. 특히 속도를 크게 향상시키지 못하기 때문입니다. 시작할 때 정적 파일을 생성하는 것은 일반적으로 문제가 없습니다.
• stdout에 대한 로깅은 훌륭해야 합니다. Django는 아마도 쉽게 할 수 있고 Core
• 호스트 이름, 컨테이너 이름, 링크에 대한 기본 항목을 제거하려는 이유는 무엇입니까?
• 하드 코딩된 네트워크 항목을 제거하는 것은 제가 정말로 하고 싶은 일입니다. Hyperkitty가 Core의 요청을 인증하는 방법에 따라 몇 가지 문제가 있을 수 있지만 업스트림에서도 해결할 수 있습니다.

전반적으로 대부분의 아이디어가 마음에 듭니다. 이상적으로는 각 변경 사항이 별도의 Pull Request에 포함되기를 원하며 해당 PR에서 더 자세히 논의할 수 있습니다.

.env 파일 정보:

• 전체 docker-compose.yml을 검색하지 않고 변경해야 하는 변수를 최종 사용자에게 명확하게 표시합니다.
• 중복 정의를 제거합니다(예: 하이퍼키티 API 키).
• 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/

.env 파일에 대해 @morbidick의 의견에 동의합니다. 주로 업데이트를 훨씬 쉽게 만들어주기 때문입니다.
저장소를 오염시키지 않고 간단히 git pull 를 수행할 수 있습니다.
또한 .env 파일은 .gitignore 있어야 합니다.

예 : Sentry가 이 작업을 수행하는 방법을 살펴보십시오.
https://github.com/getsentry/onpremise

그들은 또한 제공 env.example 당신이 당신의 자신에 복사 할 수있는 파일 .env 파일을.