Docker 설치에 어떤 장점이 있나요?

제품 지원 자체 호스팅
1

문서와 여기의 많은 스레드에서 Docker가 유일한 (좋은) 방법이라고 제안하는 것을 알고 있지만, 그 이유를 알고 싶었습니다. 저는 월 $3.50짜리 Amazon Lightsail Debian 인스턴스를 구매했고, 20분 만에 Discourse를 설정하여 실행했습니다. rbenv를 사용하여 Ruby 3.2.2를 설치했고, 나머지는 간단했습니다. Discourse가 Rails 관례를 따르지 않는다는 것도 발견했는데, 예를 들어 왜 ./config/discourse.conf와 GlobalSetting이 이러한 값을 지정하는 config/environments/production.rb 대신 사용되는지 궁금합니다. 이것이 Docker 이미지들이 결국 생성하는 내용인가요 (또한 sidekiq.yml에 production 환경 값이 없는 것도)?

Docker에서 실행하는 데 장점이 있나요? 무언가를 놓치고 있는 건 아닌지 궁금합니다…

2

정말 짧게 말하면, 표준 설치 방법을 사용하지 않는다면 여기서 도움을 드리기 어렵습니다. 그 경로를 벗어나면 문제가 생길 수 있는 경우가 너무 많기 때문입니다.

3

아, 알겠어. 그래, OS가 다르니까 그런 거구나. 이미 어떻게 했는지 물어보는 사람이 있어서 혹시 모르니 여기에 공유할게.

Ruby 3.2.x(rbenv를 사용해야 OS에 종속되지 않음), Node v16.19.x/npm 8.19.x, 그리고 PostgreSQL(11 이상의 버전이면 아마 문제없을 것)이 필요해.

  1. .ruby-version 파일을 만들어서 설치한 Ruby 버전(3.2.2)을 지정했어.
  2. bundle을 실행했는데 모든 gem이 정상적으로 빌드됐어.
  3. PostgreSQL 자체에서 데이터베이스를 설정해야 했어:
CREATE DATABASE discourse;
CREATE USER discourse WITH password 'fA....';
GRANT ALL PRIVILEGES ON DATABASE discourse TO discourse;
\c discourse
GRANT ALL ON SCHEMA public TO discourse;

database.yml이 production 변수를 받지 않는다는 점이 놀라웠어 (이건 Rails 관례에 매우 어긋나는 것 같아). 모든 DB 설정은 SMTP 값과 함께 config/discourse.conf에 있었다. 그 값들을 채워 넣었어.

그 다음 데이터베이스 마이그레이션을 실행했어:

bundle exec rails db:migrate

모두 정상 작동했고 마이그레이션도 성공적으로 완료됐어.

  1. config/sidekiq.yml에서 development 섹션 뒤에 다음 내용을 추가했어:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. 그 다음 lib/tasks/assets.rake 파일을 151줄 부근에서 수정해서 다음 내용을 추가했어:
harmony: true,

그러면 다음과 같이 보여:

  uglified, map =
    Uglifier.new(
      comments: :none,
      harmony: true,
      source_map: {
        filename: File.basename(from),
        output_filename: File.basename(to),
      },
    ).comp

그리고 다음 npm 패키지를 설치했어:

npm install terser
npm install -g uglify-js@"<3"

그 후 에셋을 빌드했어:

RAILS_ENV=production bundle exec rake assets:precompile

그리고 성공! 이제 이 명령이 작동해야 해:

 bundle exec sidekiq -e production -C config/sidekiq.yml
 bundle exec puma --config config/puma.rb -e production

이것으로 sidekiq와 puma 웹 서버가 실행돼.

(훨씬 저렴하고 더 많은 제어가 가능해, 예를 들어 나는 이미 Ruby 3.2.2를 실행하고 있어). 대부분의 시간은 특이한 문제들을 해결하는 데 걸렸어 (예를 들어 production 값들이 있어야 할 자리에 없어서 찾아보는 것 같은). 하지만 그 외에는 꽤 빨랐어!

4

정말 인상적입니다. 다만 위에서 언급했듯이, 사이트가 깨지는 문제가 발생하면 상황이 달라집니다. 문제를 해결해 줄 수 있는 커뮤니티 내의 인원은 매우 제한적일 수 있습니다. 따라서 가장 큰 위험점이자 단점은, 완전한 재설치를 필요로 할 정도로 길거나 심지어 재앙적인 수준의 다운타임이 발생할 수 있다는 것입니다.

사이트가 다운된 시간이 길수록 평판 하락과 회원 감소라는 손실이 커질 수 있습니다.

단순히 실험 목적으로 사용하고 안정적인 프로덕션 사이트에 크게 의존하지 않는다면, 시간 외에는 크게 잃을 것이 없습니다.