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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
proposed					-

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

Cells: Git Access

이 문서는 Cells 아키텍처가 모든 Git 액세스(HTTPS 및 SSH) 패턴에 미치는 영향을 설명하며, 이러한 기능이 어떻게 변경되어야 하는지에 대한 설명을 제공합니다.

1. 정의

Git 액세스는 응용 프로그램 전반에 걸쳐 이루어집니다. 시스템에 의해 수행되는 작업(깃 저장소 읽기)일 수도 있고, 사용자에 의해 수행되는 작업(Web IDE를 통해 새 파일 생성, 명령 줄을 통한 git clone, git push 등)일 수도 있습니다. Cells 아키텍처는 모든 Git 저장소가 Cell 내부에 로컬로 존재하므로 다른 Cell과 저장소를 공유할 수 없다고 정의합니다.

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

2. 데이터 흐름

지금까지 GitLab에서 Git 저장소에 수행되는 다양한 작업들이 있습니다. 이것은 그 영향을 더 잘 이해하기 위해 현재의 동작을 설명한 데이터 흐름입니다.

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

프로젝트: 그룹에 할당됨
위키: 프로젝트에 할당된 추가 저장소
디자인: 위키와 유사, 프로젝트에 할당된 추가 저장소
스니펫: 저장소를 보유하는 가상 프로젝트를 생성, 아마도 사용자와 연계됨

2.1. HTTPS를 통한 Git clone

실행: HTTPS를 통한 git clone

sequenceDiagram 사용자 ->> 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 ->> 사용자: 응답 사용자 ->> Workhorse: POST /gitlab-org/gitlab.git/git-upload-pack Workhorse ->> Gitaly: RPC PostUploadPackWithSidechannel Gitaly ->> 사용자: 응답

2.2. SSH를 통한 Git clone

실행: SSH를 통한 git clone

2.3. HTTPS를 통한 Git push

실행: HTTPS를 통한 git push

sequenceDiagram 사용자 ->> 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 ->> 사용자: 응답

2.4. SSH를 통한 Git push

실행: SSH를 통한 git clone

sequenceDiagram 사용자 ->> Git SSHD: ssh git@gitlab.com Git SSHD ->> Rails: GET /api/v4/internal/authorized_keys Rails ->> Git SSHD: 200 OK(수락된 SSH 키 목록) Git SSHD ->> 사용자: SSH 수락 사용자 ->> 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 ->> 사용자: 응답

2.5. 웹을 통한 커밋 생성

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

여기서:

gl_repository는 project-1111일 수 있다 (Gitlab::GlRepository)
일부 경우에는 gl_repository가 GitLab Shell에서 실행된 리포지토리의 전체 경로일 수 있다(/gitlab-org/gitlab.git)

4. 평가

셀이 자체 리포지토리에만 액세스할 수 있다면 Git 리포지토리를 지원하는 것은 복잡해 보이지 않는다. 주요한 복잡성 중 하나는 스니펫을 지원하는 것이지만, 이것은 아마도 사용자의 개인 네임스페이스를 지원하기 위한 접근 방식과 동일한 범주에 속할 것이다.

4.1. 장점

HTTPS/SSH 및 훅을 지원하는 데 사용되는 API는 명확히 정의되어 있으며 쉽게 라우팅될 수 있다.

4.2. 단점

리포지토리 객체의 공유가 주어진 셀 및 Gitaly 노드로 제한된다.
셀 간 포크는 아마도 지원되지 않을 것으로 보인다(알아내기: 현재 다른 Gitaly 노드 간의 작동 방식).

5. 포크 및 객체 풀

셀 아키텍처와 관련된 가장 큰 고민 중 하나는 포킹을 어떻게 처리할지이다. 현재, Gitaly는 포크 저장소의 중복을 제거하기 위해 개체 풀을 활용한다. 만약 포크가 원본 리포지토리가 아닌 다른 저장소 노드에 만들어진다면, 우리는 실질적으로 리포지토리의 두 완전한 사본을 가지게 되어 저장 공간의 효율성이 저하되고 개체 풀을 활용할 수 없게 된다.

한 셀의 저장소 노드는 다른 셀의 저장소 노드와 통신할 수 없기 때문에, 셀 간 포크는 불가능하다. 따라서, 포크된 리포지토리가 원본 부모 리포지토리와 동일한 셀(및 동일한 Gitaly 노드)에 있도록 보장하는 것이 필요할 것이다. 이는 또한 Gitaly가 저장 및 성능 효율성을 제공하기 위해 개체 풀을 활용할 수 있도록 할 것이다.

5.1. 현재 작동 방식

단일 Gitaly 저장소 노드

현재, 하나의 Gitaly 저장소 노드로 뒷받침된 GitLab 인스턴스의 경우, 포킹은 아주 잘 작동한다. 모든 포크는 하나의 저장소 노드에 있어야 하므로, 개체 중복 제거(및 개체 풀)가 모두 예상대로 작동한다.

숄더드 Gitaly 저장소

숄더드 Gitaly 저장소란 여러 Gitaly 저장소 노드가 하나의 인스턴스에 연결되고 노드 사이에 우선 순위 가중치에 기반하여 리포지토리가 할당되는 경우를 말한다.

Gitaly는 다른 저장소에서 가져와야 하는 것을 알고 있기 때문에, 분할된 구역 간 포킹은 문제가 없이 작동한다.

Gitaly 클러스터

Gitaly 클러스터의 경우, 최근에 이 문제가 해결되었는데, 이는 개체 풀이 부모 저장소와 동일한 저장소 노드에 생성되지 않도록 됐다. 이는 효율적으로 포킹을 제대로 지원할 수 있도록 만들며(개체 풀을 공유할 수 있음), 개체 중복 제거 관점에서도(Git은 저장 공간을 제대로 중복 처리할 수 있음) 올바르게 작동할 수 있게 했다.