하하, 말했잖아. 다른 용도로 쓰고 있어서 그냥 종료할 수 없어. 포트 변경이 그렇게 어렵진 않을 거라고 생각했는데 (유명한 마지막 말인 것 같아).
링크된 주제에서 질문하시는 걸 권합니다. 해당 스크립트를 잠깐 살펴본 결과 하드코딩된 것으로 보이지만, 틀렸을 수도 있고, 스크립트가 빌드된 것일 수도 있습니다.
하드코딩된 부분도 제가 알아차렸는데, yml 파일과 ENV 변수에도 포트 설정에 대한 참조가 있더라고요. 지금은 이걸 포기하겠습니다. 테스트하고 싶었던 것에 비해 이미 너무 많은 시간을 투자해버렸거든요.
새로운 Ubuntu 22.04로 VM을 띄웠습니다. 개발용 설치가 실패하네요: Install Discourse for development using Docker - #213 by nordize
오늘은 좀 안 좋은 하루네요… 하지만 분명 몇 분 만에 해결될 문제는 아니었습니다 (비유가 아닙니다). 시간을 내주셔서 감사합니다. 그리고 그 시간도 낭비하게 해서 죄송합니다.
@merefield 간단한 질문 하나: 컨테이너에서 플러그인 코드 업데이트를 가져오는 더 빠른 방법이 있나요? d/shutdown_dev; d/boot_dev를 실행하면 시간이 오래 걸리고, 도커 이미지를 가져오면서 데이터가 대량으로 다운로드됩니다. 브라우저에서 테스트하기 위해 코드 한 줄만 바꿀 때마다 이 작업을 반복하는 것은 도커화된 환경에서도 너무 과도한 것 같습니다.
d/rails s로 레일스 서버를 재시작해도 플러그인 코드 변경 사항이 반영되지 않습니다.
이것은 플러그인을 제거하거나 추가할 때만 필요하며, 코드 한 줄을 변경할 때는 필요하지 않습니다.
해당 줄이 Ruby나 CSS라면 새 코드가 핫로드됩니다. Ruby의 경우 터미널에서 유니콘(unicorn)이 재시작되는 것을 볼 수 있어야 합니다(기억이 맞다면).
JavaScript의 경우 브라우저만 새로고침하면 됩니다.
플러그인이 심볼릭 링크 안에 있다는 점을 언급했어야 했는데, d/shutdown_dev; d/boot_dev를 실행하지 않으면 변경 사항이 반영되지 않습니다(가이드에도 이렇게 나와 있죠). 하지만 이건 단순한 매핑된 파일이므로 도커 자체로 우회할 수 있는 방법이 있지 않을까 생각했습니다. 다른 스레드에 질문을 하거나 우회 방법으로 수정해 볼 수도 있고(아니면 심볼릭 링크를 쓰지 않는 방법도)요.
나한테는 이게 좀 이상하게 들린다. 서버 프로세스는 도커가 아닌 설치 환경에서와 똑같이 단순히 재시작될 뿐이다. 심볼릭 링크는 아무런 차이를 만들지 않으며, 오히려 적절한 작업 방식이다. 왜 너의 환경에서는 이렇게 동작하지 않는지는 전혀 모르겠다…
음, 편하게 시도해 보세요. rails와 ember를 재시작하는 것으로 충분했다면 제가 올리지 않았을 겁니다. 말씀드린 것처럼, 가이드에도 이 부분이 언급되어 있습니다.
가이드에 따르면, 플러그인 구성이 변경된 경우(예: 유효한 심볼릭 링크를 삭제하거나 추가하는 경우)에만 이러한 재시작 명령을 실행해야 합니다. 그 외에는 Rails가 코드 변경 사항을 감지하고 프로세스를 재시작해야 합니다. 설정을 통해 이 동작을 끄는 것이 가능할 수 있지만, 기본값으로는 이 동작이 유지되어야 합니다.
다음은 Docker가 아닌 개발 환경에서의 자동 재시작 예시입니다. Docker 환경에서도 동작은 비슷할 것입니다:
[DEV]: Edited files which are not autoloaded. Restarting server...
- plugins/discourse-multilingual/extensions/post.rb
RESTARTING UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
Got TERM signal
Shutting down
Terminating quiet threads
Scheduler exiting...
Pausing to allow jobs to finish...
Bye!
Starting CSS change watcher
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
post.rb 파일을 수정하고 저장한 후, 나머지는 자동으로 처리되었습니다.
현재 제가 있는 곳에서는 Docker 기반 개발 머신에 접근할 수 없어 Docker 설치 환경에서도 동일한지 확인해 드리지 못해 죄송합니다. 다만, 변함이 없다면 Docker 환경에서도 동일하게 작동한다고 기억하고 있습니다.
제가 지어낸 이야기가 아닙니다 
그리고 "그냥 작동해야 한다"는 말만으로는 제가 할 수 있는 일이 많지 않아요 저는 Ubuntu 22.04의 새 VM 설치 환경에서 해당 가이드를 철저히 따랐습니다.
- 플러그인을 discourse/plugins/ 하위 폴더에 심볼릭 링크로 연결하고 플러그인의 JS 코드를 변경하더라도, d/rails s와 d/ember-cli를 재시작하는 것만으로는 변경 사항이 반영되지 않습니다. 반드시 d/shutdown_dev; d/boot_dev를 실행해야만 반영됩니다.
- 반면, 플러그인을 discourse/plugins/ 하위 폴더에 복사해 두고 JS 코드를 변경하면, d/shutdown_dev; d/boot_dev를 실행하지 않고 d/rails s와 d/ember-cli만 재시작해도 변경 사항이 반영됩니다.
위 내용을 직접 시도해 보셔도 좋습니다. 문제가 되는 플러그인은 discourse-math이며, assets/initializers/javascript/*.js 파일의 코드를 수정한 것입니다 (이 특정 플러그인 파일들은 사이드로드(side-loaded) 방식으로 로드되며, 브라우저가 직접 GET 요청으로 호출하지는 않습니다. 이것이 차이를 만드는지 확신은 없으며, 아직 Discourse의 내부 동작 방식을 깊이 파고들지 않았기 때문입니다).
p.s. 브라우저 캐시를 우회하여 새로고침해야 한다는 점은 알고 있습니다 … 제게 약간의 신용을 좀 주세요.
일종의 말발굽(직접적인 출처)에서 확인한 내용입니다:
따라서 문제는 사용자의 로컬 환경에 국한된 것일 수도 있고, 현재 빌드에서 발생한 회귀(regression)일 수도 있지만, 후자의 가능성은 낮아 보입니다.
포기합니다, 당신이 이겼네요. 나중에 직접 시도해 보시면 알려주세요.
나는 분명히 "이기기"를 시도하는 것이 아닙니다. 하지만 우리는 이해의 기준점을 마련해야 합니다:
- 백엔드 코드 변경 시 자동으로 재시작되어야 합니다.
d/shutdown_dev; d/boot_dev는 개별 코드 줄이 아니라 플러그인 구성 자체가 변경될 때만 _필요_해야 합니다.
이렇게 하면 문제를 해결하기 위해 살펴봐야 할 범위가 줄어들 것입니다.
방금 git pull을 수행하고 변경 사항을 시도해 보았는데, 재시작이 정상적으로 이루어졌으므로 빌드 회귀 문제가 아닙니다.
제게 더 이상한 부분은, 도커 환경에서는 패키징된 동작을 우연히 덮어쓰기 어려우므로, 오히려 더 안정적이어야 한다는 점입니다.
집에 가서 제 도커 빌드에서 이 부분을 테스트해 보겠습니다.
현재 워크플로우가 짜증스럽고 번거롭다는 점을 충분히 이해합니다. 저라면 분명히 짜증나고 답답했을 것입니다.
캐시를 완전히 비웠다면, 이 시점에서 무엇을 제안해야 할지 모르겠습니다.
참고로, 초기화 프로그램(initializers)은 페이지를 처음 열 때 한 번만 실행됩니다. 따라서 서버 프로세스의 재시작은 무의미합니다(그리고 이는 백엔드 코드만 커버합니다).
웹 앱을 개발할 때는 항상 캐시를 비활성화한 상태로 개발 도구를 실행합니다. 저는 웹 개발 자체는 잘 아는데, Discourse 코드와 도구만 처음 접하는 것뿐입니다. 가이드 스레드에도 질문을 남겼습니다. 당분간은 고생하지 않으려고 discourse/plugins/ 아래에 플러그인 디렉토리를 복사해 두었습니다.
오늘 나중에 비슷한 것을 시도해 보고 결과를 알려드리겠습니다.
브라우저 호출을 살펴본 바로는, 초기화 프로그램 JS의 JS 코드가 eval()을 통해 discourse-math.js로 사이드로드(side-loaded)되고 있으며(모든 페이지 열림 시마다), 이는 서버 측 컴포넌트가 초기화 프로그램의 해당 JS 코드(내가 수정하고 있는 코드)를 처리하고 캐싱하고 있음을 명확히 시사합니다. 따라서 다시 캐싱하도록 트리거가 필요한 것은 바로 그 특정 서버 측 캐셔인데, 플러그인이 심볼릭 링크로 연결되어 있으면 이것이 일어나지 않지만, 복사된 경우에는 일어납니다.
저는 Discourse 도구 체인(toolchain)에 익숙하지 않습니다(시간 부족으로 이 시점에서 익숙해지고 싶지도 않았습니다) … 그래서 역설계(reverse-engineering)를 하고 질문을 하고 있습니다.
non-docker dev:
방금 이니셜라이저(initializer)에서 이것을 시도해 보았는데, 어떤 프로세스도 재시작할 필요가 없었고, 브라우저만 새로고침하면 js 코드 변경 사항이 바로 반영되었습니다 … 이건 non-docker 환경이었어요 … 나중에 시도해 볼게요
잠시 후…
docker-dev:
자, 이제 PC에 와서 완전히 새로 설치한 docker 솔루션을 시도해 보았는데, 같은 현상을 확인했습니다: 서버를 실행한 채로 이니셜라이저를 편집하고 파일을 저장한 뒤 브라우저를 새로고침하면 변경 사항이 적용되며, 컨테이너를 다시 빌드할 필요가 없습니다.
즉, 동일한 동작을 보입니다.
(예시로 Discourse Locations 플러그인을 사용했습니다.)
당신의 이니셜라이저에 문제가 없는지 확실하게 확인해 보셨나요?
재시작 후 작동하는 것을 보면, 네, 확신합니다. 100% 재현 가능성을 보장하려면 제가 언급한 특정 플러그인을 시도해 볼 수 있습니다. GUI에서 이를 활성화하고 GUI에서 Katex 옵션을 선택한 후, 제가 언급한 초기화 프로그램 JS 파일을 편집하고, 그 안에 Latex 코드가 포함된 게시물을 작성해 보세요. 이 플러그인은 특수한 경우로, 게시물에 Latex 코드가 포함된 경우에만 JS 초기화 프로그램을 온디맨드로 로드할 수 있습니다(제가 Discourse를 설계한다면 그렇게 했을 것입니다) … 하지만 이 문제에 시간을 낭비하라고 기대하지는 않으며, 제가 무언가를 지어낸다고 설득하려는 것도 아닙니다
네, 좋은 지적이네요.
정말 정말 이상하네요.
지금은 도커 설치 대신 일반 설치(아쉽게도 설정에 시간이 더 걸리지만 
)로 전환해서 상황을 확인해 보는 것을 제안합니다.
팀에서 무엇이 문제인지에 대한 의견을 들어보는 것이 도움이 될 것입니다. 하지만 도커 솔루션은 컨테이너화되고 원자적이기 때문에, 여기에서 다른 동작이 발생할 가능성을 확실히 줄여줄 것입니다. 