많은 조사와 시행착오 끝에 Linux용 Docker Desktop이 권한 문제를 일으킨다는 것을 알게 되었습니다.
Discourse 애플리케이션은 Docker 컨테이너 내에서 루트 사용자가 아닌 discourse 사용자로 실행됩니다. 그러나 여기와 여기에 설명된 바와 같이:
Linux용 Docker Desktop은 가상 머신을 실행하며, 컨테이너는 해당 가상 머신 내부에서 실행됩니다. 이 경우 컨테이너에 호스트 폴더를 동일한 방식으로 마운트할 수 없으며, 먼저 가상 머신에 마운트해야 합니다.
따라서, 저는 Docker 전문가라고 할 수 없는 입장에서 이 문제를 해결하는 두 가지 방법을 찾았습니다:
(1) Linux용 Docker Desktop을 버리고 Docker를 네이티브로 실행하기
Discourse 컨테이너가 이러한 방식으로 사용되도록 설계된 것으로 보이므로, 이것이 가장 지속 가능한 해결책이라고 생각합니다. 다만, 이 경우 이미지, 컨테이너 및 리소스를 관리하는 모든 명령어를 기억해야 하므로 망설여집니다. 또한 프론트엔드 개발자로서 기능을 관리하는 UI를 더 선호합니다. 하지만 Docker에 대해 더 배우기 위한 투자로 받아들이기로 했습니다.
또는
(2) 컨테이너에 마운트된 폴더의 소유자 변경
이 방법을 통해 Docker Desktop에서 Discourse를 로컬에서 성공적으로 실행하는 데 성공했지만, 터미널에 여러 경고가 표시되어 장기적으로 이 해결책이 지속 가능한지 확신이 서지 않습니다.
이 과정에는 여러 단계가 포함됩니다:
1단계: 저장소 클론하기
$ git clone https://github.com/discourse/discourse.git
$ cd discourse
2단계: 컨테이너 초기화
호스트 머신의 클론된 discourse 폴더 내에서 다음을 실행합니다:
$ d/boot_dev
무엇을 하는 것일까요? 여기를 참조하세요.
중요: 컨테이너 생성 후 아무 작업도 수행하지 않도록 --init 플래그를 생략하세요.
3단계: 폴더 소유자 변경
Docker 컨테이너 내의 discourse 사용자는 ID 1000을 가집니다. 이 가이드는 호스트 머신의 사용자도 동일한 ID를 가지고 있다고 가정합니다. 호스트 머신의 사용자가 다른 ID를 가지는 경우 문제가 발생하지 않을 수도 있지만, 저는 이를 테스트할 수 없으므로 이 상황에 대해 확답을 드릴 수 없습니다. Linux 터미널에서 id 또는 echo $UID를 실행하여 자신의 ID를 확인할 수 있습니다.
호스트 머신에서 다음을 실행합니다:
# Docker 컨테이너에서 셸 열기
$ d/shell
# 이미 /src에 있어야 하지만, 확실하게 하기 위해:
$ cd /src
# /src의 소유자를 discourse 사용자와 그룹으로 변경
$ chown 1000:1000 .
# /src 내의 모든 파일과 폴더의 소유자를 discourse 사용자와 그룹으로 변경 (비재귀적)
$ chown 1000:1000 *
# 거의 모든 하위 폴더의 소유자를 재귀적으로 discourse 사용자와 그룹으로 변경
# 'database' 폴더를 제외한 모든 폴더, 해당 폴더는 'postgres' 사용자와 그룹에 속하기 때문
$ chown -R 1000:1000 app bin config d db docs documentation images lib log plugins public script spec test vendor
# 작동했는지 확인, 이제 discourse 사용자와 그룹이 표시되어야 함
$ ls -l
# 컨테이너 종료
$ exit
4단계: 정상적으로 계속하기
호스트 머신에서 다음을 실행하여 컨테이너 설정을 계속하고 Discourse를 시작합니다:
# gems 설치
$ d/bundle install
# 데이터베이스 마이그레이션
$ d/rake db:migrate
$ RAILS_ENV=test d/rake db:migrate
# 관리자 사용자 생성
$ d/rake admin:create
# 하나의 터미널에서:
d/rails s
# 그리고 별도의 터미널에서
d/ember-cli
참고:
다음과 같은 경고를 몇 가지 마주쳤습니다:
fatal: detected dubious ownership in repository at '/src'
이는 Linux용 Docker Desktop의 가상화 기능에서 비롯된 것입니다.
이 경고는 무시하고, 호스트 머신에서 다음을 실행하세요:
d/exec git config --global --add safe.directory /src
왜 Linux용 Docker Desktop은 VM을 실행합니까?