• 요구 사항
• 디자인 선택 사항
• 구성
  • 설치 명령줄 옵션
• 차트 구성 예시
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • serviceAccount
  • tolerations
  • affinity
  • annotations
  • priorityClassName
  • git.config
  • cgroups
• 외부 서비스
  • Workhorse
• 차트 설정
  • Git 저장소 지속성
  • TLS로 Gitaly 실행
  • 전역 서버 후크
  • GitLab에서 생성된 커밋에 GPG 서명 추가하기
  • 서버 측 백업

GitLab-Gitaly 차트 사용하기

gitaly 하위 차트는 구성 가능한 Gitaly 서버의 배포를 제공합니다.

요구 사항

이 차트는 완전한 GitLab 차트의 일부로서 또는 이 차트가 배포된 Kubernetes 클러스터에서 접근 가능한 외부 서비스로 제공되는 Workhorse 서비스에 의존합니다.

디자인 선택 사항

이 차트에서 사용되는 Gitaly 컨테이너에는 아직 Gitaly로 이관되지 않은 Git 리포지토리에서 작업을 수행하기 위해 GitLab Shell 코드베이스가 포함되어 있습니다. Gitaly 컨테이너에는 GitLab Shell 컨테이너의 사본이 포함되어 있으며, 이에 따라 이 차트 내에서 GitLab Shell을 구성해야 합니다.

구성

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

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

설치 명령줄 옵션

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

(이하 생략)

차트 구성 예시

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
      # optional: boolean
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

image.pullSecrets

pullSecrets를 사용하면 파드에서 이미지를 끌어오기 위해 개인 레지스트리에 대한 인증을 할 수 있습니다.

개인 레지스트리 및 해당 인증 방법에 대한 자세한 내용은 Kubernetes documentation에서 확인할 수 있습니다.

아래는 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 명령에 구성을 추가할 수 있습니다. 아래에서 git-config(1)에서 문서화된 대로 설정을 허용합니다.

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

cgroups

Gitaly는 고갈을 방지하기 위해 각 cgroup에 메모리 및 CPU 제한이 있는 cgroups를 사용하여 리포지토리 별로 운영되는 Git 프로세스를 cgroup에 할당합니다. 각 cgroup에는 시스템 안정성을 보장하고 리소스 포화를 방지하기 위한 메모리 및 CPU 제한이 있습니다.

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

과다 등록 예시

cgroups:
  enabled: true
  # 모든 리포지토리 cgroup을 통한 총 제한
  memoryBytes: 64424509440 # 60GiB
  cpuShares: 1024
  cpuQuotaUs: 1200000 # 12 cores
  # 리포지토리 당 제한, 1000개 리포지토리 cgroups
  repositories:
    count: 1000
    memoryBytes: 32212254720 # 30GiB
    cpuShares: 512
    cpuQuotaUs: 400000 # 4 cores

외부 서비스

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

Workhorse

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

차트 설정

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

참고: Gitaly는 Workhorse 및 Sidekiq와 인증하는 데 사용되는 Auth Token을 사용합니다. Auth Token 시크릿 및 키는 global.gitaly.authToken 값을 소스로 사용합니다. 추가로, Gitaly 컨테이너에는 일부 구성이 가능한 GitLab Shell의 복사본이 있습니다. Shell authToken은 global.shell.authToken 값에서 소스됩니다.

Git 저장소 지속성

이 차트는 Git 저장소 데이터를 위해 PersistentVolumeClaim을 생성하고 해당 지속적인 볼륨을 마운트합니다. 이 작업을 수행하려면 Kubernetes 클러스터에 물리적 스토리지가 있어야 합니다. 또한, emptyDir를 사용하려면 PersistentVolumeClaim를 비활성화하세요: persistence.enabled: false.

참고: Gitaly의 지속성 설정은 모든 Gitaly pod에 대해 유효해야 하는 volumeClaimTemplate에서 사용됩니다. 단일 특정 volume을 참조하도록 의도된 설정(volumeName과 같은)을 포함해서는 않습니다. 특정 volume을 참조하려면 PersistentVolumeClaim를 수동으로 생성해야 합니다.

참고: 배포한 후에는 이러한 설정을 변경할 수 없습니다. StatefulSet에서 VolumeClaimTemplate은 변경할 수 없습니다.

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

TLS로 Gitaly 실행

참고: 이 섹션은 Helm 차트를 사용하여 클러스터 내부에서 Gitaly를 실행하는 경우를 가리킵니다. 클러스터 외부 Gitaly 인스턴스를 사용하고 해당 통신에 TLS를 사용하려면 외부 Gitaly 문서를 참조하세요.

Gitaly는 TLS를 통해 다른 구성 요소와 통신하는 것을 지원합니다. 이는 global.gitaly.tls.enabled 및 global.gitaly.tls.secretName 설정에 의해 제어됩니다. TLS로 Gitaly를 실행하는 단계는 다음과 같습니다:

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

   사용할 호스트명을 알아내려면 /srv/gitlab/config/gitlab.yml 파일을 확인하고 그 안에 있는 repositories.storages 키 하위에 지정된 다양한 gitaly_address 필드를 확인하세요.

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

참고: 내부 Gitaly pod에 대한 사용자 정의 서명 인증서를 생성하는 데 사용할 수 있는 기본 스크립트는 이 리포지토리에서 찾을 수 있습니다. 사용자는 해당 스크립트를 사용하거나 참조하여 올바른 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은 전역 서버 후크(Global server hooks)를 지원합니다. 후크 스크립트는 Gitaly pod에서 실행되며, 따라서 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나 병합 커밋, 스쿼시(commit)와 같이 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’를 사용하여 서버 측 백업 활성화하기.