가이드

작성자 Matt Connor 2026-08-12 · 업데이트됨 2026-08-26

VPS에 Discourse 설치하기: Docker 공식 가이드

Q: 도메인 이름 없이 VPS에 Discourse를 설치할 수 있습니까?

아니요. 배포된 설정에 따르면 Discourse는 IP 주소만으로는 작동하지 않으며, DISCOURSE_HOSTNAME가 반드시 필요합니다. Discourse는 해당 호스트 이름을 기준으로 절대 경로 링크를 생성하므로, IP 주소를 사용하면 링크가 깨지고 인증서 발급이 차단됩니다. 설치를 시작하기 전에 A 레코드를 생성하고, dig +short forum.example.com을 사용하여 서버 주소로 올바르게 해석되는지 확인하십시오.

Q: 직접 호스팅하는 Discourse는 어떻게 백업합니까?

관리자 페이지의 백업(Backups) 메뉴를 사용하거나, ./launcher enter app 실행 후 discourse backup을 실행하십시오. 아카이브 파일은 호스트의 /var/discourse/shared/standalone/backups/default/ 경로에 저장됩니다. 업로드를 포함하는 설정이 활성화되어 있는지 확인하고, /var/discourse/containers/app.yml를 아카이브와 함께 복사하여 다른 머신으로 옮기십시오. 사이트와 동일한 디스크에 저장된 백업은 해당 디스크 장애 시 함께 소실되므로 안전하지 않습니다.

VPS 환경에서 공식 Docker launcher를 사용하여 Discourse를 설치하는 방법을 설명합니다. app.yml 설정, SMTP 구성, RAM 및 스왑 요구 사항, 재빌드 과정 등 성공적인 배포를 위해 반드시 확인해야 할 핵심 사항을 정리했습니다.

VPS에 Discourse 설치하기: 단일 컨테이너, 단일 설정 파일

VPS에 Discourse를 설치하려면 프로젝트에서 제공하는 설치 프로그램을 실행하고, 간단한 마법사 질문에 답한 뒤 빌드가 완료될 때까지 기다리면 됩니다. Discourse는 Rails 애플리케이션, PostgreSQL, Redis, nginx를 포함하는 단일 Docker 컨테이너 형태로 배포됩니다. 이후 변경하게 될 모든 설정은 /var/discourse/containers/app.yml 파일 하나에 담기며, 모든 변경 사항은 재빌드 과정을 거쳐 사이트에 적용됩니다.

공식 설치 방식은 discourse_docker입니다. 이는 launcher 셸 스크립트와 일련의 YAML 템플릿으로 구성됩니다. Discourse는 사용자가 직접 작성한 Compose 파일을 지원하지 않으며, 컨테이너를 수동으로 분리하여 운영하도록 설계되지 않았습니다. 만약 Docker Compose로 VPS에서 서비스를 운영하는 방식에 익숙하다면, 이와는 다른 구조를 예상해야 합니다. 여기에는 docker compose up -d이 없으며, ./launcher rebuild app이 곧 배포를 의미합니다.

시작하기 전에 Discourse가 요구하는 사항

네 가지 요구 사항은 사용자가 자주 놓치는 부분이며, 로그인 페이지에 도달하기 전에 각각 문제가 발생할 수 있습니다.

메모리. 하나의 컨테이너가 PostgreSQL, Redis, Sidekiq 및 Ruby 웹 서버를 모두 실행합니다. 빌드 단계에서 에셋을 컴파일할 때는 실제 사이트 운영 시보다 더 많은 메모리가 필요합니다.
실제 도메인 이름. 제공되는 샘플 설정 파일에 명시된 대로 "Discourse는 IP 주소만으로는 작동하지 않습니다."
아웃바운드 메일 경로. 계정 활성화, 비밀번호 재설정, 관리자 초대 및 요약 메일은 모두 SMTP(Simple Mail Transfer Protocol)를 통해 발송됩니다.
호스트의 80번 및 443번 포트. 이미 운영 중인 프록시 뒤에 Discourse를 배치하기로 의도한 경우가 아니라면, 이 포트들은 비어 있어야 합니다.

ChartDiscourse published hardware requirements (official install docs, August 2026)

label

ram_gb

storage_gb

Documented minimum

Documented recommended

The data behind this chart

[
  {
    "label": "Documented minimum",
    "ram_gb": 1,
    "storage_gb": 10
  },
  {
    "label": "Documented recommended",
    "ram_gb": 2,
    "storage_gb": 20
  }
]

공식 설치 문서에서는 최소 사양으로 1 GB의 RAM(스왑 포함)과 10 GB의 디스크 공간을 제시하며, 권장 사양으로 2 GB의 RAM과 20 GB의 디스크 공간을 권장합니다. 첫 번째 수치는 설치를 완료하기 위한 최소한의 기준일 뿐, 커뮤니티를 원활하게 운영하기 위한 권장 수치가 아님을 유의하십시오. 이러한 차이가 발생하는 이유는 메모리 사용량의 정점이 트래픽이 아닌 빌드 과정에서 발생하기 때문입니다.

설치 전 도메인을 서버로 연결

사용할 호스트네임에 대한 A 레코드를 생성한 뒤, 서버에서 직접 해당 레코드를 확인합니다.

dig +short forum.example.com
curl -4 -s https://ifconfig.co

두 명령어는 동일한 주소를 출력해야 합니다. 설치 마법사가 호스트네임에 대해 연결 테스트를 수행하므로 두 결과는 일치해야 하며, 여전히 다른 곳을 가리키는 레코드가 있으면 테스트는 실패합니다. 2분 전에 생성한 레코드는 캐시되어 있을 수 있으므로, 마법사와 씨름하기보다는 이전 TTL(time to live)이 만료될 때까지 기다리십시오.

해당 레코드를 CDN으로 프록시할지 여부를 지금 결정하십시오. 프록시된 레코드는 서버 주소를 숨기며, 이 경우 컨테이너의 인증서 요청은 실패하게 됩니다. ACME(automatic certificate management environment) 챌린지에 Discourse가 아닌 프록시가 응답하기 때문입니다. 최초 설치 시에는 레코드를 프록시하지 않은 상태로 유지하십시오.

공식 설치 프로그램 실행

단일 명령어로 git을 설치하고, Docker 공식 설치 스크립트로 Docker를 설치하며, discourse_docker을 /var/discourse로 복제한 뒤 설정 마법사를 시작합니다.

wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

이미 서버에 Docker가 설치되어 있고 각 단계를 직접 확인하고 싶다면, 동일한 작업을 수동으로 수행하십시오.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

root 권한으로 실행하십시오. 일반 사용자 권한으로 시작하면 discourse-setup은 This script must be run as root. Please sudo or log in as root first. 오류와 함께 즉시 중단됩니다. 서버에 Docker가 설치되어 있지 않으면 수동 복제 과정에서 아무것도 설치되지 않으므로 Docker is not installed. Please install Docker first. 오류와 함께 중단됩니다.

설정 마법사가 묻는 내용과 기록하는 내용

2026년 8월 기준으로 discourse-setup은 얇은 래퍼(wrapper) 형태로 동작합니다. 이 도구는 호스트 네트워크와 Docker 소켓을 마운트한 상태로 discourse/setup-wizard:release를 컨테이너로 실행하며, 이를 통해 마법사가 구성 중인 시스템을 직접 검사할 수 있습니다. 마법사는 호스트 이름과 관리자 이메일 주소를 물어본 뒤, SMTP 블록 설정을 요구합니다. 이후 containers/app.yml를 기록하고 재빌드를 수행합니다.

시작하기 전에 알아두어야 할 두 가지 동작 방식이 있습니다. 시스템 메모리가 부족하고 스왑(swap)이 설정되어 있지 않으면, 마법사는 작업을 중단하고 스왑 생성을 제안합니다. 이때 래퍼는 2 GB 크기의 /swapfile을 생성하여 /etc/fstab에 추가하고, /etc/sysctl.d/30-discourse-swap.conf에 vm.swappiness = 10을 설정한 뒤 마법사를 다시 시작합니다. 마법사가 완료되면 Rebuilding app in 5 seconds (Ctrl+C to cancel)...을 출력하고 호스트에서 ./launcher rebuild app을 실행합니다. 소규모 VPS에서는 이 빌드 과정에 수 분이 소요되며, 모든 에셋을 처음부터 컴파일해야 하므로 첫 번째 빌드가 가장 오래 걸립니다.

./discourse-setup --help는 문제가 발생했을 때 유용한 플래그 목록을 보여줍니다. --skip-rebuild은 빌드 없이 설정을 기록하기만 하며, --skip-connection-test는 DNS 및 포트 확인 과정을 건너뜁니다. --skip-connection-test는 테스트 실패 원인을 이미 알고 있는 경우에만 사용하십시오. 예를 들어, 호스트가 사용자가 직접 관리하는 네트워크 방화벽 뒤에 있는 경우가 이에 해당합니다.

첫 빌드 전 app.yml 확인하기

마법사가 생성한 파일은 이제 사용자가 직접 관리해야 합니다. sudo nano /var/discourse/containers/app.yml을 사용하여 파일을 엽니다. 이 파일의 항목들은 거의 모든 설정을 결정합니다.

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  ## Uncomment these two lines if you wish to add Lets Encrypt (https)
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

expose:
  - "80:80"   # http
  - "443:443" # https

env:
  DISCOURSE_HOSTNAME: "forum.example.com"
  DISCOURSE_DEVELOPER_EMAILS: "you@example.com"
  DISCOURSE_SMTP_ADDRESS: smtp.example.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: user@example.com
  DISCOURSE_SMTP_PASSWORD: "your-smtp-password"

DISCOURSE_HOSTNAME은 사이트가 응답할 주소이며, Discourse는 이 값을 기준으로 링크를 생성합니다. 따라서 잘못된 값을 입력하면 사이트가 한 번 로드된 후 다른 곳으로 리다이렉트되는 문제가 발생합니다. DISCOURSE_DEVELOPER_EMAILS은 쉼표로 구분된 목록이며, 여기에 기재된 주소는 첫 가입 시 자동으로 관리자 권한을 부여받습니다. 본인의 이메일 주소를 입력하고 해당 계정으로 가입하십시오. 이것이 첫 번째 관리자 계정을 생성하는 방법입니다.

이 파일은 SMTP 비밀번호를 일반 텍스트로 저장하므로 sudo chmod 700 /var/discourse/containers를 사용하여 해당 디렉터리의 접근 권한을 제한해야 합니다. 또한 YAML 형식에서는 공백이 곧 설정이므로, 키 정렬이 어긋나면 파싱 오류로 인해 빌드가 실패하고 사이트가 작동하지 않게 됩니다. 샘플 파일에도 명시된 주의 사항이 하나 있습니다. 따옴표로 묶이지 않은 비밀번호 내부에 #이 포함되면 그 이후부터는 주석으로 처리되므로, 해당 문자가 포함된 비밀번호는 반드시 따옴표로 묶어야 합니다.

이메일 설정은 설치 과정에서 가장 큰 걸림돌입니다

2026년 8월 기준으로 마법사를 통해 SMTP 설정을 건너뛰고 Discourse ID 로그인을 사용할 수 있으며, app.yml에는 이메일 설정 유효성 검사를 건너뛰는 기능을 하는 DISCOURSE_SKIP_EMAIL_SETUP 스위치가 포함되어 있습니다. 소프트웨어를 처음 살펴보는 단계라면 설정을 건너뛰는 것도 합리적입니다. 하지만 커뮤니티 운영을 위해서는 권장하지 않습니다. 발신 메일이 없으면 사용자가 계정을 활성화하거나 비밀번호를 재설정할 수 없기 때문입니다.

실질적인 문제는 대부분의 VPS 제공업체가 아웃바운드 25번 포트를 차단하고 있어, 서버에 직접 메일 서버를 구축해도 메일이 발송되지 않는다는 점입니다. 587번 포트나 암시적 TLS(transport layer security)를 사용하는 465번 포트에서 인증된 릴레이를 사용하십시오. 465번 포트의 경우 샘플 설정에서 권장하는 DISCOURSE_SMTP_FORCE_TLS: true을 설정하십시오. 재빌드하기 전에 호스트에서 연결 가능 여부를 먼저 테스트하십시오.

nc -vz smtp.example.com 587

정상적인 결과는 succeeded!로 끝나는 한 줄의 메시지입니다. 명령이 응답 없이 대기하다가 시간 초과가 발생한다면 VPS 외부로 나가는 경로에서 해당 포트가 차단된 것이며, Discourse 설정으로는 이를 해결할 수 없습니다. 제공업체가 허용하는 포트로 변경하거나, 해당 포트를 열어달라고 요청하십시오.

사이트가 가동되면 관리자 페이지의 이메일 메뉴에서 테스트 메시지를 발송한 뒤, 같은 페이지의 '건너뜀(Skipped)' 및 '반송됨(Bounced)' 탭을 확인하십시오. 이 탭들에는 Discourse가 발송을 거부했거나 릴레이 서버에서 거절된 메일이 기록됩니다. 로그를 일일이 읽는 것보다 이곳에서 사유를 확인하는 것이 훨씬 빠릅니다.

TLS: 컨테이너가 직접 인증서를 발급받게 설정

Discourse가 80번과 443번 포트를 직접 점유한다면 내장된 발급 기능을 사용하십시오. 위에서 언급한 두 개의 SSL 템플릿 줄의 주석을 해제한 뒤 재빌드합니다. 이 템플릿은 acme.sh를 구동하고, 인증서를 /shared/ssl 아래의 공유 볼륨에 저장하며, 컨테이너 내부에서 주기적으로 갱신하고, Discourse가 HTTPS를 강제하도록 설정합니다.

이 과정이 성공하려면 인터넷에서 80번 포트로 접근할 수 있어야 합니다. HTTP 챌린지 응답이 해당 포트에서 이루어지기 때문입니다. 443번 포트만 허용하는 방화벽을 사용하면 빌드는 완료되지만 인증서는 절대 발급되지 않습니다. 재빌드 직후 ./launcher logs app 명령어로 결과를 확인하십시오.

Nginx나 Caddy를 앞단에 배치해야 합니까?

VPS에서 Discourse만 단독으로 운영한다면 배치하지 마십시오. 컨테이너는 이미 최적화된 nginx를 실행 중이며, 두 번째 프록시를 추가하면 홉(hop)이 늘어나고, 갱신해야 할 인증서가 추가되며, 헤더 관련 버그가 발생할 새로운 원인이 생깁니다.

동일한 VPS에서 다른 사이트도 함께 운영한다면 프록시를 앞에 두십시오. templates/web.socketed.template.yml을 템플릿 목록에 추가하고, 두 개의 expose 라인을 주석 처리한 뒤, 두 개의 SSL 템플릿은 주석 처리된 상태로 둡니다. 그러면 컨테이너는 /var/discourse/shared/standalone/nginx.http.sock의 유닉스 소켓에서 대기하며 포트를 전혀 점유하지 않게 되어, 80번과 443번 포트를 사용자의 프록시가 자유롭게 사용할 수 있습니다.

server {
  listen 443 ssl;
  server_name forum.example.com;

  location / {
    proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
    proxy_set_header Host $http_host;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

.sock 뒤의 콜론은 nginx의 유닉스 소켓 문법의 일부이며, sudo nginx -t는 이 콜론이 없으면 설정을 거부합니다. X-Forwarded-Proto 또한 필수 항목입니다. Discourse는 절대 경로 링크를 생성하므로, 해당 헤더가 없으면 HTTPS 페이지에서 http:// 링크를 출력하게 되고, 브라우저는 이를 혼합 콘텐츠(mixed content)로 간주하여 차단합니다. 컨테이너가 소켓 방식으로 전환되면 TLS 관리는 사용자의 몫이 되므로, Ubuntu 24.04 및 nginx에서의 Certbot을 참고하여 호스트에서 인증서를 발급받으십시오. 아직 프록시를 결정하지 못했다면 nginx, Caddy 및 Traefik 비교 문서를 통해 각 선택의 장단점을 확인하시기 바랍니다.

리빌드, 업그레이드 및 실무에서 사용하는 명령어

cd /var/discourse
./launcher rebuild app

rebuild는 실행 중인 컨테이너를 삭제하고, app.yml에서 새로운 컨테이너를 부트스트랩한 뒤 실행합니다. 빌드하는 동안 사이트는 오프라인 상태가 되므로, 모든 설정 변경은 몇 분간의 계획된 점검 시간으로 간주해야 합니다.

env: 하위의 값만 변경하는 경우에는 리빌드가 필요하지 않습니다. ./launcher destroy app && ./launcher start app은 이미 빌드된 이미지로부터 컨테이너를 다시 생성하며, 이는 수 초 내에 완료됩니다. templates: 또는 hooks: 하위의 변경 사항은 이미지 자체를 수정하므로 전체 리빌드가 필요합니다.

업그레이드는 두 가지 방식으로 진행됩니다. 포인트 릴리스는 app.yml이 빌드 시점에 복제하는 docker_manager 플러그인이 제공하는 /admin/upgrade 웹 인터페이스에서 적용합니다. 베이스 이미지나 템플릿에 대한 변경 사항은 git을 통해 이루어집니다.

cd /var/discourse
git pull
./launcher rebuild app

리빌드 과정에서 소규모 서버가 실패하는 경우가 많은데, 이는 에셋 컴파일이 시스템 전체에서 메모리 사용량이 가장 많은 작업이기 때문입니다. 빌드가 중간에 멈추고 dmesg에 ruby 프로세스를 지칭하는 Out of memory: Killed process와 같은 줄이 표시된다면, 사이트가 이전에는 정상적으로 작동했더라도 빌드 도중 메모리가 부족해진 것입니다. 스왑(swap)을 추가하고 리빌드를 다시 실행하십시오.

./launcher logs app
./launcher enter app
./launcher cleanup

logs은 컨테이너의 출력을 출력하며, enter은 컨테이너 내부의 셸을 엽니다. cleanup는 24시간 이상 정지된 컨테이너를 삭제합니다. 리빌드할 때마다 이전 컨테이너가 남게 되어 소규모 VPS의 디스크 공간이 조용히 부족해질 수 있으므로, 가끔 cleanup을 실행하십시오.

백업 및 백업 파일에 포함되지 않는 항목

Admin의 Backups 페이지에서 백업을 수행합니다. 아카이브는 호스트의 /var/discourse/shared/standalone/backups/default/ 경로에 저장됩니다. 동일한 작업을 셸에서 직접 실행할 수도 있습니다.

cd /var/discourse
./launcher enter app
discourse backup

discourse restore <filename> 명령은 복원을 수행하며, discourse enable_restore 명령을 실행하기 전까지는 복원이 거부됩니다. 이 보호 장치는 실수로 입력한 명령이 운영 중인 포럼을 덮어쓰는 것을 방지하기 위해 존재합니다.

사용자가 직접 해결해야 할 두 가지 공백이 있습니다. 아카이브에는 데이터베이스가 포함되며, 업로드된 파일은 백업 설정에서 업로드 포함 옵션이 켜져 있을 때만 포함되므로 신뢰하기 전에 해당 설정을 확인하십시오. 아카이브에는 app.yml 파일이 포함되지 않으므로, 새 VPS에 복원할 때 여전히 호스트 이름과 SMTP 블록 설정이 필요합니다. 즉, 해당 파일도 서버 외부로 별도 복사해 두어야 합니다.

또한 아카이브는 보호 대상 사이트와 동일한 디스크에 저장되므로, 이를 진정한 의미의 백업이라고 할 수 없습니다. 일정을 설정하여 다른 곳으로 아카이브를 전송하십시오.

rsync -avz root@forum.example.com:/var/discourse/shared/standalone/backups/default/ ~/discourse-backups/

활발한 포럼이 사용하는 RAM 비용

부트스트랩은 감지된 메모리와 CPU를 기반으로 UNICORN_WORKERS 및 db_shared_buffers을 설정하며, 샘플 설정은 공유 버퍼를 전체 메모리의 4분의 1로 제한합니다. 각 unicorn 워커는 완전한 Ruby 프로세스이며 Sidekiq은 그 옆에서 백그라운드 작업을 실행하므로, 메모리 사용량은 등록된 회원 수가 아니라 동시 요청 수에 따라 결정됩니다. 수백 명의 회원이 있는 조용한 포럼은 부하가 크지 않습니다. 보통은 같은 서버를 공유하는 다른 서비스가 더 중요하며, 만약 사진 라이브러리가 있다면 PhotoPrism과 Immich 비교에 명시된 RAM 최소 요구 사양을 통해 Discourse 재빌드를 완료할 여유 공간이 있는지 확인할 수 있습니다.

이 글을 포함하여 기사에 나온 수치만으로 서버 크기를 결정하지 마십시오. 직접 측정해야 합니다.

free -m
docker stats --no-stream

스왑이 지속적으로 사용되면서 페이지 응답이 느려진다면 RAM이 부족하다는 신호입니다. 메모리 사용량은 일정한데 페이지 응답이 느리다면 다른 원인이 있을 가능성이 크므로, 더 상위 플랜을 구매하기 전에 ./launcher logs app을 먼저 읽어보십시오. 외부에서 상태를 확인하는 점검 항목도 추가하십시오. 새벽 3시에 메모리가 부족해 포럼이 조용히 중단되는 상황을 방지하기 위해, 별도의 호스트에서 Uptime Kuma 상태 모니터를 운영하면 회원들이 알기 전에 관리자가 먼저 문제를 파악할 수 있습니다.

Discourse가 적합하지 않은 경우

Discourse는 설치 규모가 크고 app.yml에 위치한 설정을 변경할 때마다 재빌드 과정을 거쳐야 하는 무거운 애플리케이션입니다. 이러한 비용을 지불하는 이유는 강력한 중재 도구와 방대한 아카이브에서도 정상적으로 작동하는 검색 기능을 얻기 위함입니다. 30명 정도의 인원이 대화할 공간이 필요한 경우라면, Discourse는 대화 규모에 비해 지나치게 과한 시스템입니다. 먼저 셀프 호스팅 포럼 소프트웨어 비교 문서를 읽어보십시오. Discourse를 선택할 때는 단순히 익숙한 이름이기 때문이 아니라, Discourse가 제공하는 기능이 반드시 필요할 때 선택해야 합니다.

FAQ

도메인 이름 없이 VPS에 Discourse를 설치할 수 있습니까?

아니요. 배포된 설정에 따르면 Discourse는 IP 주소만으로는 작동하지 않으며, DISCOURSE_HOSTNAME가 반드시 필요합니다. Discourse는 해당 호스트 이름을 기준으로 절대 경로 링크를 생성하므로, IP 주소를 사용하면 링크가 깨지고 인증서 발급이 차단됩니다. 설치를 시작하기 전에 A 레코드를 생성하고, dig +short forum.example.com을 사용하여 서버 주소로 올바르게 해석되는지 확인하십시오.

설치를 완료하려면 SMTP를 설정해야 합니까?

2026년 8월 기준으로 설정을 건너뛸 수 있습니다. 설치 마법사에서 대신 Discourse ID 로그인을 제공하며, app.yml에는 이메일 설정 유효성 검사를 건너뛰는 스위치가 포함되어 있습니다. 초기 확인 이후의 모든 단계에서는 SMTP를 설정해야 합니다. 계정 활성화와 비밀번호 재설정은 모두 이메일을 통해 이루어지기 때문입니다. 대부분의 VPS 제공업체는 아웃바운드 25번 포트를 차단하므로, 587번 또는 465번 포트에서 인증된 릴레이를 사용하십시오.

Discourse 재빌드(rebuild)가 도중에 실패하는 이유는 무엇입니까?

주로 메모리 부족이 원인입니다. 빌드 중 에셋을 컴파일할 때는 운영 중인 사이트보다 더 많은 메모리가 필요하므로, 포럼을 운영하기에 충분한 사양의 서버라도 재빌드 시에는 실패할 수 있습니다. dmesg 실행 결과 Out of memory: Killed process에서 ruby 프로세스가 언급된다면, 스왑을 추가(마법사에서 제공하는 스왑 파일은 2 GB입니다)한 뒤 ./launcher rebuild app를 다시 실행하십시오. YAML 오류로 빌드가 중단된다면 app.yml의 들여쓰기 오류일 가능성이 높습니다.

Discourse를 직접 운영하는 Nginx나 Caddy 뒤에 배치해야 합니까?

VPS에서 다른 사이트도 함께 운영하는 경우에만 그렇게 하십시오. 서버를 단독으로 사용하는 경우, 컨테이너가 80번과 443번 포트를 점유하고 자체 인증서를 발급하게 두는 것이 관리 요소를 줄이는 방법입니다. 서버를 공유해야 한다면 templates/web.socketed.template.yml을 추가하고 expose 라인을 주석 처리한 뒤, /var/discourse/shared/standalone/nginx.http.sock의 유닉스 소켓으로 프록시를 설정하십시오. X-Forwarded-Proto를 전달하지 않으면 Discourse가 HTTPS 페이지에서 http:// 링크를 생성하게 됩니다.

직접 호스팅하는 Discourse는 어떻게 백업합니까?

관리자 페이지의 백업(Backups) 메뉴를 사용하거나, ./launcher enter app 실행 후 discourse backup을 실행하십시오. 아카이브 파일은 호스트의 /var/discourse/shared/standalone/backups/default/ 경로에 저장됩니다. 업로드를 포함하는 설정이 활성화되어 있는지 확인하고, /var/discourse/containers/app.yml를 아카이브와 함께 복사하여 다른 머신으로 옮기십시오. 사이트와 동일한 디스크에 저장된 백업은 해당 디스크 장애 시 함께 소실되므로 안전하지 않습니다.

#discourse #forum #self-hosting #docker #community