Rebuild를 실행했지만 아무 변화가 없어요. 여전히 HTTPS가 거부되고, 게다가 HTTP에서는 다시 NGINX 환영 페이지로 돌아갔습니다.
nginx가 설치되어 있는 것은 확실합니다.
다음 명령어를 시도해 보셨나요?
apt purge nginx
또는
dpkg -l |grep nginx
nginx를 완전히 종료한 후 ./discourse-doctor는 어떤 결과를 출력하나요?
응답: nginx가 설치되어 있지 않음
응답: 아무것도 없음
모든 입력 항목(이메일, 웹 주소 등)이 비어 있습니다.
그리고 포트 80 → 80, 443 → 443, 2222 → 22에서 컨테이너 2개가 실행 중입니다.
discourse 컨테이너 앱이 실행 중이라고 표시됩니다.
그리고 Discourse 버전이 NOT FOUND(찾을 수 없음)라고 표시합니다.
아, 아래로 스크롤을 안 했네. 출력 텍스트를 읽어보고 뭐라고 되어 있는지 확인해볼게.
수정: 같은 내용이 나와 있어
./discourse-setup을 실행하여 이 설치를 시작하셨나요?
그 컨테이너들은 무엇인가요?
설치 과정을 거쳤다는 뜻(거쳤습니다)이신가요, 아니면 제가 실행한 ./discourse-doctor를 실행하지 않았다는 뜻이신가요.
실수했습니다. 하나뿐이었고, 4efab95a60b8입니다.
이제 HTTP 페이지에는 데이터를 전송하지 않았다고만 나와서, 이제 NGINX 페이지조차 보이지 않습니다.
수정: 다시 nginx 페이지로 돌아왔습니다.
수정2: 아니요, 그렇지 않습니다.
docker ps는 무엇을 표시합니까?
텍스트 파일과 완전히 동일한 컨테이너입니다.
아마도 이 시나리오에서는 caddy를 사용한 리버스 프록시가 더 나을 수 있습니다?
그것이 무엇인지 이름이 궁금했습니다. 이 번호는 의미가 없습니다.
과거에 caddy를 성공적으로 사용해 본 적이 있습니다. 하지만 아마도 같은 문제가 발생할 가능성이 높습니다.
제안 하나 드립니다.
DigitalOcean에서 5달러짜리 드롭렛에 가입해 보세요. 설치 가이드를 그대로 따르되, 추가 인증서를 복사하거나 다른 작업을 하지 마세요.
DO 드롭렛은 시간 비례 과금 방식이라, 가이드를 따르는 데 걸리는 시간(30분 이내) 동안 설치 과정을 검증하는 데 드는 비용은 0.02달러에 불과합니다. 이후 인스턴스가 필요 없다면 그냥 삭제 버튼을 누르면 됩니다.
그래도 실패한다면 이제 문제를 해결해 나갈 수 있는 단서가 생기는 것입니다.
성공한다면 이는 Discourse의 문제가 아님을 증명하는 것입니다. 더 복잡한 환경을 선택하는 경우, 불행히도 그 환경이 초래하는 추가적인 문제들에 대한 책임도 함께 지게 됩니다. 표준 설치 방식은 DO의 Ubuntu 이미지에서 검증되었으며, 그 네트워크 정책은 Let’s Encrypt와 관련하여 문제를 일으키지 않습니다(다만, 이메일 전송을 위해 때때로 상당한 조치가 필요할 수는 있습니다).
참고로, 동일한 인증서 이름을 반복적으로 요청했다면 Let’s Encrypt가 해당 특정 FQDN을 쿨다운 상태로 설정했을 수 있습니다.
드디어 해결했습니다. 제가 한 작업은 다음과 같습니다. Caddy를 설치하고, URL로 들어오는 모든 연결을 localhost:444로 리디렉션하도록 프록시를 설정했는데, 그래도 해결되지 않았습니다. app.yml 파일에 들어가서 Port 항목을 다음과 같이 변경했습니다.
- "81:80" - HTTP를 포트 81로 이동하여 Caddy를 위해 예약
-"444:443" - Caddy가 HTTPS를 처리합니다
이렇게 하고 웹사이트에 접속하면 로딩이 되며, HTTPS 연결이 거부되지 않습니다!
도와주신 모든 분들과 조언을 남겨주신 분들께 감사드립니다!
다시 discourse를 설치해야 한다면 꼭 그렇게 할 예정입니다.