앱은 Discourse Docker 컨테이너 외부에 있지만 같은 서버에 설치됩니다. 그렇다면 이 작업을 수행하는 방법에 대한 세부 사항이나 가이드, 또는 안내를 공유해 주실 수 있을까요?
DE 플러그인/API를 사용하는 것보다 이렇게 하는 데에는 어떤 단점이 있을까요?
단점의 대부분은 이러한 연결이 쓰기 액세스에 사용될 수 있다는 사실과 관련이 있습니다. 이것이 요구 사항인가요?
통합에 데이터베이스에 대한 쓰기 액세스가 필요하면, 필요한 작업만 노출하는 플러그인을 작성하는 것을 고려해 보세요.
필수는 아니지만, 그 단점은 괜찮습니다. 
DE 플러그인을 사용하기 시작했는데, 불행히도 제 사용 사례에서는 일부 페이지에서 API를 통해 너무 많은 요청을 보내고 있어(사이트에 저 혼자 접속한 상태인데도) 직접 연결이 필요할 것 같습니다. 대부분 커스텀 쿼리인데, 이것이 영향을 미치는지 확실하지 않습니다. 그래도 DE 플러그인은 여전히 마음에 듭니다!
컨테이너 외부에서 Postgres DB에 직접 연결하는 가장 좋은 방법이 무엇인지 혹시 알고 계신가요? 포럼과 사이트가 모두 동일한 서버에 있어 도움이 될 수 있을 것 같습니다.
수정: DE 플러그인으로 인해 속도 제한(rate limit)에 걸리는 것 같습니다. 하지만 Sam이 요청이 같은 서버에서 오면 속도 제한이 적용되지 않는다고 말한 것으로 기억하는데, 여전히 그런가요?
가능하긴 하지만, 다른 앱이 테이블에 락을 획득하여 Discourse가 정상적으로 작동하는 것을 차단할 수 있습니다.
필요한 API 엔드포인트를 추가하는 새로운 플러그인을 사용하시거나, Discourse를 복제하고 여러분의 앱을 연결할 수 있는 별도의 PostgreSQL 인스턴스를 만들어 완전히 독립적인 구조로 전환하는 방법을 고려해 보세요.
정보 주셔서 감사합니다, Rafael. 저는 select 문만 사용하게 될 텐데, 제가 아는 한 select 문은 락을 걸지 않으므로 Discourse 측에서 테이블이 변경되는 경우(예: 업그레이드 시)에만 신경 쓰면 될 것 같습니다. 그때는 다른 앱을 일시적으로 꺼둘 수 있으니, 이렇게 하면 락에 대한 우려를 덜 수 있을까요?
데이터베이스 복제에 관해서는, 꽤 흥미로운 옵션인 것 같습니다. 실시간으로 수행할 수 있어서 데이터가 몇 분 정도만 지연되는 수준으로 유지할 수 있을까요? (최신 주제를 자주 가져와야 합니다. 사이트의 거의 모든 페이지에 주제가 표시되는데, 2분간 캐싱은 하지만 페이지/조건마다 캐시가 달라지고 이러한 유형의 페이지가 수백 개에 달합니다.) 또한 데이터베이스가 커지면 이 옵션이 더 이상 불가능해질 수도 있을까요? (다른 Discourse 포럼에서는 이미 데이터베이스가 몇 GB에 달합니다.)
(플러그인을 만드는 것은 여기서는 옵션이 되지 않을 것 같습니다. Data Explorer 플러그인보다 나은 점이 어디인지 모르겠고, 사실 Data Explorer 플러그인은 이 문제만 제외하면 거의 완벽합니다.)
이것이 작동하지 않는 이유에 대해 아이디어를 가진 분이 있을까요?
이 주제에서 @pfaffman과 @Nacho_Caballero의 게시글을 참고했고, 이 게시물에서 @mpalmer의 글을 참고했습니다: How to make the database (or part of it) accessible to a cloud data processor? 및 Accessing to the database from outside the container - #4 by mpalmer.
먼저 app.yml을 다음과 같이 수정했습니다:
expose:
- "127.0.0.2:5432:5432"
컨테이너를 다시 빌드했습니다. 컨테이너 내부에서 postgres 사용자의 비밀번호를 설정했고, 컨테이너 내부에서는 다음 명령어로 연결할 수 있습니다:
psql -h localhost -d discourse -U postgres
그러나 컨테이너를 나간 후 연결을 시도하면 다음과 같은 오류가 발생합니다:
# psql -h 127.0.0.2 -p 5432 -d discourse -U postgres
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
포트 번호를 다른 것으로 변경해 보았지만 동일한 문제가 발생합니다. 127 IP 주소는 docker ps와 Network Settings의 inspect에서 확인했습니다(독립형 Discourse 인스턴스 3개를 실행 중입니다).
IP 주소를 변경해 보면(다른 Discourse 포럼 중 하나의 IP로), (더 즉각적이고) 다른 응답/메시지가 반환되므로, 위의 설정이 부분적으로는 정확한 것으로 보입니다:
# psql -h 127.0.0.3 -p 5432 -d discourse -U postgres
psql: could not connect to server: Connection refused
Is the server running on host "127.0.0.3" and accepting
TCP/IP connections on port 5432?
제가 무엇을 잘못하고 있는지 아이디어가 있을까요? psql: server closed the connection unexpectedly를 검색해 보면 네트워크 문제인 것 같습니다 - 따라서 컨테이너 내부에서 다른 설정을 변경해야 하는 것일까요?
컨테이너 외부에서 이 문제를 해결한 방법은 SSH 터널을 사용하는 것입니다. 저는 postgres 사용자를 대신해 새로운 사용자를 생성하고 SSH와 postgres에 커스텀 포트를 사용했지만, 당신의 환경 설정에도 이 방법이 작동해야 합니다:
ssh -L 5432:localhost:5432 EXTERNAL_VPS_IP "psql -U postgres -d discourse -h localhost"
여기서 EXTERNAL_VPS_IP는 원격 서버에 연결할 때 사용하는 IP 주소입니다.
여전히 작동하지 않는다면, app.yml에서 노출된 IP를 docker ps에서 가져온 내부 컨테이너 IP 대신 docker bridge IP를 사용하도록 변경해 볼 수 있습니다. 이것이 필수적인지 확실하지는 않지만, 저는 이렇게 설정되어 있습니다:
expose:
- "127.0.0.1:5432:5432"
# 또는 커스텀 포트를 사용하는 경우: - "127.0.0.1:CUSTOM_PORT:5432"
그 후 컨테이너를 다시 빌드하는 것을 잊지 마세요.
결과를 알려주세요. 모든 것을 정상적으로 작동시키는 데 제게는 정말 오랜 시간이 걸렸지만(돌이켜 보면 아주 간단했습니다), 도움을 드릴 기꺼이 준비되어 있습니다.
정보 주셔서 감사합니다 @Nacho_Caballero… 특히 docker에 대한 링크가 아주 도움이 됐네요!
당신(그리고 다른) 스레드에서 주신 조언이 맞았던 것 같습니다. 아래 설정이 필요합니다:
expose:
- "127.17.0.1:5432:5432"
해당 링크에서 언급했듯이, Docker는 컨테이너의 올바른 IP로 자동으로 포워딩을 수행합니다(이 IP들이 동적이기 때문에 그럴 만하죠 - 저도 궁금했던 부분입니다). 대부분의 설정에서는 이것이 전부면 충분할 것 같습니다.
하지만 저는 이미 그걸 시도해 봤었거든요 - 그래서 제 문제가 무엇이었는지 궁금하시겠죠. 방화벽이었습니다!(psql: server closed the connection unexpectedly 오류를 알아본 것 같았어요!)
이제 모두 해결되었습니다 - 모두 감사합니다 
알아두니 좋네요! 해결하신 것 같아 기쁩니다. 방화벽이 iptables인가요? 포트를 어떻게 열었나요?
저는 firewalld를 사용하지만, iptables의 경우 다음과 같은 명령이 작동할 것입니다:
iptables -A INPUT -p tcp --dport xxxx -j ACCEPT
iptables -A OUTPUT -p tcp --dport xxxx -j ACCEPT