https://github.com/discourse/discourse/pull/5760
Here’s the PR 
I know; I too have spent too much time debugging docker-sync than I care to admit. This new approach, albeit not as fast, requires zero additional effort to setup and is quite stable from my own experiences!
드디어 맥에 Discourse를 설치했는데… 속도가 너무 느려요. 페이지당 20초나 걸리는 것 같아요.
그래서 질문이 있습니다:
같은 문제를 겪고 계신 분 계신가요?
이것은 Docker for Mac의 문제입니다. 개발을 위해 Mac에 Discourse를 네이티브로 설정하기를 수행하면 성능이 크게 향상됩니다.
아마도 Discourse는 도커를 아예 사용하지 않는 게 나을지도 모르겠네요. 장점이 보이지 않습니다. 진심으로 말하자면, 도커는 그저 불필요한 한 계층일 뿐이고, 컨테이너 디버깅은 골칫거리가 될 겁니다. 그냥 제 생각일 뿐입니다.
도커는 실행 중인 애플리케이션 주위의 환경을 표준화하고 호스트 시스템으로부터 이를 샌드박싱(격리)합니다.
도커 없이 셀프 호스팅된 설치 환경을 지원하는 것은 Discourse 팀에게 악몽이 될 것입니다. 호스트 환경과 설정은 Discourse 인스턴스마다, 특히 Mac과 Linux 간에 극도로 달라질 것이기 때문입니다.
도커는 리눅스에서 작은 성능 저하(마찬가지로 Mac에서는 더 큰)를 가져오지만, 분산 개발 팀과 수천 개의 셀프 호스팅 인스턴스를 가진 이 같은 오픈소스 프로젝트에게는 그 장점이 매우 큽니다.
어떤 형태로든 상업적 규모(예: 클러스터 오케스트레이션을 위해 Kubernetes 사용)로 애플리케이션을 실행하려면, 구현 세부 사항을 오케스트레이터로부터 추상화하기 위해 애플리케이션을 컨테이너화해야 합니다.
저는 개발 환경(우분투를 사용하긴 합니다)에서 Docker를 사용하지 않습니다. 제 방식대로 하는 것이 실제로는 더 많은 노력이 들 수 있는데, 처음부터 다시 빌드하는 과정이 꽤 번거롭기 때문입니다.
@cmoi 님, 반갑습니다.
저희 맥(Mac)에서 개발용 새 환경을 설치해 봤는데(개발 환경에 대한 내용은 위 #44 게시글 참조) 매우 빠릅니다. 전혀 문제가 없었습니다.
다른 질문과 관련하여
@cmoi 님이 말씀하시길…
아마도 Discourse는 Docker를 아예 사용하지 않는 것이 나을지도 모르겠습니다. 장점이 보이지 않습니다. 진지하게 말씀드리자면, 그냥 불필요한 한 층(layer)일 뿐이고 컨테이너 디버깅은 골칫거리가 될 것입니다. 그냥 의견입니다.
우리는 프로덕션과 스테이징 환경에서 Docker를 사용하여 Discourse를 운영 중이며, 그 결과는 훌륭합니다. 그 이유 중 하나는 Docker를 사용하면 “메탈(on the metal, 즉 직접 설치)” 환경에서 설정하는 것보다 훨씬 적은 시간과 노력을 들여 설정할 수 있다는 점입니다. 또한 서버가 충돌할 경우 Docker 환경에서는 복구하는 것이 훨씬 쉽습니다.
따라서 프로덕션 환경에서 Docker를 실행해야 하는 이유는 분명히 많습니다.
그러나 플러그인 개발의 경우, 저는 결국 Docker 없이 “베어 메탈(bare metal, 즉 직접 설치)” 환경으로 전환했고, 플러그인 로드 및 재로드, 디버깅 등 그 모든 재미있는 작업들이 Docker 밖에서 확실히 훨씬 빠르고 재미있을 것임을 이미 체감하고 있습니다.
