수정: @pfaffman 님이 @tophee 님이 이전에 작성한 내용을 기반으로 이 내용을 독립적인 주제로 다시 작성했습니다. 아직 제가 테스트를 해보지 않았고, Chris의 문구를 여기저기 이동했으므로, 실수가 있다면 대부분 @pfaffman 님의 책임일 가능성이 높습니다.
Run other websites on the same machine as Discourse 에 설명된 대로 수동으로 처리하는 대신 NGINX Proxy Manager를 사용해야 할 이유가 없다면요?
저는 이미 이를 사용하고 있습니다. 개인 서버에 꽤 오랫동안 사용하다가 Discourse 인스턴스를 새로운 클라우드 서버로 이전했을 때, 4년 전 구 서버에서 설정했던 NGINX 리버스 프록시 설정의 대부분을 잊어버렸다는 것을 깨달았습니다. 그래서 "NGINX Proxy Manager로 하면 어떨까?"라고 생각했죠. 놀랍게도 메타 포럼에서 이 도구가 언급되는 경우가 드물다는 것을 알게 되었고, 제가 놓친 단점이 있는지 궁금해지기 시작했습니다.
실제로 이 과정은 시행착오가 좀 필요했지만, 다음과 같이 작동하게 만들었습니다(이것이 최선의 방법이라는 보장은 없습니다. 사실 더 나은 방법이 있을 것이라고 확신합니다. 따라서 수정과 개선 제안은 매우 환영합니다):
우선, Discourse 인스턴스에 접근하는 방법은 두 가지입니다: 1. 포트 노출, 2. 웹소켓을 통한 접근. 이 포럼 어딘가에서 웹소켓이 더 빠르고 효율적이라는 것을 배운 것 같아서 웹소켓을 사용하고 있지만, 포트 노출이 훨씬 쉬울 것입니다. 따라서 웹소켓 작동을 설정할 수 없다면 포트 노출을 시도해 보세요. 혼동을 피하기 위해: 포트를 통해 Discourse에 접근하려면 아래 단계 0, 1, 2, 3, 4, 8을 따르세요. 웹소켓을 사용하려면 단계 0, 1, 5, 6, 7, 8, 9를 따르세요.
0. 시작점
30분 표준 설치를 완료했다고 가정하고, 아직 Discourse가 Let’s Encrypt 인증서를 발급받지 않았다고 가정해 보겠습니다. 리버스 프록시를 사용하는 경우 인증서가 필요 없기 때문입니다. NGINX Proxy Manager가 그 역할을 대신합니다. 이미 인증서가 있어도 상관없습니다. NGINX Proxy Manager가 단순히 새로운 인증서를 발급받게 될 뿐입니다.
1. NGINX Proxy Manager 설치
다음 단계는 NGINX Proxy Manager를 설치하여 두 개의 도커 컨테이너(NGINX Proxy Manager와 그 데이터베이스 컨테이너)가 추가로 실행되도록 하는 것입니다.
다음은 질문하신 부분인 다소 까다로운 부분입니다.
첫 번째 장애물은 Discourse가 기본 도커 bridge 네트워크에서 실행되는 반면, NGINX Proxy Manager는 기본적으로 “사용자 생성 네트워크”(제 경우 npm_default라고 불리는)에서 실행된다는 것입니다. 이는 NGINX Proxy Manager가 Discourse를 볼 수 없음을 의미합니다. 
2. 모든 컨테이너를 기본 bridge 네트워크로 이동
Discourse를 사용자 지정 네트워크로 이동할 수 있는지, 그리고 어떻게 해야 하는지 제가 알지 못하기 때문에, NGINX Proxy Manager를 기본 bridge 네트워크로 이동해야 합니다. 도커 컴파일 파일의 두 NGINX Proxy Manager 컨테이너에 network_mode: bridge를 추가하여 이를 수행할 수 있습니다.
3. 서비스 이름 대신 IP 주소 사용
다음 문제는 bridge 네트워크로만 이동하면 표준 도커 컴파일 파일이 더 이상 작동하지 않는다는 것입니다. NGINX Proxy Manager가 더 이상 데이터베이스 컨테이너를 찾을 수 없게 됩니다. 이는 서비스 이름에 대한 내부 DNS 해석(도커 컴파일 파일이 이에 의존)이 사용자 생성 네트워크에서만 사용 가능하고 기본 도커 네트워크에서는 사용 불가능하기 때문입니다. 따라서 하드코딩된 IP 주소를 사용해야 합니다(컨테이너 IP가 변경되면 깨지므로 이것이 확실히 최적의 해결책이 아닌 이유입니다). 따라서 컨테이너가 작동하지 않는다는 것을 알면서도 시작해야 하고, NGINX Proxy Manager 데이터베이스 컨테이너의 IP를 적어 두었다가 도커 컴파일 파일의 DB_MYSQL_HOST: "db"를 DB_MYSQL_HOST: "<db_container_IP>"로 교체해야 합니다.
이제 모든 컨테이너가 기본 bridge 네트워크에 있으므로 NGINX Proxy Manager가 Discourse와 데이터베이스를 모두 볼 수 있습니다.
4. Discourse 접근 가능하게 만들기
그러나 Discourse를 “보는” 것과 접근할 수 있는 것은 같은 것이 아닙니다. 따라서 NGINX Proxy Manager가 전달하는 모든 트래픽을 Discourse가 수락하도록 확인해야 합니다. 웹소켓 사용을 신경 쓰지 않는다면, NGINX Proxy Manager를 Discourse 컨테이너 IP의 포트 80(443이 아님)으로 지정하면 될 것입니다. 다음과 같이요:
다만, 이것은 테스트해 보지 않았습니다. 언급했듯이 저는 웹소켓 설정을 사용하고 있으며, 이는 몇 가지 추가 단계를 요구합니다. 웹소켓을 사용하는 경우 위 호스트명/IP와 포트는 무시됩니다.
5. app.yml을 웹소켓 사용으로 구성
이것은 OP(원문)에서 설명되어 있으므로 자세히 다루지 않겠습니다.
6. NGINX Proxy Manager 컨테이너에 웹소켓 마운트
볼륨으로 마운트하여 NGINX Proxy Manager가 웹소켓에 액세스할 수 있도록 해야 합니다: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. 이것은 기본 NGINX Proxy Manager 도커 컴파일 파일에 대한 마지막 변경 사항이므로, 제 환경에서 작동하는 최종 버전은 다음과 같습니다:
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. NGINX Proxy Manager를 웹소켓 사용으로 구성
마지막 단계: NGINX Proxy Manager가 웹소켓을 사용하도록 지시합니다. 기억이 정확하지는 않지만, 단순히 "Websockets support"를 켜는 것만으로는 부족했던 것 같아서 OP의 NGINX location을 “Advanced” 탭에 복사했습니다. 다음과 같이요:
“Custom locations” 탭에서는 작동하지 않았습니다.
8. SSL 활성화 잊지 마세요
NGINX Proxy Manager의 SSL 구성에 대해 언급하지 않은 이유는 꽤 자명해 보였고, 프로세스의 어느 시점에 활성화하는지는 중요하지 않다고 생각했기 때문입니다. 따라서 아직 하지 않았다면, 제 설정은 다음과 같습니다:
9. 주의 사항
요약하자면, Discourse 컨테이너를 재시작할 때마다 메인 NGINX Proxy Manager 컨테이너도 재시작해야 합니다(db 재시작은 불필요).
Discourse에 웹소켓을 통해 액세스하고 있다면, Discourse 컨테이너를 재빌드할 때(기본 이미지를 업데이트하기 위해 몇 개월마다 필요함) 이전 웹소켓이 삭제되고 새 웹소켓이 생성된다는 점을 알아야 합니다. 그 결과, NGINX Proxy Manager가 Discourse 인스턴스와 연결을 잃고 502 오류를 발생시킵니다. 향후 NGINX Proxy Manager 업데이트에서 새 웹소켓을 자동으로 찾을 수 있게 될 수도 있지만, 현재(2022년 1월) NGINX Proxy Manager는 NGINX Proxy Manager를 재시작하지 않으면 재빌드된 Discourse 컨테이너를 찾지 못합니다.
설명
위 지침이 왜 웹소켓과 포트를 결합하는지 궁금해하신다면, 단순한 이유는 이 글을 작성하면서 갑자기 NGINX Proxy Manager와 Discourse가 웹소켓을 사용하는 경우 같은 도커 네트워크에 있을 필요가 없을 수도 있다는 생각이 떠올랐기 때문입니다. 그리고 이것이 확인되었을 때, 아무도 지침을 완전히 다시 작성하고 싶어 하지 않았습니다.
지원 포럼의 가장 매혹적인 측면은 문제를 잘 설명하는 것이 질문을 게시하기 전에 해결책으로 이어지는 경우가 많다는 것입니다. 그리고 이 경우, 저는 다른 사람의 질문에 답하면서도 제 자신의 질문에 대한 답을 찾았을지도 모릅니다. 
하지만 NGINX Proxy Manager를 12초 이상 살펴본 결과, 잘 작동할 것 같다고 생각합니다. 이전에 논의된 적이 있는 또 다른 자동화 NGINX 프록시 도구가 있는데, 제 방대한 NGINX Proxy Manager 지식을 바탕으로 볼 때 그 도구가 더 나을 것 같습니다. Traefik에 점점 실망하고 있기 때문에, 그 도구를 살펴볼 수도 있겠네요.
). 요약하자면 모든 것이 올바른 방향으로 진행되었습니다. 그 후 웹소켓으로 Discourse가 실행되도록 수정을 진행했는데, 이번에도 모든 것이 잘 작동했습니다. 다행히 이전 Discourse 설정 시 자동 백업이 이루어져 있었기 때문에 몇 번의 클릭만으로 모든 것을 복원할 수 있었습니다(Discourse를 더 많이 사용할수록 더 좋아집니다!).