Docker 설치에서 로컬 플러그인 디렉토리를 사용할 수 있나요?

저는 /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를 실행하면 정상적으로 작동합니다.

plugins 디렉터리는 Docker 컨테이너 외부에 있으며 마운트되어 있습니다.

따라서 ~/discourse에서 Discourse Docker를 실행 중인 경우, 로컬에서 플러그인을 클론하거나 ~discourse/plugins로 심볼릭 링크를 만들 수 있습니다.

@merefield 하지만 제가 이미 그렇게 했습니다 (제 메시지를 참고하세요)가 작동하지 않았어요 … 제가 놓치고 있는 게 뭔가요?

플러그인을 다시 로드하려면 해당 명령으로 docker 컨테이너를 재시작해야 합니다.

./launcher rebuild app 명령이 그렇게 하지 않나요?

이것은 프로덕션 환경에서 원격으로 설치할 때 사용하는 방법입니다.

로컬에서 작업하는 경우라면 제가 링크해 둔 개발용 Docker 설치 방법을 고려해 보시는 것이 좋습니다.

로컬에서 프로덕션 설치를 실행하는 것은 좀… 이상합니다.

네, 맞아요. 개발용 설치를 한다는 건 알고 있었지만, 제 환경은 표준 도커 설치(즉, 개발용이 아닌 설치)라서 제 질문은 여전히 유효한 것 같습니다: 로컬 디렉터리에서 플러그인을 사이드로드할 수 있나요, 아니면 app.yml을 통해 GitHub에서 원격으로만 가져올 수 있나요?

참고로 “올바른” 워크플로우는 개발용 설치를 하고 거기서 작업하는 거라는 건 잘 알고 있습니다. 개발용 설치와 설정이라는 고된 과정을 전부 거치지 않고 플러그인을 수정하고 테스트할 수 있는 빠르고 간편한 방법을 원했을 뿐입니다.

알겠습니다. 특이한 구성 때문에 제가 혼란을 겪었네요.

프로덕션 환경에서는 플러그인이 컨테이너로 클론되므로, 이 방식은 로컬 플러그인 개발에는 적합하지 않습니다. 해당 워크플로우에서는 변경 사항을 GitHub에 업로드해야 하기 때문입니다.

제 제안은 그 설정을 폐기하고, docker 또는 non-docker 중 주요 개발 옵션 두 가지 중 하나를 사용하는 것입니다.

제가 제대로 이해했는지 확인하고 싶습니다. 말씀하신 것은 원격 GitHub 플러그인을 클론하는 것을 의미하며, 로컬 디렉터리에서 클론하는 것은 불가능하다는 뜻인가요? 심지어 github file:///을 통해서도요? 즉, 해당 시점에서 launcher.sh가 호스트가 아니라 컨테이너 내에서 실행되어, 호스트의 마운트된 폴더로 클론하는 대신 컨테이너 내에서 GitHub에서 클론한다는 말씀이신가요? 그렇게 되면 제가 git clone file:///…을 사용할 수 있게 됩니다.

프로덕션 설치를 로컬 마운트된 디렉터리에 접근할 수 있는 프랑켄슈타인 같은 환경으로 바꾸고 싶다면, 해당 접근 권한을 부여하도록 빌드 스크립트를 수정해야 합니다. 이러한 커스터마이징에 대한 지원은 전적으로 본인이 책임져야 합니다.

개인적으로는 이렇게 하면 오히려 본인에게 일과 취약성만 만들어지는 것이라고 생각합니다.

Docker 개발용 설치는 효율적인 로컬 플러그인 개발을 위한 유지보수 부담이 적은 솔루션으로 정확히 설계되었으므로, 사용을 고려해 보시기 바랍니다.

알겠습니다. 말씀하신 대로 맞습니다. 플러그인의 자바스크립트 파일에서 간단한 변경 사항을 테스트하기 위해서였거든요. 컨테이너 안의 파일을 직접 편집했습니다(/var/www/discourse/public/assets/plugins/discourse-math-.js)만데, 캐시를 비운 것에도 불구하고 브라우저에서는 여전히 오래된 파일이 표시됩니다. 아마도 플러그인의 js 파일이 내장된 nginx 등에 의해 캐시되고 있기 때문인 것 같습니다.

컨테이너 안의 현재 js 파일을 편집(소리가 좀 쑥스럽긴 하지만)하고, 그 변경 사항이 브라우저에서 보이도록 만드는 방법에 대한 팁을 주시면 감사하겠습니다.

"짧은 편지를 쓸 시간이 없었다"는 영역에 이미 발을 들여놓은 것 같습니다… 정식 개발 설치 경로를 따를 시간이 없었고, 컨테이너 내부의 js 파일을 수정하는 것이 이렇게 어려울 줄은 몰랐습니다(브라우저에서 제 변경 사항을 보이도록 Discourse가 플러그인 js 파일을 어떻게 캐시하는지 살펴볼 시간이 거의 없었거든요) 등등.

단순한 js 파일이라면 테마 컴포넌트로 배포할 수 있습니다.

discourse_theme gem을 사용하면 https로 접근 가능한 사이트로 테마 컴포넌트를 복사할 수 있습니다.

이를 위해 기존 원격 프로덕션 사이트를 사용할 수도 있으며, 로컬 사이트를 별도로 설정할 필요가 없습니다.

Discourse Theme CLI (테마 빌드를 돕는 콘솔 앱) - howto / developers - Discourse Meta를 참고하세요.

기존 플러그인의 JS 파일(구체적으로는 초기화 파일)을 수정하고 싶은데, 테마 컴포넌트는 도움이 되지 않습니다(혹시 제 이해가 잘못된 거라면요).

테마 컴포넌트는 마지막으로 로드된다고 생각되므로, 플러그인을 오버라이드하게 됩니다.

또 다른 좋은 방법은 플러그인을 포크한 후 로컬로 클론하여 수정하고, 로컬 dev 설치 환경에서 테스트하는 것입니다 (:wink: ). 만족스러운 결과가 나오면 커밋하고 포크에 푸시한 뒤, 프로덕션 환경에서 포크 버전을 사용하시면 됩니다.

다만, 테마 컴포넌트 솔루션의 장점은 포크를 유지 관리할 필요가 없다는 점입니다. 부모 플러그인이 진화하면서 포크 유지 관리가 골칫거리가 될 수 있기 때문입니다.

테마 컴포넌트가 이런 파일을 수정할 때 도움이 될지 잘 모르겠습니다… 제 이해로는 해당 파일(그리고 다른 파일들)은 매핑器等을 거쳐 컨테이너의 /var/www/discourse/public/applets/plugins/discourse-math-<id>.js 파일을 생성하며, 브라우저가 이 파일을 로드합니다. 저는 후자만 변경하면 되는데, 브라우저는 여전히 서버 측 캐싱이 있는 것처럼 구버전 파일을 보고 있습니다.

로컬 개발 환경 설치는 시간과 노력을 많이 소모하지만, 다른 방법이 없다면 시도해볼 수 있습니다. 플러그인 JS를 직접 수정하는 것이 이렇게 번거로울 줄은 몰랐습니다. 또한 JS 파일인데도 컨테이너의 nginx에 서버 측 캐싱이 있어서일까요? 제 직접 수정 사항이 브라우저에 반영되지 않는 이유를 여전히 이해하지 못하겠습니다.

어쨌든 오늘 이 문제를 조사할 수 있는 시간은 다 됐습니다 :(. 그럼에도 불구하고 도움을 주셔서 감사합니다!

문제가 아닙니다.

원하시는 구체적인 내용을 자세히 언급하기는 어렵지만, 한 이니셜라이저가 다른 이니셜라이저보다 나중에 실행되도록 하려면 after: 매개변수를 사용하세요. 예시:

(크레딧: @angus)

개발 도구는 정확히 이 목적을 위해 발전해 왔으므로, 가능하다면 사용해 보세요. 개발용 도커 환경 설정은 몇 시간이 아니라 몇 분밖에 걸리지 않으며, 한 번 설정해 두면 이후 다양한 용도로 유용하게 활용할 수 있습니다. 익숙하다는 이유만으로 로컬에서 프로덕션 설치를 사용하는 유혹에 빠지지 마세요! :wink: 프로덕션 환경은 그런 용도로 설정되어 있지 않기 때문입니다.

바보 같겠지만, 기본 포트 3000을 다른 것으로 변경하는 방법을 어떻게 알아볼 수 있나요? 해당 포트를 다른 용도로 사용 중이어서 d/boot-dev --init 실행이 실패합니다. -e UNICORN_PORT=4200을 시도해 보았지만, 제가 확인한 가이드 어디에도 포트에 대한 언급이 없습니다. config/cloud/cloud66/files 폴더 안의 thin.yml 파일도 무시되는 것 같습니다.

3000은 Ruby 서버 포트이고, 4200은 Ember 포트입니다. 두 프로세스 모두 실행되어 있어야 하며, 브라우저에서는 4200 포트를 통해 사이트에 접근합니다. 개발용 Docker 설치는 개발용 Docker 관련 주제에서 논의하는 것이 더 나을까요?

음, d/boot_dev --init 실행이 실패합니다 (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). 나중에 이 문제를 더 깊이 파고들 수도 있겠네요. 시간 내주셔서 감사합니다. 이런 것들이 좀 더 잘 문서화되어 있기를 바랍니다.

정말 그런 것 같습니다. 포트 3000에서 이미 프로세스가 실행 중입니다. 이를 종료하세요.

lsof -wni tcp:3000 명령어를 사용하면 해당 포트를 사용하는 프로세스를 나열할 수 있습니다.