스테이징 서버를 설정할 때 도움이 되는 몇 가지 팁이 있습니다.
스테이징 서버란?
스테이징 서버는 기본적으로 프로덕션 사이트의 클론입니다. 이 역시 서버에 위치하며 동일한 방식으로 작동합니다. 일반적인 Discourse 사이트와 마찬가지로 Docker 컨테이너 내에서 실행됩니다.
이것은 위험한 사항을 시도하거나, 사용자에게 쉽게 숨길 수 없는 사항을 시험해 볼 수 있는 장소를 제공하기 위해 존재합니다. Discourse Advertising Plugin (Ads) 를 사용하여 광고를 시험하거나, 포럼 가져오기나 병합과 같은 특별한 작업을 수행하려는 경우 매우 유용합니다.
이것은 개발 서버와 대비됩니다. 개발 서버는 일반적으로 개발자가 안전하게 코드를 조정할 수 있도록 쉽게 접근할 수 있는(또는 샌드박싱된) 장소에서 실행됩니다.
무엇이 필요한가요?
-
표준 셀프호스팅 설치를 위해 필요한 모든 것
-
S3 백업이 설정되어 있다면 작업이 훨씬 쉬워집니다
- 그렇지 않다면 SSH를 통해 서버로 대용량 파일을 넣고 빼는 방법이 필요합니다
단계
원하는 대로 서버를 설정하세요
일반적으로 Digital Ocean에 호스팅된 가상 Ubuntu 서버를 사용하지만, 익숙한 도구를 사용하면 됩니다.
Discourse 설치
이 가이드(또는 dashboard.literatecomputing.com)를 통해 설치합니다. ‘쓰레기’ 이메일 자격 증명을 사용하는 것을 권장합니다(이메일이 작동할 필요가 없거나 원하지 않기 때문이죠).
설치된 것이 작동하는지 확인하세요:
관리자 계정 생성 (필요한 경우)
명령줄에서 관리자 계정을 설정합니다. 이렇게 하면 이메일을 통한 인증 과정을 생략할 수 있습니다.
./launcher enter app
rake admin:create
명령줄에서 백업으로 복원할 수 있으므로, 설치 테스트를 제외하면 엄밀히 말해서 필수 사항은 아닙니다.
app.yml 편집 및 몇 가지 조정 추가
-
원래 app.yml의 사본을 만들어 두는 것이 좋습니다(저는
app.vanilla.yml이라고 부릅니다). 문제를 일으켰을 때 되돌릴 수 있습니다. -
env섹션의 끝에 다음 줄을 추가하세요:## Staging server specific settings DISCOURSE_BACKUP_FREQUENCY: 0 DISCOURSE_LOGIN_REQUIRED: true DISCOURSE_DISABLE_EMAILS: 'yes' DISCOURSE_S3_DISABLE_CLEANUP: true DISCOURSE_ALLOW_RESTORE: true -
S3(또는 유사한) 백업이 구성되어 있다면 이것도 추가하세요(메인 사이트의 설정을 사용하세요)
## S3 Configuration DISCOURSE_S3_ACCESS_KEY_ID: 'your_key' DISCOURSE_S3_SECRET_ACCESS_KEY: 'your_secret' DISCOURSE_BACKUP_LOCATION: 's3' DISCOURSE_S3_BACKUP_BUCKET: 'your_backups_location' DISCOURSE_S3_REGION: 'your_s3_region' DISCOURSE_S3_DISABLE_CLEANUP: true그리고 S3 업로드도 수행하고 있다면:
DISCOURSE_ENABLE_S3_UPLOADS: true DISCOURSE_S3_UPLOAD_BUCKET: 'your_uploads_location'
4.在那里 계신 동안 프로덕션 사이트에 있는 것과 동일한 플러그인을 추가하는 것도 좋습니다.
-
재빌드 수행
./launcher rebuild app
스테이징 서버 관리
이제 S3 백업에 연결되어 있지만(백업을 덮어쓰지 않음), 복원이 쉽고, 어떤 상황에서도 누구에게도 이메일을 보내지 못하는 스테이징 서버를 갖추게 되었습니다. 완벽합니다!
새로운 백업을 스테이징 서버로 복원하고 마음껏 작업할 수 있습니다. 결과물이 마음에 들지 않으면 단순히 다시 복원하면 됩니다.
켜기 또는 끄기
스테이징 서버를 ‘켜진’ 상태로 장기간 두면 Google에 색인될 위험이 있으며, 사용자가 실수로 프로덕션 대신 여기에 로그인할 수 있습니다. 자격 증명은 프로덕션 사이트의 클론이므로 이는 매우 가능성이 높습니다.
이 두 가지 문제를 완화하는 간단한 방법은 Discourse를 단순히 꺼두는 것입니다:
./launcher stop app
그리고 사용 가능하도록 다시 켜려면:
./launcher restart app
업데이트
플러그인과 코드의 관점에서 정렬이 유지되도록 하려면 스테이징 서버와 프로덕션 사이트 모두를 동시에 업데이트/재빌드해야 합니다. app.yml 변경 사항도 마찬가지입니다.
S3를 사용하지 않는다면 백업을 서버 간에 수동으로 이동해야 합니다. 그리고 그것들은 큽니다!
테스트 서버 시드 데이터 생성
스테이징 서버가 필요하다면, Restore를 통해 실제 포럼의 실제 데이터로 채워 넣어야 합니다. 때로는 특정 데이터가 문제를 일으키는 원인이며, 다른 데이터 세트로 포럼을 테스트하면 잘못된 희망을 줄 수 있습니다.
그러나 Discourse가 어떤 모습인지 확인하기 위한 테스트 서버가 필요하다면, 가짜 데이터로 확인해 보고 싶을 수 있습니다. 그렇다면 이렇게 할 수 있습니다:
./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate
이것은 포럼에 가짜 데이터를 시드하여 원하는 테마와 플러그인으로 어떤 모습인지 볼 수 있게 해줍니다. 아직 포럼을 시작하지 않았다면, 이것이 어떤 모습일지 약간의 아이디어를 얻을 수 있습니다.
2단계 인증 관리
메인 사이트의 계정 사용자 이름/비밀번호는 스테이징 사이트에서도 잘 작동해야 하지만, 2FA의 경우 그렇게 깔끔하지 않습니다. 문제가 발생하면 2FA를 끄세요:
./launcher enter app
rake users:disable_2fa[<USERNAME>]
, but would this be a good opportunity to use 
