lega4
7월 12, 2024, 7:21오후
1
처음에는 Discourse를 거의 기본 설정으로 실행해 보았는데 꽤 잘 작동했고, 파일 업로드도 다른 작업도 수행할 수 있었습니다.
그런 다음 app.yml의 경로가 /var/discourse임을 깨닫고 /var/www/discourse로 변경한 후, 컨테이너를 중지하고 제거했으며 이전 폴더를 완전히 삭제했습니다. 그리고 다시 실행 중이긴 하지만… 이제 파일을 업로드할 수 없다는 것을 발견했습니다.
uploads 폴더에는 어떤 권한이 필요한가요? 수동으로 일부 변경은 할 수 있지만, 정확히 무엇을 해야 하는지 그리고 일반적으로 문제가 없는지 알고 싶습니다(새로 시작하는 경우 launcher가 올바른 권한을 설정하는 것을 처리해야 하지 않나요?)
로그에는 다음과 같은 nginx 오류가 있습니다.
2024/07/12 19:11:23 [crit] 76#76: *160552 stat() “/var/www/discourse/public/uploads/default/original/1X/971c712ff3f1758abc63ac777ad708042cc41ddf.png” failed (13: Permission denied), client: 172.17.0.1, server: _, request: “GET /phorum/uploads/default/original/1X/971c712ff3f1758abc63ac777ad708042cc41ddf.png HTTP/1.0”, host: “myhost.com ”, referrer: “https://myhost.com/phorum/admin/site_settings/category/branding ”
uploads의 권한은 다음과 같습니다:
drwxr--r--+ 3 discourse www-data 21 Jul 12 11:47 uploads
pfaffman
7월 12, 2024, 7:42오후
2
그것이 권장되는 방법입니다.
/var/www/discourse 경로는 컨테이너 내부의 discourse 경로입니다. /var/discourse는 컨테이너 외부에서 Discourse_docker를 위한 일반적인 경로입니다.
방금 시작하신 것 같으니, 이번에는 아무것도 이름 변경하지 않고 처음부터 다시 시작하시는 것을 권장합니다.
제 추측으로는 app.yml의 경로를 업데이트하지 않으셔서 존재하지 않는 것을 접근하려고 시도하고 있는 것 같습니다.
lega4
7월 12, 2024, 7:44오후
3
이 서버에는 다른 프로젝트들이 많이 있으며, 모두 /var/www 폴더에 잘 정리되어 있으므로 이 상태를 유지하는 것을 선호합니다
하지만 저는 업데이트했는데요? mounts에 넣어야 하나요, 아니면 어디에 넣어야 하나요?
Jagster
7월 12, 2024, 7:49오후
4
죄송하지만 도움을 드릴 수 없습니다. 하지만 거기에 Nginx가 없다는 건 확실해요
lega4
7월 12, 2024, 7:50오후
5
죄송합니다, 어떤 nginx를 말씀하시는 건지 이해가 안 됩니다. 로그는 Discourse의 nginx에서 온 것이며, 제 SSL 종료(SSL-terminating) nginx는 그 위에 있습니다.
Jagster
7월 12, 2024, 7:53오후
6
제 말의 핵심이 바로 그겁니다. 리버스 프록시인 nginx가 해당 경로에 있지 않다면, 왜 도커 컨테이너가 그 경로에 있어야 하죠?
컨테이너는 독립적으로 작동하며, 컨테이너에 대한 경로는 그 내부의 Nginx가 수행하는 작업에 영향을 주어서는 안 됩니다. 다른 부분도 함께 변경하셨나요?
Jagster
7월 12, 2024, 8:02오후
7
현재 내 상태를 확인해 봤습니다:
lrwxrwxrwx 1 root root 15 Jul 12 10:10 uploads -> /shared/uploads
예를 들어 /var/www/discourse/public/uploads/default/original/1X에 있는 이미지 하나를 보면 다음과 같은 형태입니다:
-rw-r--r-- 1 discourse www-data 7100 May 19 2022 08335563eac3a393e60a902d4d38cffdfa6d967d
이 정도는 압니다. 그렇지 않으면 Docker는 저에게 정말 거대한 수수께끼일 테니까요
lega4
7월 12, 2024, 8:08오후
8
그러니까 기본적으로 모든 사용자가 쓰기 가능한 상태인가요? 보안 측면에서 좋지 않은 것으로 간주되지 않나요?
pfaffman
7월 12, 2024, 8:09오후
9
앱의 app.yml에 있는 시크릿을 세상 전체에 노출할 위험을 감수하고 싶지 않을 것입니다.
Jagster
7월 12, 2024, 8:10오후
10
도커 안에서? 그렇게 생각하지는 않아요. 그리고… CDCK에서 계획하고 만들어 놓은 거니까, 그들이 무엇을 하는지 잘 알고 있을 거라고 믿어요
lega4
7월 12, 2024, 8:12오후
11
물론이죠, 하지만 저는 아무것도 서빙하지 않으니까요
내부든 외부든 권한은 동일합니다. 그리고 업로드 폴더가 마운트되어 있거든요.
lega4
7월 13, 2024, 9:58오전
12
음, 아무것도 작동하지 않아서 결국 uploads 폴더의 권한을 755로 변경했고, 이제 잘 작동합니다. 재빌드 후 업로드 자체는 (엔진 측면에서) 문제가 없었던 것 같지만, nginx가 해당 파일을 읽지 못하는 상황이었습니다.
Jagster
7월 13, 2024, 11:27오전
13
당신이 왜 이런 일을 하는지 완전히 이해하지는 못하겠습니다. 작은 실수만 해도 전 세계적으로 노출될 경로에 컨테이너를 배치하는 것은 당신의 선택입니다. 하지만 그건 당신의 선택이죠. 그런데 그 외의 모든 것은… 왜 그런 건가요?
Discourse 앞에 리버스 프록시를 두는 것은 정말로 사소한 일이고, 그렇게 하지 않는다면 당신의 설정은 그 모든 번거로움 없이 표준 설치 환경이 될 것입니다. 물론, 당신이 놀고 싶고 그것이 취미라면 모를까, 하지만 곧 누군가가 나타나 표준 설치 환경에 대해서만 지원을 받을 수 있다고 말할 것입니다. 그리고 가장 큰 문제는 실제로 아무도 당신이 무엇을 했는지, 혹은 왜 그렇게 했는지를 모른다는 점입니다.
lega4
7월 13, 2024, 11:30오전
14
"이렇게"라고요? 제 설정은 비교적 표준적인 편이에요
pfaffman
7월 13, 2024, 11:36오전
15
원한다면 파일을 업로드하여 해당 파일의 권한을 확인하고 복사할 수 있습니다.
여러 파일을 업로드한 다음 다음을 실행해 보세요.
find uploads -ls |less
Jagster
7월 13, 2024, 11:39오전
16
당신은 다른 일을 하려다 보니 생긴 문제를 고치고 있습니다. 표준적인 환경에서는 필요 없는 일이에요. 리버스 프록시를 사용해도 마찬가지입니다.
그래서 당신은 표준 환경에서 꽤나 먼 거리에 있습니다
다른 누구도 겪지 않는 버그가 당신 손에 있는 경우
당신이 뭔가 이상한 짓을 한 경우
아마도 버그일 수 있습니다. 그리고 당신은 안전(여러모로)한 경로를 사용하여 표준 설치 환경에서 확인했으며, 동시에 리버스 프록시를 올바른 방식으로 연결해 보았을 겁니다. 만약 그래도 문제가 해결되지 않는다면, 문제는 가상 호스트와/또는 포트에 있을 것이라고 단언할 수 있습니다. 하지만 만약 잘 작동한다면… 우리는 다시 “이상한 짓”이라는 옵션으로 돌아오게 되는데, 여기서 아무도 당신이 무엇을 했는지 모릅니다.
여기서 문제를 보시나요?
어쨌든 — 리버스 프록시를 사용하면 지원이 되지 않습니다 … 여기서는 그런 정책입니다. 하지만 다른 사용자들은 도와줄 수 있고, 실제로 자주 도와줍니다,
그리고 컨테이너 내부의 구조는 어떻게 되어도 상관없습니다.
도커 컨테이너도 마찬가지입니다.
