AWS에 배포된 Discourse가 데이터베이스 URL에서 에셋을 가져오는 중

팀 여러분 안녕하세요

저는 AWS ECS에서 Discourse를 실행하고 있습니다. 애플리케이션을 실행하려고 할 때 브라우저의 콘솔 탭에서 아래 URL들로 인해 오류가 발생하고 있습니다. 누락된 설정 변경 사항이 있을까요?

Mixed Content: 'https://discuss-stage.tllms.com/finish-installation/register’에 있는 페이지는 HTTPS로 로드되었지만, 비보안 favicon 'http://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png’을 요청했습니다. 이 요청은 차단되었습니다. 콘텐츠는 HTTPS를 통해 서빙되어야 합니다.

위의 URL에서 discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com은 제 데이터베이스 엔드포인트입니다.

database.yml 파일에 위 엔드포인트를 입력했습니다.

Docker를 사용하여 ECS에 Discourse를 배포했습니다. 애플리케이션에 접근하려고 하면 네트워크 브라우저가 https://discuss-stage.tllms.com/ 대신 아래 URL들에서 리소스를 가져오고 있습니다.

이것은 database.yml 파일에서 사용되는 discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com RDS 엔드포인트입니다.

Mixed Content: ‘https://discuss-stage.tllms.com/’에 있는 페이지는 HTTPS로 로드되었지만, 비보안 favicon ‘http://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png’을 요청했습니다. 이 요청은 차단되었습니다. 콘텐츠는 HTTPS를 통해 서빙되어야 합니다.

다음 Content Security Policy 지시문: “script-src https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/logs/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/sidekiq/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/mini-profiler-resources/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/assets/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/brotli_asset/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/extra-locales/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/highlight-js/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/javascripts/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/plugins/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/theme-javascripts/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/svg-sprite/”을 위반하기 때문에 스크립트 ‘https://discuss-stage.tllms.com/assets/browser-detect.js’의 로딩이 거부되었습니다. ‘script-src-elem’이 명시적으로 설정되지 않았으므로 ‘script-src’가 폴백으로 사용됩니다.

S3 버킷의 잘못된 설정으로 보입니다.

Discourse를 어떻게 설치하셨나요? Discourse 공식 표준 설치를 사용하셨나요, 아니면 Bitnami 설치 문제 해결이었나요?

잘못 설정된 CDN이라고 봅니다.
config/discourse.conf 파일을 공유해 주실 수 있나요?
그리고 사이트 설정에서 c0fbtc를 검색해 보시고 결과가 나오는지 확인해 보세요.

제이, 안녕하세요.

저는 이를 일반 Rails 애플리케이션으로 설치했습니다. 아래는 제가 따랐던 단계입니다.

  1. GitHub 저장소를 클론했습니다.
  2. Bundle을 사용하여 gems를 설치했습니다.
  3. database.yml 파일을 수정하여 AWS RDS 엔드포인트를 가리키도록 했습니다.
  4. discourse.conf 파일을 수정하여 AWS Elasticache를 가리키도록 했습니다.
  5. 어디에서도 S3 버킷 구성을 사용하지 않았습니다.
  6. 코드를 Docker 컨테이너에 복사하여 ECS에 배포했습니다.

저는 미리 만들어진 Docker 이미지를 사용하지 않았습니다. 직접 Docker 이미지를 빌드했습니다.

설정 파일 삭제

이것은 맞지 않는 것 같습니다. 저라면 데이터베이스가 실제로 로컬에 있는지, 아니면 이상한 이름을 가진 건지 확인해 보겠습니다.

아래와 같이 설정해야 할 것 같습니다:

# db 서버의 호스트 주소
# 처음에 소켓을 사용하도록 시도하기 위해 빈 값으로 설정됩니다
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# discourse를 실행 중인 데이터베이스 이름
db_name = default

S3는 무엇에 사용되나요? 그리고 discourse_defaults.conf 파일을 변경하지 않고 discourse.conf 파일을 별도로 생성해야 하나요?

이것은 S3와는 아무런 관련이 없습니다.

discourse.conf 파일은 app.yml에서 생성되므로, 해당 파일에서 변경 사항을 적용한 후 다시 빌드해야 합니다.

Richard

https://github.com/discourse/discourse에서 discourse를 클론했습니다. 저장소에서 app.yml 파일을 어디에도 찾을 수 없었습니다.

모든 Discourse 설정이 사용하지 않으려는 discourse_docker를 가리키고 있습니다. 저는 제 자체 컨테이너를 구축하고 싶습니다.

(완벽하게 작동하는 수레바퀴를 다시 발명하려는 시도에 대해 경고합니다. 또한, 여기 있는 일부 사용자는 커뮤니티에 이롭지 않기 때문에 당신을 지원하는 데 대해 매우 열의가 없을 것입니다).

무엇을 하든, 결국 해당 값들이 discourse.conf에 올바르게 반영되는지 확인해야 합니다. 수동으로 편집했다면, 최소한 AWS 호스트명을 db_host에 넣고 db_name은 default로 두어야 합니다.

Richard님, 안녕하세요.

저는 Vijay와 같은 팀에서 일하고 있습니다. 여기서 우리가 해결하려는 구체적인 사용 사례는 Discourse를 포크하여 우리 회사 GitHub에 올리는 것입니다. 이후 AWS에 빌드 및 배포할 예정입니다. GitHub에 올려두려는 이유는 우리 요구사항에 맞춰 변경 사항을 자유롭게 적용할 수 있는 유연성을 유지하기 위해서입니다. 적용 가능한 부분에서는 기여를 하고자 합니다. Discourse 공개 저장소에서 Dockerfile을 찾을 수 없었기 때문에, Docker 이미지를 빌드하기 위해 자체적으로 Dockerfile을 작성하게 되었습니다. 또한, GitHub Actions를 사용하여 Docker를 AWS ECS 서비스에 배포하고 있습니다.

우리의 요구사항을 고려할 때, 다른 접근 방식을 사용할 수 있었을까요?

감사합니다.

네. 공식 discourse 및 discourse_docker 저장소를 사용하고 모든 변경 사항을 플러그인으로 구현하는 것을 권장합니다.

공식 discourse_docker를 사용하면 이 주제에서 다루고 있는 것과 같은 문제를 방지할 수 있습니다. 또한 Discourse를 포크하지 않고 모든 수정 사항을 별도의 플러그인에 유지하면 메인 브랜치에서 벗어나는 것을 방지하고, 모든 업스트림 변경 사항을 포크로 다시 가져오는 데 상당한 노력을 기울일 필요가 없습니다.

플러그인 개발의 학습 곡선은 몇 주 안에 업스트림 병합에 드는 노력과 균형을 이루게 되며, 그 이후로는 훨씬 더 효율적입니다.

공식 Discourse 저장소를 사용하면 관리형 호스팅도 고려해 볼 수 있으며, 도움이 필요할 때 사람들이 더 열정적(또는 비용이 덜 부담스러운)으로 도와줄 가능성이 높아집니다.

피드백 감사합니다. 몇 가지 추가 질문이 있습니다:

  1. 플러그인 방식을 사용할 경우, 플러그인으로 구현이 불가능한 특정 요구 사항에서 병목 현상이 발생할 가능성이 있나요? 예를 들어, 사용자 역할을 매우 맞춤화하여 관리하는 경우를 말씀드립니다.
  2. discourse_docker를 사용해 AWS 계정의 ECS에 배포할 경우, 끝에서 끝(end-to-end) 파이프라인은 어떤 모습일까요? 말씀드렸듯이 현재 우리는 GitHub Actions를 사용해 AWS 계정의 ECS에 배포하고 있습니다. 공개 저장소에서 AWS 자격 증명을 안전하게 보호하면서 사용할 수 있는 배포 전략이 있을까요?
  1. 플러그인은 Ruby의 몽키 패칭과 Ember 객체의 확장을 지원하므로, 결국 모든 것이 가능합니다.

  2. 제 전문 분야가 아니므로 이 부분은 다른 사람에게 맡기겠습니다.

항상 discourse_docker 저장소의 복사본으로 시작하세요. 해당 저장소 안에 app.yml 파일을 생성하세요.

discourse_docker 작업 복사본에서 launcher 스크립트의 bootstrap 하위 명령을 사용하여 docker 이미지를 생성하세요. docker 이미지를 docker 저장소에 push하세요. 해당 docker 이미지를 원하는 곳에 배포하세요.

필요하다면 플러그인을 작성하세요. 커스텀 플러그인을 다른 플러그인과 마찬가지로 app.yml에 나열하세요.

@ashish_rawat @Vijay_Vantipalli ECS에서 Discourse Docker를 어떻게 설정하셨나요? EC2 서버에서 시도해 보면 Discourse는 정상적으로 로드됩니다. 하지만 Discourse Docker 이미지를 ECR 레지스트리에 푸시하고 해당 이미지로 태스크를 생성하면 컨테이너가 실행되지 않으며 Exit Code 1만 표시됩니다. 일주일 넘게 막혀 있는 상태입니다. 조언을 듣고 싶습니다. 감사합니다!

이를 위해 별도의 RDS 인스턴스와 Redis 클러스터용 ElastiCache를 생성했습니다.

./launcher start-cmd app에 포함된 인수를 살펴보세요. ECS로 복사할 때 놓친 것이 있을 수 있습니다.

빠른 답변 감사합니다! 단순한 것을 놓치고 있는 것 같습니다. 말씀하신 대로 시도해 보겠습니다.

범위 밖의 질문이어서 죄송합니다. start-cmd 앱에서 찾은 “-e” 옵션을 추가해 보았지만, 다음과 같은 다른 인자들도 있습니다:

+ /usr/bin/docker run --shm-size=512m -d --restart=always 
-h <서버 IP> 
-e DOCKER_HOST_IP=172.17.0.1 
--name app -t -p 80:80 
-v /var/discourse/shared/web-only:/shared 
-v /var/discourse/shared/web-only/log/var-log:/var/log 
--mac-address <주소> local_discourse/app /sbin/boot

-v 옵션은 정말로 필수인가요?

네, 그것들은 볼륨 마운트입니다. Discourse 컨테이너 내부의 /shared 경로에 저장 공간이 제공되는 것은 반드시 필요합니다.