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 @hswimelar @grzesiek @trizzi @sgoldstein devops package 2023-06-09

컨테이너 레지스트리 Self-Managed 데이터베이스 롤아웃

요약

컨테이너 레지스트리의 최신 버전은 PostgreSQL 데이터베이스를 사용하도록 다시 설계되었으며 GitLab.com에 배포되었습니다. 이제는 데이터베이스에서 제공하는 이점을 Self-Managed 사용자에게 제공해야 합니다. 컨테이너 레지스트리는 새로운 데이터베이스 없이 실행할 수 있지만, 많은 새로운 기능들이 이것 없이는 구현할 수 없습니다. 또한, GitLab.com 및 Self-Managed에서 사용하는 레지스트리를 통일하면 사용자 경험을 일원화할 수 있으며 이전 레지스트리 구현의 유지 관리 부담을 줄일 수 있습니다. 이를 위해 우리는 결국 Self-Managed 전체가 새 레지스트리 데이터베이스로 이전되어야 하며 이로써 이전 객체 저장 메타데이터 서브시스템의 지원을 폐지하고 제거할 수 있게 됩니다.

본 문서는 우리가 GitLab.com에서 수백만 개의 컨테이너 이미지를 이전하기 위해 사용된 입증된 코어 이전 기능을 Self-Managed 사용자가 메타데이터 데이터베이스의 이점을 누리는 데 어떻게 활용할 수 있는지 설명하려고 합니다.

동기

Self-Managed 사용자가 새 메타데이터 데이터베이스로 이전할 수 있도록 함으로써 이러한 사용자는 데이터베이스가 필요한 새로운 기능을 활용할 수 있습니다. 게다가 데이터베이스의 채택이 더 많아질수록 컨테이너 레지스트리 팀은 우리의 지식과 용량에 중점을 두고 더 많은 리소스를 할애할 수 있으며 이로써 이전의 레지스트리 메타데이터 서브시스템을 완전히 제거할 수 있는 가능성이 열립니다. 이로써 GitLab.com 및 Self-Managed 사용자를 위한 컨테이너 레지스트리의 유지 관리성과 안정성이 크게 향상됩니다.

목표

  • 차트 및 옴니버스 배포를 위한 레지스트리에 대한 PostgreSQL 데이터베이스 인스턴스의 새로운 종속성을 점진적으로 롤아웃합니다.
  • 차트 및 옴니버스 배포를 위한 레지스트리 PostgreSQL 데이터베이스 인스턴스에 대한 자동화를 점진적으로 롤아웃합니다.
  • Self-Managed 관리자가 기존 레지스트리 배포를 메타데이터 데이터베이스로 이전할 수 있는 프로세스 및 도구를 개발합니다.
  • Self-Managed 관리자가 메타데이터 데이터베이스를 사용하는 컨테이너 레지스트리의 새로운 설치를 구성하고 유지할 수 있는 프로세스 및 도구를 개발합니다.
  • 원본 객체 저장 메타데이터 서브시스템의 지원을 완전히 폐지할 수 있도록하는 계획을 수립합니다.

비목표

  • 관리자가 메타데이터 데이터베이스로 이전하게 하는 것을 벗어난 새로운 컨테이너 레지스트리 기능을 개발합니다.
  • 데이터베이스가 기본이 되는 시기 및 데이터베이스를 지원하지 않는 레지스트리의 지원을 중지해야 하는 시기와 같은 라이프사이클 지원 결정을 내립니다.

제안

Self-Managed 관리자가 레지스트리 데이터베이스로 이동하려면 두 가지 주요 구성 요소를 더 발전시켜야 합니다. 배포 환경과 레지스트리 이전 도구입니다.

배포 환경에 대해서는 사용자가 레지스트리가 예상되는 워크로드에 적합한 데이터베이스에 액세스하도록 배포를 설정하는 데 필요한 작업을 문서화해야 합니다. 또한 새로운 및 기존 배포의 레지스트리 데이터베이스의 설치 및 유지관리를 용이하게 하는 도구 및 자동화를 개발해야 합니다.

레지스트리에 대해서는 우리가 GitLab.com에서 모든 컨테이너 이미지를 이전하는 데 사용된 코어 이전 기능과 조화를 이루는 동시에 새로운 및 기존 배포의 레지스트리 데이터베이스에 대한 예상되는 이전 시간을 제공해야 합니다.

Beta 단계에서는 우리의 업무의 주요 기능을 강조하여 빠르게 참조할 수 있는 요약을 제공할 수 있습니다. 현재 보유하고 있는 기능, 계획중인 기능, 그들의 상태 및 이전 경험의 전반적인 상태에 대한 간단한 차트를 통해 Self-Managed 사용자에게 공지할 수 있습니다. 이를 통해 사용자는 한눈에 이 프로젝트의 상태를 확인하고 자신의 요구와 리스크 허용 수준에 충분히 완성되었는지 판단할 수 있습니다.

이것은 컨테이너 레지스트리 운영 설명서에 문서화되어야 하며, 이 블루프린트가 아닌 곳에 문서화되어야 합니다. 이 정보를 제공함으로써 Self-Managed 관리자들에게 익숙한 위치에 배치하고 동일한 문서의 다른 섹션들과의 논리적 상호 연결이 가능하게 합니다.

예를 들어:

메타데이터 데이터베이스는 Self-Managed 사용자를 위해 초기 베타 버전입니다. 기존 레지스트리의 코어 이전 프로세스가 구현되었으며 온라인 가비지 수집도 완전히 구현되었습니다. 특정 데이터베이스 활성 기능은 GitLab.com에서만 활성화되어 있으며 레지스트리 데이터베이스에 대한 자동 프로비저닝은 사용 가능하지 않습니다. 컨테이너 레지스트리 데이터베이스 관련 기능의 상태에 대한 표를 보기 위해서는 아래 링크를 참조하세요.

기능 설명 상태 링크
이전 도구 기존 배포를 데이터베이스로 이전할 수 있게 합니다. 완료됨 이전 도구
자동 이전 검증 Import가 가져온 데이터의 무결성을 테스트합니다. 백로그 Self-Managed Import 유효성 검증
Foo Bar Lorem ipsum dolor sit amet. 16.5에 예정됨 <링크>링크>

드라이버별 지원 구조화

이전 작업은 데이터베이스에 저장되도록 레지스트리 메타데이터를 반복하는 객체 저장 드라이버 구현에 크게 의존합니다. 드라이버의 구현 차이가 이전 프로세스의 성능과 신뢰성에 공헌할 수 있습니다.

이것은 구조화 지원에 대한 몇 가지 지점에 대한 간략한 요약입니다.

운전자별 지원의 구조화에 반대하는 주장

각 저장 드라이버는 코드에서 잘 추상화되어 있으며, 특히 가져오기 프로세스는 다음 메서드를 사용합니다:

  • Walk
  • List
  • GetContent
  • Stat
  • Reader

각 메서드는 읽기 메서드이므로 객체 저장 메서드를 통해 데이터를 만들거나 삭제할 필요가 없습니다. 게다가, 이러한 메서드는 모두 표준 API 메서드입니다.

가져오기 프로세스의 일환으로 객체 저장을 통해 데이터를 변형하지 않기 때문에, 이러한 드라이버들을 재확인하거나 잠재적인 오류를 예측할 필요가 없어야 합니다. 여기에 우리가 해야 할 노력을 지향하기 위해 사용자 피드백에 의존하는 것은 불필요한 작업을 예약하는 것을 방지할 수 있습니다.

운전자별 지원을 장려하는 주장

오프라인 가비지 수집 기능을 향상시키고 지원하는 데 우리의 경험은 저장 드라이버 구현이 중요하지 않아야 하지만 중요하다는 것을 보여 주었습니다. 드라이버는 성능과 신뢰성에 중요한 차이점이 있음이 입증되었습니다. 계획된 가능한 드라이버 관련 개선 사항 중 많은 부분은 각 드라이버에 대한 새로운 작업보다는 테스트와 안정성과 관련이 있습니다.

특히, 저장 드라이버 간의 재시도와 오류 보고는 표준화된 것처럼 희망할만큼 표준화되어 있지 않기 때문에, 장기 실행 가져오기 프로세스가 재시도할 수 있는 오류에 의해 중단될 수 있는 가능성이 있습니다.

등록기 크기와 저장 드라이버의 조합을 기반으로 가져오기 추정을 만드는 것은 Self-Managed 관리자가 이관을 예약하는 데 유용할 것입니다. 로컬 파일 시스템 저장 및 객체 저장 간에 차이가 있을 것이며, 객체 저장 공급 업체 사이에도 차이가 있을 수 있습니다.

또한, 가져오기자와 협력하여 저장 드라이버의 차이를 조절할 수 있습니다. 저장 드라이버로부터 통합된 재시도 가능한 오류 보고가 없더라도, 가져오기자가 더 많은 시간에 대해 더 많은 오류에 대해 재시도할 수 있습니다. 재시도할 수 없는 오류에 대해 여러 번 재시도할 수 있지만, 객체 저장에 쓰기가 이루어지지 않으므로 이는 궁극적으로 해를 끼치지 않아야 할 것입니다.

게다가, 자가 관리 가져오기 유효성 검증을 구현함으로써 가져오기 전과 후에 이미지의 샘플을 대상으로 일관성 검사를 수행할 수 있으며, 이는 저장 드라이버 구현 전반에 걸쳐 보다 큰 일관성으로 이어질 것입니다.

설계 및 구현 세부 정보

가져오기 도구

가져오기 도구는 컨테이너 레지스트리 프로젝트의 잘 검증된 구성 요소로, 우리는 처음부터 로컬 테스트를 수행하는 방법으로 사용해 왔습니다. 이 도구는 핵심 가져오기 기능을 다루는 코드의 얇은 래퍼입니다 — 이 동작은 철저히 검증되었습니다.

핵심 가져오기 기능이 탄탄하더라도, 이 도구와 주변 프로세스가 비전문가 사용자가 레지스트리를 가져오는 데 최소한의 위험과 GitLab 팀 구성원의 최소한의 지원으로 가능하도록 보장해야 합니다. 따라서 지금 가장 중요한 작업은 이러한 목표를 달성하기 위해 이 도구의 UX를 구축하는 것입니다. 이 에픽은 제안된 개선 사항을 많이 담고 있습니다.

디자인

이 도구는 엄격한 업타임 요구 사항이 있는 대형 레지스트리를 갖고 있는 사용자들과 더 간편한 작업 흐름을 필요로 하는 작은 레지스트리를 갖고 있는 사용자를 모두 지원할 수 있는 단일 실행 흐름으로 설계되었습니다. 이는 GitLab.com에서 사용된 것과 동일한 가져오기 전처리, 전체 가져오기 주기를 통해 이루어집니다. 또한 공통 저장소에 보유된 참조되지 않은 블롭을 카탈로그화하는 추가적인 단계가 추가되었습니다.

원샷 가져오기

대부분의 경우, 사용자는 레지스트리가 오프라인이거나 읽기 전용 모드일 때 가져오기 도구를 실행할 수 있습니다. 각 단계는 순차적으로 완료되며, 다음으로 직접 이동합니다. 명령이 완료되면 가져오기 프로세스가 완료되고 레지스트리는 메타데이터 데이터베이스를 완전히 활용할 준비가 됩니다.

최소 다운타임 가져오기

대형 레지스트리를 갖고 있으며 최소한의 다운타임이 필요한 사용자를 위해, 각 단계는 적절한 플래그를 전달할 때 개별적으로 실행될 수 있습니다. 사용자는 우선 레지스트리가 평소의 작업을 수행하는 동안 사전 가져오기 단계를 실행합니다. 그 후 완료되고 사용자가 레지스트리에 쓰기를 중지할 준비가 되면 태그 가져오기 단계를 실행할 수 있습니다. GitLab.com 마이그레이션이 이루어진 것과 마찬가지로, 태그 가져오기를 위해서는 레지스트리가 오프라인이거나 읽기 전용 모드여야 합니다. 이 단계는 최소한의 작업으로 빠르고 효율적인 태그 가져오기를 수행하며, 세 가지 단계 중에서 항상 가장 빨리 완료되어 전체 가져오기 시간에서 다운타임 구성 요소를 분수로 줄이게 됩니다. 그 후 사용자는 메타데이터 데이터베이스를 사용하도록 구성된 레지스트리를 실행할 수 있습니다. 그 후, 사용자는 세 번째 단계를 실행할 수 있으며, 이 단계는 공통 저장소에 있는 어떤 블롭이든 데이터베이스에 표시되도록 만들며, 따라서 온라인 가비지 수집 프로세스를 수행하게 됩니다.

배포 경로

메타데이터 데이터베이스를 사용하고자 하는 사용자를 지원하기 위해 도구, 프로세스 및 문서 작업이 필요합니다. 특히 마이그레이션을 위해 필요한 새 데이터베이스 인스턴스를 제공하는 데 기반을 제공해야 합니다.

새로운 배포에 대해서는 우리는 일반 지원으로 이동하고, 레지스트리 데이터베이스와 마이그레이션에 대한 자동화가 마련되어 있고, Self-Managed를 위해 새로운 데이터베이스 인스턴스를 기본적으로 활성화하기 전까지 대규모 GitLab 버전 업데이트가 이루어진 후에 대기해야 합니다.

Omnibus

차트

대체 솔루션

아무것도 하지 않기

장점

  • 데이터베이스 및 관련 기능은 일반적으로 대규모 및 고가용성 배포에 가장 유용합니다.
  • 자체 관리형 배포를 위해 추가 논리적 또는 물리적 데이터베이스를 지원할 필요가 없어집니다.

단점

  • GitLab.com의 레지스트리와 자체 관리형에서 지원되는 기능이 시간이 지남에 따라 크게 다를 것입니다.
  • 두 개의 레지스트리 구현을 지원하는 유지 관리 부담이 새로운 레지스트리 기능의 속도를 떨어뜨립니다.
  • GitLab.com의 레지스트리가 자체 관리형으로 릴리스되기 전에 변경 사항을 유효화하기 위한 효과적인 방법이 되지 않을 것입니다.
  • 대규모 자체 관리형 사용자들은 여전히 레지스트리를 자신들의 요구에 맞게 확장하지 못할 것입니다.

점진적 이전

자체 관리형에서 GitLab.com 마이그레이션을 정확하게 복제하는 접근 방식입니다.

장점

  • 이미 성공한 프로세스를 복제합니다.
  • 인스턴스 대신 리포지토리별 다운타임을 범위로 지정합니다.

단점

  • 마이그레이션 프로세스의 모든 측면에서 복잡성이 크게 증가합니다.
  • 데이터 일관성 문제의 가능성이 크게 증가합니다.
  • 레지스트리 마이그레이션 진행 상황이 덜 명확해집니다.