Install Discourse for development using Docker

문서 개발자 가이드
, ,
232

지금까지 두 대의 컴퓨터에서 시도해 보았는데, 둘 다 권한 오류로 실패하고 있습니다.

pfaffman@shinytim:~/src/discourse-repos/discourse$ d/bundle install
Bundler 2.4.2가 실행 중이지만, lockfile은 2.4.1로 생성되었습니다. Bundler 2.4.1을 설치하고 해당 버전으로 재시작합니다.
https://rubygems.org/에서 gem 메타데이터를 가져오는 중입니다.
bundler 2.4.1 가져오는 중

오류로 인해 https://rubygems.org/에서 gem 다운로드 재시도 (2/4): Bundler::PermissionError `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`에 쓰기 도중 오류가 발생했습니다. 해당 경로에 쓰기 권한을 부여해야 할 가능성이 높습니다.

오류로 인해 https://rubygems.org/에서 gem 다운로드 재시도 (3/4): Bundler::PermissionError `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`에 쓰기 도중 오류가 발생했습니다. 해당 경로에 쓰기 권한을 부여해야 할 가능성이 높습니다.

오류로 인해 https://rubygems.org/에서 gem 다운로드 재시도 (4/4): Bundler::PermissionError `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`에 쓰기 도중 오류가 발생했습니다. 해당 경로에 쓰기 권한을 부여해야 할 가능성이 높습니다.

잠긴 bundler 버전(2.4.1) 설치 중 오류가 발생했습니다. 자세한 내용은 `--verbose` 플래그를 지정하여 다시 실행하십시오. bundler 2.4.2를 사용하여 진행합니다.
https://rubygems.org/에서 gem 메타데이터를 가져오는 중.........
https://github.com/discourse/mail.git 가져오는 중
`/usr/local/lib/ruby/gems/3.1.0/cache/bundler/git`에 쓰기 도중 오류가 발생했습니다.
해당 경로에 쓰기 권한을 부여해야 할 가능성이 높습니다.
1개의 좋아요
233

저도 같은 문제를 겪었습니다.

1개의 좋아요
234

이 문제에 대해 새로운 업데이트가 있나요?

235

안녕하세요,

저는 완전 초보입니다. GitHub에 올리기 전에(그리고 서버에 올리기 전에, 어떻게 해야 할지는 모르겠지만 지금은 중요하지 않습니다) 개발용 Ubuntu 22.04에서 Discourse를 설정하려고 시도하고 있습니다.

이 튜토리얼을 참고하여 Docker를 사용하여 로컬에 Discourse를 설치하려고 했습니다.

Docker를 올바르게 설치한 것 같지만, 다음 명령을 입력할 때:

sudo d/rails s

"GitHub - discourse/mail: A Really Ruby Mail Library · GitHub is not yet checked out. Run bundle install first."라는 오류가 발생합니다.

그리고 다음을 실행하면:

sudo d/bundle install

아래와 같은 오류가 나요:
“Fetching GitHub - discourse/mail: A Really Ruby Mail Library · GitHub
There was an error while trying to write to
/usr/local/lib/ruby/gems/3.1.0/cache/bundler/git. It is likely that you need
to grant write permissions for that path.”

조언 부탁드립니다 :slight_smile:

236

이 문제를 수정하기 위해 풀 리퀘스트를 생성했습니다 - Setting bundler version to 2.4.1 which is same as version that generated lockfile to avoid failing script - Pull Request #665 - discourse/discourse_docker - GitHub

1개의 좋아요
237

리포트 감사합니다. 이 문제는 이 커밋으로 수정될 예정입니다.

빌드가 진행 중이며, 따라서 1시간 이내에 새로운 discourse_dev:release 이미지가 푸시될 것입니다. 이후 변경 사항을 적용하려면 d/shutdown_dev와 d/boot_dev를 실행해야 합니다.

4개의 좋아요
238

이 컨테이너에 특정 정적 IP 주소를 설정하거나 할당하는 방법은 무엇인가요?

239

안녕하세요! 저도 같은 오류가 발생했습니다.

app/assets/javascripts 디렉토리로 들어가서 d/boot_dev --init를 실행하기 전에 yarn을 실행함으로써 문제를 해결했습니다.

제 추측은 d/boot_dev --init가 실행 중 어딘가에 node_modules가 존재한다고 가정한다는 것입니다. 리포지토리를 방금 클론한 상태에서는 node_modules가 없기 때문에 실패하게 됩니다.

1개의 좋아요
240

Ubuntu 22에서 이 튜토리얼을 따라 하다 보니, d/boot_dev --init가 다음과 같은 출력으로 종료됩니다:

Migrating database...
rake aborted!
Discourse::Utils::CommandError: /src/lib/discourse.rb:137:in `exec': mkdir: cannot create directory ‘/src/public/plugins/’: Permission denied
/src/lib/discourse.rb:171:in `execute_command'
/src/lib/discourse.rb:137:in `exec'
/src/lib/discourse.rb:33:in `execute_command'
/src/lib/plugin/instance.rb:727:in `activate!'
/src/lib/discourse.rb:352:in `block in activate_plugins!'
/src/lib/discourse.rb:349:in `each'
/src/lib/discourse.rb:349:in `activate_plugins!'
/src/config/application.rb:216:in `block in <class:Application>'
/src/lib/plugin.rb:6:in `initialization_guard'
/src/config/application.rb:216:in `<class:Application>'
/src/config/application.rb:75:in `<module:Discourse>'
/src/config/application.rb:74:in `<main>'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/home/discourse/.bundle/gems/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

이 튜토리얼은 여전히 최신 상태인가요?

1개의 좋아요
241

명령어(d/command)를 실행할 때 sudo를 사용하지 않으려면, 아래 명령어를 사용하여 자신을 docker 그룹에 추가한 후 다시 로그인해야 합니다.

sudo adduser $(whoami) docker
2개의 좋아요
242

안녕하세요,
저도 정확히 같은 문제를 겪고 있습니다.

저는 이렇게 했습니다:
docker 그룹에 자신을 추가하고 시스템을 재부팅했습니다. groups 명령어로 확인해 보니 실제로 docker 그룹의 멤버인 것을 확인했습니다.

하지만 여전히 이 오류가 계속 발생합니다.

저는 Ubuntu 22.04를 사용 중이며, 다른 프로젝트들을 위해 이미 Docker Desktop으로 docker를 설치해 둔 상태입니다. 제가 작업 중인 사용자 계정은 관리자 권한이 없으며(sudo 그룹에 속하지 않음), 관리자 권한이 있는 다른 계정에 접근은 가능합니다. 하지만 일상적인 작업에는 그 다른 계정을 사용할 수 없습니다.
이것이 문제가 될까요?

243

음. 직접 설치한(bare metal) Ubuntu 22.04를 사용 중이신 건가요, 아니면 WSL 가상 머신으로 실행 중이신 건가요?

244

Bare metal. 업무용 노트북에 Ubuntu 22.04를 네이티브로 설치해 두고 있습니다.

다음과 같은 사항을 확인했습니다:
컨테이너의 /src 폴더가 호스트 머신의 /home/gregor/repos/discourse에 마운트되어 있습니다:

image
image1270×720 58.3 KB

호스트 머신에서 git 저장소를 가져온 후, 이 폴더는 저와 제 그룹에게 속해 있습니다:

repos $ whoami
gregor
repos $ groups
gregor docker
repos $ pwd
/home/gregor/repos
repos $ ll
[...]
drwxrwxr-x 21 gregor gregor 4096 Mär 24 10:57 discourse/
[...]

d/* 스크립트는 docker 컨테이너 내부에서 모든 명령을 discourse 사용자로 실행합니다(여기 참조). 그리고 해당 discourse 사용자는 마운트된 /src 폴더에 대한 쓰기 권한이 없습니다.

rake aborted!
Discourse::Utils::CommandError: /src/lib/discourse.rb:137:in `exec': mkdir: cannot create directory ‘/src/public/plugins/’: Permission denied

image
image1207×734 109 KB

컨테이너에 로그인하여 내부에서 폴더 생성을 시도하면 이를 재현할 수 있습니다. root 사용자로 실행하면 성공합니다.

image
image1270×720 45.2 KB

호스트 머신에서는:
image
image1201×689 115 KB

discourse 사용자로 실행하면 실패합니다:

image
image1270×720 51.6 KB

하지만 이 모든 것을 하나로 연결해 내기 어렵습니다 :thinking:

245

음. 저는 Windows의 WSL에서 Ubuntu 22.04를 실행하고 있습니다:

d/shell 실행 후:

image
image1297×236 13 KB

그리고

$ docker inspect -f "{{ .Mounts }}" discourse_dev
[{bind  /home/toka/dv/discourse/discourse/data/postgres /shared/postgres_data  delegated true rprivate}
 {bind  /home/toka/dv/discourse/discourse /src  delegated true rprivate}]
246

호스트의 UID가 1000과 다른가요? 그렇다면 문제가 바로 거기에 있습니다. Docker 내부의 Discourse 사용자는 UID 1000이므로, 호스트의 파일은 UID 1000에 의해 쓰기가 가능해야 합니다.

247

이 SO 게시물이 저를 여러분과 같은 방향으로 이끌어 주었습니다. 호스트 머신의 gregor 사용자와 컨테이너의 discourse 사용자가 모두 동일한 ID 1000을 가진다는 것을 확인했습니다.

249

d/exec ls -lan과 echo $UID의 출력 결과는 무엇입니까?

250

d/shell을 실행한 후:
image
모든 파일이 discourse가 아닌 root 소유임을 확인할 수 있습니다. 스크린샷과 다른 점입니다.

(이전 게시글에서 nobody/nogroup로 표시되었는데, 이는 호스트 머신에서 discourse 사용자와 그룹을 생성하는 실험을 했다가 실패한 결과로 인해 발생한 오해였습니다. 따라서 해당 게시글을 삭제했습니다)

251

/src 안의 모든 파일이 root 사용자가 소유하고 있음을 나타냅니다.

image
image348×239 15.8 KB

(디스코urses 그룹은 결과가 없었던 이전 시도로 인해 생성되었습니다)

그리고 도움을 주셔서 정말 감사합니다. 좀 멍청하게 느껴지는데, 유닉스 권한 시스템에 대한 지식이 부족한 것 같습니다.

252

많은 조사와 시행착오 끝에 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을 실행합니까?

3개의 좋아요