| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| None |
@skarbek
|
@andrewn
| - |
Cells Difference with Dedicated
기존 읽기
- 셀 반복, 특히 Cell 1.0
- GitLab Dedicated
- GitLab Dedicated 기술 문서
GitLab Dedicated Diff
GitLab Dedicated는 처음부터 시작하여 안정적인 서비스만 실행할 수 있는 기회를 가졌습니다. GitLab.com은 베타 기능 또는 GitLab Dedicated에 없는 보조 기능을 실행하고 있습니다.
고급 검색
GitLab Dedicated가 하는 일:
Dedicated는 테넌트용 AWS OpenSearch를 프로비저닝하기 위해 GET 도구를 사용합니다. 응용 프로그램은 GET에 의해 자동으로 구성되어 이 기능을 활용하도록 구성됩니다.
GitLab.com이 현재 하는 일:
GitLab.com은 전역 검색 그룹(Global Search)에서 개발 중인 두 가지 아이템을 활용합니다. 우리는 대부분의 고객을 위해 애플리케이션 수준 검색 기능을 제공하는 Elasticsearch 클러스터를 가지고 있습니다. 이는 코드 검색 및 GitLab 애플리케이션 내에서 검색 가능한 다른 모든 것을 검색하는 데 현재 사용됩니다. Global Search 팀은 코드 검색 기능을 최종적으로 대체하기 위해 추가로 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 규모에서 우리는 책임과 역할에 따라 대상 설정이 대기 중인 Redis의 약 13개 배포를 가지고 있습니다. 이러한 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 차트의 일부로 배포되는 장비들을 통해 클라우드 로드 밸런서를 활용하여 트래픽을 적절한 기본 리소스로 연결합니다. 각 테넌트에는 고유한 설치가 있으며 고객 트래픽이 경로 지정된 분리된 엔드포인트를 향하게 됩니다.
프론트엔드 워크로드를 처리하기 위한 배포는 단일 서비스로 처리되며, GitLab Helm 차트와 함께 관리되고 배포되는 webservice입니다.
아래에서는 미래에 CloudFlare의 도입을 언급하며, CloudFlare는 앞으로 HAProxy가 필요하지 않은 다양한 WAF 기능을 제공할 것입니다.
GitLab.com이 현재 하는 일:
HAProxy는 CloudFlare 뒤와 Google 로드 밸런서 세트 뒤에 있습니다.
주요 목적은 프론트엔드 트래픽의 대상 클러스터로의 트래픽 라우팅을 제공하며 트래픽 관리를위한 다양한 규칙을 제공합니다.
이 관리 중 일부에 관해서는 다양한 기준에 따라 스로틀링 또는 요청 차단이 있습니다.
우리는 registry.gitlab.com, Pages 엔드포인트 및 CI 트래픽과 같은 전용 엔드포인트를 처리하는 HAProxy 플릿 몇 개를 가지고 있습니다.
우리는 복수의 프론트엔드 webservice를 배포하기 위해 Helm 차트의 고급 기능을 활용하며, 이들은 대상 트래픽을 제공하는 그룹으로 분할됩니다.
HAProxy는 규칙 다양성으로이 트래픽 그룹을 분할하도록 구성되어 있습니다.
이 그룹은 현재 api, git, internal-api, web 및 websockets으로 알려져 있습니다.
GitLab.com Cells가 하는 일:
GitLab Cells는 요청을 경로 지정해야하는 새로운 레이어를 도입합니다. 라우팅 서비스는 고객을 적절한 클러스터로 안내하기 위해 모든 요청을 가로챌 것으로 예정되어 있습니다. 이 레이어는 현재의 HAProxy 설정보다 상위에 있습니다. 라우팅 서비스 뒤에는 현재의 GitLab Helm 차트의 일부로 배포되는 기존 인그레스를 활용할 계획입니다. 요청은 그런 다음 프론트엔드의 인그레스 구성으로 직접 이동합니다. CloudFlare에서 방화벽 규칙으로 가능하고 필요한 경우 Windows HAProxy에서 구성된 다양한 트래픽 규칙을 평가해야합니다. 이상적으로는 HAProxy가 Cells 아키텍처에서 사라집니다.
Helm 차트는 프론트엔드 Pods를 배포하는 데 사용되며, 오늘은 현재와 동일하게 단 하나의 Pod 만 배포될 것입니다.
자산 라우팅
GitLab Dedicated이 하는 일:
자산은 webservice로 알려진 프론트엔드 서비스에 의해 제공됩니다.
webservice Pods는 GitLab Helm 차트에 의해 배포됩니다.
GitLab.com이 현재 하는 일:
자산은 팀 딜리버리가 소유한 배포 절차의 일환으로 Google Cloud Storage 버킷에 배포됩니다. 자산은 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 리포지터리 내의 우리 고유의 terraform 메커니즘으로 구성됩니다.
컨테이너 레지스트리는 온라인 가비지 수집을 위해 PostgreSQL 데이터베이스를 사용하며, 데이터베이스 마이그레이션은 Kubernetes Job에 의해 관리되며 매뉴얼 롤백이 가능합니다.
컨테이너 레지스트리는 캐싱 레이어로써 Redis를 사용합니다.
GitLab.com Cells가 하는 일:
메일 전달
GitLab Dedicated이 하는 일:
진행 중인 작업. 이슈 2481 참조
- 발신: AWS
SES제품을 활용하여 발신 이메일에 중점을 두는 계획입니다. - 수신: 수신 이메일은 지원되지 않습니다.
GitLab.com이 현재 하는 일:
- 발신: 이메일은 제3자인 Mailgun에 의해 처리됩니다.
- 수신: 이메일은 웹훅 전달 방법을 활용한 GitLab 애플리케이션에 의해 처리되며, 구성된 받은 편지함에 있는 이메일을 감시하고 이를 적절히 Sidekiq 워커로 보내는 방식입니다.
GitLab.com Cells가 하는 일:
발신: 제공 업체와 강력한 관계가 있으며 변경을 원하지 않기 때문에 계속해서 Mailgun을 사용할 것입니다. Dedicated 프로비저너는 최소한의 구성 변경으로 Mailgun/제3자 발신 메일 게이트웨이를 지원할 수 있습니다. 수신: 토론 중
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 콘텐츠(이슈, epic, Merge Request)를 벡터화하고 검색, 권장, 비정상 탐지, 분류, 백로그 정리, 중복 제거 및 기타 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를 활용하여 구성 관리를 하며, 비밀 관리를 위해 Vault로의 통합 및 구성 관리를 위해 Chef에 복잡한 역할 구조를 갖추고 있습니다.
GitLab.com Cells가 하는 일:
Chef가 제거되어 GitLab Dedicated 도구를 재사용하게 되며, 이는 Cells에서 실행될 것입니다.
재해 복구
GitLab Dedicated이 하는 일:
기존 문서 참조:
지금 GitLab.com이 하는 일:
기존 문서 참조:
GitLab.com Cells가 할 일:
나중에 블루프린트가 작성될 것입니다.
피처 플래그
GitLab Dedicated이 하는 일:
피처 플래그는 크게 활용되지 않으며 적극적으로 사용을 꺼냅니다. 특별한 사용 사례에는 재정의 메커니즘이 있습니다. 이는 기술적인 제약이 아닌 비즈니스 결정임을 유의하세요.
지금 GitLab.com이 하는 일:
공학자들이 변경 사항을 안전하게 배포할 수 있는 복잡한 과정을 가지고 있습니다.
GitLab.com Cells가 할 일:
ChatOps는 결국 Cells를 지원하기 위해 확장될 것입니다. 추가된 기능을 제공하기 위해 Epic 12797이 작성되었습니다. Iteration Cells 1.0에 대해 특별한 작업은 수행되지 않을 것입니다.
배포
GitLab Dedicated이 하는 일:
테넌트 설치에 기여하는 모든 컴포넌트는 버전이 매겨집니다. 계약에 따라 유지 보수 창이 정의되고 고객과 합의되며, 버전 업그레이드, 인프라 구성 변경 또는 애플리케이션 구성 변경과 같은 유지 보수 기회를 제공합니다. 이에 사용된 도구는 비프로덕션 테넌트에서 지나치게 테스트됩니다.
지금 GitLab.com이 하는 일:
전용 팀 Delivery는 하루에 여러 차례 GitLab의 새 버전을 관리하고 배포하는 일을 책임집니다. 다양한 단계, Canary 및 Main,를 활용하여 배포의 위험 관리를 지원합니다.
GitLab.com Cells가 할 일:
Delivery는 초기 개발에 대해 책임을 진 상태입니다. 이 작업 주변의 현재 블루프린트은 위험을 관리하기 위해 Ring 배포 개념을 도입합니다.
서브넷
GitLab Dedicated이 하는 일:
Dedicated는 모든 테넌트에 대해 의도적으로 중첩되는 IP CIDR의 정적 디렉터리을 사용합니다. 고객의 요구에 따라 서브넷을 설정할 수 있습니다.
지금 GitLab.com이 하는 일:
다양한 GCP 프로젝트 및 환경 전체에서 문서, 테라폼 코드 및 VPC 피어링이 모두 조화롭게 작동하도록 신중하게 관리되고 있습니다.
GitLab.com Cells가 할 일:
Kubernetes
GitLab Dedicated이 하는 일:
GitLab Environment Toolkit에 의해 관리되는 단일 Kubernetes 클러스터가 있습니다. GitLab Helm 차트에 의해 전체 GitLab 설치가 배포됩니다. 동일한 클러스터에 설치된 관측 스택을 위한 Instrumentor에 필요한 도구가 포함됩니다.
지금 GitLab.com이 하는 일:
클러스터는 config-mgmt 리포지터리를 통해 매뉴얼으로 구성됩니다.
이러한 클러스터에 대한 모든 것의 배포는 배포되는 여러 도구를 관리, 유지 및 GitLab 애플리케이션 워크로드를 관찰하는 데 필요한 여러 도구를 배포하는 적어도 세 개의 리포지터리를 통해 관리됩니다.
GitLab.com Cells가 할 일:
SRE 루트 액세스 권한
GitLab Dedicated이 하는 일:
VM:
Ansible에 의해 관리됨: [SSH](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html] (내부 링크)를 사용하고 Identify-Aware Proxy를 사용합니다. 이는 긴급 탈출 절차 (내부 링크)와 함께 사용해야 합니다.
쿠버네티스:
kubectl: 긴급 탈출 절차 (내부 링크).
지금 GitLab.com이 하는 일:
VM:
- Chef에 의해 관리되는 VM: 사용자 및 SSH 키가 Chef에 의해 관리되며 루트 액세스를 얻기 위해 bastion이 필요합니다.
- Rails Console: 읽기 전용 액세스를 위해 Teleport를 사용합니다.
-
psql: Teleport를 사용합니다.
쿠버네티스:
-
kubectl: Chef에서 관리되는 키를 가진 bastion 서버와gcloud설정을 통해 설정합니다. - GKE VM: 노드에 액세스하기 위해 Google의 OS Login을 사용합니다.
GitLab.com Cells가 할 일:
VM:
쿠버네티스:
-
kubectl: GitLab Dedicated과 동일합니다. - GKE VM: GitLab Dedicated과 동일합니다.
Observability
GitLab Dedicated이 하는 일:
.com에서 활용하는 동일한 메트릭 세트를 소비하는 감시 스택은 Instrumentor에 번들로 포장되어 테넌트의 Kubernetes 클러스터에 배포됩니다. 이에는 경보, 페이징, 대시보드 제공 및 예측에 대한 적절한 규칙이 모두 포함됩니다. 일부 메트릭이 부족하지만, 부족한 부분에 대한 완전한 커버리지를 확보하기 위해 작업 중입니다.
모든 테넌트에 대한 메트릭의 전역적인 뷰는 존재하지 않습니다.
로깅은 AWS 테넌트의 경우 AWS OpenSearch, GCP 테넌트의 경우 Google Cloud Logging을 사용하여 관리됩니다.
GitLab.com이 현재 하는 일:
다양한 방법으로 여러 GCP 프로젝트에 걸쳐 Prometheus와 Thanos의 대규모 설치가 관리됩니다. 대시보드, 경보 및 페이지의 모든 구성은 Runbooks 리포지터리를 활용합니다.
우리는 기본적으로 우리의 Grafana 설치가 모든 필요한 환경에 대해 쿼리를 분산시킬 수 있는 대규모 Thanos 구성과 대화를 나누고 있는데, 이를 통해 전역적인 뷰를 제공받습니다.
로그는 우리의 가상 머신과 쿠버네티스 클러스터 모두에 fluentd를 사용하여 관리되며, 데이터는 PubSub로 전송되어 Elasticsearch로 가져오며, Kibana를 사용하여 데이터를 확인합니다. CloudFlare, GKE 및 HAProxy와 같은 일부 서비스는 너무 많은 데이터를 덤프하므로 Google의 로깅 솔루션(Stackdriver 또는 BigQuery)에 의존합니다.
GitLab.com Cells이 할 일:
Camoproxy
GitLab Dedicated이 하는 일:
사용되지 않음.
GitLab.com이 현재 하는 일:
go-camo는 사용자 정의 Helm 차트에 의해 배포됩니다. go-camo는 HTTP 기반 리소스에서 HTTPS로 이미지를 제공하는 데 사용됩니다.
GitLab.com Cells이 할 일:
Certificates
GitLab Dedicated이 하는 일:
GitLab Dedicated은 cert-manager, Let’s Encrypt 및 NGINX를 사용하여 인증서를 발급하고 관리합니다.
GitLab.com이 현재 하는 일:
GitLab.com은 Cloudflare을 사용하여 인증서를 사용하며, 보조 서비스인 Grafana 등을 위해 cert-manager 및 GCP 인증서를 혼합하여 사용합니다.
GitLab.com Cells이 할 일:
GitLab.com의 경우, 계속해서 Cloudflare을 사용하여 Cloudflare의 인증서를 계속하여 사용할 것입니다.
osquery
GitLab Dedicated이 하는 일:
osquery를 설치하지 않습니다.
GitLab.com이 현재 하는 일:
우리는 우리의 osquery 설치를 관리하기 위해 chef cookbook을 사용합니다.
GitLab.com Cells이 할 일:
Cell 아키텍처에 배포되는 배포 방법과 호환되는 툴링이 개발되어야 합니다.
osquery에서 다루어질 사항:
osquery는 모든 가상 머신을 다루며, 오늘날 다루는 예제 중 일부는 bastion 노드, HA Proxy 노드 등입니다.
osquery가 필요한 이유:
- 가시성: 현재 우리는 여전히 VMs 및 쿠버네티스 클러스터 내에서 일어나는 일에 대해 매우 제한된 가시성을 가지고 있습니다.
- 컴플라이언스 요구 사항: 컴플라이언스는 쿠버네티스나 레거시 VMs와 같은 환경에서의 작업에 대한 명확한 통찰력을 요구합니다.
- 사건 조사: 지난 사건들은 악의적인 명령어가 실행되기 전과 후의 탐지 및 조사 부족으로 인해 몇 가지 부족한 조사로 남아 있습니다.
Wiz Runtime Sensor
GitLab Dedicated이 하는 일:
Wiz는 사용되지 않습니다.
GitLab.com이 현재 하는 일:
Wiz Runtime Sensor는 .com에 새롭게 도입되는 도구입니다. Wiz Runtime Sensor는 가벼운 eBPF 기반 에이전트로, 애플리케이션/워크로드가 실행하는 의심스러운 작업에 대한 선언을 생성합니다. 자세한 내용은 Wiz Runtime 내부 핸드북 페이지를 참조하십시오.
이 글을 쓰는 시점에서, 이 도구는 아직 프로덕션 환경에 배포되지 않았으며 여전히 스테이징 환경에서 테스트 중입니다. 현재, Helm 차트를 사용하여 배포됩니다.
GitLab.com Cells이 할 일:
이 도구를 사용하기로 결정된 경우, Cellular 아키텍처에 적합한 배포 방법을 다시 만들어야 합니다. 현재 사용 중인 배포 방법은 Cellular 아키텍처에 부적절합니다.
Wiz Runtime Sensor로 다루어질 사항:
Wiz Runtime Sensor는 DaemonSet으로 쿠버네티스 클러스터에 배포될 것입니다. DaemonSet은 모든 노드에 센서를 추가하며, Wiz Runtime Sensor는 악의적인 스크립트 실행, 민감한 파일 접근/수정, 컨테이너 이스케이프 시도와 같은 모든 노드의 시스콜을 감시할 것입니다.
Wiz Runtime Sensor가 필요한 이유:
- 가시성: 현재 우리는 여전히 VMs 및 쿠버네티스 클러스터 내에서 일어나는 일에 대해 매우 제한된 가시성을 가지고 있습니다.
- 컴플라이언스 요구 사항: 컴플라이언스는 쿠버네티스나 레거시 VMs와 같은 환경에서의 작업에 대한 명확한 통찰력을 요구합니다.
- 사건 조사: 지난 사건들은 악의적인 명령어가 실행되기 전과 후의 탐지 및 조사 부족으로 인해 몇 가지 부족한 조사로 남아 있습니다.