현재 공식 Discourse 배포 방식은 EC2 인스턴스 기반인 것 같습니다. 이제 Helm을 사용하여 Kubernetes 클러스터에 Discourse를 공식적으로 설정해야 합니다.
K8s는 지원되지 않으며, 대부분의 사용자에게는 불필요하게 복잡합니다. launcher를 사용하여 이미지를 빌드하고 Docker에 푸시한 다음, K8s가 해당 이미지를 사용하도록 구성해야 합니다. 또한 필요한 환경 변수 설정이 여러 가지 있습니다. 그리고 에셋을 사전 컴파일하여 S3에 푸시해야 합니다.
어떤 이유로든 K8s가 상황을 복잡하게 만든다는 데 동의하지 않습니다. EC2 기반 배포를 관리하는 것이 K8s 기반 배포보다 훨씬 더 복잡합니다. EC2 패치 적용은 매우 복잡해집니다. 다른 모든 애플리케이션이 K8s에 있는 상황에서, Discourse를 다른 플랫폼에서 유지하고 통합을 관리하는 것은 운영 팀에게 과부하가 됩니다. 특히 Discourse의 EC2 기반 배포도 컨테이너 기반 배포일 뿐인데, Discourse 팀이 K8s와 거리를 두게 만드는 복잡성이나 제한 사항이 무엇인지 확신할 수 없습니다.
제가 제공한 링크는 이러한 복잡성 중 많은 부분을 다루고 있습니다. Docker Compose가 안정화되기 전에 컨테이너 빌드용 "런처"를 개발했기 때문에, 이미지를 빌드하려면 이 런처를 사용해야 합니다.
업그레이드를 수행할 때 데이터베이스 마이그레이션을 두 단계로 진행해야 하는데, Kubernetes에서 이를 쉽게 수행하는 방법을 아직 확인하지 못했습니다. 저는 GCP에서 Kubernetes 배포를 몇 번 수행했고, Terraform으로 관리되는 EKS 배포를 돕기도 했습니다.
시스템 관리에 대해 전혀 모르는 사람들에게는 단일 VM과 단일 컨테이너가 유지보수가 쉽고, 셀프 호스터를 위한 주요 대상 사용자입니다. 이는 여기서 지원되는 유일한 설치 방법입니다.
Bitnami 이미지가 존재합니다. 여기서는 지원되지 않지만, 업데이트가 지연되고 플러그인이 설치되지 않는 것을 괜찮다고 생각하신다면 작동할 수 있습니다. Bitnami에서 이에 대한 도움을 받을 수 있습니다.