• 요구 사항
• 설계 선택 사항
• 구성
  • 설치 명령줄 옵션
• 차트 구성 예시
  • 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 명령에 구성을 추가할 수 있습니다. 아래와 같이 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 파드를 구성하는 데 사용됩니다.

Git 리포지터리 지속성

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

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

Gitaly를 TLS로 실행하기

Gitaly는 다른 컴포넌트와의 통신을 TLS로 지원합니다. 이는 global.gitaly.tls.enabled 및 global.gitaly.tls.secretName 설정으로 제어됩니다. Gitaly를 TLS로 실행하려면 다음 단계를 따르세요:

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

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

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

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 컨테이너에서 사용 가능한 도구로 제한됩니다.

적절한 값을 설정하여 사용하기 위해 다음과 같은 값들을 설정할 수 있습니다:

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는 대시보드, WebIDE 등 GitLab UI를 통해 생성된 모든 커밋 및 Merge 커밋 및 스쿼시와 같은 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