이것은 공식적으로 지원되지 않는 개발 환경 설치 가이드라는 점에 유의하세요. macOS에 대한 공식적으로 지원되는 가이드는 여기(네이티브)와 여기(Docker)에 있습니다. 책임 하에 진행하세요.
이 가이드의 목표는 postgres와 redis를 컨테이너화하되, ruby는 컨테이너 외부에 두는 것입니다.
Docker를 사용한 Discourse 개발 방식을 시도해 보았지만, 제 머신에서는 너무 느렸습니다.
그다음 macOS에서의 Discourse 개발 가이드를 살펴봤습니다. 하지만 스크립트가 처음 한 일은 brew를 설치하는 것이었습니다. brew가 아주 훌륭할 수 있지만, 저는 오랫동안 MacPorts를 사용해 왔고 brew 설치를 계속 성공적으로 거부하고 싶습니다. 게다가 그 스크립트는 postgresql과 redis 같은 것들을 전역으로 설치했는데, 저는 프로젝트별로 관리할 수 있기를 원했습니다.
그래서 제가 asdf와 docker-compose의 조합을 사용하여 성공적으로 작동한 방법은 다음과 같습니다. 그 결과는 위에서 설명한 두 가지 방식 사이의 절충안입니다. postgres와 redis는 docker-compose를 사용하여 컨테이너에서 실행되므로, 프로덕션에서 Discourse가 사용하는 공식 버전과 설치로 고정할 수 있습니다. Rails는 메탈(호스트 OS)에서 실행됩니다. 이 조합은 제게 훨씬 더 빠릅니다. 결과는 사람마다 다를 수 있습니다.
따라 하려면 머신에 asdf와 Docker가 모두 설치되어 있어야 합니다. (오, asdf는 정말 훌륭하네요… 다양한 개발 환경을 쉽게 유지 관리하는 데 관심이 있다면 반드시 설치해야 합니다. renv, nvm… jenv를 제외하고 거의 모든 것을 대체합니다.)
macOS 설치 스크립트가 수행하는 작업을 살펴보면, 설치되는 항목을 세 가지 범주로 나눌 수 있습니다:
ruby와yarn과 같은 커맨드 라인 환경 및 도구.asdf를 사용하여 설치하고 프로젝트 디렉터리에 버전을 고정합니다.- 서비스—특히 postgres와 redis. Docker compose를 사용하여 설치하여, 이 프로젝트에 필요한 버전으로 고정할 수 있고 쉽게 시작하고 중지할 수 있는 개발 환경을 갖습니다.
- 기타—주로 ImageMagick과 최적화 및 같은 이미지 조작 라이브러리. 이들은
brew,port또는 소스에서 직접 설치할 수 있습니다.
docker-compose가 실행하는 postgres 서버에 연결하도록 개발 환경을 가볍게 재구성해야 합니다.
Discourse 소스
아래의 모든 단계는 Discourse 소스 디렉터리 내에서 수행해야 합니다:
git clone https://github.com/discourse/discourse.git && cd discourse
asdf가 .tool-versions 설정 파일을 저장하는 위치이고 Docker를 위한 docker-compose.yml 파일을 생성할 위치이므로 이것은 중요합니다.
asdf
asdf를 사용하여 설치해야 하는 세 가지 항목이 있습니다: ruby, yarn, postgres. 다행히도 asdf는 모두를 한 번에 설치하고 프로젝트 디렉터리에 버전을 고정하는 것을 쉽게 만듭니다. 먼저 다음 내용으로 .tool-versions 파일을 생성하세요:
yarn 1.22.2
ruby 2.6.5
postgres 10.12
그 다음 asdf install을 실행하기만 하면 됩니다.
이제 스크립트에 포함된 Ruby 라이브러리 설치 단계와 후속 지침에 있는 단계를 수행할 수 있어야 합니다:
gem update --system
gem install bundler
gem install rails
gem install mailcatcher
gem install pg -- --with-pg-config=$HOME/.asdf/installs/postgres/10.12/bin/pg_config
bundle install
asdf를 설치한 위치에 따라 pg_config 경로 조정이 필요할 수 있습니다.
docker-compose.yml
다음으로 redis와 postgres를 시작하도록 구성된 docker-compose.yml 파일을 생성해야 합니다. 제 파일은 다음과 같습니다:
version: "3"
networks:
discourse:
driver: bridge
services:
data:
image: "geoffreychallen/discourse_data:latest"
command: /sbin/boot
ports:
- "5432:5432"
- "6379:6379"
volumes:
- "data_shared:/shared/"
- "data_logs:/var/log/"
networks:
- discourse
volumes:
data_shared:
driver: local
data_logs:
driver: local
표준 Discourse 데이터 컨테이너를 사용하도록 제안해 주신 @pfaffman님께 감사드립니다. geoffreychallen/discourse_data:latest는 Discourse Docker에서 빌드되었습니다. 두 가지 변경 사항과 함께 샘플 data.yml 파일을 사용했습니다. 첫째, discourse 사용자의 비밀번호를 discourse로 설정했습니다. 둘째, 테스트 데이터베이스를 생성할 수 있도록 해당 사용자를 슈퍼유저로 만들었습니다. 제 data.yml 파일의 hooks 부분은 다음과 같습니다:
hooks:
after_postgres:
- exec:
stdin: |
alter user discourse with password 'discourse';
cmd: sudo -u postgres psql discourse
raise_on_fail: false
- exec:
stdin: |
alter user "discourse" with superuser;
cmd: sudo -u postgres psql discourse
raise_on_fail: false
다시 말하지만, 이것은 제가 만든 컨테이너를 사용하지 않고 직접 Discourse 데이터 컨테이너를 빌드하려는 경우를 위한 것입니다. 이 컨테이너를 프로덕션에서 사용하지 마세요—완전히 안전하지 않습니다!
이 구성에서는 표준 postgres와 redis 포트 모두를 노출하고 컨테이너가 시작하는 데 필요한 boot 명령을 실행합니다.
docker-compose.yml이 제자리에 놓인 후, 테스트해 보세요:
docker-compose up
모든 것이 올바르게 구성되었다면 redis와 postgres가 부팅되는 것을 볼 수 있습니다. 취소하려면 Control-C를 누르거나, 어떤 이유로든 깨끗하게 종료되지 않으면 docker-compose down을 실행하세요.
기타 라이브러리
대부분의 이미지 최적화 라이브러리는 port 또는 brew를 사용하여 설치할 수 있습니다. port를 사용하여 수행하는 방법은 다음과 같습니다:
sudo port install imagemagick pngquant optipng jhead jpegoptim gifsicle
svgo는 npm이 설치된 후에 설치할 수 있습니다. 매우 직관적이므로 다루지 않겠습니다.
참고로 제 생각에는 이 도구 중 어느 것도 필수적이지 않습니다. 나중에 여러 단계에서 누락되었음을 알리는 경고가 보이지만, 아무것도 문제가 되지 않는 것 같습니다.
config/database.yml 및 spec/fixtures/multisite/two_dbs.yml
마지막으로 postgres에 올바르게 연결하도록 개발 환경을 가볍게 재구성해야 합니다. 기본적으로 Unix 소켓을 사용하려고 하는데, 이는 컨테이너에서 내보내지지 않습니다.
이를 수정하려면 config/database.yml을 수정해야 합니다. 기본적으로 다음을 보는 모든 곳에서:
adapter: postgresql
다음으로 대체하세요:
adapter:postgresql
host: localhost
username: discourse
password: discourse
host 추가는 Discourse가 소켓을 사용하지 않도록 하고, username과 password는 Discourse가 위에서 설정한 비밀번호와 함께 기본 Discourse 데이터베이스 사용자로 연결하도록 합니다.
config/database.yml에서 이 변경을 세 번 수행해야 했습니다: development 아래에서 한 번, test 아래에서 한 번, 마지막으로 profile 아래에서 한 번. 테스트 스위트를 작동시키기 위해 spec/fixtures/multisite/two_dbs.yml에서도 유사한 변경을 해야 했습니다.
시작합니다…
자, 시작해 보겠습니다! 한 창에서 docker-compose를 사용하여 개발 환경을 실행하세요:
docker-compose up
두 번째 창에서 데이터베이스 설정 단계를 실행해 보겠습니다:
bundle exec rake db:create
```\n작동했다면 이제 [`brew` 기반 macOS 가이드](https://meta.discourse.org/t/beginners-guide-to-install-discourse-on-macos-for-development/15772)의 적절한 지점에서 계속할 수 있습니다.
작업을 마친 후에는 `docker-compose`를 중지하고 다음 번까지 개발 환경을 정리할 수 있습니다.
데이터베이스와 redis 내용을 영구적으로 삭제하려면 `docker-compose down -v`를 실행하여 컨테이너 자체와 함께 영구 볼륨을 지우면 됩니다. 하지만 `-v` 플래그가 없으면 `docker-compose down`은 개발 세션 간에 데이터베이스를 유지합니다.
## 테스트가 통과합니까?
제 설정은 두 가지 테스트 케이스에서 실패했습니다:
```sh
Failures:
1) UploadCreator#create_for pngquant should apply pngquant to optimized images
Failure/Error: expect(upload.filesize).to eq(9558)
expected: 9558
got: 9550
(compared using ==)
# ./spec/lib/upload_creator_spec.rb:115:in `block (4 levels) in <main>'
2) tasks/uploads uploads:secure_upload_analyse_and_update when store is external when secure media is enabled rebakes the posts attached
Failure/Error: expect(post1.reload.baked_at).not_to eq(post1_baked)
expected: value != 2020-03-08 03:20:01.777117000 +0000
got: 2020-03-08 03:20:01.777117000 +0000
(compared using ==)
Diff:
<The diff is empty, are your objects producing identical `#inspect` output?>
# ./spec/tasks/uploads_spec.rb:90:in `block (5 levels) in <main>'
Finished in 19 minutes 21 seconds (files took 13.67 seconds to load)
4297 examples, 2 failures, 11 pending
제 생각에 첫 번째는 pngquant가 예상보다 약간 더 잘 작동하는 것처럼 보입니다. 그것이 왜 실패를 나타내는지 확실하지 않습니다. 두 번째도 이해하지 못합니다. 하지만 제게는 합리적으로 보입니다.
즐거운 해킹을!