이 스레드와 다른 여러 스레드를 읽어봤는데, 지금까지도 Discourse 이미지를 ECS나 GKE, 혹은 원하는 컨테이너 오케스트레이션 플랫폼에 쉽게 배포해서 바로 작동하게 만드는 간단한 방법이 없는 것 같습니다.
저는 Terraform을 사용해 Elasticache 클러스터, RDS 인스턴스, ECS 클러스터를 관리하고 있습니다. "이것이 제 Discourse 이미지이고, 여기는 Postgres, Redis, SMTP 등에 연결하기 위한 환경 변수입니다"라고만 하면 되는 수준으로 간단하게 사용하고 싶습니다.
2020년 현재 이와 유사한 것이 존재합니까? 이전에도 이 주제에 대한 많은 논의가 있었지만 만족스러운 해결책이 나오지 않았던 것 같고, 여전히 컨테이너 관례를 무시하고 컨테이너를 사용하는 관용적인 방식과의 호환성을 깨뜨리는 Discourse의 맞춤형 스크립트에 묶여 있는 상태입니다…
2일 전에 비슷한 질문에 답변을 드린 적이 있습니다
이것은 잘못된 가정입니다. 언급된 모든 요소는 Discourse의 일부이며, 성공적인 설치를 보장하기 위해 컨테이너 내에서 Discourse가 직접 제어해야 합니다.
복잡한 멀티 컨테이너 시나리오로 넘어가는 경우, 이는 대량 자금력을 가진 대규모 고객에게만 _필요_하며, 이 경우 저희 엔터프라이즈 호스팅 서비스를 이용하시도록 권해 드립니다.
그렇다면 왜 컨테이너를 시작하고 오케스트레이터 역할을 수행하는 이런 이상한 부트스트랩 스크립트가 필요한가요?
Discourse 이미지가 환경 변수를 받아들이고, 엔트리포인트에서 해당 리소스들에 접근하여 필요한 테이블 등을 생성할 수 없나요? 외부 영속성 계층에 의존하는 다른 서비스/웹 앱들은 이러한 방식으로 컨테이너화에 성공한 사례가 있습니다. 단순히 ECS나 EKS 등에 배치하고 데이터베이스 위치 등을 지정하면 잘 작동합니다. Discourse에서도 이것이 가능한가요?
저희는 그 정반대입니다. 막대한 예산이 없는 비영리 조직이기 때문에, 모든 엔터프라이즈 앱을 단일 AWS ECS 호스트에 올려 비용을 최대한 절감하려는 것입니다. 하지만 이를 위해서는 개별 앱이 깔끔하게 컨테이너화되어 ECS 태스크 정의(Task Definition)로 정의될 수 있어야 하며, 즉 자체적인 Docker 이미지여야 합니다.
글쎄요, 어느 정도는 그렇습니다. Discourse는 월 5달러짜리 VPS에 간단한 단일 Docker 설치 이미지로 쉽게 들어갈 수 있는데, 그 금액에서 몇 센트나 아끼려고 설치 난이도와 지속적인 유지보수 복잡성을 크게 높이는 것이 정말로 그 수고에 가치가 있는지 모르겠습니다. 단순하게 유지하세요!
위 링크에서 설명하듯, 컨테이너를 빌드하고 Kubernetes로 실행할 수 있습니다. 플랫폼에 종속되어 있어 GKE 배포를 고집하는 몇몇 고객을 위해 GKE 배포를 수행한 적이 있습니다.
목표가 비용 절감이라면 월 5달러에서 10달러 정도의 비용이 드는 방식이 적합합니다.
저희 도구는 컨테이너 오케스트레이션을 관리할 전문 IT 인력이 없는 소규모 그룹이라는 가장 일반적인 사용자를 위해 최적화되어 있습니다.
다만, 완전히 클라우드를 활용하시려면 필요한 부분들이 준비되어 있습니다. 확인해야 할 소스 저장소는 다음과 같습니다:
해당 저장소의 samples/web_only.yml 파일에서는 외부 리소스를 사용하는 방법을 보여줍니다.
launcher 스크립트도 bootstrap 하위 명령을 통해 커스텀 Docker 이미지를 빌드할 수 있습니다.