• 1. Definition
• 2. Data flow
• 3. Proposal
• 4. Evaluation
• 4.1. Pros
• 4.2. Cons

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

Cells: Admin Area

Cells 아키텍처 제안에서 우리는 GitLab의 모든 관리 관련 테이블을 공유할 계획입니다. 이를 통해 하나의 인터페이스에서 모든 Cells를 더 간단하게 관리할 수 있으며, 다른 Cells에서 설정이 다르게 발전하는 위험을 줄일 수 있습니다. 이로 인해 모든 Cells에 분산되는 데이터를 관리할 수 있는 관리자 영역 페이지가 도입됩니다.

1. Definition

“전체 인스턴스”를 관통하는 데이터를 포함하는 관리자 영역 페이지에는 결과가 있습니다. 관리자 영역 페이지는 임의의 Cell에 의해 제공될 수도 있고 아마도 하나의 Cell에 의해 제공될 수도 있습니다. 이미 많은 관리자 영역에서 많은 Cells에 걸친 데이터가 있습니다. 예를 들어 모든 그룹, 프로젝트, 주제, 작업, 분석, 응용 프로그램 디렉터리 등이 있습니다. 또한 “백그라운드 작업” 및 “백그라운드 마이그레이션” 페이지와 같이 많은 Cell에 걸친 관리 모니터링 기능이 있습니다.

2. Data flow

3. Proposal

우리는 이러한 예외를 처리하는 방법을 몇 가지 가능한 옵션을 통해 결정해야 할 것입니다:

1. 모든 이러한 페이지들을 전용 개별 Cell 관리 섹션으로 이동합니다. 아마도 URL은 /cells/<cell_id>/admin과 같이 단일 Cell로 라우트될 필요가 있을 것입니다. 그러면 우리는 이러한 데이터를 Cell 당 표시할 수 있습니다. 이러한 페이지들은 모든 Cells에서 공유되는 설정을 제어하는 다른 관리자 영역 페이지와 구별될 것입니다. 우리는 이것이 Self-managed 고객들 및 GitLab의 단일 Cell 인스턴스에게 표시되어야 하는지 여부와 어떻게 이것이 영향을 미치는지에 대해 고려할 필요가 있을 것입니다.
2. 이 데이터를 모든 Cells에서 가져와 단일 UI에 제시될 수 있도록 데이터의 집계 인터페이스를 구축합니다. 이것은 데이터를 한눈에 보고 필터링해야 하는 관리자에게 유익할 수 있습니다. 특히 데이터가 어느 Cell에 있는지 모를 때 특히 그렇습니다. 그러나 모든 Cells가 완전히 독립적으로 설계되었을 때 이러한 종류의 집계를 구축하는 것은 매우 까다로우며, 이는 또한 Cells 간의 호환성에 대한 엄격한 요구사항을 부과합니다.

다음 개요는 현재 Admin 영역에 포함된 각 기능을 어느 수준에서 관리할 것인지를 설명합니다:

(1) 특정 설정에 따라 일부는 클러스터 수준에서 관리되며, 일부는 Cell 수준에서 관리됩니다.

4. Evaluation

4.1. Pros

4.2. Cons