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_owner_record.owner &&
        Feature.enabled?(:routable_runner_token, token_owner_record.owner)
    },
    payload: {
      o: ->(token_owner_record) { token_owner_record.owner.organization_id },
      g: ->(token_owner_record) { token_owner_record.group_type? ? token_owner_record.sharding_key_id : nil },
      p: ->(token_owner_record) { token_owner_record.project_type? ? token_owner_record.sharding_key_id : nil },
      u: ->(token_owner_record) { token_owner_record.creator_id }
    }
  }

토큰 디코딩 및 요청 라우팅#

HTTP 라우터는 토큰을 규칙과 대조하여 페이로드를 디코딩하고, 요청을 셀 기준으로 분류합니다.

각 토큰 타입마다 HTTP 라우터에 새 규칙이 필요합니다.

러너 토큰을 라우팅하는 규칙은 다음과 같습니다:

{
  "id": "session_token_header_runner_token",
  "match": {
    "type": "header",
    "name": "runner-token",
    "regexValue": "^glrtr?-(?<payload>[0-9A-Za-z_-]{27,300})\\.01\\.(?<payload_length>[0-9a-z]{2})[0-9a-z]{7}$"
  },
  "transform": {
    "type": "routable-token-payload",
    "input": [
      "${payload}",
      "${payload_length}"
    ],
    "output": "decoded"
  },
  "action": "classify",
  "classify": {
    "type": "CELL_ID",
    "value": "${decoded.c}"
  },
  "validate": {
    "exist": [
      "${decoded.c}"
    ]
  }
}

라우터는 다음 단계에 따라 규칙을 처리합니다:

• 매치(Match): match.regexValue가 토큰에서 payload와 payload_length를 캡처합니다. payload_length는 디코더에게 페이로드의 얼마나 많은 부분을 읽어야 하는지 알려주어, 토큰 전체를 디코딩하는 것을 방지합니다.

• 변환(Transform): routable-token-payload 변환이 Base64 페이로드를 디코딩하고 결과를 decoded 아래에 첨부합니다. 예를 들어, decoded.c는 셀을 나타냅니다.

• 검증(Validate): 라우터가 decoded.c가 존재하는지 확인합니다.

• 분류(Classify): 라우터가 decoded.c 값을 사용하여 Topology Service에 CELL_ID 분류 요청을 보내고, Topology Service가 반환하는 셀로 요청을 프록시합니다.

샘플 요청과 함께 이 규칙을 단계별로 살펴보려면, http-router 문서의 러너 토큰 예시를 참조하세요.

리소스 경로 기반 라우팅#

출시 예정

리소스 ID 기반 라우팅#

출시 예정