• 요구 사항
• 설계 선택 사항
• 구성
  • 설치 명령 줄 옵션
• 차트 구성 예시
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
  • tolerations
  • annotations
  • priorityClassName
  • git.config
• 외부 서비스
  • Workhorse
• 차트 설정
  • Git 저장소 지속성
  • 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 문서에서 설명된 대로 수행해야 합니다.

설치 명령 줄 옵션

아래 표에는 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 문서에서 확인할 수 있습니다.

아래는 pullSecrets 사용 예시입니다

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

tolerations

tolerations를 사용하면 색정된 워커 노드에 파드를 스케줄링할 수 있습니다.

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

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

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)의 문서화된 구성을 key / value 쌍으로 허용합니다.

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

외부 서비스

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

Workhorse

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

차트 설정

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

참고: Gitaly는 Workhorse 및 Sidekiq 서비스와 인증하는 데 사용할 Auth 토큰을 사용합니다. Auth 토큰 비밀 및 키는 global.gitaly.authToken 값에서 소스가 됩니다. 추가로, Gitaly 컨테이너에는 일부 구성을 설정할 수 있는 GitLab Shell의 사본이 있습니다. Shell authToken는 global.shell.authToken 값에서 소스가 됩니다.

Git 저장소 지속성

이 차트는 Git 저장소 데이터에 대한 PersistentVolumeClaim를 준비하고 해당 지속적인 볼륨을 마운트합니다. 이 작동하려면 쿠버네티스 클러스터에 물리적 저장소가 필요합니다. 만약 emptyDir를 사용하길 원한다면 PersistentVolumeClaim을 비활성화하세요. persistence.enabled: false로.

참고: Gitaly의 지속성 설정은 volumeClaimTemplate에 사용됩니다. 모든 Gitaly 파드에서 유효해야 하는 volumeClaimTemplate입니다. 단일 특정 볼륨을 참조하는 설정(예: volumeName)은 포함해서는 안 됩니다. 특정 볼륨을 참조하려면 PersistentVolumeClaim를 수동으로 생성해야 합니다.

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

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 노드의 모든 호스트명은 인증서의 대체 이름(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(예: WebIDE)를 통해 생성된 모든 커밋 및 병합 커밋 및 스쿼시와 같은 GitLab에 의해 생성된 커밋에 대해 GPG 서명을 할 수 있습니다.

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