| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 진행 중인 작업이며, Cells 디자인의 매우 초기 상태를 나타냅니다. 중요한 측면은 문서화되지 않았지만, 향후 추가할 예정입니다. 이는 Cells의 한 가지 가능한 아키텍처이며, 우리는 구현할 접근 방식을 결정하기 전에 대안과 대조할 예정입니다. 이 문서는 우리가 이 접근 방식을 선택하지 않기로 결정한 이유를 문서화하기 위해 구현하지 않기로 결정할 경우에도 유지될 것입니다.
Cells: Admin Area
Cells 아키텍처 제안에서 GitLab의 모든 관리 관련 테이블을 공유할 계획입니다. 이로 인해 모든 Cells를 단일 인터페이스에서 더 간단하게 관리할 수 있으며, 서로 다른 Cells에서 설정이 다른 위험을 줄일 수 있습니다. 이는 모든 Cells에 퍼진 데이터를 관리할 수 있는 관리 영역 페이지에 도전을 제공합니다.
1. 정의
“전체 인스턴스”를 포괄하는 데이터가 포함된 관리 영역 페이지에는 관리 영역 페이지가 모든 Cell 또는 아마도 단일 Cell에 의해 제공될 수 있기 때문에 결과가 발생합니다. 이미 많은 관리 영역 부분들이 많은 Cells에 걸친 데이터를 가지고 있습니다. 예를 들어, 모든 그룹, 프로젝트, 주제, 작업, 분석, 응용프로그램 목록 등도 있습니다. 또한 “백그라운드 작업” 및 “백그라운드 마이그레이션” 등 많은 Cell에 걸쳐있는 관리 모니터링 기능도 있습니다.
2. 데이터 흐름
3. 제안
이러한 예외 상황을 다루기 위해 몇 가지 가능한 옵션 중에서 어떻게 다룰지 결정해야 합니다:
- 이러한 페이지를 전부 별도의 Cell당 관리자 섹션으로 빼내기. 아마도 URL은
/cells/<cell_id>/admin와 같이 단일 Cell로 라우팅될 필요가 있을 것으로 예상되며, 그러면 우리는 이러한 데이터를 각 Cell마다 표시할 수 있을 것입니다. 이러한 페이지는 모든 Cells에서 공유되는 설정을 제어하는 다른 관리 영역 페이지와 구별될 것입니다. 또한, 이것이 자체 관리 고객들에게 어떻게 영향을 미치는지, 또는 GitLab의 단일 Cell 인스턴스에 대해 이것을 표시해야 하는지 여부도 고려해야 할 것입니다. - 이 데이터를 모든 Cells에서 검색하고 단일 UI에서 표시할 수 있도록 일부 집계 인터페이스를 작성. 이것은 특히 데이터가 어느 Cell에 있는지 모를 때 한눈에 모든 데이터를 볼 필요가 있는 관리자에게 유익할 수 있습니다. 그러나 모든 Cells가 완전히 독립적으로 설계되었을 때 이러한 종류의 집계를 만드는 것은 매우 까다롭기 때문에 이것을 구축하는 것은 또한 Cell 간의 호환성에 더 엄격한 요구사항을 부과합니다.
다음 개요는 현재 관리 영역에 포함된 각 기능이 어느 수준에서 관리될지에 대해 설명합니다:
| 기능 | 클러스터 | Cell | 조직 |
|---|---|---|---|
| 남용 보고서 | |||
| 분석 | |||
| 응용프로그램 | |||
| 배포 키 | |||
| 레이블 | |||
| 메시지 | ✓ | ||
| 모니터링 | ✓ | ||
| 구독 | |||
| 시스템 후크 | |||
| 개요 | |||
| 설정 - 일반 | ✓ | ||
| 설정 - 통합 | ✓ | ||
| 설정 - 저장소 | ✓ | ||
| 설정 - CI/CD (1) | ✓ | ✓ | |
| 설정 - 보고 | ✓ | ||
| 설정 - 메트릭 | ✓ | ||
| 설정 - 서비스 사용 데이터 | ✓ | ||
| 설정 - 네트워크 | ✓ | ||
| 설정 - 외관 | ✓ | ||
| 설정 - 기본 설정 | ✓ |
(1) 특정 설정에 따라 몇 가지는 클러스터 수준에서 관리되고, 일부는 Cell 수준에서 관리됩니다.