| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@hswimelar
|
@grzesiek
|
@trizzi
@sgoldstein
| devops package | 2023-06-09 |
Container registry Self-Managed database rollout
요약
최신 버전의 컨테이너 레지스트리는 PostgreSQL 데이터베이스를 사용하도록 다시 설계되었으며 GitLab.com에 배포되었습니다. 이제 이 데이터베이스가 제공하는 이점을 Self-Managed 사용자에게 제공해야 합니다. 컨테이너 레지스트리는 새로운 데이터베이스 없이 실행할 수 있지만, 이를 사용하지 않으면 많은 새로운 원하는 기능을 구현할 수 없습니다. 또한, GitLab.com 및 Self-Managed에 사용되는 레지스트리를 통합하여 일관된 사용자 경험을 제공하고 이전 레지스트리 구현의 유지 보수 부담을 줄일 수 있습니다. 이를 위해 우리는 결국 모든 Self-Managed가 새 레지스트리 데이터베이스로 마이그레이션되어야 하며, 그 후 이전 오브젝트 스토리지 메타데이터 서브시스템의 지원을 폐기하고 제거할 예정입니다.
이 문서는 이미 수백만 개의 컨테이너 이미지를 GitLab.com에서 마이그레이션하는 데 사용된 검증된 코어 마이그레이션 기능을 어떻게 사용하여 Self-Managed 사용자가 메타데이터 데이터베이스의 이점을 누릴 수 있는지 설명합니다.
목표
- 차트 및 옴니버스 배포용 레지스트리를 위한 PostgreSQL 데이터베이스 인스턴스의 새로운 의존성을 순차적으로 롤아웃합니다.
- 차트 및 옴니버스 배포용 레지스트리 PostgreSQL 데이터베이스 인스턴스의 자동화를 순차적으로 롤아웃합니다.
- Self-Managed 관리자가 기존 레지스트리 배포를 메타데이터 데이터베이스로 마이그레이션하는 데 사용할 수 있는 프로세스 및 도구를 개발합니다.
- Self-Managed 관리자가 메타데이터 데이터베이스를 사용하는 새로운 설치를 시작하는 데 사용할 수 있는 프로세스 및 도구를 개발합니다.
- 기존 오브젝트 스토리지 메타데이터 서브시스템의 지원을 완전히 중단할 수 있는 계획을 수립합니다.
계획
Self-Managed 관리자가 레지스트리 데이터베이스로 이동할 수 있도록 하려면 배포 환경과 레지스트리 마이그레이션 도구의 두 가지 주요 컴포넌트가 더 발전해야 합니다.
배포 환경에 대한 문서는 사용자가 예상되는 레지스트리 워크로드에 적합한 데이터베이스에 액세스할 수 있도록 배포를 설정하는 데 필요한 작업들을 문서화해야 합니다. 또한 뉴 및 기존 배포의 설정 및 유지 관리를 용이하게 하는 도구 및 자동화를 개발해야합니다.
레지스트리에 대해서는 모든 지원하는 저장 드라이버에 대해 관리자가 각 지원되는 저장 드라이버의 추정 가져올 시간을 얻을 수 있도록 하여 위한 테스트 및 자동화를 개발해야합니다.
베타 단계에서 우리는 작업의 주요 기능을 강조하여 빠른 참조를 제공할 수 있으며, 사용자들이 프로젝트의 상태를 한눈에 알 수 있도록 간단한 차트를 통해 이를 광고할 수 있습니다. 이를 통해 사용자는 프로젝트 상태를 파악하고 자신들의 요구 및 위험 허용 수준에 맞게 프로젝트가 기능 완료 상태인지 결정할 수 있습니다.
이 기능들은 레지스트리 관리 문서에 문서화되어야 하며, 여기에 제공된 정보는 Self-Managed 관리자들에게 친숙한 위치에 있게 하여 다른 문서 섹션과의 논리적 상호 연결이 가능하며, 가비지 컬렉션 섹션과 같은 다른 섹션들과의 교차 링크를 허용합니다.
예를 들면:
메타데이터 데이터베이스는 Self-Managed 사용자를 위한 초기 베타 버전입니다. 기존 레지스트리의 코어 마이그레이션 프로세스가 구현되었으며 온라인 가비지 수집은 완전히 구현되었습니다. 특정 데이터베이스 활성화 기능은 GitLab.com에만 활성화되어 있으며, 레지스트리 데이터베이스의 자동 프로비저닝은 사용할 수 없습니다. 컨테이너 레지스트리 데이터베이스와 관련된 기능의 상태에 대한 테이블은 다음과 같습니다.
| 기능 | 설명 | 상태 | 링크 |
|---|---|---|---|
| Import Tool | 기존 배포를 데이터베이스로 마이그레이션합니다. | 완료 | Import Tool |
| 자동 가져오기 유효성 검사 | 가져오기가 유지된 데이터의 무결성을 테스트합니다. | 백로그 | Self-Managed 가져오기 유효성 검사 유효성 검사 |
| Foo Bar | 로렘 입숨 덜로 시트 아멧 | 16.5에 대한 예정 |
드라이버별 지원 구조화
가지고 있는 오브젝트 스토리지 드라이버 구현에 의존하는 가져오기 작업은 데이터베이스에 저장할 수 있도록 레지스트리 메타데이터를 반복하므로, 드라이버의 구현 차이점은 가져오기 프로세스의 성능과 신뢰성에 의미 있는 영향을 미칠 수 있습니다.
각각의 스토리지 드라이버는 다음 방법들을 사용합니다:
- 워크
- 리스트
- 콘텐츠 가져오기
- 통계
- 리더
각각의 메서드는 우리가 오브젝트 스토리지 메서드를 통해 데이터를 생성하거나 삭제할 필요가 없는 읽기 방법입니다. 또한 모든 이러한 메서드는 표준 API 메서드입니다.
오브젝트 스토리지 메서드를 통해 데이터를 변형하지 않고 가져오기 프로세스의 일부로 사용하는 경우에는 이러한 드라이버를 재확인하거나 잠재적인 오류를 예측할 필요가 없습니다. 베타 중 사용자 피드백에 의존하여 우리가 작업해야 하는 내용을 지시하고 불필요한 작업을 예약하는 것을 방지할 수 있습니다.
디자인 및 구현 세부 정보
가져오기 도구
가져오기 도구는 컨테이너 레지스트리 프로젝트의 검증된 컴포넌트로, 테스트를 수행하기 위해 처음부터 사용해온 구성요소입니다. 이 도구는 코어 가져오기 기능에 대한 얇은 래퍼이며, 가져오기 로직을 처리하는 코드는 광범위하게 검증되었습니다.
핵심 가져오기 기능은 탄탄하지만, 이 도구와 주변 프로세스가 비전문가의 사용자가 최소의 위험과 최소의 GitLab 팀 지원에서 자신들의 레지스트리를 가져오게해야 한다는 목표가 달성되도록 이 도구의 UX를 만들어야합니다. 따라서 이 에픽에는 많은 제안된 개선 사항이 포함되어 있습니다.
설계
이 도구는 단일 실행 흐름이 완전한 가용성 요구 사항을 갖춘 대규모 레지스트리를 사용하는 사용자와 읽기 전용 시간을 절대 최소화하기 위해 더 복잡한 프로세스를 활용할 수 있는 사용자를 모두 지원할 수 있도록 설계되었습니다. 이와 함께 작은 레지스트리를 갖는 사용자들은 간소화된 작업 흐름에서 이점을 얻을 수 있습니다. GitLab.com에서 사용된 사전 가져오기 후 완전한 가져오기 주기와 함께 공통 리포지터리에 보관된 참조되지 않은 블랍을 카탈로그화하는 추가 단계를 통해 이를 실현하였습니다.
일회성 가져오기
대부분의 경우, 사용자는 레지스트리가 오프라인이거나 읽기 전용 모드일 때 가져오기 도구를 실행할 수 있습니다. 관리자가 이미 오프라인 가비지 수집을 실행하기 위해 수행해야 하는 것과 유사합니다. 각 단계는 순차적으로 완료되어 다음으로 직접 이동합니다. 명령이 완료되면 가져오기 프로세스가 완료되고 레지스트리가 메타데이터 데이터베이스를 완전히 활용할 준비가 됩니다.
최소 다운타임 가져오기
대규모 레지스트리를 갖는 사용자들과 가능한 한 최소의 다운타임이 필요한 사용자들을 위해, 도구에 적절한 플래그가 전달될 때 각 단계를 독립적으로 실행할 수 있습니다. 사용자는 먼저 레지스트리가 평소의 작업을 수행하는 동안 사전 가져오기 단계를 실행합니다. 그것이 완료되고 사용자가 레지스트리에 쓰기를 중지할 준비가 되면 태그 가져오기 단계를 실행할 수 있습니다. GitLab.com 마이그레이션과 마찬가지로 태그 가져오기에는 레지스트리가 오프라인이거나 읽기 전용 모드여야 합니다. 이 단계는 빠르고 효율적인 태그 가져오기를 달성하기 위해 가능한 최소한의 작업을 수행하며, 세 단계 중에서 항상 가장 빠르며 다운타임 컴포넌트를 총 가져오기 시간의 일부로 줄일 수 있습니다. 그런 다음 사용자는 메타데이터 데이터베이스를 사용하도록 구성된 레지스트리를 가동시킬 수 있습니다. 이후 사용자는 세 번째 단계를 주요 레지스트리 작업 중에 실행할 수 있습니다. 이 단계는 공통 리포지터리에 있는 모든 둥글어진 블랍을 데이터베이스에 표시하고 따라서 온라인 가비지 수집 프로세스를 수행할 수 있도록 만듭니다.
배포 경로
새로운 배포를 위해 메타데이터 데이터베이스를 사용하려는 사용자들을 지원하기 위해 도구, 프로세스 및 문서 작업이 개발되어야 합니다. 특히 마이그레이션에 필요한 새 데이터베이스 인스턴스의 기초를 제공하기 위해 작업이 필요합니다.
새로운 배포를 위해서는 일반 지원으로 이동하고 레지스트리 데이터베이스 및 마이그레이션 자동화가 마련되어 있으며 Self-Managed형 시스템에 기본적으로 데이터베이스를 활성화하기 전까지 기다려야 합니다.
Omnibus
Charts
대안적 해결책
아무것도 하지 않기
장점
- 데이터베이스 및 관련 기능은 일반적으로 대규모이고 고가용성 배포에 가장 유용합니다.
- Self-Managed형 배포를 위해 추가 논리적 또는 물리적 데이터베이스를 지원할 필요가 없어집니다.
단점
- GitLab.com의 레지스트리와 Self-Managed형에서 지원하는 기능이 시간이 지남에 따라 크게 다를 것입니다.
- 두 개의 레지스트리 구현을 지원하는 유지 보수 부담은 새로운 레지스트리 기능을 릴리스하는 속도를 줄일 것입니다.
- GitLab.com의 레지스트리는 Self-Managed형으로 릴리스되기 전에 변경 사항을 확인하는 효과적인 방법이 아닙니다.
- 대규모 Self-Managed형 사용자는 레지스트리를 자신들의 요구에 맞게 확장할 수 없을 것입니다.
점진적 마이그레이션
이 접근 방식은 Self-Managed형에서 GitLab.com 마이그레이션을 정확하게 복제하는 것입니다.
장점
- 이미 성공적인 프로세스를 복제합니다.
- 인스턴스 대신 리포지터리별로 다운타임의 범위를 규정합니다.
단점
- 마이그레이션 프로세스의 모든 측면에서 현저한 복잡성이 증가합니다.
- 데이터 일관성 문제의 가능성이 크게 증가합니다.
- 레지스트리 마이그레이션 진행상황이 덜 명확해집니다.