테스트 후 베타 버전은 결국 안정적인 릴리스로 배포됩니다. 코어에 대한 변경 사항의 규모에 따라 커맨드 라인을 통해 특수한 단계를 수행해야 할 수 있습니다.
VPS(가상 개인 서버)는 Discourse 설치 환경이 실행되도록 지불한 서버입니다. 가정용 PC에서 실행하는 경우를 제외하고, 이는 일반적으로 지원되지 않는 설치 환경이 될 가능성이 높습니다.
저는 VPS 제공업체로 Upcloud를 사용했습니다. 지금은 Cobtabo를 사용하고 있습니다.
충분한 테스트가 완료된 모든 베타 버전은 사람들이 '안정판(Stable)'이라 부르는 릴리스로 전환됩니다.
Moin이 제공한 링크에는 다음 항목이 있습니다.
호스팅된 Discourse 플랜은 일반적으로 최적의 보안과 안정적인 성능을 보장하기 위해 ‘테스트 통과’ 브랜치를 사용합니다.
잘못 들으신 거라면 죄송합니다. 하지만 VPS 같은 용어에 익숙하지 않으신 것으로 보아 이 분야에 매우 초보적인 단계이신 것 같습니다. Discourse를 직접 설치하셨나요, 아니면 기존에 있던 Discourse 포럼을 인수하신 건가요? 우리 모두 한때는 Discourse 설치 및 유지 관리에 대해 초보적이었습니다.
의견이 아닙니다. 당신이 선택하여 사용하는 소프트웨어라면 사실입니다. 이는 당신이 사용하는 대부분의 오픈소스 소프트웨어, 심지어 클로즈드소스 소프트웨어와도 동등한 수준입니다. 저는 VPS라고 썼습니다. Android는 V와 P를 대문자로 표기했습니다.
하지만 공평하게 말하면, 배우는 데 도움을 받고 싶지 않다면 결국 스스로 알아내야 할 것 같습니다.
행운을 빕니다! 
anon55243134 님이 거의 모든 게시물을 삭제한 것을 확인했습니다. 팀과 업데이트 스크립트 유지보수, 그리고 업데이트 관련 안내 측면에서 여기서 교훈을 얻을 수 있다고 생각합니다.
anon55243134 님은 수년간 자체 호스팅 Discourse를 운영해 오신 분인데, 업그레이드 프롬프트를 따랐을 뿐인데 설치가 손상되고 작동하지 않게 되었습니다.
만약 저에게 이런 일이 발생했다면 포럼 콘텐츠 손실 가능성 때문에 매우 화나고 당황했을 것입니다. 자체 호스팅을 선택한 이상, 그것이 가능하더라도 큰 돈을 지불해 문제를 해결할 준비가 되어 있거나 능력이 되지 않을 수 있습니다.
경고와 확인 절차가 부족하다고 생각합니다.
더 우려스러운 점은, 삭제된 게시물 중 하나에서 상당히 심각한 실패가 발생했는데도 이를 포착하지 못하고 스크립트가 계속 실행된 것을 볼 수 있다는 것입니다:
cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting
스크립트를 직접 확인해 보지는 않았지만, 존재하지 않는 항목이 발견된다는 것은 문제가 앞을 닥치고 있음을 의미하며, 이때는 중단해야 한다고 생각합니다.
기존에 해결된 문제를 다시 꺼내게 되어 죄송합니다! 제 경우엔 Ubuntu와 Postgres를 업그레이드한 후 /var/discourse 디렉터리에서 sudo ./launcher rebuild app을 다시 실행했는데, 모든 것이 정상적으로 재빌드되었고 사이트도 복구되었습니다.
이 문제를 해결하는 데 도움을 주신 모든 분들께 감사드립니다. 도움을 정말 감사히 생각하며, 이 커뮤니티가 없었다면 지금의 저는 없었을 것입니다.
감사합니다!
Discourse를 개선할 확고한 기회가 여기에 있습니다. 현재 7~8년 동안 안정적인 인스턴스를 운영해 온 결과, 서버 명령줄을 통해 업그레이드가 필요한 시기가 항상 있었습니다. 이는 문서에도 권장 주기와 함께 명시되어 있습니다.
그러나 문서의 접근성은 더 쉬울 수 있습니다. Document Categories 플러그인은 확실히 개선점입니다. 하지만 여전히 내 생각에는 더 좋아질 수 있다고 봅니다.
이 부분을 개선하기 위한 제 추천은 관리자 웹 인터페이스에 직접 링크를 추가하는 것입니다. 예를 들어 (?) 링크를 클릭하면 정보를 담은 팝업이 나타나고, 여기에 더 자세한 정보가 담긴 Meta의 토픽으로 연결되는 링크가 포함되도록 하는 것입니다.
업데이트 패널에서는 유사한 방식으로 추가 정보를 제공하는 것이 유용할 것입니다. 예를 들어 Core & Docker의 경우, 서버 명령줄에서 수행해야 한다는 필수 메시지와 해당 릴리스 노트 링크(요구 사항을 자세히 설명하는 첫 섹션 포함)를 제공하면서 버튼을 회색으로 처리할 수 있습니다. 즉, Docker 버전 X 및 Ubuntu LTS 버전 X(또는 공식 지원되는 동등한 Linux 배포판)입니다. 링크된 토픽에는 서버 명령줄에서 복사하여 붙여넣을 수 있는 항목도 포함해야 합니다.
스크립트의 경우 이것이 얼마나 쉽게 구현될 수 있을지 확실하지 않습니다. 하지만 초기 스크립트가 일부 기본 요구 사항을 확인하도록 하는 것입니다. 필요한 종속성이 없으면 메시지를 출력하고 종료하며, 어떻게 하는지에 대한 필요한 기본 정보에 대한 링크를 제공할 수 있습니다.
실패한 업그레이드 메시지는 더 직관적이어야 합니다. 이전 오류를 확인하려면 위로 스크롤하라고 안내하지만, 재빌드에 영향을 주지 않는 것으로 보이는 일반적인 오류들이 있음을 발견했습니다. 따라서 재빌드 실패의 원인이 된 주요 오류를 로그 파일로 내보내는 것이 훨씬 낫습니다. 그러나 이 제안된 변경 사항은 상당한 노력과 시간이 필요할 것입니다.
#documentation:self-hosting에는 셀프 호스팅을 시작하기 전에 알아야 할 사항에 대한 소개와 함께 더 철저한 시작 가이드가 필요합니다. 예를 들어 Ubuntu LTS와 같은 운영체제에 대한 충분한 지식, 유지 관리 및 배포판 업그레이드에 대한 기본 정보, 백업의 모범 사례 및 직접적인 how-to 가이드 등입니다. 이러한 라이브 링크는 Meta로 연결되는 링크와 함께 Staff 카테고리에서 태그가 달린 토픽으로 추가될 수 있습니다.
Bloomberg는 기억이 맞다면 이 토픽에서 무슨 일이 일어났는지에 대한 좋은 토픽을 만들었습니다. 제 입장에서는 @anon55243134 에게 사과드립니다. 그러나 그들도 자신의 책임을 져야 합니다. 지원을 받으러 온다면, 모든 가능한 사람들이 가능한 해결책으로 안내할 수 있도록 말하는 것을 듣고 요청된 정보를 제공할 의향이 있어야 합니다.
우리는 모두 디자인 등이 더 좋아질 수 있다는 아이디어나 의견을 가질 수 있습니다. 하지만 우리가 원하는 변경 사항이 없을 때, 현재 그것이 어떻게 작동하는지 받아들여야 합니다.
손상된 다운타임이 얼마나 고통스러운지 잘 압니다. 얼마 전 제가 자원봉사자로 관리하는 클라이언트에서 문제가 발생했습니다. 서버가 너무 작아 앱을 재빌드할 수 없었고, 여기의 공간 확보 how-to로 해결할 수 없었음에도 불구하고 1개월 이상 청원했지만 무시당했습니다. 제가 경고했듯이 결국 서버는 주요 충돌을 겪었습니다. 그들은 결국 여기의 멤버에게 돈을 지불하여 문제를 해결했고, 이는 여유로운 공간이 있는 새 서버를 배포하는 것으로 이어졌습니다. 그들의 부주의로 인해 사이트는 2주 이상 다운되었습니다. 이후에는 메일 서버를 유지 관리하지 않아 사이트는 다운되지 않았지만, 알림 이메일의 부재가 많은 피해를 입혔습니다. 더 많은 이야기를 할 수 있지만, 이는 Discourse의 문제가 아닙니다. 셀프 호스팅의 문제입니다.
오래전에 템플릿 파일로 인한 재빌드 문제가 있었습니다. 로그는 템플릿 파일을 주석 처리하면 추측을 탐구할 수 있는 충분한 정보를 주었습니다. 제 문제를 해결하는 데 효과가 있었습니다. 여기에서 문제가 언급되었을 때 제가 한 일을 게시하여 팀이 문제를 식별하는 데 도움이 되었습니다.
모든 측면에서 우리는 개선하기 위해 노력해야 합니다. 문제를 해결하는 데 도움을 줄 경험과 기술을 가진 사람들의 말을 읽고 듣는 데 시간을 할애하세요. 제가 할 수 있는 일들에 대한 인식을 얻은 방법도 바로 그 때문입니다. 제가 경험하지 못한 것들(특히 Discourse의 복잡성으로 인해)은 최선을 다해 조사하고 도움을 요청하며, 이 놀라운 소프트웨어를 더 잘 이해하는 여기의 모든 사람의 조언을 따릅니다.
@anon55243134 만약 여러분이 기회를 줄 의향이 있다면, 우리는 모두 여러분이 다시 온라인으로 돌아올 수 있도록 도울 수 있습니다. 이 과정에서 "우리가 어떻게 생각하느냐"로 벗어나지 않고, 당분간 "현재 어떻게 되어 있는가"를 받아들여야 합니다. 문제가 해결된 후에는 배운 교훈을 되돌아보고, 잠재적으로 상황을 개선하는 방법에 대한 권장 사항에 대한 좋은 논의를 시작할 수 있습니다. 그리고 팀이 수용적이라면(보통 그렇습니다) 다른 프로젝트가 진행 중이므로 상당한 시간이 필요할 것이라는 점을 받아들여야 합니다. 우리 쪽에서는 아이디어를 작업할 수 있고, 실제 노하우를 가진 사람들은 시간이 있다면 how-to, 모범 사례 등에 필요한 일부 정보를 작업할 수 있습니다.
함께하면 모두가 더 많은 것을 이룹니다. 결정하지 않으면 우리는 거의 아무것도 성취하지 못합니다.