제 경험상에도 동의합니다. 지난 몇 년간 수많은 기이한 작은 실패들을 목격해 왔기 때문에, 항상 처음부터 시작하여 사이트를 복원할 수 있도록 완전한 백업을 유지하고 있습니다. 문제를 현장에서(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와 같은 서비스로 이관하는 것에 매우 가깝습니다.