| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| None |
@skarbek
|
@andrewn
| - |
Dedicated와의 Cells 차이점
기존 읽기
- 셀 이터레이션, 특히 셀 1.0
- GitLab Dedicated
- GitLab Dedicated 기술 문서
GitLab Dedicated 차이점
GitLab Dedicated는 매끄러운 서비스만 운영할 수 있도록 공백으로부터 시작하는 기회를 가졌습니다. GitLab.com은 베타 기능이나 GitLab Dedicated에는 없는 보조 기능을 실행하고 있습니다.
고급 검색
GitLab Dedicated는 무엇을 하고 있나요:
Dedicated는 테넌트를 위해 AWS OpenSearch를 프로비저닝하기 위해 GET 도구를 활용합니다. 이 응용 프로그램은 GET에 의해 자동으로 구성되어 이 기능을 활용하도록 구성됩니다.
지금 GitLab.com은 무엇을 하고 있나요:
GitLab.com은 글로벌 검색 그룹 내에서 집중적으로 개발 중인 두 가지 항목을 활용합니다. 저희는 Elasticsearch 클러스터를 보유하고 있으며, 이는 대부분의 고객을 위한 응용프로그램 수준의 검색 기능을 제공합니다. 현재 이는 코드 검색 및 GitLab 응용프로그램 내에서 검색 가능한 다른 모든 것을 검색하는 데 사용됩니다. 글로벌 검색팀은 결국 코드 검색 기능을 대체하기 위해 추가로 Zoekt를 사용하는 것을 테스트하고 있습니다.
GitLab.com Cells가 무엇을 할 것인가:
용량 계획
GitLab Dedicated는 무엇을 하고 있나요:
Tamland이 사용됩니다.
지금 GitLab.com은 무엇을 하고 있나요:
Tamland이 사용됩니다.
GitLab.com Cells가 무엇을 할 것인가:
Tamland가 동일하게 활용될 것입니다. Dedicated를 위한 작업이 완료되었습니다. Cells를 위해 수행해야 할 소규모 작업이 있을 수 있습니다.
Redis
GitLab Dedicated는 무엇을 하고 있나요:
Dedicated는 Redis를 위해 GCP Memorystore 제품을 활용합니다. 이 작업은 진행 중인 작업이지만 GitLab 환경 도구에서 지원됩니다.
지금 GitLab.com은 무엇을 하고 있나요:
.com 규모에서 우리는 책임과 역할을 보류 중인 대상 구성과 함께 약 13개의 Redis 배포를 보유하고 있습니다. 이러한 Redis 배포는 표준 Redis 배포 및 Redis 클러스터 간에 차이가 있습니다. 우리는 이 서비스를 확장함에 따라 이러한 다양한 고민점을 해결한 일련의 우선 순위 작업에 따라 구성을 변경합니다.
GitLab.com Cells가 무엇을 할 것인가:
Cells는 GitLab의 훨씬 작은 설치이므로 .com처럼 우리의 Redis 인프라를 그만큼 확장할 필요가 없을 것입니다. 선택한 참조 아키텍처는 우리의 요구에 맞게 충분히 큰 Redis 배포를 설치해야 합니다. 고객 트래픽을 수신하는 첫 번째 Cells의 Redis 동작에 대한 감시는 우리가 필요로 하는 개선 사항을 결정하기 위해 밀접하게 모니터링되어야 할 것입니다.
비밀 관리
GitLab Dedicated는 무엇을 하고 있나요:
Dedicated는 비밀 관리를 위해 Google Secret Manager를 활용합니다. 테넌트당 고유한 비밀과 환경 내에서 공유되는 비밀 두 가지 유형의 비밀이 사용됩니다. 후자는 Amp와 같은 테넌트의 관리를 엄격히 위해 사용되므로 각 GitLab 설치에는 고유한 비밀 집합이 있으며 일부 구성 항목은 해당 클라우드 제공 업체의 시크릿 서비스를 사용하여 저장됩니다. Dedicated 테넌트 프로비저닝 도구 인 Instrumentor는 다양한 단계 간에 필요한 비밀만 인식하고 공유합니다.
지금 GitLab.com은 무엇을 하고 있나요:
.com은 KMS를 이미 간단한 항목용으로 활용하고 있으며 Chef 런에 대한 비밀 관리용 래퍼로도 활용됩니다. 대부분의 비밀은 HashiCorp Vault에 푸시되며 인프라의 여러 부분이 이 서비스를 사용하여 가상 머신과 Kubernetes 설치 간에 공유되는 항목에 사용됩니다.
GitLab.com Cells가 무엇을 할 것인가:
토의 중.
HAProxy
GitLab Dedicated는 무엇을 하고 있나요:
HAProxy는 사용되지 않습니다. 대신, GitLab Helm 차트의 일부로 배포된 인그레스를 활용하여 클라우드 로드 밸런서를 활용하여 트래픽을 적절한 하위 리소스로 보냅니다. 각 테넌트는 고유한 설치를 갖기 때문에 고객 트래픽이 라우팅되는 분리된 엔드포인트가 있습니다.
프론트엔드 워크로드를 처리하는 배포는 저희의 Helm 차트로 관리되고 배포된 단일 서비스(webservice)에 의해 처리됩니다.
아래에서 우리는 앞으로 CloudFlare의 도입을 언급했는데, 이는 HAProxy가 필요하지 않은 다양한 WAF 기능을 제공하게 될 것입니다.
지금 GitLab.com은 무엇을 하고 있나요:
HAProxy는 CloudFlare 뒤에 있으며 Google 로드 밸런서의 뒤에 있습니다.
기본 목적은 프론트엔드 트래픽을 대상 클러스터로 라우팅하고 다양한 기준에 따라 요청 차단 또는 쓰로틀링과 같은 트래픽 관리 규칙을 제공하는 것입니다.
저희는 registry.gitlab.com, Pages 엔드포인트 및 CI 트래픽과 같은 특정 엔드포인트를 처리하는 몇 개의 HAProxy 플릿을 가지고 있습니다.
우리는 우리의 Helm 차트의 고급 기능을 활용하여 다양한 프론트엔드 webservice를 배포하고 있습니다. 이들은 대상 트래픽을 제공하는 그룹으로 분할됩니다.
HAProxy는 다양한 규칙을 사용하여 이러한 트래픽 그룹을 나눕니다.
오늘날 이러한 그룹은 api, git, internal-api, web, websockets으로 알려져 있습니다.
GitLab.com Cells가 무엇을 할 것인가:
GitLab Cells는 요청을 라우팅해야 할 새로운 레이어를 도입합니다. 라우팅 서비스는 클라이언트를 적절한 클러스터로 이동시키기 위해 모든 요청을 가로챌 것으로 계획되어 있습니다. 이 레이어는 현재 HAProxy 설정보다 상위에 위치합니다. 라우팅 서비스 뒤에는 현재 GitLab Helm 차트의 일부로 배포된 인그레스가 이용될 예정입니다. 요청은 그런 다음 우리의 프론트엔드의 인그레스 구성으로 직접 이동합니다. HAProxy에서 구성된 다양한 트래픽 규칙을 검토하여 필요한 경우 CloudFlare 내에서 방화벽 규칙으로 설정될 수 있는지 여부를 평가해야 합니다. 이상적으로, Cells 아키텍처에서 HAProxy가 없어질 것입니다.
Helm 차트는 프론트엔드 Pods를 배포하는 데 사용되며, 오늘날 Dedicated가 하는 것을 모방하여 하나의 Pod만 배포될 것입니다.
에셋 라우팅
GitLab Dedicated이 하는 일:
에셋은 webservice로 알려진 프론트엔드 서비스에 의해 제공됩니다.
webservice Pods는 GitLab Helm 차트에 의해 배포됩니다.
GitLab.com이 현재 하는 일:
에셋은 팀 딜리버리가 소유한 배포 프로시저의 일부로 구글 클라우드 스토리지 버킷에 배포됩니다. 이후에 CloudFlare에서 관리되는 특정 라우팅 구성에 의해 제공됩니다.
이로써 webservice 배포는 정적 에셋을 처리하는 데 필요하지 않으며, 이러한 서비스들은 요청을 처리하는 데 집중할 수 있습니다.
GitLab.com Cells가 할 일:
에셋의 배포는 변경되지 않을 것입니다. 이 프로세스는 여전히 CloudFlare와 동일할 것입니다.
Cloudflare
GitLab Dedicated가 하는 일:
아직 CloudFlare는 연루되지 않았습니다. Dedicated에 WAF 솔루션을 가져오기 위한 작업이 진행 중입니다.
GitLab.com이 현재 하는 일:
CloudFlare는 우리에게 기본 및 사용자 정의 방화벽, DNS 및 트래픽 라우팅 관리를 제공하는 첫 번째 방어선입니다.
GitLab.com Cells가 할 일:
CloudFlare의 사용은 기술적으로 routing-service를 사용함으로써 확대될 것입니다. .com 진입점은 변하지 않으며, routing-service의 추가를 제외하고는 서비스에 변경이 없어야 합니다.
컨테이너 레지스트리
GitLab Dedicated가 하는 일:
Dedicated는 Helm 차트를 활용하여 GitLab 레지스트리 서비스를 배포하고 구성합니다. 레지스트리 서비스는 GitLab Environment Toolkit에서 관리되는 저장소 버킷을 바탕으로 합니다.
GitLab.com이 현재 하는 일:
.com은 동일한 GitLab Helm 차트를 활용하여 컨테이너 레지스트리 서비스를 배포하고 구성합니다.
백업 스토리지는 우리 자체 테라폼 메커니즘으로 config-mgmt 저장소에서 구성됩니다.
컨테이너 레지스트리는 온라인 가비지 수집을 위해 포스그레스SQL 데이터베이스를 사용하며, 데이터베이스 마이그레이션은 Kubernetes 작업에 의해 관리되며 수동 롤백이 가능합니다.
컨테이너 레지스트리는 또한 캐싱 레이어로서 Redis를 사용합니다.
GitLab.com Cells가 할 일:
메일 배송
GitLab Dedicated가 하는 일:
진행 중인 작업. 이슈 2481 참조
- 발신: AWS
SES제품을 활용하여 발신 이메일에 초점을 맞추고자 합니다. - 수신: 수신 이메일은 지원되지 않습니다.
GitLab.com이 현재 하는 일:
- 발신: 이메일은 써드 파티인 Mailgun에 의해 처리됩니다.
- 수신: 이메일은 웹훅 전달 방법을 통해 GitLab 애플리케이션에 의해 처리되며, 구성된 받은 편지함에 있는 이메일을 감시하고 이를 Sidekiq 워커에 적절히 지시합니다.
GitLab.com Cells가 할 일:
발신: 우리는 제공업체와 강력한 관계가 있으며 변경하고자 하는 의사가 없으므로 계속해서 Mailgun을 사용할 것입니다. Dedicated 프로비저너는 최소한의 구성 변경으로 Mailgun/써드파티 발신 메일 게이트웨이를 지원할 수 있습니다. 수신: 토의 중
PostgreSQL
GitLab Dedicated가 하는 일:
단일 RDS 인스턴스가 배포됩니다.
GitLab.com이 현재 하는 일:
GitLab Rails 코드베이스의 일부 기능의 규모를 처리하기 위해 데이터베이스를 세 개의 PostgreSQL 클러스터로 분할했습니다.
대부분의 데이터 저장을 처리하는 main 클러스터, 모든 CI 관련 데이터를 처리하는 ci, 그리고 최종적으로 embedding 데이터베이스로 구성되어 있습니다.
또한 더 분해하여 다른 PostgreSQL 클러스터로의 분해도 평가 중입니다.
각 데이터베이스 앞에는 연결 풀러로서 일련의 PgBouncer가 있습니다.
GitLab.com Cells가 할 일:
우리가 할 일은 별도의 블루프린트에서 진행 중입니다.
임베딩 데이터베이스
GitLab Dedicated가 하는 일:
GitLab Dedicated는 임베딩 데이터베이스를 사용하지 않으며, 아직 실험 단계입니다.
GitLab.com이 현재 하는 일:
pgvector를 실행하는 PostgreSQL 클러스터가 배포되었습니다. 임베딩 데이터는 GitLab 콘텐츠(이슈, 에픽, 병합 요청)를 벡터화하고 검색, 권장사항, 이상 징후 감지, 분류, 백로그 정리, 중복 제거 및 기타 AI 인접 작업에 사용할 수 있는 곳에 데이터를 저장합니다.
GitLab.com Cells가 할 일:
임베딩 데이터베이스는 아직 실험적이며, Cells 1.0의 범위를 줄이기 위해 지원하지 않을 것입니다.
GitLab Pages
GitLab Dedicated이 하는 일은 무엇입니까:
막 출시되었습니다!
지금 GitLab.com이 하는 일은 무엇입니까:
GitLab Pages는 .com의 활성 기능입니다.
GitLab.com Cells은 무엇을 할 것인가:
우리는 Cells 1.0 에서 GitLab Pages를 활성화하지 않을 것이므로 현재 범위를 벗어납니다.
VM 구성 관리
GitLab Dedicated이 하는 일은 무엇입니까:
VM의 관리는 모두 GitLab Environment Toolkit으로 처리됩니다. 머신을 프로비저닝하기 위해 Terraform을 사용하고 VM을 구성하기 위해 Ansible을 사용합니다.
지금 GitLab.com이 하는 일은 무엇입니까:
.com은 비밀 관리를 위해 볼트와 통합된 Chef를 활용하며 Chef에 내장된 복잡한 역할 구조로 구성을 관리합니다.
GitLab.com Cells은 무엇을 할 것인가:
쉐프가 제거되어 GitLab Dedicated 도구를 재사용할 것입니다.
재해 복구
GitLab Dedicated이 하는 일은 무엇입니까:
기존 문서를 참조하세요:
지금 GitLab.com이 하는 일은 무엇입니까:
기존 문서를 참조하세요:
GitLab.com Cells은 무엇을 할 것인가:
나중에 블루프린트가 작성될 것입니다.
특징 플래그
GitLab Dedicated이 하는 일은 무엇입니까:
특징 플래그는 적극적으로 활용되지 않으며 적극적으로 권장되지 않습니다. 특별한 사용 사례에 대한 재정의 매커니즘이 존재합니다. 이는 비즈니스 결정이며 기술적 제한이 아닙니다.
지금 GitLab.com이 하는 일은 무엇입니까:
공학자들이 안전하게 변경 사항을 롤아웃할 수 있도록 FAIRLY 복잡한 프로세스를 가지고 있습니다.
GitLab.com Cells은 무엇을 할 것인가:
ChatOps는 나중에 Cells을 지원하기 위해 확장될 것입니다. 추가 기능을 제공하기 위해 Epic 12797가 생성되었습니다. Iteration Cells 1.0에 대한 작업은 발생하지 않을 것입니다.
배포
GitLab Dedicated이 하는 일은 무엇입니까:
테넌트 설치에 필요한 모든 구성 요소는 버전이 지정됩니다. 계약에 따라 유지 보수 창이 정의되고 고객과 합의되어 버전 업그레이드, 인프라 구성 변경 또는 응용 프로그램의 구성 변경과 같은 모든 유지 보수 작업이 수행됩니다. 이를 위해 사용되는 도구는 비생산 테넌트에서의 방대한 테스트를 거쳐 실행됩니다.
지금 GitLab.com이 하는 일은 무엇입니까:
Delivery라는 전담 팀은 GitLab의 새로운 버전을 하루에 여러 차례 배포하는 데 책임이 있습니다. 위험 관리를 돕기 위해 Canary와 Main과 같은 여러 단계가 활용됩니다.
GitLab.com Cells은 무엇을 할 것인가:
Delivery는 초기 개발에 대한 책임을 유지할 것입니다. 이 작업을 둘러싼 현재 블루프린트는 위험을 관리하기 위해 링 배포라는 개념을 도입합니다.
서브넷
GitLab Dedicated이 하는 일은 무엇입니까:
모든 테넌트에 대해 의도적으로 겹치는 IP CIDR의 정적 목록을 사용합니다. 고객 요구 사항에 따라 서브넷을 구성할 수 있습니다.
지금 GitLab.com이 하는 일은 무엇입니까:
여러 GCP 프로젝트 및 환경 전체에서 문서, 테라폼 코드 및 VPC 피어링이 모두 동질적인 방식으로 작동하도록 매우 엄격하고 신중하게 관리됩니다.
GitLab.com Cells은 무엇을 할 것인가:
Kubernetes
GitLab Dedicated이 하는 일은 무엇입니까:
GitLab Environment Toolkit으로 관리되는 단일 Kubernetes 클러스터가 생성됩니다. GitLab Helm 차트로 전체 GitLab 설치가 배포됩니다. 동일한 클러스터에 설치되는 가시성 스택을 위한 도구가 Instrumentor에 포함되어 있습니다.
지금 GitLab.com이 하는 일은 무엇입니까:
클러스터는 Terraform을 통해 수동으로 구성되며, 클러스터에 대한 모든 배포는 클러스터 내에서 배포되는 GitLab 응용 프로그램 워크로드를 관리, 유지 및 관찰하기 위해 필요한 다양한 도구를 배포하는 세 개 이상의 리포지토리를 거쳐 관리됩니다.
GitLab.com Cells은 무엇을 할 것인가:
SRE 루트 액세스 권한
GitLab Dedicated이 하는 일:
VM:
Ansible로 관리됨: [SSH](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html] (내부 링크) 및 Identity-Aware Proxy를 사용한 혼합. 이는 긴급 절차 (내부 링크)와 함께 사용해야 함.
Kubernetes:
kubectl: 긴급 절차 (내부 링크).
GitLab.com이 현재 하는 일:
VM:
- Chef로 관리되는 VM: 사용자 및 SSH 키가 Chef로 관리되며 루트 액세스가 가능하도록하기 위해 bastion이 필요함.
- Rails Console: 읽기 전용 액세스를 위해 Teleport를 사용하여 Rails 콘솔을 실행합니다.
-
psql: Teleport를 사용합니다.
Kubernetes:
-
kubectl: Chef로 키가 관리되는 bastion 서버를 사용하여 설정 후gcloud를 설정합니다. - GKE VMs: 노드에 액세스하려면 Google의 OS Login을 사용합니다.
GitLab.com Cells이 할 일:
VM:
Kubernetes:
-
kubectl: GitLab Dedicated와 동일함. - GKE VMs: GitLab Dedicated와 동일함.
관찰 가능성
GitLab Dedicated이 하는 일:
관측성 스택은 .com에 활용되는 동일한 메트릭 세트를 소비하며 이를 인스트루먼터에 번들로 만들어 테넌트의 Kubernetes 클러스터에 배포합니다. 이에는 경보, 페이징, 대시보드 및 예측을 위한 모든 적절한 규칙이 포함됩니다. 일부 메트릭이 부족하지만, 부족한 부분을 보완하기 위해 작업 중에 있습니다.
테넌트 전체의 메트릭에 대한 전역적인 보기가 존재하지 않습니다.
로그는 AWS 테넌트의 경우 AWS OpenSearch를, GCP 테넌트의 경우 Google Cloud Logging을 사용하여 관리됩니다.
GitLab.com이 현재 하는 일:
다양한 방법을 통해 다수의 GCP 프로젝트에 걸친 대규모 Prometheus 및 Thanos 설치를 관리합니다. 모든 대시보드, 경보 및 페이지 구성을 위해 Runbooks 저장소를 활용합니다.
우리는 기본적으로 Grafana 설치가 모든 필요한 환경에 대해 쿼리를 분산시킬 수 있는 대규모 Thanos 구성과 대화할 수 있어 전역적인 보기를 제공받습니다.
로그는 fluentd를 사용하여 가상 머신 및 Kubernetes 클러스터에서 데이터를 PubSub로 보내고 Elasticsearch에 가져와서 Kibana를 사용하는 방식으로 관리됩니다.
일부 서비스(예: CloudFlare, GKE 및 HAProxy)는 너무 많은 데이터를 덤프하는데, 이 경우 Google의 Logging 솔루션(Stackdriver 또는 BigQuery)에 의존합니다.
GitLab.com Cells이 할 일:
Camoproxy
GitLab Dedicated이 하는 일:
사용되지 않음.
GitLab.com이 현재 하는 일:
go-camo는 사용자 정의 Helm 차트로 배포됩니다. go-camo는 HTTP 기반 리소스에서 HTTPS로 이미지를 제공하는 데 사용됩니다.
GitLab.com Cells이 할 일:
인증서
GitLab Dedicated이 하는 일:
GitLab Dedicated은 cert-manager, Let’s Encrypt 및 NGINX를 사용하여 인증서를 발급 및 관리합니다.
지금 GitLab.com이 하는 일:
GitLab.com은 인증서를 위해 Cloudflare를 사용하고 그라파나와 같은 보조 서비스를 위해 cert-manager 및 GCP 인증서를 혼용합니다.
GitLab.com Cells가 할 일:
GitLab.com을 위해 우리는 계속해서 Cloudflare의 인증서를 사용할 것입니다.
osquery
GitLab Dedicated가 하는 일:
osquery를 설치하지는 않습니다.
지금 GitLab.com이 하는 일:
osquery 설치를 관리하기 위한 chef cookbook가 있습니다.
GitLab.com Cells가 할 일:
Cell 아키텍처에 배포하는 데 활용되는 배포 방법과 호환되는 개발 도구가 개발되어야 합니다.
osquery가 다루게 될 사항:
osquery는 모든 가상 머신을 다룰 것이며, 오늘 날 몇 가지 예시로는 배스천 노드, HA 프록시 노드 등이 대상입니다.
osquery가 필요한 이유:
- 가시성: 현재도 VM 및 Kubernetes 클러스터 안에서 무슨 일이 일어나고 있는지에 대한 가시성이 매우 부족합니다.
- 준수 요구 사항: 준수 요구 사항에 따르면 Kubernetes나 레거시 VM과 같은 환경에서의 동작에 대한 명확한 통찰력이 필요합니다.
- 사건 조사: 지난 사건 조사들은 악의적인 명령어가 실행되기 전과 후의 탐지 및 조사 부재로 인해 몇 가지 조사를 해결하지 못한 채 남아 있습니다.
Wiz Runtime Sensor
GitLab Dedicated가 하는 일:
Wiz는 사용되고 있지 않습니다.
지금 GitLab.com이 하는 일:
Wiz Runtime Sensor는 현재 .com에 도입된 새로운 도구입니다. Wiz Runtime Sensor는 경량 eBPF 기반 에이전트로, 애플리케이션/작업 부하가 실행한 의심스러운 작업에 대한 결과를 생성하기 위해 시스콜을 수신합니다. Wiz Runtime 내부 핸드북 페이지에서 자세한 내용을 확인하세요.
작성 시점에서 이것은 아직 제품 환경에 배포되지 않았으며 아직 스테이징 환경에서 테스트 중입니다. 현재 헬름 차트를 사용하여 배포되고 있습니다.
GitLab.com Cells가 할 일:
만약 이 도구를 활용하려면 Cellular 아키텍처에 적합한 배포 방법을 재구성해야 할 것입니다. 현재 활용되고 있는 배포 방법은 Cellular 아키텍처에 부족할 것입니다.
Wiz Runtime Sensor가 다루게 될 사항:
Wiz Runtime Sensor는 DaemonSet으로 Kubernetes 클러스터에 배포될 것입니다. DaemonSet은 모든 노드에 센서를 추가하며, Wiz Runtime Sensor는 악의적인 스크립트 실행, 민감한 파일 접근/수정, 컨테이너 이탈 시도와 같은 악의적인 동작을 위한 시스콜을 관찰할 것입니다.
Wiz Runtime Sensor가 필요한 이유:
- 가시성: 현재도 VM 및 Kubernetes 클러스터 안에서 무슨 일이 일어나고 있는지에 대한 가시성이 매우 부족합니다.
- 준수 요구 사항: 준수 요구 사항에 따르면 Kubernetes나 레거시 VM과 같은 환경에서의 동작에 대한 명확한 통찰력이 필요합니다.
- 사건 조사: 지난 사건 조사들은 악의적인 명령어가 실행되기 전과 후의 탐지 및 조사 부재로 인해 몇 가지 조사를 해결하지 못한 채 남아 있습니다.