• 서문
• 제안
  • 아키텍처 개요
  • API 개요
  • 문제들
  • GitLab 구성
  • 주 셀
  • Secondary Cell
    • 단순한 데이터베이스 시퀀스의 고유성
    • 사용 가능한 ID 보충
    • 테이블 시퀀스의 견고한 고유성
• 장점
• 단점
• GitLab.com에서 셀에서 지원되지 않는 기능
• 질문

Cells 1.0

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

Cells 1.0은 세포 구조의 첫 번째 반복입니다. Cells 1.0의 목표는 내부 고객에게 솔루션을 제공하고, 다음 반복을 위한 기초 단계로서, 더 작은 범위의 제품을 제공할 수 있도록 하는 것입니다.

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

Cells 1.5에 대해 더 읽어보세요. 이는 기존 고객을 이전하고, Cells 1.0 아키텍처 위에 구축된 것을 의도한 것입니다.

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

서문

Cells 1.0은 다음과 같은 기대 사항을 가진 내부 고객을 대상으로 합니다:

1. 멀티테넌시 SaaS 솔루션(GitLab.com)을 사용하여 그들의 조직을 제공하려고 합니다.
2. GitLab.com의 나머지보다 업데이트를 나중에 받을 수 있다는 점을 받아 들입니다. GitLab이 패치 릴리스를 한다면, Delivery 팀은 릴리스를 공개하기 전에 모든 셀이 패치 릴리스 버전을 실행하도록 보장합니다. 이것은 모든 셀이 패치 릴리스 이외의 시간에는 GitLab의 동일한 버전을 실행하지는 않다는 것을 의미합니다. 자세한 내용은 이 비공개 토론을 참조하세요.
3. 나머지 시스템과의 고도로 격리된 환경을 사용하고 싶어합니다.
4. 조직에 기여하는 모든 사용자를 제어하려고 합니다.
5. 그들의 그룹과 프로젝트는 비공개여야 합니다.
6. 그들의 사용자는 다른 조직과 상호 작용하거나 계정으로 공개 프로젝트에 기여할 필요가 없습니다.
7. 자신의 계정으로 조직을 전환할 수 없는 것을 수용합니다.

개발 및 인프라 관점에서 우리는 다음과 같은 목표를 달성하고 싶습니다:

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

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

1. 사용자는 많은 조직과 상호 작용할 수 있어야 합니다.
2. Cells는 조직을 이동하여 리밸런싱할 수 있어야 합니다.
3. 라우팅 솔루션은 동적으로 요청을 라우팅할 수 있어야 합니다.

제안

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

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

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

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

아키텍처 개요

API 개요

문제들

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

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

GitLab 구성

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

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

1. primary_cell:는 Secondary Cells에서 구성되며, 기본 셀 API에 액세스하기 위한 URL 엔드포인트를 나타냅니다.
2. secrets_prefix:는 모든 Cells에서 사용할 수 있으며, 각 비밀과 세션 쿠키가 이 식별자로 접두어가 붙어야 함을 나타냅니다.

주 셀

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

1. POST /api/v4/internal/cells/database/claim

   1. 요청:
      • table: 예를 들어 projects와 같은 할당된 시퀀스를 위한 테이블 이름
      • count: 고유하게 보장된 ID의 개수, 예를 들어 100,000
   2. 응답:
      • start: 시작 시퀀스 값
      • limit: 허용된 최대 시퀀스 값

2. POST /api/v4/internal/cells/routes

   1. 요청:
      • path: 리소스의 전체 경로, 예를 들어 my-company/my-project
      • source_type: 리소스를 보유한 컨테이너의 클래스 이름, 예를 들어 project
      • source_id: 리소스를 보유한 컨테이너의 소스 ID, 예를 들어 1000
      • namespace_id: 리소스와 관련된 기본 네임스페이스
      • name: 리소스의 표시 이름
      • cell_id: 리소스를 보유한 셀의 식별자
   2. 응답:
      • 201: Created: 리소스가 생성됨
        • id:: 주 셀에 저장된 리소스의 ID
      • 409: Conflict: 리소스가 이미 존재함
   3. 동작:
      1. 엔드포인트는 id를 반환합니다. 동일한 ID를 호출하는 셀의 routes 테이블에 삽입하는 데 사용해야 합니다.

3. GET /api/v4/internal/cells/routes/:id

   1. 요청:
      • id: 리소스 식별자
   2. 응답:
      • 200: OK: 리소스가 발견됨. 응답 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하십시오.
      • 404: Not found: 리소스가 존재하지 않음

4. 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가 일치해야 합니다.

5. DELETE /api/v4/internal/cells/routes/:id

   1. 요청: 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하십시오.
   2. 응답:
      • 200: OK: 지정된 매개변수를 가진 리소스가 성공적으로 삭제됨
      • 404: Not found: 지정된 리소스가 발견되지 않음
      • 400: Bad request: 리소스 삭제에 실패함
6. POST /api/v4/internal/cells/redirect_routes
7. GET /api/v4/internal/cells/redirect_routes/:id
8. PUT /api/v4/internal/cells/redirect_routes/:id
9. DELETE /api/v4/internal/cells/redirect_routes/:id

Secondary Cell

현재 Secondary Cell은 특정 API를 노출하지 않습니다. Secondary Cell은 주 데이터베이스 키의 고유성을 보장하기 위한 솔루션을 구현합니다.

1. 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의 lower_limit을 잃어 버릴 수 있습니다. 그러나 이 모델에서는 시퀀스를 미리 보충해야 하며, 그렇지 않으면 새 레코드 삽입 시에 재앙적인 실패가 발생할 수 있습니다. 위에서 설명한 고효율 ID 사용과 관련하여, 모든 요청된 ID 공간을 너무 많이 낭비할 수 있습니다. 예를 들어, 101에서 200까지의 범위를 요청한 후, 테이블은 처음 80개 ID(101에서 180까지)를 사용한 후 나머지 20개 ID를 낭비하게 됩니다.

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

테이블 시퀀스의 견고한 고유성

이는 간단한 고유성과 매우 유사하지만 다음과 같은 추가 기능이 있습니다:

• 테이블당 두 시퀀스(A/B)를 교대로 사용하여 할당된 시퀀스를 완전히 활용합니다.
• DEFAULT를 변경하여 nextval2(table_id_seq_a::regclass, table_id_seq_b::regclass) 함수가 두 개의 인수를 받게 합니다.
• 빈 ID가 모두 소진되면 시퀀스를 보충합니다.
• 시퀀스 간격을 만들지 않습니다.

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로 만들 수 있는 한계가 심각합니다. 많은 테이블을 노출하는 것은 사이트 간 상호 작용을 허용하기 위해 추가 코드 양이 상당히 많이 필요합니다.
  • 모든 테이블을 분류해야 합니다. 레코드가 복제되면 클러스터 전체에 데이터 일관성이 확보될 수 있도록 해야 합니다.

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

셀 1.0 초기 배포에서 일부 기능의 범주를 줄이는 대신 무언가를 배포하고자 합니다. 이것은 셀 1.0이 향후 이러한 기능을 지원하지 않을 것을 의미하는 것은 아니지만, 현재 당사의 응용/인프라는 아직 이를 지원하지 않습니다.

아래 표는 기존의 GitLab.com 기능과 Self-Managed형/전용 기능을 비교한 것입니다.

질문

1. 보조 셀에서 사용자와 함께 새로운 조직을 만드는 방법은 무엇인가요?

   정의되어 있지 않습니다.

2. 보조 셀에 기존 조직의 새로운 사용자를 등록하는 방법은 무엇인가요?

   조직이 이미 생성된 경우, 사용자를 초대할 수 있습니다. 그런 후, 보조 셀에서 등록 흐름을 제공할 수 있습니다.

3. 사용자는 어떻게 로그인하나요?

   • UI: 조직에서 로그인은 해당 조직으로 범위가 지정될 것입니다: https://<GITLAB_DOMAIN>/users/sign_in?organization=gitlab-inc.
   • SAML: https://<GITLAB_DOMAIN>/users/auth/saml/callback은 ?organization=gitlab-inc을 받아 정확한 셀로 라우팅될 것입니다.
   • 이것은 높은 가용성을 갖는 솔루션을 사용하여 사용 가능한 조직 디렉터리으로 동적 라우팅 방법을 사용하는 것이 필요할 수 있습니다.

4. 초기에 보조 셀에 테이블을 추가하는 방법은 무엇인가요?

   기본 셀은 시퀀스의 고유성을 보장하므로 시퀀스가 있어야 합니다.

5. 컨테이너 레지스트리는 클러스터 전체적으로 지원되는가요, 아니면 셀 내부 지역적으로 지원되는가요?

   컨테이너 레지스트리는 셀 내부에서 실행될 수 있으며, 시크릿을 기반으로 한 라우팅을 따르면 동일한 모델로 필터링될 수 있습니다. 라우팅 레이어로부터 정적으로 라우팅될 수 있는 형태로 GitLab에 의해 서명된 JWT 토큰이 보장되어야 할 것입니다.

6. GitLab 페이지는 클러스터 전체적으로 지원되는가요, 아니면 셀 내부 지역적으로 지원되는가요?

   GitLab 페이지는 Cells 1.0에서 중요하지 않다는 결정에 따라 Cells 1.0에서는 지원되지 않을 것입니다. 여기에서 토론을 찾을 수 있습니다.

   .gitlab.io 도메인을 지원하기 위해 GitLab Pages가 의도된 경우:

   • GitLab Pages는 셀을 실행하되 별도의 도메인을 제공합니다.
   • 사용자 지정 도메인은 별도의 도메인을 사용합니다.
   • 단점: 각 셀당 도메인을 관리해야하는 문제가 발생합니다.
   • 단점: 사용자에게 셀을 노출시키는 문제가 발생합니다.

7. 내부 엔드포인트에 정적 비밀번호를 사용해야 할까요, 아니면 JWT를 사용해야 할까요?

   정의되어 있지 않습니다. 제시된 솔루션의 단순성을 위해 정적 비밀번호를 사용합니다.

8. SSH 클론을 어떻게 처리해야 하나요?

   의도적으로 이 제안이 해결하려는 라우팅과는 별도의 문제입니다. SSH 클론과 관련된 문제는 다음과 같습니다:

   • 사용자의 공개 키를 구분하기 위해 사용자의 공개 키를 확인해야 합니다.
   • 클러스터 전체에서 고유한 공개 키를 보장해야 합니다.

9. 다른 클러스터 전체 고유 제약 조건이 있나요?

   • 인증된 키
   • GPG 키
   • 사용자 지정 이메일
   • 페이지 도메인
   • 미정

10. 방송 메시지나 애플리케이션 설정과 같은 클러스터 전체 테이블을 동기화하는 방법은 무엇인가요?

    우리는 아마도 API를 사용하여 이러한 정보를 라우트하고 주기적으로 동기화할 것입니다. 동기화될 가능성이 있는 테이블은 다음과 같습니다:

    • 응용 프로그램 설정
    • 방송 메시지
    • 미정

11. 이 제안을 실무에서 사용하는 방법은 무엇인가요?

    정의되어 있지 않습니다.

12. 관리자 계정을 어떻게 관리하나요?

    아직 클러스터 전체 동기화를 하지 않았기 때문에, 관리자 계정은 각 셀 당 제공해야 합니다. 이미 기존 제공된 것 같은 것으로 보입니다.

13. 이 제안은 주요 사항인가요, 클러스터 전체 서비스인가요?

    실제로는 주요 셀이 클러스터 전체 서비스로 작동합니다. 의도에 따라 다음과 같이 명명할 수 있습니다:

    • 기본 셀: 현재 주요 셀이 특별한 목적을 가졌지만, 나중에 이름을 바꿀 것입니다.
    • 클러스터 전체 데이터 제공자
    • 탑도로지 서비스: 클러스터 전체 데이터 제공자에 대한 대안 이름으로, 현재 기본 셀이 오늘도 특별한 목적을 가지고 있는 것으로 표시합니다.

14. 비밀번호는 어떻게 생성되나요?

    접두사를 사용하여 비밀번호를 생성합니다. 그러나 접두사는 생성된 비밀번호에 추가됩니다. 예시:

    • GitLab Runner Tokens은 다음과 같이 생성됩니다: glrt-2CR8_eVxiioB1QmzPZwa
    • 셀 접두사: secrets_prefix: kPptz
    • GitLab 도키먼트는 다음과 같이 생성됩니다: glrt-kPptz_2CR8_eVxiioB1QmzPZwa

15. 왜 경로 기반 라우팅 대신에 시크릿 기반 라우팅을 사용해야 하나요?

    Cells 1.0은 빠르게 다중 테넌트 및 다중 셀 솔루션을 배포할 수 있도록 하는 아키텍처의 첫 번째 근사치로 제공되기 때문에 경로 기반 라우팅을 해결해야 할 필요성이 큽니다. 경로 기반 라우팅을 해결하는 것은 상당한 노력이 필요합니다:

    • 기존 경로를 /org/<org-name>/-/로 접두사와 함께 바꾸면 시큰한 기존 사용자의 작업 방식을 변경하는 선택을 해야 합니다. 예를 들어, /api/v4/jobs/request와 같이 모