• 요구 사항
• 설계 선택
• 구성
  • 설치 명령줄 옵션
• 차트 구성 예시
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • serviceAccount
  • tolerations
  • affinity
  • annotations
  • priorityClassName
  • git.config
  • cgroups
• External Services
  • Workhorse
• Chart settings
  • Git Repository Persistence
  • Gitaly의 TLS 실행
  • 전역 서버 후크
  • GitLab에서 생성된 커밋의 GPG 서명
  • 서버 측 백업

GitLab-Gitaly 차트 사용하기

gitaly 서브 차트는 Gitaly 서버의 조정 가능한 배포를 제공합니다.

요구 사항

이 차트는 Workhorse 서비스에 대한 액세스에 따라 다릅니다.
완전한 GitLab 차트의 일부이거나 이 차트가 배포되는 Kubernetes 클러스터에서 접근할 수 있는 외부 서비스로 제공됩니다.

설계 선택

이 차트에서 사용되는 Gitaly 컨테이너는 Gitaly로 아직 포팅되지 않은 Git 저장소에서 작업을 수행하기 위해 GitLab Shell 코드베이스를 포함합니다.
Gitaly 컨테이너에는 GitLab Shell 컨테이너의 복사본이 포함되어 있으며, 그 결과 이 차트 내에서 GitLab Shell을 구성해야 합니다.

구성

gitaly 차트는 두 부분으로 구성됩니다: 외부 서비스와 차트 설정.

Gitaly는 기본적으로 GitLab 차트를 배포할 때 구성 요소로 배포됩니다.
Gitaly를 별도로 배포하는 경우, global.gitaly.enabled를 false로 설정해야 하며, 외부 Gitaly 문서에 설명된 추가 구성을 수행해야 합니다.

설치 명령줄 옵션

아래 표는 --set 플래그를 사용하여 helm install 명령에 제공할 수 있는 모든 가능한 차트 구성을 포함합니다.

차트 구성 예시

extraEnv

extraEnv는 모든 컨테이너에서 추가 환경 변수를 노출할 수 있도록 합니다.

아래는 extraEnv의 사용 예시입니다:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

컨테이너가 시작되면 환경 변수가 노출되었는지 확인할 수 있습니다:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFrom은 다른 데이터 소스에서 모든 컨테이너에 추가 환경 변수를 노출할 수 있도록 합니다.

아래는 extraEnvFrom의 사용 예시입니다:

extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # 선택: 불리언
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # 선택: 불리언

image.pullSecrets

pullSecrets는 private registry에 인증하여 팟을 위한 이미지를 가져올 수 있도록 합니다.

private registries 및 인증 방법에 대한 추가 세부정보는 Kubernetes 문서에서 확인할 수 있습니다.

아래는 pullSecrets의 사용 예시입니다:

image:
  repository: my.gitaly.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

이 섹션은 ServiceAccount가 생성되어야 하는지와 기본 액세스 토큰이 팟에 마운트되어야 하는지를 제어합니다.

tolerations

tolerations는 오염된 작업자 노드에서 팟을 스케줄할 수 있게 합니다.

아래는 tolerations의 사용 예시입니다:

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

affinity

자세한 내용은 affinity를 참조하세요.

annotations

annotations는 Gitaly 팟에 주석을 추가할 수 있도록 합니다.

아래는 annotations의 사용 예시입니다:

annotations:
  kubernetes.io/example-annotation: annotation-value

priorityClassName

priorityClassName은 Gitaly 팟에 PriorityClass를 할당할 수 있도록 합니다.

아래는 priorityClassName의 사용 예시입니다:

priorityClassName: persistence-enabled

git.config

git.config는 Gitaly에서 생성된 모든 Git 명령어에 구성을 추가할 수 있게 해줍니다. 아래와 같이 key / value 쌍으로 구성된 설정을 git-config(1)에 문서화된 대로 허용합니다.

git:
  config:
    - key: "pack.threads"
      value: 4
    - key: "fsck.missingSpaceBeforeDate"
      value: ignore

cgroups

소모를 방지하기 위해, Gitaly는 작업 중인 저장소에 따라 Git 프로세스를 cgroup에 할당하기 위해 cgroups를 사용합니다. 각 cgroup은 메모리 및 CPU 한계를 가지고 있어 시스템 안정성을 보장하고 자원 포화 상태를 방지합니다.

Gitaly가 시작되기 전에 실행되는 initContainer는 root로 실행되어야 합니다. 이 컨테이너는 Gitaly가 cgroups를 관리할 수 있도록 권한을 설정합니다. 따라서, /sys/fs/cgroup에 쓰기 액세스 권한을 가지기 위해 파일 시스템에 볼륨을 마운트합니다.

과다 구독의 예

cgroups:
  enabled: true
  # 모든 저장소 cgroups에 대한 총 한계
  memoryBytes: 64424509440 # 60GiB
  cpuShares: 1024
  cpuQuotaUs: 1200000 # 12 cores
  # 저장소별 한계, 1000 저장소 cgroups
  repositories:
    count: 1000
    memoryBytes: 32212254720 # 30GiB
    cpuShares: 512
    cpuQuotaUs: 400000 # 4 cores

External Services

이 차트는 Workhorse 서비스에 첨부되어야 합니다.

Workhorse

workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181

Chart settings

다음 값은 Gitaly Pods를 구성하는 데 사용됩니다.

Git Repository Persistence

이 차트는 PersistentVolumeClaim을 프로비저닝하고 Git 저장소 데이터를 위한 해당 지속 볼륨을 마운트합니다. 이를 위해 Kubernetes 클러스터 내에 물리적 저장소가 필요합니다. 대신 emptyDir를 사용하고 싶다면 PersistentVolumeClaim을 비활성화하십시오: persistence.enabled: false.

persistence:
  enabled: true
  storageClass: standard
  accessMode: ReadWriteOnce
  size: 50Gi
  matchLabels: {}
  matchExpressions: []
  subPath: "data"
  annotations: {}

Gitaly의 TLS 실행

참고: 이 섹션은 Helm 차트를 사용하여 클러스터 내에서 Gitaly를 실행하는 것과 관련이 있습니다. 외부 Gitaly 인스턴스를 사용하고 이를 통해 TLS로 통신하려는 경우 외부 Gitaly 문서를 참조하세요.

Gitaly는 다른 구성 요소와 TLS를 통해 통신하는 것을 지원합니다. 이는 global.gitaly.tls.enabled 및 global.gitaly.tls.secretName 설정에 의해 제어됩니다.

TLS를 통해 Gitaly를 실행하는 단계는 다음과 같습니다:

1. Helm 차트는 Gitaly와 TLS를 통해 통신하기 위해 제공할 인증서를 기대합니다. 이 인증서는 존재하는 모든 Gitaly 노드에 적용되어야 합니다. 따라서 이러한 Gitaly 노드 각각의 모든 호스트 이름은 인증서에 Subject Alternate Name(SAN)으로 추가되어야 합니다.

   사용해야 할 호스트 이름을 알기 위해서는 Toolbox 포드의 /srv/gitlab/config/gitlab.yml 파일을 확인하고, 그 안의 repositories.storages 키 아래에 지정된 다양한 gitaly_address 필드를 확인하세요.

   kubectl exec -it <Toolbox pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
   

참고: 내부 Gitaly 포드에 대한 사용자 서명 인증서를 생성하기 위한 기본 스크립트는 이 리포지토리에서 찾을 수 있습니다. 사용자는 적절한 SAN 속성으로 인증서를 생성하기 위해 해당 스크립트를 참조하거나 사용할 수 있습니다.

1. 생성된 인증서를 사용하여 k8s TLS 비밀을 생성합니다.

   kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key
   

2. --set global.gitaly.tls.enabled=true를 전달하여 Helm 차트를 다시 배포합니다.

전역 서버 후크

Gitaly StatefulSet은 전역 서버 후크를 지원합니다. 후크 스크립트는 Gitaly 포드에서 실행되므로 Gitaly 컨테이너에서 사용할 수 있는 도구로 제한됩니다.

후크는 ConfigMaps를 사용하여 채워지며, 적절한 값으로 설정하여 사용할 수 있습니다:

1. global.gitaly.hooks.preReceive.configmap
2. global.gitaly.hooks.postReceive.configmap
3. global.gitaly.hooks.update.configmap

ConfigMap을 채우기 위해 kubectl을 스크립트 디렉토리로 지정할 수 있습니다:

kubectl create configmap MAP_NAME --from-file /PATH/TO/SCRIPT/DIR

GitLab에서 생성된 커밋의 GPG 서명

Gitaly는 GitLab UI를 통해 생성된 모든 커밋을 GPG로 서명할 수 있는 기능이 있습니다. 예를 들어, WebIDE와 GitLab에 의해 생성된 커밋, 병합 커밋 및 스쿼시도 포함됩니다.

1. GPG 개인 키를 사용하여 k8s 비밀을 생성합니다.

   kubectl create secret generic gitaly-gpg-signing-key --from-file=signing_key=/path/to/gpg_signing_key.gpg
   

2. values.yaml에서 GPG 서명을 활성화합니다.

   gitlab:
     gitaly:
       gpgSigning:
         enabled: true
         secret: gitaly-gpg-signing-key
         key: signing_key
   

서버 측 백업

차트는 Gitaly 서버 측 백업을 지원합니다.

사용하려면:

1. 백업을 저장할 버킷을 생성합니다.

2. 객체 저장소 자격 증명 및 저장소 URL을 구성합니다.

   gitlab:
     gitaly:
       extraEnvFrom:
          # 예상되는 환경 변수에 기존 객체 저장소 비밀을 마운트합니다.
          AWS_ACCESS_KEY_ID:
            secretKeyRef:
              name: <Rails 객체 저장소 비밀>
              key: aws_access_key_id
          AWS_SECRET_ACCESS_KEY:
            secretKeyRef:
              name: <Rails 객체 저장소 비밀>
              key: aws_secret_access_key
       backup:
         # 이것은 Gitaly 서버 측 백업을 위한 연결 문자열입니다.
         goCloudUrl: <객체 저장소 연결 URL>
   

   객체 저장소 백엔드에 대한 예상 환경 변수 및 저장소 URL 형식은 Gitaly 문서를 참조하세요.

3. backup-utility로 서버 측 백업 활성화.