HTTP 라우터

HTTP 라우터에 대해 설명합니다.

HTTP 라우터 # HTTP 라우터는 클러스터 내 들어오는 요청을 어떤 셀이 처리해야 할지 결정하는 서비스입니다. 이는 일반적으로 요청이 요청하는 리소스에 의해 결정됩니다. 예를 들어, cell-2 내의 프로젝트를 찾는 요청은 cell-2 로 라우팅됩니다. HTTP 라우터에 대한 자세한 내용은 디자인 문서 와 프로젝트 저장소 를 참조하세요. 라우팅 규칙 # 라우팅 규칙은 요청을 디코딩하고 라우팅 결정을 내리는 방법을 정의합니다. 규칙은 규칙셋으로 구성됩니다(예: session_token ). 규칙은 정적이며 HTTP 라우터 배포 이전에 (규칙셋 기준으로) 선택됩니다. 라우팅 결정은 위에서 아래로 평가됩니다. 첫 번째 일치 시 단락(short-circuit)됩니다. 규칙 및 들어오는 요청이 라우팅 규칙에 매칭되는 실행 예시에 대한 더 심층적인 설명은 http-router 문서의 rules 를 참조하세요. 라우팅 가능한 토큰 기반 라우팅 # 라우팅 가능한 토큰(routable token)은 라우팅 정보를 토큰 자체에 직접 인코딩합니다. 요청에 라우팅 가능한 토큰이 포함되어 있으면, HTTP 라우터는 해당 토큰을 디코딩하여 요청을 올바른 셀로 라우팅합니다. 라우터는 리소스를 소유한 셀을 찾기 위해 다른 서비스에 쿼리할 필요가 없습니다. 이는 Routable Tokens 디자인 문서 를 따릅니다. 라우팅 가능한 토큰 기반 라우팅에는 두 가지 측면이 있습니다: GitLab은 토큰을 생성할 때 라우팅 정보를 인코딩합니다. HTTP 라우터는 해당 정보를 디코딩하여 요청을 라우팅합니다. 토큰에 라우팅 정보 인코딩 # routable_token 을 가능한 한 빨리 도입하세요. 이렇게 하면 토큰이 처음부터 라우팅 가능한 정보와 함께 생성됩니다. HTTP 라우터 디코더 변경은 나중에 이루어질 수 있습니다. 라우터가 요청을 라우팅할 위치를 알지 못하는 경우, 레거시 셀로 폴백합니다. GitLab은 TokenAuthenticatable concern의 routable_token: 옵션을 통해 토큰에 라우팅 정보를 인코딩합니다. 자세한 내용은 TokenAuthenticatable concern 사용하기 를 참조하세요. 예를 들어, Ci::Runner#token 은 라우팅 가능합니다. 러너 토큰은 그룹 타입 및 프로젝트 타입 러너에 대해 조직(organization), 그룹(group), 프로젝트(project), 사용자(user) 키를 인코딩합니다: add_authentication_token_field :token, encrypted: :optional, expires_at: :compute_token_expiration, format_with_prefix: :prefix_for_new_and_legacy_runner, routable_token: { if: ->(token_owner_record) { (token_owner_record.group_type? || token_owner_record.project_type?) && token_o