사실 이것을 작동하게 하려면 시행착오가 좀 필요했지만, 다음과 같이 성공했습니다(이것이 최선의 방법이라는 보장은 없습니다. 실제로는 더 나은 방법이 있을 것이라고 생각하므로, 수정과 개선에 대한 조언을 매우 환영합니다):
@pfaffman이 OP로 이동시킨 지침
우선, Discourse 인스턴스에 접근하는 방법은 두 가지가 있습니다: 1. 포트 노출, 2. 웹소켓을 통한 접근. 이 포럼 어딘가에서 웹소켓이 더 빠르고 효율적이라고 들었기 때문에 웹소켓을 사용하지만, 포트 노출이 훨씬 쉬울 수 있으므로 웹소켓이 작동하지 않으면 포트 노출을 시도해 보세요(아래에 자세히 설명되어 있음).
자, 30분 표준 설치를 완료했고, 아직 Discourse가 Let’s Encrypt 인증서를 발급받지 않았다고 가정해 보겠습니다. 리버스 프록시를 사용하는 경우 인증서가 필요 없기 때문입니다. NPM이 그 일을 처리해 줄 것입니다. 이미 인증서가 있어도 상관없습니다. NPM이 단순히 새로운 인증서를 발급받기만 하면 됩니다.
1. NPM 설치
다음 단계는 NPM을 설치하는 것입니다. 이렇게 하면 두 개의 Docker 컨테이너(NPM 및 해당 데이터베이스 컨테이너)가 추가로 실행됩니다.
다음은 질문하신 다소 까다로운 부분입니다.
첫 번째 장벽은 Discourse가 기본 Docker bridge 네트워크에서 실행되는 반면, NPM은 기본적으로 “사용자 생성 네트워크”(제 경우 npm_default라고 불림)에서 실행된다는 것입니다. 즉, NPM은 Discourse를 볼 수 없습니다. 
2. 모든 컨테이너를 기본 bridge 네트워크로 이동
Discourse를 사용자 지정 네트워크로 이동할 수 있는지, 그리고 어떻게 해야 하는지 제가 알지 못하는 한, NPM을 기본 bridge 네트워크로 이동해야 합니다. Docker Compose 파일의 두 NPM 컨테이너 모두에 network_mode: bridge를 추가하여 이를 수행할 수 있습니다.
3. 서비스 이름 대신 IP 주소 사용
다음 문제는 bridge 네트워크로만 이동하면 표준 Docker Compose 파일이 더 이상 작동하지 않는다는 것입니다. NPM이 더 이상 데이터베이스 컨테이너를 찾을 수 없게 됩니다. 이는 서비스 이름에 대한 내부 DNS 해석(Docker Compose 파일이 의존하는 것)이 사용자 생성 네트워크에서만 사용 가능하고 기본 Docker 네트워크에서는 사용 불가능하기 때문입니다. 따라서 하드코딩된 IP 주소를 사용해야 합니다(컨테이너 IP가 변경되면 깨지므로 이것이 확실히 최적의 해결책이 아닌 이유입니다). 따라서 작동하지 않는다는 것을 알면서도 컨테이너를 시작하고, NPM 데이터베이스 컨테이너의 IP를 적어 두어야 하며, Docker Compose 파일의 DB_MYSQL_HOST: "db"를 DB_MYSQL_HOST: "<db_container_IP>"로 대체해야 합니다.
이제 모든 컨테이너가 기본 bridge 네트워크에 있으므로 NPM이 Discourse와 데이터베이스를 모두 볼 수 있게 됩니다.
4. Discourse 접근 가능하게 만들기
그러나 Discourse를 “보는” 것과 접근할 수 있는 것은 다른 문제입니다. 따라서 NPM이 전달하는 트래픽을 Discourse가 수용하도록 해야 합니다. 웹소켓 사용을 신경 쓰지 않는다면, NPM을 Discourse 컨테이너 IP의 포트 80(443이 아님)으로 가리키면 됩니다. 방법은 다음과 같습니다:
다만, 이것은 테스트해 보지 않았습니다. 언급했듯이 저는 웹소켓 설정을 사용하며, 이를 위해 몇 가지 추가 단계가 필요합니다. 웹소켓을 사용할 경우 위의 호스트명/IP와 포트는 무시됩니다.
5. 웹소켓 사용을 위한 app.yml 구성
이것은 OP에서 설명되어 있습니다, 따라서 여기서 자세히 다루지 않겠습니다.
6. NPM 컨테이너에 웹소켓 마운트
볼륨으로 마운트하여 NPM이 웹소켓에 접근할 수 있도록 해야 합니다: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. 이것이 기본 NPM Docker Compose 파일에 대한 마지막 변경 사항이므로, 제 환경에서 작동하는 최종 버전은 다음과 같습니다:
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
network_mode: bridge
ports:
- '80:80'
- '81:81'
- '443:443'
environment:
DB_MYSQL_HOST: "172.17.0.6"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "my-super-safe-pwd"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'my-super-safe-pwd'
volumes:
- ./data/mysql:/var/lib/mysql
7. NPM을 웹소켓 사용하도록 구성
마지막 단계: NPM이 웹소켓을 사용하도록 지시합니다. 기억하기로는 "Websockets support"를 단순히 켜는 것만으로는 부족했던 것 같아서, OP의 NGINX location을 “Advanced” 탭에 복사했습니다. 방법은 다음과 같습니다:
“Custom locations” 탭에서는 작동하지 않았습니다.
8. SSL 활성화 잊지 마세요
NPM의 SSL 구성은 매우 자명해 보이고, 프로세스의 어느 시점에 활성화하는지는 중요하지 않다고 생각하기 때문에 언급하지 않았습니다. 따라서 아직 하지 않았다면, 제 설정은 다음과 같습니다:
9. 최종 면책 조항
이 글을 쓰던 중, 웹소켓을 사용하는 경우 NPM과 Discourse가 같은 Docker 네트워크에 있을 필요가 없을 수도 있다는 생각이 갑자기 들었습니다. 현재 이를 확인할 시간이 없지만, 이것이 사실이라면 위의 2, 3, 4번 단계를 무시해도 작동할 것입니다.
지원 포럼의 가장 매혹적인 측면은 다음과 같습니다: 문제를 잘 설명하는 것이 질문을 게시하지 않고도 해결책으로 이어지는 경우가 많습니다. 그리고 이 경우, 저는 다른 사람의 질문에 답변하고 있었지만 제 자신의 질문에 대한 답도 찾았을 수 있습니다. 