머릿속에 몇 가지 아이디어가 떠올랐는데, 그중 하나는 플러그인을 설치하는 플러그인이었습니다. 이를 위해서는 포럼을 다시 빌드해야 합니다. Ruby를 사용해 다시 빌드하는 방법이 있을까요? 정말로 이걸 시도하고 싶지 않습니다:
p `cd ../../`
p `. /launcher rebuild app`
표준 설치 환경에서는 Discourse(그리고 따라서 플러그인)가 docker 컨테이너 내에서 실행됩니다. 해당 컨테이너는 호스트 파일시스템에 대한 완전한 접근 권한이 없으므로, 호스트의 /var/discourse 디렉터리에 접근하여 app.yml을 수정하거나 launcher를 실행할 수 없습니다.
그리고 설사 가능하더라도… 여기에는 순환 의존성(circular dependency) 문제가 있습니다. ./launcher rebuild를 실행하면 docker 컨테이너가 종료되고… 이는 플러그인에서 시작한 launcher rebuild 프로세스까지 종료하게 됩니다. 
여기에는 몇 가지 잠재적인 해결책이 있습니다. 예를 들어, 컨테이너 내부에서 config/launcher에 접근할 수 있도록 추가적인 docker 볼륨 마운트를 설정하는 방법 등이 있습니다. 하지만 이는 간단하지 않습니다.
기억이 정확하지는 않지만, 누군가 ‘플러그인 매니저’ 플러그인을 만든 적이 있는 것 같습니다… 당시에는 볼륨 마운트와 같은 항목을 추가하기 위해 app.yml에 몇 가지 수정이 필요했습니다. 하지만 현재 관련 주제를 찾을 수 없으므로 더 이상 유지보수되지 않는 것으로 추정됩니다. 혹시 다른 분이 링크를 찾아서 공유해 주실 수 있을까요? (아니면 전부 꿈이었을지도… 
)
CDCK 측에서는 고객이 자유롭게 설치/업데이트/제거할 수 있도록 하려면 테마를 사용하는 방향으로 기울어 있습니다. 사용자가 임의로 플러그인을 설치할 수 있게 하는 것은 옵션이 아닙니다. 같은 서버에서 실행되는 다른 고객들에게 영향을 미칠 수 있기 때문입니다.
네, 여기 있습니다:
음… 알겠습니다.
아, 맞다! 그 부분은 생각하지 못했네요!
Dashboard.literatecomputing.com은 app.yml(또는 web_only.yml)을 편집하고 재구축(실제로는 bootstrap, destroy, rebuild)을 수행하여 플러그인을 설치하고 제거합니다. 두 개의 컨테이너로 설치된 경우 다운타임은 최소로 줄어듭니다.
또한 docker와 postgres 업그레이드, docker prune 등을 수행합니다. 표준 설치를 관리하기 때문에 특정 도구에 종속되지 않으며, 실제로 무언가를 수행할 때(예: 잘못된 플러그인 설치)만 문제가 발생할 수 있습니다.
이는 ansible 플레이북을 구동하는 (비공개) discourse 플러그인입니다. 무료 트라이얼 그룹에 가입하여 무료(제한적인 지원 포함)로 사용할 수 있습니다.
이 플러그인은 단순히 저장소를 /plugins 디렉토리로 클론하는 것 같습니다. 흥미롭네요.
ProCourse Installer는 정말 훌륭했습니다! 일부 플러그인에 문제가 생긴 것은 아쉬울 따름입니다.
기존 컨테이너에 플러그인을 추가하려면 컨테이너 내에서 다음과 같은 작업을 수행할 수 있습니다:
cd /var/www/discourse/plugins
git clone my-plugin-url
rake db:migrate assets:precompile
sv restart unicorn
하지만 다음에 다시 빌드할 때 플러그인을 컨테이너와 app.yml 모두에 유지하는 문제는 여전히 남아 있습니다.
app.yml의 새로운 ENV 변수를 적용하기 위해 ./launcher destroy app;./launcher start app을 실행해본 적이 여러 번 있는데, 그때마다 “새” 컨테이너가 데이터베이스의 버전보다 뒤처져 있는 것을 발견했습니다. 누군가가 컨테이너 내의 일부 플러그인만 업그레이드하여, 이전 컨테이너에 있던 Discourse 버전과는 호환되지만 다시 빌드했을 때 얻게 되는 버전과는 호환되지 않는 상황이 되면 문제는 더 심각해집니다. . .
그래서 ProCouese 플러그인은 저장소를 클론만 했으며, 클론된 플러그인 폴더를 rm -rf로 삭제하려면 해당 플러그인 페이지를 통해만 제거할 수 있습니다.
실제로 개념 검증(Proof of Concept)으로서 꽤 잘 작동했습니다. 다만, 문제 해결을 더 어렵게 만들 수 있다는 지적이 있어 몇 가지 조정이 필요합니다. 예를 들어 프로코스 인스톨러에 접근하는 방법에 대한 커맨드 라인 정보나 더 나은 로그 파일이 필요할 수 있습니다.
장점으로는 프로코스 인스톨러를 삭제하거나 주석 처리만 하면 모든 플러그인을 간단히 비활성화할 수 있다는 것입니다. 하지만 현재는 깨져 있는 상태입니다.
조(Joe)에게는 매우 선진적인 아이디어들이 있습니다. 기억이 맞다면, 그는 초기 투표 후(Post Voting) 플러그인을 만든 사람이었습니다.