Kubernetes에서 자체 호스팅 솔루션으로 마이그레이션

안녕하세요,

저는 그동안 Bitnami의 비공식 지원 이미지를 사용하여 Kubernetes 클러스터에서 Discourse를 운영해 왔습니다. 이제 Bitnami가 해당 이미지를 비추천(deprecate)하고 유료화(paywall)에 들어감에 따라, AWS에서 자체 호스팅(self-hosted) 솔루션으로 서버를 마이그레이션할 계획입니다.

커뮤니티에서 도움을 주시면 감사할 몇 가지 질문이 있습니다:

  • 현재 설치에 외부 Postgres DB를 사용하고 있으며, 이 구성은 그대로 유지할 예정입니다. 다만, Bitnami 설치 스크립트가 Discourse에 매핑하는 환경 변수를 통해 UI에서 일부 설정을 업데이트했습니다. 예를 들어 DISCOURSE_S3_BACKUP_BUCKET은 S3_BACKUP_BUCKET으로 매핑됩니다.
    • 필요한 yaml 파일에 Discourse 설정을 설정하는 것으로 충분한가요, 아니면 여전히 환경 변수를 사용해야 하나요?
    • UI에서 백업을 수행하면 실제로 무엇이 복원되나요? 데이터베이스가 업데이트되나요?
    • 완전히 새로운 데이터베이스를 새로 설치한 후 백업/복원을 수행하는 것이 더 나은가요?
    • 새 설치가 더 새로운 버전의 Discourse인 경우, 복원을 시도할 때 문제가 발생합니까?
  • 표준 설치 가이드는 Docker를 사용합니다. 표준 설치가 단일 VM에 Docker를 사용하는 것으로 보이는데, 프로덕션 환경에서 컨테이너를 어떻게 모니터링하나요?
  • 마이그레이션 과정과 주의사항을 자세히 설명하는 문서가 있나요?

마이그레이션이 진행되면서 더 많은 질문이 생길 것 같지만, 조언이나 도움이 주신다면 정말 감사하겠습니다.

감사합니다.

이미 그렇게 계획하고 계셨다면 모르겠지만, 기존 사이트가 깨지지 않도록 마이그레이션을 위해 새 데이터베이스(서버가 동일하더라도)를 사용하는 것을 권장합니다.

Bitnami가 정확히 무엇을 하고 있다고 생각하시는지 파악하기 어렵지만, ENV에서 설정해야 할 값은 DISCOURSE_S3_BACKUP_BUCKET입니다. app.yml에서 S3 변수를 올바르게 설정하는 방법은 업로드를 위한 S3 호환 객체 저장소 제공자 구성을 참고해 주세요.

"더 나은"이라는 것이 "기존 사이트가 손상되지 않고 다시는 작동하지 않는 상태가 되지 않을 것"을 의미한다면,答案是 네입니다. :wink:

YML 파일에 설정하세요.

네, 데이터베이스가 업데이트됩니다. 명령줄에서 백업 복원하기를 권장합니다.

그것이 원하시는 것입니다. 복원 대상 위치의 버전은 백업 버전과 동일하거나 더 최신이어야 합니다. 복원 후 데이터베이스가 마이그레이션됩니다.

이 정보가 필요하신 모든 내용일 수 있으며, 우리는 여기서 무료로 도움을 드릴 준비가 되어 있습니다. 직접적인 설정 지원이 필요하시다면 저에게 연락하시거나 Marketplace 채널에서 도움을 요청하실 수 있습니다.

또 다른 옵션은 이미지를 빌드하고 k8s에서 이를 실행하는 것입니다. 저는 몇 번 그렇게 해봤으며, 이미지 빌드에 github를 사용했습니다.

제 경험상에도 동의합니다. 지난 몇 년간 수많은 기이한 작은 실패들을 목격해 왔기 때문에, 항상 처음부터 시작하여 사이트를 복원할 수 있도록 완전한 백업을 유지하고 있습니다. 문제를 현장에서(in situ) 해결하는 데 의존하는 것은 결국 당신을 배신할 것입니다.

당신과 마찬가지로, Bitnami가 무료 이미지와 차트를 제공을 중단했을 때 난감한 상황에 빠졌습니다. 수많은 배포 환경을 적응시키고 이관해야 했습니다. 그중 하나가 제 Discourse 배포 환경이었습니다. 유용하시다면, 제가 아주 짧은 시간 안에(즉, 작동은 하지만 이상적인 설계와는 거리가 먼) 만든 대체 Helm 차트 링크를 공유합니다. 이 차트는 수년 동안 “커뮤니티 표준” Helm 차트가 등장하지 않았기 때문에 “공식 설치 방법”을 사용하려는 시도입니다. (Bitnami의 차트가 사실상 그 표준이었을 것이라고 추측합니다. 왜냐하면 우리 중 거의 아무도 이 갑작스러운 변화를 예측하지 못했기 때문입니다.) 어쨌든, 제 연구 커뮤니티 중 하나에서 실행 중인 이 새로운 차트는 기본적으로 두 개의 컨테이너를 가진 팟(pod)입니다: 공식 Docker-in-Docker 컨테이너와 python:3 기반으로 Docker를 설치한 후 공식 Discourse 설치를 사용하는 커스텀 컨테이너입니다. 모든 구성 요소(Discourse 서버, Redis, PostgreSQL)가 런처 스크립트에 의해 로컬로 빌드된 이미지의 블랙박스 내에서 실행되므로, 확장성이나 고가용성(HA)에 대한 지원이 없습니다. 팟이 다른 노드로 재생성될 때(예: OS 업데이트를 위해 노드 드레인 또는 노드 충돌) 발생하는 다운타임을 줄이기 위해, docker save를 사용하여 빌드된 이미지를 영구 볼륨에 저장하고, local_discourse/app:latest가 발견되지 않을 경우 해당 이미지를 로드하도록 구성했습니다.

그러나 당신의 질문에 답하자면, 이 새로운 배포 환경에서 무언가를 모니터링하는 방법을 모릅니다. “프로덕션”으로 실행하고 있지만, 제 커뮤니티는 작고 사용량도 중간 정도라 포럼이 잠시 오프라인이 되더라도 큰 문제가 되지 않습니다. 그럼에도 불구하고, 저는 셀프 호스팅을 포기하고 Communiteq이나 Discourse.org와 같은 서비스로 이관하는 것에 매우 가깝습니다.