물론 저에게도 이런 질문이 떠올랐습니다. Discourse가 이미 도커 컨테이너로만 배포되고 있는 상황에서, 팀이 “클라우드 네이티브” 도커 이미지를 유지보수할 가능성이 있을까요?
bitnami 이미지와 여러분의 이미지 사이에서 가장 큰 차이는 운영 모드입니다. 현대적인 인프라는 설치를 자동화할 수 있기를 기대합니다. 보통 k8s에서는 helm을 통해, 그리고 VM을 사용하는 비교적 전통적인 환경에서는 ansible 배포를 통해 동일한 결과를 얻습니다. 따라서 현재 다소 방치된 bitnami 이미지와 동등한 수준으로 Discourse를 끌어올리기 위해서는 자동 설치 루틴을 추가하고, 경우에 따라서는 helm 템플릿을 수정해야 할 것입니다.
여기 계시는 김에, Discourse 자체와 그 "클라우드 준비 상태(cloud readiness)"에 대한 피드백도 남기고자 합니다.
일반적으로 현재 고객 프로젝트에서 Discourse를 재현 가능한 설정에 통합하려는 시도를 해본 결과, Discourse가 현대적인 인프라의 관점에서 설계되지 않았다는 점이 빠르게 드러났습니다. 한 가지 예로, 공유 NFS 스토리지가 필요합니다. 이는 신뢰할 수 없을 뿐만 아니라 확장성도 떨어집니다. 다행히 이 중 대부분은 이미 S3로 리디렉션할 수 있지만, 플러그인 부분은 여전히 남아 있습니다.
플러그인 문제를 해결하는 방법은 세 가지가 있습니다:
데이터베이스에 저장된 평가 코드(권장하지 않음)
Discourse 컨테이너 시작 전에 휘발성 스토리지(예: tmpfs)에 쓰는 사전 패키지화된 사이드카 컨테이너(kubernetes 용어로는 emptyDir에 쓰는 initContainers로 사용됨, 비록 매우 편리하지는 않지만 권장됨)
시작 시 데이터베이스에서 현재 플러그인 정보와 설치 명령을 가져오고, 런타임에도 플러그인을 설치하는 워처/리스너 루틴을 갖춘 설치 루틴(권장하지 않음, 매우 느리고 오류가 발생하기 쉬움)
음, 이미 답변이 있었습니다: 다행히 이 중 대부분은 이미 S3로 리디렉션할 수 있지만, 플러그인 부분은 여전히 남아 있습니다. 사용 중인 Helm 차트를 통해 적절하게 업그레이드하지 못할 위험을 높이기 때문에, 사전에 컨테이너를 빌드해 사용하는 것은 잘못된 관행입니다.