음… 
스크립트는 /var/discourse에 대한 접근 권한조차 필요하지 않습니다(왜 필요할까요?!).
이 전체 문제는 다음과 같은 몇 가지 사항에서 비롯됩니다:
- 도커가 무엇인지, 어떻게 작동하는지, 그리고 그것이 무엇을 가능하게 하는지에 대한 막대한 오해
- 도커 = 도커-컴포즈라는 개념을 억지로 결합시키는 것 (아닙니다!)
호스트 환경을 거의 건드리지 않는 완전히 격리된 설정을 가질 수 있습니다…
충분히 조사해 본 결과, 전체 “setup” 스크립트는 매우 비기술적인 사람을 위해 설치를 최대한 단순하게 만들기 위해 작성된 것으로 보입니다. 이 스크립트는 환경을 확인하고, 사용자를 안내하며, 모든 것을 설정합니다. 이는 좋은 점이 될 수 있지만, 의도된 경로에서 아주 작은 차이조차 벗어나려는 시도는 완전히 실패합니다.
가장 기본적인 설정에서는 호스트 디렉토리에 대한 접근 권한조차 필요하지 않을 수 있습니다 - 모든 것이 제한된 환경(이미지를 사용하여 컨테이너를 생성하고, 필요한 모든 스토리지는 도커 볼륨을 통해 처리됩니다 [다른 곳으로 마이그레이션하거나 파일에 접근하려는 경우 문제가 있지만, 여기서는 기본 사항에 대해 이야기하고 있습니다]) 내에 포함됩니다.
또한 DNS가 올바른지 확인하고, 인증서, 리버스 프록시, SMTP 등을 설정하려고 시도합니다 - 다시 말하지만, 이러한 쉬운 설정을 제공하는 것은 완전히 문제없습니다.
하지만!
문제는 그것을 버리는 것이 아니라, 추가로 순수한 도커 이미지를 제공하는 것입니다 (이미 존재하며, 스크립트와 스크립트가 사용하는 템플릿에서 사용됩니다! discourse_docker/templates/postgres.template.yml at main · discourse/discourse_docker · GitHub & discourse_docker/launcher at main · discourse/discourse_docker · GitHub) 그리고
- 적절한 버전 관리: 이미지를 릴리스된 디스커스 버전(3.4.5 등)으로 태그합니다.
- 예상되는 환경 변수(데이터베이스/레디스/등 연결을 제어하는 것)와 호스트에 마운트할 수 있는 가능한 경로/볼륨에 대한 합리적이고 단순한 문서화.
그것뿐입니다…
aforementioned miniflux 가이드를 살펴보세요: Miniflux Installation with Docker - 이미지에 대한 세부 사항(그리고 어떤 저장소가 이를 제공하는지)과 구성할 수 있는 가능한 환경 변수를 제공합니다.
또는 MySQL 도커 이미지: mysql - Official Image | Docker Hub - 동일한 개념입니다 - 구성할 수 있는 것이 무엇인지 설명하는 가이드입니다 (특히 “Environment Variables” 섹션을 참고하세요).
누구도 "mysql 이미지를 사용하려면 mysql 런처를 사용하여 mysql 이미지를 빌드해야 합니다"라고 말하지 않거나, 레디스의 경우에도 마찬가지입니다 - 이 경우 단순히 기존 이미지를 사용하며, 이것이 도커를 사용하는 핵심과 요점입니다. 그런데 디스커스의 경우 갑자기 이것이 “나쁜” 해결책이 되고, 모든 사람이 "자신의 이미지를 직접 빌드해야 합니다!"라고 외칩니다 – 왜!?