저는 /var/discourse에 표준(수정: 개발용이 아닌) Docker 설치 환경을 갖추고 있습니다. app.yml에서 원격 GitHub 저장소를 링크하는 대신, 로컬 플러그인 디렉터리를 사용하여 Discourse에 플러그인을 로드하는 것이 가능한가요? 가능하다고 하면 어떻게 해야 하나요?
작동할 것으로 생각했던 두 가지 방법을 시도해 보았습니다:
GitHub에서 discourse-math를 /var/discourse/plugins/discourse-math로 클론했습니다. launcher rebuild 실행 시 discourse-math에 대한 언급이 없었고, Docker 마운트에도 GUI에도 discourse-math가 보이지 않았습니다. 즉, plugins 폴더가 무시되고 있는 것 같습니다.
또한 /var/discourse 외부의 다른 디렉토리로 클론한 후 /var/discourse/plugins/discourse-math로 심볼릭 링크를 만드는 방법도 시도해 보았습니다 … 결과는 동일했습니다.
GitHub 저장소를 /var/discourse-math.git에 클론하고 app.yml을 - git clone file:////var/discourse-math.git로 수정했지만, 그 후 launcher rebuild에서 fatal: '/var/discourse-math.git' does not appear to be a git repository라는 오류가 발생했습니다 … launcher가 이미 Docker 컨테이너 내에서 이를 실행하는 것 같습니다. 수동으로 cd /tmp && git clone file:////var/discourse-math.git를 실행하면 정상적으로 작동합니다.
네, 맞아요. 개발용 설치를 한다는 건 알고 있었지만, 제 환경은 표준 도커 설치(즉, 개발용이 아닌 설치)라서 제 질문은 여전히 유효한 것 같습니다: 로컬 디렉터리에서 플러그인을 사이드로드할 수 있나요, 아니면 app.yml을 통해 GitHub에서 원격으로만 가져올 수 있나요?
참고로 “올바른” 워크플로우는 개발용 설치를 하고 거기서 작업하는 거라는 건 잘 알고 있습니다. 개발용 설치와 설정이라는 고된 과정을 전부 거치지 않고 플러그인을 수정하고 테스트할 수 있는 빠르고 간편한 방법을 원했을 뿐입니다.
제가 제대로 이해했는지 확인하고 싶습니다. 말씀하신 것은 원격 GitHub 플러그인을 클론하는 것을 의미하며, 로컬 디렉터리에서 클론하는 것은 불가능하다는 뜻인가요? 심지어 github file:///을 통해서도요? 즉, 해당 시점에서 launcher.sh가 호스트가 아니라 컨테이너 내에서 실행되어, 호스트의 마운트된 폴더로 클론하는 대신 컨테이너 내에서 GitHub에서 클론한다는 말씀이신가요? 그렇게 되면 제가 git clone file:///…을 사용할 수 있게 됩니다.
알겠습니다. 말씀하신 대로 맞습니다. 플러그인의 자바스크립트 파일에서 간단한 변경 사항을 테스트하기 위해서였거든요. 컨테이너 안의 파일을 직접 편집했습니다(/var/www/discourse/public/assets/plugins/discourse-math-.js)만데, 캐시를 비운 것에도 불구하고 브라우저에서는 여전히 오래된 파일이 표시됩니다. 아마도 플러그인의 js 파일이 내장된 nginx 등에 의해 캐시되고 있기 때문인 것 같습니다.
컨테이너 안의 현재 js 파일을 편집(소리가 좀 쑥스럽긴 하지만)하고, 그 변경 사항이 브라우저에서 보이도록 만드는 방법에 대한 팁을 주시면 감사하겠습니다.
"짧은 편지를 쓸 시간이 없었다"는 영역에 이미 발을 들여놓은 것 같습니다… 정식 개발 설치 경로를 따를 시간이 없었고, 컨테이너 내부의 js 파일을 수정하는 것이 이렇게 어려울 줄은 몰랐습니다(브라우저에서 제 변경 사항을 보이도록 Discourse가 플러그인 js 파일을 어떻게 캐시하는지 살펴볼 시간이 거의 없었거든요) 등등.
테마 컴포넌트가 이런 파일을 수정할 때 도움이 될지 잘 모르겠습니다… 제 이해로는 해당 파일(그리고 다른 파일들)은 매핑器等을 거쳐 컨테이너의 /var/www/discourse/public/applets/plugins/discourse-math-<id>.js 파일을 생성하며, 브라우저가 이 파일을 로드합니다. 저는 후자만 변경하면 되는데, 브라우저는 여전히 서버 측 캐싱이 있는 것처럼 구버전 파일을 보고 있습니다.
로컬 개발 환경 설치는 시간과 노력을 많이 소모하지만, 다른 방법이 없다면 시도해볼 수 있습니다. 플러그인 JS를 직접 수정하는 것이 이렇게 번거로울 줄은 몰랐습니다. 또한 JS 파일인데도 컨테이너의 nginx에 서버 측 캐싱이 있어서일까요? 제 직접 수정 사항이 브라우저에 반영되지 않는 이유를 여전히 이해하지 못하겠습니다.
어쨌든 오늘 이 문제를 조사할 수 있는 시간은 다 됐습니다 :(. 그럼에도 불구하고 도움을 주셔서 감사합니다!
개발 도구는 정확히 이 목적을 위해 발전해 왔으므로, 가능하다면 사용해 보세요. 개발용 도커 환경 설정은 몇 시간이 아니라 몇 분밖에 걸리지 않으며, 한 번 설정해 두면 이후 다양한 용도로 유용하게 활용할 수 있습니다. 익숙하다는 이유만으로 로컬에서 프로덕션 설치를 사용하는 유혹에 빠지지 마세요! 프로덕션 환경은 그런 용도로 설정되어 있지 않기 때문입니다.
바보 같겠지만, 기본 포트 3000을 다른 것으로 변경하는 방법을 어떻게 알아볼 수 있나요? 해당 포트를 다른 용도로 사용 중이어서 d/boot-dev --init 실행이 실패합니다. -e UNICORN_PORT=4200을 시도해 보았지만, 제가 확인한 가이드 어디에도 포트에 대한 언급이 없습니다. config/cloud/cloud66/files 폴더 안의 thin.yml 파일도 무시되는 것 같습니다.
음, d/boot_dev --init 실행이 실패합니다 (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). 나중에 이 문제를 더 깊이 파고들 수도 있겠네요. 시간 내주셔서 감사합니다. 이런 것들이 좀 더 잘 문서화되어 있기를 바랍니다.