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					-

셀 1.0

이 문서는 Cells 1.0에 대한 기술 제안을 설명합니다.

Cells 1.0은 세포 구조의 첫 번째 반복입니다. Cells 1.0의 목표는 SaaS GitLab.com 오퍼링을 사용하는 새로운 기업 고객을 위한 솔루션을 제공하는 것입니다.

Cells 1.0은 GitLab.com SaaS에 배포될 목적으로 완벽하게 작동하는 기능입니다.

Cells 1.5에 대해 더 읽어보세요. 이는 기존 고객을 이주시키기 위한 메커니즘을 제공하고 Cells 1.0 아키텍처 위에 구축되었습니다.

Cells 2.0에 대해 더 읽어보세요. 이는 세포 구조에서 공개 및 오픈 소스 기여 모델을 지원하기 위한 것입니다.

전문

Cells 1.0은 다음과 같은 기대를 가진 기업 고객을 대상으로 합니다:

저희의 Multi-Tenant SaaS 솔루션(GitLab.com)을 사용하여 조직을 운영하고 싶어합니다.
GitLab.com이 다른 곳보다 나중에 업데이트를 받을 수도 있다는 점을 수용합니다. GitLab이 보안 릴리스를 할 때, Delivery 팀은 릴리스를 공개하기 전에 모든 셀이 보안 릴리스 버전을 실행하도록 합니다. 이는 보안 릴리스 이외의 시간에는 모든 셀이 GitLab의 동일한 버전을 실행하는 것을 의미하지는 않습니다. 더 많은 정보는 이 개인 토론을 참조하십시오.
시스템의 나머지 부분과 고립된 환경을 사용하기를 원합니다.
조직에 기여하는 모든 사용자를 제어하고 싶어합니다.
그들의 그룹과 프로젝트가 비공개로 유지되기를 원합니다.
그들의 사용자들은 다른 조직과 상호 작용할 필요가 없으며, 자신의 계정으로 공개 프로젝트에 기여할 필요가 없습니다.
자신의 계정으로 다른 조직으로 전환할 수 없는 것을 수용합니다.

개발 및 인프라 관점에서 다음 목표를 달성하고 싶습니다:

모든 Cells는 단일 도메인 하에 접근 가능합니다.
Cells는 대부분 독립적이며 최소한의 데이터 공유가 필요합니다. 모든 상태 데이터는 분리되어 있으며, 초기에는 최소한의 데이터 공유가 필요합니다. 이에는 데이터베이스와 클라우드 저장소 버킷이 포함됩니다.
Cells는 다른 버전을 사용하더라도 독립적으로 실행될 수 있어야 합니다.
최종적으로 클러스터 전체에서 데이터를 공유할 수 있는 아키텍처를 가져야 합니다.
견고하지만 간단한 라우팅 솔루션입니다.
모든 식별자(기본 키, 사용자, 그룹, 프로젝트 이름)가 클러스터 전체에서 고유해야 합니다. 이를 통해 나중에 논리적인 리밸런싱을 수행할 수 있습니다. 이에는 gitlab_internal 또는 gitlab_shared 스키마를 사용하는 테이블을 제외한 모든 데이터베이스 테이블이 포함됩니다.
모든 사용자 및 그룹이 클러스터 전체에서 고유하기 때문에, 동일한 사용자는 Cells 2.0에서 GitLab.com의 다른 조직과 그룹에 접근할 수 있습니다.
Cells를 관리하고 업그레이드하는 데 드는 부담이 최소화되며, 이는 GitLab Dedicated 인스턴스를 관리하는 것과 유사합니다. 보조 Cells는 운영 부담이 선형적으로 증가해서는 안됩니다.
Cell은 GitLab Dedicated와 동일한 도구를 사용하여 배포되어야 합니다.

본 제안은 가능한 범위를 최대한 줄이도록 설계되었지만, 다음 장기적 목표를 달성할 수 없게 만들어서는 안됩니다:

사용자는 여러 조직과 상호 작용할 수 있어야 합니다.
셀은 조직을 이동하여 리밸런스할 수 있어야 합니다.
라우팅 솔루션이 동적으로 고객을 경로 지정할 수 있어야 합니다.

제안

다음 문장은 Cells 1.0을 달성하기 위한 고수준 제안을 설명합니다:

사용하는 용어:
1. Primary Cell: 현재의 GitLab.com 배포. 이 아키텍처에서 클러스터 전체 서비스를 제공하는 특수 목적의 셀입니다.
2. Secondary Cells: 클러스터 전체의 고유성을 보장하기 위해 Primary Cell과 연결되는 셀입니다.
조직 속성:
1. 우리는 고객이 Secondary Cell에서 새로운 조직을 생성할 수 있도록 허용합니다. 선택한 Cell은 GitLab 운영자에 의해 제어됩니다.
2. 조직은 비공개로 유지되어야 하며, 공개로 전환될 수 없습니다.
3. 그룹 및 프로젝트는 비공개로 설정할 수 있지만 공개로 설정할 수는 없습니다.
사용자 속성:
1. 사용자는 해당 조직을 포함하는 Cell에 생성됩니다.
2. 사용자는 조직 탐색을 제공받지만 해당 사용자는 단일 조직의 구성원일 수 있습니다.
3. 사용자는 다른 조직에 가입하거나 상호 작용할 수 없습니다.
4. 사용자 계정은 셀 간에 이동될 수 없습니다.
5. 사용자의 개인 네임스페이스는 해당 조직에 생성됩니다.

다음 문장은 상기 목표를 달성하기 위한 고수준 개발 제안을 설명합니다:

애플리케이션 속성:
1. 애플리케이션에 의해 생성된 각 비밀 토큰(개인 액세스 토큰, 빌드 토큰, 러너 토큰 등)은 Cell을 나타내는 고유 식별자를 포함합니다. 예: us0. 해당 식별자는 Cell에 대한 정보를 난독화할 수 있어야 합니다.
2. 클라이언트로 전송되는 세션 쿠키는 Cell을 나타내는 고유 식별자로 시작해야 합니다. 예: us0.
3. 애플리케이션 구성에는 Cell 비밀 접두사 및 Primary Cell에 대한 정보가 포함됩니다.
4. 사용자는 항상 해당 사용자가 생성된 Cell에 로그인합니다.
데이터베이스 속성:
1. 데이터베이스의 각 기본 키는 클러스터 전체에서 고유해야 합니다. Primay Cell에서 할당되는 데이터베이스 시퀀스를 사용합니다.
2. 각 테이블이 클러스터 전체 또는 Cell 지역적으로 분류되도록합니다.
3. 우리는 최종적 일관성 모델을 따릅니다:
  1. 모든 클러스터 전역 테이블은 Cell 지역 데이터베이스에 저장됩니다.
    1. 모든 클러스터 전역 테이블은 전체 클러스터 모두에 걸친 고유 제약 조건을 유지합니다.
  2. 지역적으로 저장된 클러스터 전역 테이블은 해당 Cell에서만 필요한 정보를 포함합니다(Primay Cell이 아닌 경우).
  3. 클러스터 전역 테이블은 특정 레코드에 대해 권한이 있는 Cell에 의해서만 수정될 수 있습니다:
    1. 사용자 레코드는 해당 레코드의 권한 소유 Cell에 의해서만 수정될 수 있습니다.
    2. Cells 1.0에서는 클러스터 간 데이터를 복제하지 않기 때문에, 권한 소유 Cell은 해당 레코드를 포함하고 있는 Cell입니다.
4. Primay Cell은 고유 제약 조건에 대한 진실의 단일 출처이 됩니다(ID 또는 사용자, 그룹, 프로젝트 고유성에 관한 것).
  1. Secondary Cells는 API를 사용하여 사용자 이름, 그룹 또는 프로젝트를 요청합니다.
  2. Primay Cell은 모든 사용자 이름, 그룹 및 프로젝트, 그리고 레코드가 보관되어 있는 Cell에 대한 정보를 보유합니다.
  3. Primay Cell은 원본 정보(실제 사용자 또는 프로젝트 레코드)를 보유하지 않습니다. 저장된 것은 해당 정보를 저장하고 있는 Cell에 대한 표식뿐입니다.
라우팅 속성:
1. 접두사를 기반으로 하는 비밀 라우팅을 수행하는 정적 라우팅 서비스를 구현합니다.
2. 라우팅 서비스는 Cloudflare Worker로 구현되며 Edge에서 실행됩니다. 라우팅 서비스는 정적 셀 목록을 사용하여 실행됩니다. 각 셀은 프록시 URL과 접두사로 설명됩니다.
3. Cells는 공개 인터넷에 노출되지만 Zero Trust로 보호될 수 있습니다.

아키텍처 개요

API 개요

문제점

다음 기술적 문제들을 해결해야 합니다:

모든 비밀 정보는 간단한 라우팅 레이어에 의해 필요로 하는 것처럼 접두어로 붙여집니다.
모든 사용자 이름, 조직, 최상위 그룹(결과적으로 그룹 및 프로젝트)은 클러스터 전체에서 고유해야 합니다.
모든 기본 키 식별자는 클러스터 전체에서 고유해야 합니다.

GitLab 구성

gitlab.yml의 GitLab 구성은 다음 매개변수로 확장됩니다:

production:
  gitlab:
    primary_cell:
      url: https://cell1.gitlab.com
      token: abcdef
    secrets_prefix: kPptz

primary_cell: 보조 셀에 구성되어 있으며, 주 셀 API에 액세스하는 데 사용되는 URL 엔드포인트를 나타냅니다.
secrets_prefix: 모든 셀에서 사용할 수 있으며, 각 비밀과 세션 쿠키가 이 식별자로 접두사가 붙는다는 것을 나타냅니다.

주 셀

주 셀은 클러스터에서 고유성을 보장하기 위한 특별한 목적으로 사용됩니다. 주 셀은 보조 셀에서 사용할 API 인터페이스를 노출합니다. API는 내부용으로 간주되며, 보조 셀과 공유되는 비밀로 보호됩니다.

POST /api/v4/internal/cells/database/claim
1. 요청:
  - table: 할당된 시퀀스의 테이블 이름, 예: projects
  - count: 고유한 것으로 보장되는 ID 수, 예: 100,000
2. 응답:
  - start: 시작 시퀀스 값
  - limit: 허용된 최대 시퀀스 값
POST /api/v4/internal/cells/routes
1. 요청:
  - path: 리소스의 전체 경로, 예: my-company/my-project
  - source_type: 리소스를 보유하는 컨테이너의 클래스 이름, 예: project
  - source_id: 리소스를 보유하는 컨테이너의 소스 ID, 예: 1000
  - namespace_id: 리소스와 연결된 기본 네임스페이스, 예: 32
  - name: 리소스의 표시 이름
  - cell_id: 리소스를 보유하는 셀의 식별자
2. 응답:
  - 201: Created: 리소스가 생성되었습니다.
    - id:: 주 셀에 저장된 리소스의 ID
  - 409: Conflict: 리소스가 이미 존재합니다.
3. 동작:
  1. 이 엔드포인트는 id를 반환합니다. 동일한 ID가 호출하는 셀의 routes 테이블에 레코드를 삽입하는 데 사용되어야 합니다.
GET /api/v4/internal/cells/routes/:id
1. 요청:
  - id: 리소스 식별자
2. 응답:
  - 200: OK: 리소스가 발견되었습니다. 응답 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하십시오.
  - 404: Not found: 리소스가 존재하지 않습니다.
PUT /api/v4/internal/cells/routes/:id
1. 요청: 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하십시오.
2. 응답:
  - 200: OK: 리소스가 업데이트되었습니다.
  - 403: Forbidden: 다른 cell_id가 소유하기 때문에 리소스를 수정할 수 없습니다.
  - 404: Not found: 리소스가 존재하지 않습니다.
  - 409: Conflict: path에 대한 고유성 제약 조건이 실패했습니다.
3. 동작:
  1. 이 엔드포인트는 주어진 리소스를 수정합니다. cell_id가 일치하는 한 수정할 수 있습니다.
DELETE /api/v4/internal/cells/routes/:id
1. 요청: 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하십시오.
2. 응답:
  - 200: OK: 지정된 매개변수를 가진 리소스가 성공적으로 삭제되었습니다.
  - 404: Not found: 지정된 리소스가 발견되지 않았습니다.
  - 400: Bad request: 리소스가 삭제에 실패했습니다.
POST /api/v4/internal/cells/redirect_routes
GET /api/v4/internal/cells/redirect_routes/:id
PUT /api/v4/internal/cells/redirect_routes/:id
DELETE /api/v4/internal/cells/redirect_routes/:id ```

보조 셀

보조 셀은 현재 특정 API를 노출하지 않습니다. 보조 셀은 주 테이블 키의 고유성을 보장하는 솔루션을 구현합니다.

ReplenishDatabaseSequencesWorker: 이 워커는 주기적으로 모든 시퀀스를 확인하고 재보급합니다.

데이터베이스 시퀀스의 간단한 고유성

데이터베이스 시퀀스의 간단한 고유성은 테이블에 대해 클러스터 전반에 걸쳐 고유한 ID 범위를 요청하고 사용하여 보충하는 관행을 말합니다.

우리의 DDL 스키마는 다음과 같이 ID 생성을 사용합니다: id bigint DEFAULT nextval('product_analytics_events_experimental_id_seq'::regclass) NOT NULL.

/api/v4/internal/cells/database/claim는 다음 로직을 실행하여 원자적으로 ID 범위를 요청합니다.

def claim_table_seq(table, count)
  sql = <<-SQL
    BEGIN;
      -- `ALTER SEQUENCE`는 `some_seq`을(를) 쓰기 및 읽기 위해 잠그게 합니다.
      ALTER SEQUENCE seq_name INCREMENT BY 1000;
      SELECT nextval(seq_name); -- 이 예에서 반환 값은 1001입니다.
      ALTER SEQUENCE seq_name INCREMENT BY 1; -- "INCREMENT BY 1000"를 되돌립니다.

      INSERT INTO cells_sequence_claims (cell_id, table_name, start_id, end_id)
        VALUES (cell_id, table_name, 2, 1001);
    COMMIT;
  SQL

  seq_name = "#{table}_id_seq"
  last_id = select_one(sql, seq_name, limit, seq_name, seq_name).first
  { start: last_id - count, limit: count }
end

사용 가능한 ID 재보급

ReplenishDatabaseSequencesWorker는 시퀀스에 남은 공간이 임계값 아래로 내려가면 새로운 범위를 요청합니다.

def replenish_table_seq(table, lower_limit, count)
  seq_name = "#{table}_id_seq"
  maxval이 존재하지 않으므로 다른 방법으로 구현해야 하지만, 이는 쇼케이스를 위한 것입니다.
  last_id, max_id = select_one("SELECT currval(?), maxval(?)", seq_name, seq_name)
  return if max_id - last_id > lower_limit

  new_start, new_limit = post("/api/v4/internal/cells/database/claim", { table: table, count: count })
  execute("ALTER SEQUENCE RESTART ? MAXVALUE ?", new_start, new_limit)
end

이로써 시퀀스의 ID 재보급으로 인해 ID 공간의 lower_limit을 잃게 됩니다. 그러나 이 모델에서는 레코드 삽입 시에 사전에 시퀀스를 재보급해야 합니다. 그렇지 않으면 심각한 오류가 발생합니다.

위에서 언급한 ID 요청 및 보충 방식은 각 테이블에서 요청한 ID 공간을 너무 많이 낭비할 수 있습니다.

예를 들어, 범위 101에서 200을 요청한 후에 한 테이블은 첫 80개 ID(101에서 180)를 사용한 후에 보충할 수 있으므로 나머지 20개 ID가 낭비될 수 있습니다.

요청한 ID를 효율적으로 활용하기 위해, 우리는 모든 요청한 ID를 효율적으로 활용하기 위해 강력한 고유성 개념을 도입합니다. 테이블이 두 가지 번갈아가며 시퀀스를 유지하고 nextval 및 유사한 기능에 대해 사용하기 위해 사용자 정의 구현을 사용합니다.

테이블 시퀀스의 강력한 고유성

이는 간단한 고유성과 매우 유사하지만, 다음 사항이 추가됩니다:

테이블당 두 시퀀스를 번갈아가며 사용하여 할당된 시퀀스를 완전히 활용합니다.
nextval 함수에 두 개의 인수를 받아들이도록 DEFAULT를 변경합니다: nextval2(table_id_seq_a::regclass, table_id_seq_b::regclass).
시퀀스가 비는 대로 즉시 시퀀스를 보충합니다.
시퀀스 간의 빈 공간을 만들지 않습니다.

CREATE FUNCTION nextval2(seq_a oid, seq_b oid) RETURNS bigint
    LANGUAGE plpgsql
    AS $$
BEGIN
    -- 낮은 번호의 시퀀스에서 선택합니다.
    -- 단조로운 증가하는 숫자를 유지하고 싶기 때문에
    -- 할당이 실패할 때(시퀀스가 고갈되었기 때문에) 다른 시퀀스로 전환합니다.
    SELECT last_value INTO seq_a_last_value FROM seq_a;
    SELECT last_value INTO seq_b_last_value FROM seq_b;
    IF seq_a_last_value < seq_b_last_value
        BEGIN TRY
              RETURN nextval(seq_a);
        END TRY
        BEGIN CATCH
              RETURN nextval(seq_b);
        END CATCH;
    ELSE
        BEGIN TRY
              RETURN nextval(seq_b);
        END TRY
        BEGIN CATCH
              RETURN nextval(seq_a);
        END CATCH;
    END
END
$$;

장점

제안이 간결합니다:
- 각 셀은 클러스터가 작동하는 데 필요한 데이터의 일부만 보유합니다.
- main_clusterwide로 표시된 테이블은 로컬에 저장되며 망-아키텍처를 따라 셀 간에 선택적으로 복제될 수 있습니다.
  - 셀이 공유 데이터의 일부만 필요로 하는 것으로 가정하면, 보조 셀이 전체 클러스터에 걸쳐 소량의 레코드를 필요로 할 것으로 예상됩니다.
주 셀은 제한된 기능 집합에 대해서만 단일 지점 장애입니다:
- 고유성은 주 셀에서 강제됩니다.
- 주 셀의 일시적인 신뢰성은 보조 셀에 제한적인 영향을 미칩니다.
- 보조 셀은 고유 제약 조건을 강제하지 못할 것입니다: 그룹, 프로젝트 또는 사용자 생성.
- 보조 셀의 다른 기능은 현재의 그대로 계속 작동됩니다: 푸시, CI 실행.
라우팅 레이어는 접두어를 사용하여 서비스를 매우 간단하게 만듭니다.
- 서비스의 신뢰성은 현재 동적 분류가 필요하지 않기 때문에 셀의 가용성에 의존하지 않습니다.
- 라우팅 레이어가 나중에 정기적인 분류를 수행하도록 진화할 것으로 예상됩니다.
설계상 혼합 배포 호환됩니다.
- 데이터베이스 연결을 공유하지 않습니다. 클러스터 전체 데이터와 상호 작용하기 위한 API를 노출합니다.
- 응용 프로그램은 버전 간에 API 호환성을 지원해야 하므로, 첫 번째부터 실행되는 응용 프로그램의 여러 버전을 쉽게 지원할 수 있습니다.
데이터베이스 마이그레이션.
- 기본적으로 작동하며, 셀에 격리됩니다.
- 셀 간에 데이터베이스를 공유하지 않기 때문에, main_clusterwide 테이블에 대한 셀의 완전한 소유권이 있습니다.
- 클러스터 전반에 걸친 테이블 간의 모든 교차 조인을 수정하는 것은 많은 작업입니다. 각 셀에 main_clusterwide 테이블을 로컬로 저장함으로써, 처음 반복에 시간을 절약할 수 있습니다.

단점

‘main_clusterwide’로 표시된 테이블의 데이터를 의도적으로 모든 클러스터 셀에 분할합니다.
- 이러한 테이블은 (아마도) 응용 프로그램 외부에서 선택적으로 복제되어 보조 셀이 데이터를 공유할 수 있습니다.
- 실제로 우리는 어느 정도의 데이터베이스 복제를 새롭게 구현하고 있습니다.
‘main_clusterwide’로 만들 수 있는 테이블 수에 Severely 제한됩니다. 많은 테이블을 노출하는 것은 다중 셀 상호 작용을 허용하기 위해 상당한 양의 추가 코드입니다.
- 모든 테이블을 분류해야 합니다. 레코드가 복제되는 경우 클러스터 전체에서 데이터 일관성을 보장하려면 모든 테이블을 분류해야 합니다.

GitLab.com에서 Cells에서 지원되지 않는 기능

Cells 1.0의 초기 배포를 위해 일부 기능의 범위를 축소하고 있습니다. 이는 Cells 1.0이 향후 이러한 기능을 지원하지 않을 것을 의미하는 것은 아닙니다. 그러나 우리의 어플리케이션/인프라는 아직 이를 지원하지 않습니다.

다음 표는 기존의 GitLab.com 기능과 self-managed/Dedicated를 비교한 것입니다.

초기 지원하지 않음	이유
GitLab Pages	복잡성.
CI 카탈로그	CI 카탈로그는 공개 프로젝트에 의존합니다. Cells 1.0의 조직에서 공개 프로젝트를 볼 수 없습니다.
조직 전환	사용자는 단일 조직에 속합니다.
셀 간의 공유 사용자 계정	사용자는 현재 각 셀마다 새로운 사용자 계정이 필요합니다.
GitLab Duo Pro 라이선스가 인스턴스 상의 모든 프로젝트에서 작동	GitLab Duo Pro 라이선스는 부여된 후 인스턴스 상의 모든 프로젝트에서 GitLab Duo Pro를 사용할 수 있어야 합니다(https://gitlab.com/gitlab-org/gitlab/-/issues/441244). Cells 1.0에서는 이 기능이 해당 셀 내에서만 작동합니다.
셀 간의 공유 사용자 계정	사용자는 현재 각 셀마다 새로운 사용자 계정이 필요합니다.
사용자 제거	사용자는 단일 조직에만 속할 수 있습니다. 이 경우 제거는 삭제와 동일하므로 조직 1.0의 조직에서는 사용자 삭제만 제공됩니다. 제거 후 사용자는 다른 비공개 조직을 찾을 방법이 없으므로 가입할 수 없습니다.

질문

보조 셀에서 사용자가 있는 새로운 조직을 어떻게 만들까요?
정의되지 않았습니다.
보조 셀에서 기존 조직에 새로운 사용자를 등록하는 방법은 무엇인가요?
조직이 이미 생성된 경우, 사용자를 초대할 수 있습니다. 그런 다음 보조 셀에서 등록 흐름을 제공할 수 있습니다.
사용자는 어떻게 로그인하나요?
- UI: 조직 로그인은 조직으로 범위가 지정됩니다: https://<GITLAB_DOMAIN>/users/sign_in?organization=gitlab-inc.
- SAML: https://<GITLAB_DOMAIN>/users/auth/saml/callback는 ?organization=gitlab-inc을 받아서 올바른 셀로 라우팅합니다.
- 이를 위해서는 고가용성 솔루션을 사용하여 사용 가능한 조직 목록과 함께 동적 라우팅 방법을 사용해야 합니다.
초기에 보조 셀에 배포된 경우 새로운 테이블을 어떻게 추가하나요?
기본 셀은 일련 번호의 고유성을 보장하므로 시퀀스를 필요로 합니다.
컨테이너 레지스트리는 클러스터 전체인가요, 셀별인가요?
컨테이너 레지스트리는 셀별로 실행될 수 있으며, 비밀 기반 라우팅을 따를 경우 동일한 모델로 따라갈 수 있습니다. 라우팅 레이어에서 정적으로 라우팅될 수 있는 형식으로 GitLab에 의해 서명된 JWT 토큰을 보장해야 합니다.
GitLab Pages는 클러스터 전체인가요, 셀별인가요?
Cells 1.0에는 GitLab Pages가 핵심이 아니라고 판단되어 Cells 1.0을 지원하지 않을 것입니다. 이에 대한 논의는 여기에서 찾을 수 있습니다.
.gitlab.io 도메인을 지원하기를 원하는 경우:
- GitLab Pages는 셀로 실행되며, 별도의 도메인을 제공합니다.
- 사용자 정의 도메인은 별도의 도메인을 사용합니다.
- 단점: 각 셀마다 도메인을 관리해야 합니다.
- 단점: 사용자에게 Cells를 노출시킵니다.
내부 엔드포인트에는 정적 비밀을 사용할까요, JWT를 사용할까요?
정의되지 않았습니다. 제시된 솔루션을 단순하게 사용하기 위해 정적 비밀이 사용됩니다.
SSH 클론을 어떻게 처리하나요?
의도적으로 이 제안에서 해결하지 않은 라우팅과는 별개의 문제입니다. SSH 클론과 연관된 문제점은 다음과 같습니다:
- Cell에서 보유한 사용자 공개 키의 유효성을 검증해야 합니다.
- 클러스터 전체에서 공개 키의 고유성을 보장해야 합니다.
기타 클러스터 전체 고유 제약 조건이 있나요?
- 승인된 키
- GPG 키
- 사용자 지정 이메일
- 페이지 도메인
- 미정
브로드캐스트 메시지나 응용프로그램 설정과 같은 클러스터 전체 테이블을 어떻게 동기화하나요?
매우 가능성이 높은 무작위 접근 방식을 채택할 것입니다: 해당 정보를 API를 통해 노출하고 주기적으로 동기화할 것입니다. 동기화될 수 있는 테이블은 다음과 같습니다.
- 응용 프로그램 설정
- 브로드캐스트 메시지
- 미정
이 작업을 내부적으로 사용하려면 어떻게 하나요?
정의되지 않았습니다.
어떻게 관리자 계정을 관리하나요?
아직 클러스터 전체 동기화를 수행하지 않기 때문에 관리자 계정은 각 셀당 제공되어야 합니다. 아마도 GitLab Dedicated가 이미 해결했을 것입니다?
이것은 주 셀인가요, 클러스터 전체 서비스인가요?
사실상 주 셀은 클러스터 전체 서비스를 제공합니다. 의도에 따라 다음과 같이 이름을 지정할 수 있습니다.
- 주 셀: 현재 주 셀이 특별한 목적을 가졌지만 나중에 이름을 바꾸게 될 것입니다.
- 클러스터 전체 데이터 제공자
- 글로벌 서비스: 주 셀이 현재 글로벌 서비스를 구현할 것이라는 것을 나타내는 대안적인 이름입니다.
비밀은 어떻게 생성되나요?
셀 접두사는 접두사를 인코딩하는 방식으로 비밀을 생성하는 데 사용됩니다. 접두사는 생성된 비밀에 추가됩니다. 예시:
- GitLab 러너 토큰은 다음과 같은 형식으로 생성됩니다: glrt-2CR8_eVxiioB1QmzPZwa
- 셀 접두사: secrets_prefix: kPptz
- 러너 토큰은 다음과 같은 형식으로 생성됩니다: glrt-kPptz_2CR8_eVxiioB1QmzPZwa
왜 경로 기반 라우팅 대신 비밀 기반 라우팅을 사용하나요?
Cells 1.0은 빠르게 다중 테넌트 및 다중 셀 솔루션을 배포할 수 있는 아키텍처의 첫 번째 근사치를 제공하는 것이 목표입니다. 경로 기반 라우팅을 해결하는 데 필요한 노력은 상당합니다.
- 기존 경로의 모든 경로를 /org/<org-name>/-/로 접두어 추가하는 것은 /api/v4/jobs/request와 같이 모호하거나 셀별 또는 클러스터 전체 라우트를 다루는 데 명시적 선택을 필요로 합니다. 라우트를 변경하면 모든 사용자에게 파괴적인 변경 사항을 도입합니다.
- 모든 기존 라우트의 라우팅을 가능하게 하는 것은 /-/autocomplete/users와 같은 라우트에 대한 수정이 사라지기까지 많은 노력이 필요합니다. 초기 분류되는 라우트의 얼마나 많은지에 대한 몇 가지 예비 분석은 이 댓글에서 찾을 수 있습니다.
- 각 경우에 라우팅 서비스는 정의된 기준을 기반으로 기존 경로를 동적으로 분류할 수 있어야 하며, 이를 위해서는 상당한 개발 노력이 필요하며 주 셀 또는 클러스터 전체 서비스에 의존성이 증가합니다.
비밀 기반 라우팅을 따르면 초기 복잡성을 줄일 수 있으므로 나중에 최선의 결정을 내릴 수 있습니다.
- 주입된 접두사는 정적 라우팅 메커니즘을 일시적으로 활용하기 위한 조치입니다.
- 나중에는 동적 분류를 반드시 구현해야 합니다.
- Cells 1.0 이후 경로 기반 라우팅 방법을 접근하는 최상의 방법을 찾을 수 있을 것입니다.
셀 간의 데이터 이관은 어떻게 이루어지나요?
Cells 1.0은 새로운 고객을 대상으로 합니다. 기존 고객을 마이그레이션하는 것은 별도로 큰 사업입니다.
- 마이그레이션될 고객은 먼저 조직 모델에 가입해야 합니다.
- 우리는 대부분의 격리 기능이 작동할 것으로 예상합니다.
- 투명하게 소스 셀에서 대상 셀로 데이터를 이동해야 합니다. 초기에는 셀 분할 모델을 따를 것입니다. 특정 레코드의 위치를 복제하고 표시합니다.
기존 고객은 여전히 Cells 1.0으로 마이그레이션될 수 있지만, GitLab.com에서 Dedicated로 고객을 마이그레이션하는 방식과 유사한 가져오기/내보내기 기능을 사용해야 합니다. 결과적으로 현재 프로젝트 가져오기/내보내기는 CI 트레이스나 작업 아티팩트를 이전하지 않습니다.
비밀 기반 라우팅은 문제입니까?
결정되지 않았습니다.
셀 간의 사용자를 어떻게 동기화하나요?
‘main_clusterwide’ 테이블에 표시된 테이블의 비종속 복제를 구축합니다. 이를 Rails의 일부인 API로 처리할지 또는 Dedicated 서비스를 사용할지 정의되지 않았습니다. 그러나 Rails를 사용하는 것이 애플리케이션이 예상한 데이터 구조를 인식하기 때문에 가장 간단하고 신뢰할 수 있는 솔루션일 것으로 예상됩니다.
위 제안을 따르면 API를 사용하여 users 및 가능한 모든 인접 테이블을 다음과 같이 노출합니다: /api/v4/internal/cells/users/:id. API는 users 테이블을 protobuf 데이터 모델로 직렬화합니다. 이 정보는 사용자 엔트리를 동기화할 다른 셀에서 가져와야 합니다.
셀이 사용자나 프로젝트를 어떻게 찾을까요?
정의되지 않았습니다. 그러나 주 셀/클러스터 전체 데이터 제공자가 모든 이름을 객체(그룹, 프로젝트, 사용자)로 매핑한 routes 테이블에 액세스할 필요가 있습니다.
기업 고객을 위해 만들어진 사용자 프로필은 공개적인가요?
아니요. 특정 조직에서 생성된 경우 해당 조직에만 제한됩니다. 사용자 프로필은 로그인한 동안에만 사용할 수 있습니다.
주 셀이 클러스터 전체 API를 노출하는 경우의 신뢰성이 어떻게 되나요?
API는 다음을 보장할 책임이 있을 것입니다: 사용자, 그룹, 프로젝트, 조직, SSH 키, 페이지 도메인, 이메일의 고유성. API는 라우팅 서비

On this page

셀 1.0

전문

제안

아키텍처 개요

API 개요

문제점

GitLab 구성

주 셀

보조 셀

데이터베이스 시퀀스의 간단한 고유성

사용 가능한 ID 재보급

테이블 시퀀스의 강력한 고유성

장점

단점

GitLab.com에서 Cells에서 지원되지 않는 기능

질문

On this page