This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed -

이 문서는 작업 중이며 Cells 설계의 매우 초기 상태를 나타냅니다. 중요한 측면은 문서화되지 않았지만, 우리는 미래에 이를 추가할 것으로 기대합니다. 이것은 Cells에 대한 하나의 가능한 아키텍처이며, 우리는 구현할 접근 방법을 결정하기 전에 대안과 대조할 것을 의도합니다. 우리는 이 접근 방식을 선택하지 않기로 결정하더라도 그 이유를 문서화할 수 있도록 이 문서를 유지할 것입니다.

Cells: Git Access

이 문서는 Cells 아키텍처가 HTTPS 및 SSH를 통한 모든 Git 액세스에 미치는 영향을 설명하며, 이러한 기능을 Cells와 원할하게 작동하도록 변경해야 하는 방법을 설명합니다.

1. 정의

Git 액세스는 응용 프로그램 전반에 걸쳐 수행됩니다. 시스템에 의해 수행되는 작업( Git 리포지터리 읽기)일 수도 있고 사용자에 의해 수행되는 작업(Web IDE를 통한 새 파일 만들기, 명령줄을 통한 ‘git clone’ 또는 ‘git push’ 등)일 수도 있습니다. Cells 아키텍처는 모든 Git 리포지터리가 셀 내부에 로컬로 저장되어 다른 셀과 공유되지 않는다는 것을 정의합니다.

Cells 아키텍처는 모든 Git 작업이 데이터를 보유한 셀에 의해서만 처리될 수 있도록 요구합니다. 즉, 웹 인터페이스, API 또는 GraphQL을 통한 모든 작업은 올바른 셀로 라우팅되어야 합니다. 즉, ‘git clone’ 또는 ‘git push’ 작업은 셀의 컨텍스트에서만 수행될 수 있습니다.

2. 데이터 흐름

현재 GitLab에서 Git 리포지터리에 대해 수행되는 다양한 작업이 있습니다. 이것은 영향을 더 잘 나타내기 위해 현재 작동 방식을 나타내는 데이터 흐름을 설명합니다.

Git 액세스는 프로젝트에 지정된 몇 가지 엔드포인트만 변경이 필요한 것으로 보입니다. 다양한 유형의 리포지터리가 있는 것으로 보입니다:

  • 프로젝트: 그룹에 할당
  • 위키: 프로젝트에 할당된 추가 리포지터리
  • 디자인: 위키와 유사하며, 프로젝트에 할당된 추가 리포지터리
  • 스니펫: 리포지터리를 보유하기 위한 가상 프로젝트를 생성하며, 사용자에 연결될 수 있습니다.

2.1. HTTPS를 통한 Git 클론

git clone을 HTTPS를 통해 실행

sequenceDiagram User ->> Workhorse: GET /gitlab-org/gitlab.git/info/refs?service=git-upload-pack Workhorse ->> Rails: GET /gitlab-org/gitlab.git/info/refs?service=git-upload-pack Rails ->> Workhorse: 200 OK Workhorse ->> Gitaly: RPC InfoRefsUploadPack Gitaly ->> User: 응답 User ->> Workhorse: POST /gitlab-org/gitlab.git/git-upload-pack Workhorse ->> Gitaly: RPC PostUploadPackWithSidechannel Gitaly ->> User: 응답

2.2. SSH를 통한 Git 클론

git clone을 SSH를 통해 실행

sequenceDiagram User ->> Git SSHD: ssh git@gitlab.com Git SSHD ->> Rails: GET /api/v4/internal/authorized_keys Rails ->> Git SSHD: 200 OK (수락된 SSH 키 디렉터리) Git SSHD ->> User: SSH 수락 User ->> Git SSHD: SSH를 통한 git clone Git SSHD ->> Rails: POST /api/v4/internal/allowed?project=/gitlab-org/gitlab.git&service=git-upload-pack Rails ->> Git SSHD: 200 OK Git SSHD ->> Gitaly: RPC SSHUploadPackWithSidechannel Gitaly ->> User: 응답

2.3. HTTPS를 통한 Git 푸시

git push를 HTTPS를 통해 실행

sequenceDiagram User ->> Workhorse: GET /gitlab-org/gitlab.git/info/refs?service=git-receive-pack Workhorse ->> Rails: GET /gitlab-org/gitlab.git/info/refs?service=git-receive-pack Rails ->> Workhorse: 200 OK Workhorse ->> Gitaly: RPC PostReceivePack Gitaly ->> Rails: POST /api/v4/internal/allowed?gl_repository=project-111&service=git-receive-pack Gitaly ->> Rails: POST /api/v4/internal/pre_receive?gl_repository=project-111 Gitaly ->> Rails: POST /api/v4/internal/post_receive?gl_repository=project-111 Gitaly ->> User: 응답

2.4. SSH를 통한 Git 푸시

git clone을 SSH를 통해 실행

sequenceDiagram User ->> Git SSHD: ssh git@gitlab.com Git SSHD ->> Rails: GET /api/v4/internal/authorized_keys Rails ->> Git SSHD: 200 OK (수락된 SSH 키 디렉터리) Git SSHD ->> User: SSH 수락 User ->> Git SSHD: SSH를 통한 git clone Git SSHD ->> Rails: POST /api/v4/internal/allowed?project=/gitlab-org/gitlab.git&service=git-receive-pack Rails ->> Git SSHD: 200 OK Git SSHD ->> Gitaly: RPC ReceivePack Gitaly ->> Rails: POST /api/v4/internal/allowed?gl_repository=project-111 Gitaly ->> Rails: POST /api/v4/internal/pre_receive?gl_repository=project-111 Gitaly ->> Rails: POST /api/v4/internal/post_receive?gl_repository=project-111 Gitaly ->> User: 응답

2.5. 웹을 통한 커밋 생성

리포지터리에 Add CHANGELOG를 실행:

sequenceDiagram Web ->> Puma: POST /gitlab-org/gitlab/-/create/main Puma ->> Gitaly: RPC TreeEntry Gitaly ->> Rails: POST /api/v4/internal/allowed?gl_repository=project-111 Gitaly ->> Rails: POST /api/v4/internal/pre_receive?gl_repository=project-111 Gitaly ->> Rails: POST /api/v4/internal/post_receive?gl_repository=project-111 Gitaly ->> Puma: 응답 Puma ->> Web: CHANGELOG 확인

3. 제안

Cells 무상 라우터 제안은 애매한 경로(라우팅할 수 없는)를 라우팅할 수 있게 만들어야 한다고 요구합니다. 최소한 다음 경로 중 하나는 라우팅 가능한 항목(프로젝트, 그룹 또는 조직)을 도입하도록 업데이트해야 합니다.

변경:

  • /api/v4/internal/allowed => /api/v4/internal/projects/<gl_repository>/allowed
  • /api/v4/internal/pre_receive => /api/v4/internal/projects/<gl_repository>/pre_receive
  • /api/v4/internal/post_receive => /api/v4/internal/projects/<gl_repository>/post_receive
  • /api/v4/internal/lfs_authenticate => /api/v4/internal/projects/<gl_repository>/lfs_authenticate

Where:

  • gl_repository는 project-1111 (Gitlab::GlRepository)일 수 있습니다.
  • 경우에 따라 gl_repository는 GitLab Shell에 의해 실행되는 리포지터리의 전체 경로일 수 있습니다 (/gitlab-org/gitlab.git)

4. 평가

셀이 자체 리포지터리에만 액세스할 수 있는 경우 Git 리포지터리를 지원하는 것은 복잡해 보이지 않습니다. 주요한 복잡성은 스니펫을 지원하는 것이지만, 이는 사용자의 개인 네임스페이스를 지원하는 방식과 유사한 범주에 속할 것으로 예상됩니다.

4.1. 장점

  1. HTTPS/SSH 및 후크를 지원하는 데 사용되는 API는 명확하게 정의되어 있으며 쉽게 라우팅될 수 있습니다.

4.2. 단점

  1. 리포지터리 객체의 공유는 지정된 셀과 Gitaly 노드로 제한됩니다.
  2. 셀 간 포크는 아마도 지원이 불가능할 것입니다(이는 다른 Gitaly 노드 간 현재 작동 방식을 확인해보세요).

5. 포크 및 객체 풀

셀 아키텍처에서 해결해야 할 가장 큰 고민 중 하나는 포크를 어떻게 처리할 것인지입니다. 현재 Gitaly는 포크 스토리지의 중복을 제공하기 위해 객체 풀을 활용합니다. 만약 포크가 상위 리포지터리와 다른 리포지터리 노드에 생성된다면, 저장 공간의 비효율성이 발생하게 될 것으로 예상됩니다. 이로 인해 리포지터리의 두 완전한 사본이 생기게 되고 성능을 향상시키기 위해 객체 풀을 활용할 수 없게 될 것입니다.

한 셀에서의 리포지터리 노드는 다른 셀의 리포지터리 노드와 통신할 수 없으므로 셀 간 포킹이 불가능합니다. 따라서 포크된 리포지터리가 상위 부모 리포지터리와 동일한 셀(및 동일한 Gitaly 노드)에 저장되도록 보장해야 합니다. 이는 또한 Gitaly가 객체 풀을 활용하여 저장 및 성능 효율성을 유지할 수 있도록 할 것입니다.

5.1. 현재 작동 방식

단일 Gitaly 리포지터리 노드

현재, 단일 Gitaly 리포지터리 노드를 사용하는 GitLab 인스턴스의 경우 포킹은 문제없이 작동합니다. 한 개의 리포지터리 노드만 있기 때문에 모든 포크는 동일한 리포지터리 노드에 있어야 하며, 따라서 객체 중복 제거 및 객체 풀이 모두 원하는 대로 작동합니다.

분할된 Gitaly 리포지터리

여러 개의 Gitaly 리포지터리 노드가 단일 인스턴스에 연결되고 노드 간의 우선 순위 가중치에 따라 리포지터리가 할당되는 분할된 Gitaly 리포지터리입니다.

Gitaly는 여러 리포지터리 간에 데이터를 가져오는 방법을 알기 때문에, 분할된 리포지터리 간 포킹은 문제없이 작동합니다.

Gitaly 클러스터

Gitaly 클러스터의 경우 최근 이 문제를 해결하여 포크가 올바르게 작동하도록 했습니다(효율적인 관점에서 객체 풀 공유 가능, Git이 리포지터리를 정상적으로 중복 제거).