여러 개의 하위 도메인을 포함하는 Rails 애플리케이션 구축

오늘 게시물에서는 여러 개의 하위 도메인을 지원하는 Rails 애플리케이션을 구축하는 방법을 학습합니다.만약에 우리가 게임 사이트 funkygames.co을 가지고 있다면 우리는 하나의 Rails 응용 프로그램을 통해 여러 개의 하위 도메인을 지원하기를 희망한다. 예를 들어 app.funkygames.co, api.funkygames.co과 dev.funkygames.co이다.우리는 모든 하위 영역에 대한 정확한 인증을 실행하고 중복된 경로가 없기를 희망합니다.
Rails의 강력한 라우팅 구조를 사용하여 응용 프로그램의 여러 하위 도메인을 지원합니다.우리는 또한 로컬에서 하위 필드를 설정하고 여러 하위 필드를 위한 테스트를 작성할 것입니다.

선결 조건
이 문서에서는 Rails 응용 프로그램을 가리키는 모든 하위 도메인에 적절한 DNS 레코드를 설정했다고 가정합니다.이 글에서 우리는 Rails 방면의 문제만 토론한다.

다중 하위 도메인 처리
Rails는 전송 요청을 처리하고 매핑하기 위해 routes.rb 파일을 사용합니다.
특정 컨트롤러 작동routes.rb의 각 매핑은 일반적인 애플리케이션에서
다음과 같이 라우트를 컨트롤러 작업에 매핑합니다.

  get '/games/:id', to: 'games#show'

이 방법을 통해 routes.rb 파일에 정의된 모든 단점
모든 하위 도메인에 적용됩니다.이에 따라 app.funkygames.co/games/1과 api.funkygames.co/games/1은 이 노선을 통해 처리된다.그러나, 우리는 이 루트를 통해 app 자역에서 온 요청을 처리하기를 희망합니다.api 하위 도메인은 API 라우팅에만 사용됩니다.전송 요청이 특정 규칙을 충족시킬 때만 이 규칙을 처리할 수 있도록 루트에 규칙을 추가할 것입니다.
Rails 라우팅은 지정된 라우팅에 다른 규칙을 지정할 수 있는 constraints 액세스 방식을 제공합니다.

  get '/games/:id', to: 'games#show', constraints: { subdomain: 'app' }

이것은 요청이 app.funkygames.co/games/1에서 오면 GamesController's show action에서 처리될 것을 확보합니다.app을 제외한 다른 하위 도메인의 요청은 이 라우트를 통해 처리되지 않습니다.
노선마다 constraints을 이렇게 정의하는 것은 매우 번거로울 것이다.

  get '/games/:id', to: 'games#show', constraints: { subdomain: 'app' }
  get '/games/list', to: 'games#list', constraints: { subdomain: 'app' }
  post '/games/start', to: 'games#start', constraints: { subdomain: 'app' }

우리는 constraints 도움말의 블록 형식을 사용하여 여러 개를 정의할 수 있다
단일 하위 도메인의 라우팅입니다.

  constraints subdomain: 'app' do
    get '/games/:id', to: 'games#show'
    get '/games/list', to: 'games#list'
    post '/games/start', to: 'games#start'
  end

여러 개의 하위 영역에 대한 루트를 정의하려면, 우리는 constraints 파일에 여러 개의 routes.rb 블록을 추가하기만 하면 된다.

constraints subdomain: 'app' do
  ...
end

constraints subdomain: 'api' do
  ...
end

constraints subdomain: 'dev' do
  ...
end

엔진 덮개
Rails 라우팅은 요청 구속조건 및 세그먼트 구속조건을 제공합니다.세그먼트 구속조건은 요청 경로에 규칙을 추가하고 요청 구속조건은 전송 요청에 조건을 추가합니다.요청 제약 중의 해시 키는 Request 대상에서 문자열을 되돌려 주는 방법이어야 하며, 이 값은 예상 값이어야 한다.

constraints subdomain: 'app' do
  ...
end

위의 예에서 우리는 subdomain 대상에 Request 방법을 사용하고 이를 app, api 또는 dev과 같은 문자열과 일치한다.
자세한 내용은 Rails routing guide에 문의하십시오.

다중 레벨 하위 도메인 작업
만약에 우리가 app.staging.funkygames.co을 무대 환경으로 사용한다면.만약 우리가 위의 설정을 가지고 있다면, 우리는 곧 app 자역에 도착해야 하는 모든 요청이 404로 되돌아오는 것을 알아차릴 것이다.만약 우리가 더 이상 디버깅을 한다면, 우리는 하위 영역에 대한 제약이 실패했다는 것을 알아차릴 것이다.

request.subdomain #=> app.staging

우리는 자역이 app으로 돌아오기를 희망하지만, 그것은 app.staging으로 돌아간다.물론, 우리는 환경에 특정한 코드를 추가하지 않은 상황에서 이 문제를 해결하기를 희망합니다!요청 하위 영역의 해석은 config.action_dispatch.tld_length 옵션으로 관리됩니다.이 구성의 기본값은 1이며 기본적으로 1레벨 하위 도메인을 지원합니다.우리는 두 개의 등급의 자역이 있기 때문에 config.action_dispatch.tld_length의 값을 2로 설정해야 한다.

# config/application.rb
config.action_dispatch.tld_length = Integer(ENV['TLD_LENGTH'] || 1)

우리는 환경 변수를 사용하여 설정할 수 있다. 이렇게 하면 우리는 무대에 오르는 것과 생산 환경에서 같은 코드를 사용할 수 있다.현재 우리의 루트 설정도 app.staging.funkygames.co에 적용된다.

세션 관리
루트가 여러 하위 영역에서 오는 요청을 처리하는 것으로 정의되었으니,
우리는 모든 하위 영역의 신분 검증을 책임져야 한다.우리는 두 가지 방식으로 이 점을 할 수 있다. 하나는 모든 하위 영역에서 같은 사용자 세션을 사용할 수 있도록 하는 것이고, 다른 하나는 단독 하위 영역에 단독 세션을 사용할 수 있도록 하는 것이다.

요컨대 신분 검증
Rails는 기본적으로 쿠키를 사용하여 사용자 세션 키를 저장합니다.사용자가 로그인한 후 사용자의 세션 정보는 우리가 선택한 세션 저장소에 저장되고 세션 키는 쿠키로 브라우저에 저장됩니다.따라서 사용자가 다음에 저희 사이트를 방문할 때 같은 세션 쿠키는 브라우저에서 서버로 전송되고 서버는 세션 쿠키를 전송하는 세션이 존재하는지에 따라 사용자의 로그인 여부를 결정합니다.
Rails 응용 프로그램에서 세션의 기본 구성은 다음과 같습니다.

Rails.application.config.session_store :cookie_store, key: "_funkygames_session"

키 _funkygames_session은 세션 쿠키의 이름으로 사용되며, 값은 세션 id입니다.

비스킷 바탕 페인트
기본적으로 브라우저는 요청한 필드에 쿠키를 설정합니다.따라서 만약에 우리가 app.funkygames.co에서 응용 프로그램을 클릭하면 세션 쿠키는 app.funkygames.co으로 설정됩니다.모든 하위 필드는 자신의 세션 쿠키를 설정하기 때문에 기본적으로 사용자 세션은 하위 필드 사이에서 공유되지 않습니다.

서로 다른 하위 도메인 간에 세션 공유
하위 도메인 간에 사용자 세션을 공유하려면 funkygames.co 도메인 자체에 세션 쿠키를 설정하여 하위 도메인에 접근할 수 있도록 해야 합니다.이것은 domain 옵션을 세션 저장소 설정에 전달할 수 있습니다.

Rails.application.config.session_store :cookie_store, key: "_funkygames_session", domain: :all

domain을 :all으로 전달함으로써 우리는 기본적으로 Rails가 응용 프로그램의 최고급 구역(예를 들어 funkygames.co)에 세션 쿠키를 설정하는 것이지 요청 호스트에 세션 쿠키를 설정하는 것이 아니다. 요청 호스트는 각 하위 구역을 포함할 수 있다.일단 우리가 이렇게 하면 세션은 서로 다른 자역 사이에서 공유할 수 있다.

We can also pass a list of domains to the domains option in an array format to support multiple domains.

모든 하위 영역에 쿠키를 올바르게 설정할 수 있도록 설정해야 합니다.tld_length 옵션입니다.이 옵션은 domain: :all을 사용할 때 도메인의 TLD를 해석하는 방법을 지정합니다.우리의 예에서 app.funkygames.co에 대해 우리는 tld_length을 2로 설정하여 Rails가 쿠키를 설정할 때 TLD를 funkygames.co으로 해석하도록 해야 한다.따라서 다중 하위 도메인에 대한 최종 세션 스토리지 구성은 다음과 같습니다.

Rails.application.config.session_store :cookie_store,
                                       key: "_funkygames_session",
                                       domain: :all,
                                       tld_length: 2

The tld_length option from the session store is different from the config.action_dispatch.tld_length discussed earlier.

다중 하위 도메인에 대한 테스트 작성
루트는 하위 영역에 특정되어 있기 때문에 테스트 요청에 적합한 하위 영역이 없으면 요청 규범이나 통합 테스트는 404 오류를 초래할 수 있습니다.Rails 통합 테스트는 테스트 파일의 모든 요청에 적합한 하위 도메인을 설정할 수 있는 host! 지원을 제공합니다.

# Configuring subdomain in Rails integration tests
setup do
  host! 'dev.example.com'
end

# # Configuring subdomain in RSpec request specs
before do
 host! 'dev.example.com'
end

이후 요청은 routes.rb 파일의 하위 영역 루트에 따라 컨트롤러로 정확하게 연결됩니다.
필드는 여기서 중요하지 않습니다. 우리가 테스트한 코드에서 정확한 하위 필드만이 중요합니다.

로컬에서 여러 개의 하위 도메인을 설정하여 개발
로컬에서 하위 도메인을 설정할 수 있는 여러 가지 방법이 있습니다.가장 간단한 방법은 /etc/hosts 파일을 편집하는 것입니다.

127.0.0.1 dev.funkygames.local
127.0.0.1 app.funkygames.local
127.0.0.1 api.funkygames.local

이렇게 하면 하위 도메인 설정이 로컬 환경에서 작동하는지 확인할 수 있습니다.우리는 또한 pow과 같은 도구를 사용하여 로컬에서 하위 영역을 관리할 수 있다.

제약 기반 하위 도메인 라우팅
제약에 기반한 하위 필드 루트는 대부분의 경우 효과가 있지만, 어떤 경우에는 고통스러울 수도 있다.

외부 API 작업
타사 API 및 건축 통합을 사용하는 경우 .local 또는 .dev과 같은 로컬 개발 TLD를 사용할 수 없습니다.우리는 반드시 ngrok 등의 공구를 사용해야 한다.하위 영역을 기반으로 하는 루트는 이런 상황에서 작동하지 않습니다. 루트도ngrok를 통해 접근할 수 있도록 일부 루트를 백명단에 넣어야 합니다.

하위 도메인 제약 조건 외부의 라우팅
일부 라우트는 하위 도메인 구속 내에 배치할 수 없습니다.전형적인 예는 healthcheck 또는 ping 단점이다.Rails 애플리케이션 앞에서 로드 밸런서를 사용하는 경우 로드 밸런서는 정기적으로 애플리케이션이 시작되는지 확인해야 합니다.이런 상황에서 사용하는 healthcheck 단점은 하역의 제약을 받을 수 없습니다. 부하 균형기가 호스트를 요청하는 것을 모를 수 있기 때문입니다.

루트 경로 누락
Rails에는 기본적으로 응용 프로그램의 기본 경로인 root 경로가 있습니다.요청과 일치하는 다른 라우트가 없으면 root 라우트를 사용합니다.우리의 모든 루트가 하위 도메인 아래에 있을 때, root 루트가 정의되지 않은 상황이 발생할 수 있습니다.
일부 GEM은 root 노선의 존재에 따라 달라질 수 있으므로 이에 따라 견제와 균형을 늘려야 합니다.

결론
이 기사에서 우리는 여러 개의 하위 영역을 포함하는 Rails 프로그램을 설정했는데, 설정 줄이 매우 적다.우리는 또한 로컬과 서로 다른 환경에서 어떻게 자역을 설정하고 여러 자역을 위해 효과적인 테스트를 작성하는 기교를 이해했다.Rails에서 제공하는 파이프가 있어 여러 개의 하위 영역을 가진 Rails 응용을 설정하고 테스트하는 것이 쉬워졌다.
또한 Ruby Magic에 게시된 게시물이 출간되는 즉시 읽고 싶으면 subscribe to our Ruby Magic newsletter and never miss a single post으로 전화하세요!
객원 저자 Prathamesh Sonpatki은 루비와 루비 온 레일스의 개발자다.그는 또한 RubyConfIndia과 DeccanRubyConf을 연합하여 조직하였다