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
implemented @grzesiek @ayufan @grzesiek @ogolowinski @dcroft @vshushlin devops release 2019-05-16

GitLab Pages New Architecture

GitLab Pages는 GitLab 제품의 중요한 구성 요소입니다. 대부분의 경우 정적 콘텐츠를 제공하는 데 사용되며 명확히 정의된 책임을 가지고 있습니다. 그럼에도 불구하고, 안타깝게도 이는 GitLab.com Kubernetes 이주를 방해하는 요인이 되었습니다.

Cloud Native 및 Kubernetes의 채택은 GitLab이 프로젝트 뒤의 회사로서 더 빠른 성장을 도울 가장 큰 두 가지 효과 중 하나로 인식되었습니다.

이 노력은 자세히 인프라 팀 핸드북 페이지에 설명되어 있습니다.

GitLab Pages는 NFS와 강하게 결합되어 있으며 Kubernetes 이주를 방해하지 않기 위해 GitLab Pages 아키텍처에 중대한 변화가 필요합니다. 이는 1년 전에 시작된 계속되는 작업입니다. 이 설계안은 왜 중요한지와 로드맵이 무엇인지 이해하는 데 유용할 수 있습니다.

GitLab Pages 작동 방식

GitLab Pages는 정적 콘텐츠를 제공하는 데 사용되는 데몬으로, Go로 작성되었습니다.

초기에 GitLab Pages는 로컬 공유 블록 스토리지(NFS)에 정적 콘텐츠를 저장하도록 설계되었으며, 계층적 그룹 > 프로젝트 디렉토리 구조에서 각 디렉터리가 프로젝트를 나타내며 GitLab Pages 데몬이 읽고 제공할 정적 콘텐츠와 구성 파일이 포함되어 있어야 했습니다.

graph LR A(GitLab Rails) -- 새 페이지 배포 작성 --> B[(NFS)] C(GitLab Pages) -. 정적 콘텐츠 읽기 .-> B

NFS 결합으로 이 초기 설계는 구식이 되었으며, NFS 결합이 하나의 이유로 들어 있습니다. 이에 우리는 이를 더 “분리된 서비스”-와 같은 아키텍처로 대체하기로 결정했습니다. 우리가 작업 중인 새 아키텍처는 이 설계안에 설명되어 있습니다.

NFS 결합

2017년에 NFS 인프라의 확장 문제를 심각하게 경험했습니다. 심지어 CephFS로 대체를 시도했지만 실패했습니다.

그 이후로 NFS 클러스터의 운영 및 유지 관리 비용이 상당하다는 것과, 만일 우리가 Kubernetes로 이주를 결정하게 된다면 GitLab을 공유 로컬 스토리지 및 NFS에서 분리해야 한다는 것이 분명해졌습니다.

  1. NFS는 단일 장애 지점일 수 있음
  2. NFS는 신뢰할 수 있는 세로 확장만 가능함
  3. Kubernetes로 이주하기 위해서는 마운트 지점 수를 엄청나게 증가시켜야 함
  4. NFS는 Kubernetes 환경에서 제공하기 어려운 극도로 신뢰할 수 있는 네트워크에 의존함
  5. NFS에 고객 데이터를 저장하는 것은 추가 보안 위험을 수반함

NFS를 분리하지 않고 GitLab을 Kubernetes로 이주하면 복잡성, 유지 관리 비용, 엄청난 가용성 부정적 영향이 폭발적으로 증가하게 될 것입니다.

새로운 GitLab Pages 아키텍처

  • GitLab Pages는 도메인의 구성을 로컬 공유 스토리지에서 config.json 파일을 읽는 대신 GitLab 내부 API에서 가져옵니다.
  • GitLab Pages는 정적 콘텐츠를 객체 스토리지에서 제공합니다.
graph TD A(사용자) -- 페이지 배포 푸시 --> B{GitLab} C((GitLab Pages)) -. API에서 구성 읽기 .-> B C -. 정적 콘텐츠 읽기 .-> D[(객체 스토리지)] C -- 정적 콘텐츠 제공 --> E(방문자)

이 새로운 아키텍처에 대한 간단한 설명은 블로그 글 에서 확인할 수 있습니다.

반복

  1. ✓ GitLab Pages 구성 원본을 GitLab API 사용으로 재설계
  2. ✓ 성능을 평가하고 신뢰할 수 있는 캐싱 메커니즘 구축
  3. ✓ GitLab.com에서 새로운 원본을 점진적으로 롤아웃
  4. ✓ GitLab Pages API 도메인 구성 원본을 기본으로 활성화
  5. 다양한 서빙에 대한 실험을 기능 플래그를 통해 가능하게 함
  6. 의미 있는 실험을 통해 객체 저장소 서빙 디자인을 삼각측량함
  7. 점진적으로 작동하는 페이지 이주 메커니즘을 설계
  8. GitLab.com에서 객체 저장소 서빙으로 점진적으로 이주함

GitLab Pages 아키텍처 상세 로드맵이 포함된 epic도 사용 가능합니다.