• 디자인 선택 사항
  • 필수
  • 선택적
• 구성
• 설치 매개변수
• 차트 구성 예시
  • pullSecrets
  • serviceAccount
  • tolerations
  • affinity
  • annotations
• 서브-차트 활성화
• image 구성
• service 구성
• ingress 구성
• TLS 구성
  • 디버그 포트용 TLS 구성
• networkpolicy 구성
  • 내부 엔드포인트 연결 방지 정책 예시
• KEDA 구성
  • 모든 내부 엔드포인트 연결 방지 정책 예시
• 레지스트리 구성 정의
  • httpSecret
  • Notification Secret
  • Redis 캐시 Secret
  • authEndpoint
  • certificate
  • readiness 및 liveness probe
  • validation
    • manifests
  • 통지
  • hpa
  • 저장
  • middleware.storage
    • keypairid 변수
  • 디버그
  • 헬스
  • 보고
  • 프로파일링
  • 데이터베이스
    • 데이터베이스 관리
  • gc 속성
  • Redis 캐시
    • 클러스터
    • Sentinel
    • Sentinel 비밀번호 지원
  • Redis rate-limiter
• Garbage Collection
  • 수동 가비지 수집
  • 컨테이너 레지스트리에 대한 관리 명령 실행

컨테이너 레지스트리 사용

registry 서브 차트는 쿠버네티스에서 완전한 클라우드 네이티브 GitLab 배포에 Registry 구성 요소를 제공합니다. 이 서브 차트는 상위 차트를 기반으로 하며 GitLab 컨테이너 레지스트리를 포함하고 있습니다.

이 차트는 3가지 핵심 부분으로 구성되어 있습니다:

• 서비스
• 배포
• 구성맵.

모든 구성은 /etc/docker/registry/config.yml 변수에 제공되며 Deployment에서 ConfigMap에서 제공된 값을 포함합니다. ConfigMap은 상위 기본값을 재정의하지만 그것들을 기반으로 합니다. 자세한 내용은 아래를 참조하십시오:

• distribution/cmd/registry/config-example.yml
• distribution-library-image/config-example.yml

디자인 선택 사항

이 차트에서는 이러한 차트의 배포 방법으로 쿠버네티스 Deployment를 선택하여 인스턴스의 간단한 스케일링을 허용하고 롤링 업데이트를 허용합니다.

이 차트는 두 가지 필수 시크릿과 하나의 선택적 시크릿을 사용합니다:

필수

• global.registry.certificate.secret: 해당 GitLab 인스턴스에서 제공된 인증 토큰을 확인하기 위한 공용 인증서 번들을 포함하는 글로벌 시크릿입니다. GitLab를 인증 엔드포인트로 사용하는 방법에 대해서는 문서를 참조하십시오.
• global.registry.httpSecret.secret: 레지스트리 파드 간에 사용되는 공유 시크릿을 포함하는 글로벌 시크릿입니다.

선택적

• profiling.stackdriver.credentials.secret: Stackdriver 프로파일링이 활성화되어 있고 명시적 서비스 계정 자격 증명을 제공해야 하는 경우 이 시크릿에 포함된 값(기본적으로 credentials 키)이 GCP 서비스 계정 JSON 자격 증명입니다. GKE를 사용하고 있는 경우 Workload Identity를 사용하여 워크로드에 서비스 계정을 제공하는 경우(권장되지는 않지만 노드 서비스 계정을 사용하는 경우), 이 시크릿은 필요하지 않으며 제공해서는 안 됩니다. 어느 경우에든 서비스 계정에는 roles/cloudprofiler.agent 역할 또는 동등한 수동 권한이 필요합니다.

구성

아래에서 구성의 모든 주요 섹션을 설명하겠습니다. 상위 차트에서 구성할 때 이러한 값은 다음과 같을 것입니다:

registry:
  enabled:
  maintenance:
    readonly:
      enabled: false
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
  image:
    tag: 'v4.10.0-gitlab'
    pullPolicy: IfNotPresent
  annotations:
  service:
    type: ClusterIP
    name: registry
  httpSecret:
    secret:
    key:
  authEndpoint:
  tokenIssuer:
  certificate:
    secret: gitlab-registry
    key: registry-auth.crt
  deployment:
    terminationGracePeriodSeconds: 30
  draintimeout: '0'
  hpa:
    minReplicas: 2
    maxReplicas: 10
    cpu:
      targetAverageUtilization: 75
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 300
  storage:
    secret:
    key: storage
    extraKey:
  validation:
    disabled: true
    manifests:
      referencelimit: 0
      payloadsizelimit: 0
      urls:
        allow: []
        deny: []
  notifications: {}
  tolerations: []
  affinity: {}
  ingress:
    enabled: false
    tls:
      enabled: true
      secretName: redis
    annotations:
    configureCertmanager:
    proxyReadTimeout:
    proxyBodySize:
    proxyBuffering:
  networkpolicy:
    enabled: false
    egress:
      enabled: false
      rules: []
    ingress:
      enabled: false
      rules: []
  serviceAccount:
    create: false
    automountServiceAccountToken: false
  tls:
    enabled: false
    secretName:
    verify: true
    caSecretName:

이 차트를 독립적으로 배포하려는 경우 최상위 레벨에서 registry를 제거하십시오.

설치 매개변수

차트 구성 예시

pullSecrets

pullSecrets를 사용하면 pod에서 이미지를 가져오기 위해 개인 레지스트리에 인증할 수 있습니다.

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

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

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

serviceAccount

이 섹션은 ServiceAccount를 생성하고 기본 액세스 토큰을 pod에 마운트해야 하는지 여부를 제어합니다.

tolerations

tolerations를 사용하면 오염된 워커 노드에 pod를 예약할 수 있습니다.

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

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

affinity

affinity는 선택 사항으로, 다음 중 하나 또는 둘 다를 설정할 수 있습니다:

• podAntiAffinity 규칙:
  • topology key와 일치하는 pod와 동일한 도메인에 pod를 예약하지 않습니다.
  • podAntiAffinity 규칙의 두 가지 모드를 설정합니다: required(requiredDuringSchedulingIgnoredDuringExecution) 및 preferred(preferredDuringSchedulingIgnoredDuringExecution). values.yaml에서 antiAffinity를 사용하여 설정을 soft로 지정하여 preferred 모드를 적용하거나 hard로 지정하여 required 모드를 적용합니다.
• nodeAffinity 규칙:
  • 특정 존에 속하는 노드에 pod를 예약합니다.
  • nodeAffinity 규칙의 두 가지 모드를 설정합니다: required(requiredDuringSchedulingIgnoredDuringExecution) 및 preferred(preferredDuringSchedulingIgnoredDuringExecution). soft로 설정하면 preferred 모드가 적용됩니다. hard로 설정하면 required 모드가 적용됩니다. 이 규칙은 registry 차트 및 gitlab 차트와 그 하위 차트인 webservice 및 sidekiq를 제외한 모든 서브차트에 대해서만 구현됩니다.

nodeAffinity는 In operator만 구현합니다.

더 자세한 내용은 관련 Kubernetes 문서를 참조하세요.

다음 예시는 nodeAffinity와 antiAffinity를 둘 다 hard로 설정한 것입니다:

nodeAffinity: "hard"
antiAffinity: "hard"
affinity:
  nodeAffinity:
    key: "test.com/zone"
    values:
    - us-east1-a
    - us-east1-b
  podAntiAffinity:
    topologyKey: "test.com/hostname"

annotations

annotations를 사용하면 레지스트리 pod에 주석을 추가할 수 있습니다.

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

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

서브-차트 활성화

우리가 선택한 구현된 칸막이 서브-차트는 특정 배포에서 원하지 않는 구성 요소를 비활성화할 수 있는 기능을 포함합니다. 따라서, 먼저 결정해야 하는 첫 번째 설정은 enabled입니다.

기본적으로 레지스트리는 기본적으로 활성화되어 있습니다. 비활성화하려면 enabled: false로 설정하세요.

image 구성

이 섹션은 이 서브-차트의 배포에서 사용되는 컨테이너 이미지의 설정을 자세히 설명합니다. 레지스트리 및 pullPolicy의 모든 포함된 버전을 변경할 수 있습니다.

기본 설정:

• tag: 'v4.10.0-gitlab'
• pullPolicy: 'IfNotPresent'

service 구성

이 섹션은 Service의 이름과 유형을 제어합니다. 이러한 설정은 values.yaml에 의해 채워집니다.

기본적으로 Service는 다음과 같이 구성됩니다:

ingress 구성

이 섹션은 레지스트리 Ingress를 제어합니다.

TLS 구성

컨테이너 레지스트리는 다른 구성 요소와의 통신을 보호하는 TLS를 지원하며, 이에는 nginx-ingress가 포함됩니다.

TLS를 구성하기 위한 사전 요구 사항:

• TLS 인증서에는 레지스트리 서비스 호스트 이름 (예: RELEASE-registry.default.svc)이 공용 이름 (CN) 또는 대체 이름 (SAN)에 포함되어야 합니다.
• TLS 인증서를 생성한 후:
  • Kubernetes TLS Secret를 생성합니다.
  • TLS 인증서의 CA 인증서만을 포함하는 다른 Secret을 ca.crt 키로 생성합니다.

TLS를 활성화하려면:

1. registry.tls.enabled를 true로 설정합니다.
2. global.hosts.registry.protocol를 https로 설정합니다.
3. registry.tls.secretName 및 global.certificates.customCAs에 Secret 이름을 전달합니다.

registry.tls.verify가 true일 때, CA 인증서 Secret 이름을 registry.tls.caSecretName에 전달해야 합니다. 이것은 자체 서명된 인증서 및 사용자 정의 인증 기관에 필요합니다. 이 Secret은 레지스트리의 TLS 인증서를 NGINX가 확인하는 데 사용됩니다.

예:

global:
  certificates:
    customCAs:
    - secret: registry-tls-ca
  hosts:
    registry:
      protocol: https

registry:
  tls:
    enabled: true
    secretName: registry-tls
    verify: true
    caSecretName: registry-tls-ca

디버그 포트용 TLS 구성

레지스트리 디버그 포트도 TLS를 지원합니다. 디버그 포트는 Kubernetes 라이브니스 및 준비성 확인 및 Prometheus의 /metrics 엔드포인트 노출에 사용됩니다.

TLS를 활성화하려면 registry.debug.tls.enabled를 true로 설정합니다. 디버그 포트의 TLS 구성에 사용할 Kubernetes TLS Secret 을 지정할 수 있습니다. 별도의 Secret이 지정되지 않으면 디버그 구성은 레지스트리의 일반 TLS 구성인 registry.tls.secretName을 공유하게 됩니다.

Prometheus가 https를 사용하여 /metrics/ 엔드포인트를 스크랩하기 위해 인증서의 공용 이름 속성 또는 대체 이름 항목에 대한 추가 구성이 필요합니다. 자세한 내용은 Prometheus에 TLS 활성 엔드포인트 스크랩 구성 을 참조하세요.

networkpolicy 구성

이 섹션은 레지스트리의 NetworkPolicy 를 제어합니다. 이 구성은 선택 사항이며, 레지스트리의 Egress 및 Ingress를 특정 엔드포인트로 제한하는 데 사용됩니다.

내부 엔드포인트 연결 방지 정책 예시

레지스트리 서비스는 일반적으로 객체 저장소로의 egress 연결, Docker 클라이언트로부터의 ingress 연결 및 DNS 조회를 위해 kube-dns에 대한 egress 연결을 필요로 합니다. 이에 따라 레지스트리 서비스에 다음과 같은 네트워크 제한이 추가됩니다:

• 로컬 네트워크 10.0.0.0/8 포트 53으로의 모든 egress 요청이 허용됨 (kubeDNS용)
• 기타 10.0.0.0/8의 로컬 네트워크로의 egress 요청이 제한됨
• 10.0.0.0/8 외부로의 egress 요청이 허용됨

또한 레지스트리 서비스는 외부 객체 저장소에 있는 이미지를 위해 공용 인터넷에 대한 아웃바운드 연결이 필요합니다.

networkpolicy:
  enabled: true
  egress:
    enabled: true
    # 아래 규칙은 로컬 외의 모든 외부 엔드포인트로의 트래픽을 허용하지만,
    # 로컬 네트워크로의 트래픽 (DNS 요청 제외)을 제한합니다
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

KEDA 구성

이 keda 섹션은 일반적인 HorizontalPodAutoscalers 대신 KEDA ScaledObjects의 설치를 활성화합니다. 이 구성은 선택 사항이며, 사용자 지정 또는 외부 메트릭에 기반한 오토스케일링이 필요한 경우에 사용할 수 있습니다.

대부분의 설정은 해당되는 경우 hpa 섹션에 설정된 값들을 기본값으로 합니다.

다음이 모두 참이면 CPU 및 메모리 트리거는 자동으로 추가됩니다. 설정된 CPU 및 메모리 임계값에 기초하여 CPU 및 메모리 트리거가 추가됩니다:

• triggers이 설정되지 않은 경우
• 해당하는 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정되어 있는 경우

트리거가 설정되지 않은 경우, ScaledObject는 생성되지 않습니다.

이 설정에 대한 자세한 내용은 KEDA documentation를 참조하세요.

모든 내부 엔드포인트 연결 방지 정책 예시

레지스트리 서비스는 일반적으로 오브젝트 스토리지로의 이그레스 연결, 도커 클라이언트로부터의 인그레스 연결, DNS 조회를 위한 kube-dns 연결이 필요합니다.
이로 인해 레지스트리 서비스에 다음과 같은 네트워크 제한이 추가됩니다:

• 지역 네트워크의 10.0.0.0/8 포트 53으로의 이그레스 요청은 모두 허용됩니다 (kubeDNS용)
• 다른 지역 네트워크인 10.0.0.0/8로의 이그레스 요청은 제한됩니다
• 10.0.0.0/8 외부로의 이그레스 요청은 모두 허용됩니다

레지스트리 서비스는 외부 오브젝트 스토리지에 있는 이미지를 위해 공개 인터넷과의 아웃바운드 연결성이 필요합니다

networkpolicy:
  enabled: true
  egress:
    enabled: true
    # 다음 규칙은 로컬을 제외한 모든 외부 엔드포인트로의 트래픽을 허용합니다
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
        - port: 53
          protocol: UDP
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
            - 10.0.0.0/8

레지스트리 구성 정의

이 차트의 다음 속성들은 기본 레지스트리 컨테이너의 구성에 관련됩니다. GitLab과의 통합을 위해 가장 중요한 값들만 노출되었습니다. 이 통합을 위해 Docker Distribution의 auth.token.x 설정을 사용합니다. 이 설정은 레지스트리에 대한 JWT 인증 토큰을 통제합니다.

httpSecret

httpSecret 필드는 secret와 key 두 항목을 담고 있는 맵입니다.

이 링크는 레지스트리의 http.secret 값과 관련이 있습니다. 이 값은 암호화된 무작위 문자열로 채워져야 합니다.

shared-secrets 작업은 수동으로 제공되지 않을 경우 이 secret을 자동으로 생성합니다. 이 secret은 보안적으로 생성된 128자 알파벳 숫자 문자열을 base64로 인코딩합니다.

이 secret을 수동으로 생성하려면:

kubectl create secret generic gitlab-registry-httpsecret --from-literal=secret=strongrandomstring

Notification Secret

Notification Secret은 기존의 GitLab 애플리케이션으로 다양한 방식으로 되돌아가는 데 사용되며, 예를 들어 Geo에서 주(primary) 사이트와 보조(secondary) 사이트 간 컨테이너 레지스트리 데이터 동기화를 관리하는 데 도움이 됩니다.

notificationSecret secret 객체는 shared-secrets 기능이 활성화된 경우 자동으로 생성됩니다.

이 secret을 수동으로 생성하려면:

kubectl create secret generic gitlab-registry-notification --from-literal=secret=[\"strongrandomstring\"]

그런 다음 다음을 설정하십시오

global:
  # 사용자 지정 secret을 제공하려면
  registry:
    notificationSecret:
        secret: gitlab-registry-notification
        key: secret

  # Geo를 사용하고 기본 저장소를 동기화하려는 경우
  # 이것을 기본 사이트 설정에 정의합니다.
  geo:
    registry:
      replication:
        enabled: true
        primaryApiUrl: <주(primary) 레지스트리로의 URL>

secret 값이 위에 생성된 secret 이름으로 설정되었는지 확인하십시오

Redis 캐시 Secret

Redis 캐시 Secret은 global.redis.auth.enabled가 true로 설정된 경우 사용됩니다.

shared-secrets 기능이 활성화된 경우, 이 gitlab-redis-secret secret 객체는 수동으로 제공되지 않을 경우 자동으로 생성됩니다.

이 secret을 수동으로 생성하려면 Redis 패스워드 설명서를 참조하십시오.

authEndpoint

authEndpoint 필드는 레지스트리가 인증을 위해 GitLab 인스턴스들에 요청하는 URL을 제공하는 문자열입니다.

이 값은 프로토콜과 호스트명만 포함해야 합니다. 차트 템플릿은 필요한 요청 경로를 자동으로 추가합니다. 결과적인 값은 컨테이너 내부의 auth.token.realm에 채워집니다. 예를 들어: authEndpoint: "https://gitlab.example.com"

기본적으로 이 필드는 Global Settings에서 설정된 GitLab 호스트명 구성과 일치합니다.

certificate

certificate 필드는 secret와 key 두 항목을 담고 있는 맵입니다.

secret은 해당하는 Kubernetes Secret의 이름을 담고 있는 문자열이며, 이 Secret은 GitLab 인스턴스에 의해 생성된 토큰을 확인하는 데 사용될 인증서 번들을 포함합니다.

key는 Secret 내의 인증서 번들이 레지스트리 컨테이너에 auth.token.rootcertbundle로 제공될 이름입니다.

기본 예시:

certificate:
  secret: gitlab-registry
  key: registry-auth.crt

readiness 및 liveness probe

기본적으로 /debug/health 경로와 5001 포트에서 디버그를 확인하는 readiness 및 livenes probe가 구성됩니다.

validation

validation 필드는 레지스트리에서 도커 이미지 유효성 검사 과정을 제어하는 맵입니다. 이미지 유효성 검사가 활성화되면 레지스트리는 외부 레이어를 포함한 Windows 이미지를 거부합니다. 유효성 검사는 manifest push 중에만 발생하므로 레지스트리에 이미 존재하는 이미지는 이 항목의 값이 변경되더라도 영향을 받지 않습니다.

이미지 유효성 검사는 기본적으로 비활성화되어 있습니다.

이미지 유효성 검사를 사용하려면 명시적으로 registry.validation.disabled: false를 설정해야 합니다.

manifests

manifests 필드는 manifest에 관련된 유효성 정책을 특정할 수 있도록 합니다.

urls 섹션은 유효성을 확인할 manifest 레이어들을 포함합니다.

urls.allow 및 urls.deny 필드는 유효성을 검사할 레이어의 URL을 활성화하고, 거부할 정규 표현식 목록입니다. 여기에 정의되지 않은 레이어는 거부됩니다.

통지

notifications 필드는 Registry notifications를 구성하는 데 사용됩니다. 기본값으로 빈 해시가 있습니다.

예제 설정은 다음과 같이 보일 것입니다:

notifications:
  endpoints:
    - name: FooListener
      url: https://foolistener.com/event
      timeout: 500ms
      # DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243.
      # When using `maxretries`, `threshold` is ignored: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints
      threshold: 10
      maxretries: 10
      backoff: 1s
    - name: BarListener
      url: https://barlistener.com/event
      timeout: 100ms
      # DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243.
      # When using `maxretries`, `threshold` is ignored: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints
      threshold: 3
      maxretries: 5
      backoff: 1s
  events:
    includereferences: true

hpa

hpa 필드는 registry의 일부로 생성할 레지스트리 인스턴스 수를 제어하는 객체입니다. 이는 minReplicas 값이 기본값으로 2, maxReplicas 값이 10이며 cpu.targetAverageUtilization이 75%로 구성됩니다.

저장

storage:
  secret:
  key: config
  extraKey:

storage 필드는 쿠버네티스 시크릿 및 해당 키에 대한 참조입니다. 이 비밀의 내용은 Registry Configuration: storage에서 직접 가져옵니다. 자세한 내용은 해당 설명서를 참조하십시오.

AWS s3 및 Google GCS 드라이버에 대한 예제는 examples/objectstorage에서 찾을 수 있습니다:

• registry.s3.yaml
• registry.gcs.yaml

S3를 사용하는 경우 저장소 저장을 위한 올바른 권한을 부여해야 합니다. 저장 구성에 대한 자세한 내용은 관리 문서의 컨테이너 레지스트리 저장소 드라이버를 참조하십시오.

시크릿의 _내용_을 시크릿에 넣고 다음을 storage 맵의 아이템으로 제공하십시오:

• secret: YAML 블록을 수용하는 쿠버네티스 시크릿의 이름.
• key: 시크릿에서 사용할 키의 이름. 기본값은 config입니다.
• extraKey: (선택 사항) 시크릿의 추가 키의 이름으로, 이는 컨테이너 내의 /etc/docker/registry/storage/${extraKey}에 마운트됩니다. 이를 사용하여 gcs 드라이버의 keyfile을 제공할 수 있습니다.

# S3를 사용하는 예제
kubectl create secret generic registry-storage \
    --from-file=config=registry-storage.yaml

# JSON 키와 함께 GCS를 사용하는 예제
# - 참고: `registry.storage.extraKey=gcs.json`
kubectl create secret generic registry-storage \
    --from-file=config=registry-storage.yaml \
    --from-file=gcs.json=example-project-382839-gcs-bucket.json

저장 드라이버의 리디렉션을 해제할 수 있습니다. 이렇게 하면 모든 트래픽이 다른 백엔드로 리디렉팅되지 않고 레지스트리 서비스를 통해 흐르게 됩니다:

storage:
  secret: example-secret
  key: config
  redirect:
    disable: true

파일 시스템 드라이버를 사용하는 경우:

• 해당 데이터에 대한 지속적인 볼륨을 제공해야 합니다.
• hpa.minReplicas를 1로 설정해야 합니다.
• hpa.maxReplicas를 1로 설정해야 합니다.

신뢰성 및 간소화를 위해 s3, gcs, azure 또는 기타 호환되는 Object Storage와 같은 외부 서비스를 활용하는 것이 좋습니다.

참고: 이 차트는 사용자가 명시하지 않은 경우 기본적으로 delete.enabled: true을 이 구성으로 채웁니다. 이를 통해 MinIO의 기본 사용 및 Linux 패키지의 예상된 동작을 유지할 수 있습니다. 모든 사용자 제공 값은 이 기본값을 덮어씁니다.

middleware.storage

middleware.storage 구성은 업스트림 규약을 따릅니다:

구성은 꽤 범용적이며 비슷한 패턴을 따릅니다:

middleware:
  # See https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware
  storage:
    - name: cloudfront
      options:
        baseurl: https://abcdefghijklmn.cloudfront.net/
        # `privatekey` is auto-populated with the content from the privatekey Secret.
        privatekeySecret:
          secret: cloudfront-secret-name
          # "key" value is going to be used to generate filename for PEM storage:
          #   /etc/docker/registry/middleware.storage/<index>/<key>
          key: private-key-ABC.pem
        keypairid: ABCEDFGHIJKLMNOPQRST

위의 코드에서, options.privatekeySecret는 PEM 파일 내용에 해당하는 generic 쿠버네티스 시크릿의 내용입니다:

kubectl create secret generic cloudfront-secret-name --type=kubernetes.io/ssh-auth --from-file=private-key-ABC.pem=pk-ABCEDFGHIJKLMNOPQRST.pem

상기에서 사용한 privatekey는 차트에 의해 프라이빗 키 시크릿의 내용이 자동으로 채워지며 명시된 경우 무시될 것입니다.

keypairid 변수

여러 벤더들은 동일한 구성을 위해 다른 필드 이름을 사용합니다:

참고: 현재 middleware.storage 섹션의 구성만 지원됩니다.

디버그

디버그 포트는 기본적으로 활성화되며 라이브/준비 상태를 확인하는 데 사용됩니다. 또한 프로메테우스 메트릭을 metrics 값을 통해 활성화할 수 있습니다.

debug:
  addr:
    port: 5001

metrics:
  enabled: true

헬스

health 속성은 선택 사항이며, 주기적인 헬스 체크를 위한 우선순위를 포함합니다. 자세한 내용은 Docker의 [구성 문서]를 참조하세요(https://distribution.github.io/distribution/about/configuration/#health).

health:
  storagedriver:
    enabled: false
    interval: 10s
    threshold: 3

보고

reporting 속성은 선택 사항이며 보고를 활성화합니다.

reporting:
  sentry:
    enabled: true
    dsn: 'https://<key>@sentry.io/<project>'
    environment: 'production'

프로파일링

profiling 속성은 선택 사항이며 지속적인 프로파일링을 활성화합니다.

profiling:
  stackdriver:
    enabled: true
    credentials:
      secret: gitlab-registry-profiling-creds
      key: credentials
    service: gitlab-registry

데이터베이스

• GitLab 16.4에 도입된 베타 기능입니다.
• GitLab 17.3에서 일반적으로 사용 가능해집니다.

database 속성은 선택 사항이며 메타데이터 데이터베이스를 활성화합니다.

이 기능을 활성화하기 전에 관리 문서를 확인하세요.

참고: 이 기능은 PostgreSQL 12 이상이 필요합니다.

database:
  enabled: true
  host: registry.db.example.com
  port: 5432
  user: registry
  password:
    secret: gitlab-postgresql-password
    key: postgresql-registry-password
  dbname: registry
  sslmode: verify-full
  ssl:
    secret: gitlab-registry-postgresql-ssl
    clientKey: client-key.pem
    clientCertificate: client-cert.pem
    serverCA: server-ca.pem
  connecttimeout: 5s
  draintimeout: 2m
  preparedstatements: false
  primary: 'primary.record.fqdn'
  pool:
    maxidle: 25
    maxopen: 25
    maxlifetime: 5m
    maxidletime: 5m
  migrations:
    enabled: true
    activeDeadlineSeconds: 3600
    backoffLimit: 6
  backgroundMigrations:
    enabled: true
    maxJobRetries: 3
    jobInterval: 10s

데이터베이스 관리

데이터베이스 생성에 관한 자세한 내용은 컨테이너 레지스트리 메타데이터 데이터베이스 페이지를 참조하세요.

gc 속성

gc 속성은 온라인 가비지 수집 옵션을 제공합니다.

온라인 가비지 수집에는 메타데이터 데이터베이스가 필요합니다. 데이터베이스를 사용할 때 온라인 가비지 수집을 사용해야 하지만, 유지보수 및 디버깅을 위해 일시적으로 비활성화할 수 있습니다.

gc:
  disabled: false
  maxbackoff: 24h
  noidlebackoff: false
  transactiontimeout: 10s
  reviewafter: 24h
  manifests:
    disabled: false
    interval: 5s
  blobs:
    disabled: false
    interval: 5s
    storagetimeout: 5s

Redis 캐시

참고: Redis 캐시는 16.4 버전 이후의 베타 기능입니다. 이 기능을 활성화하기 전에 피드백 이슈 및 관련 문서를 검토하세요.

redis.cache 속성은 선택 사항이며 Redis 캐시와 관련된 옵션을 제공합니다. 레지스트리에서 redis.cache를 사용하려면 메타데이터 데이터베이스가 활성화되어 있어야 합니다.

예시:

redis:
  cache:
    enabled: true
    host: localhost
    port: 16379
    password:
      secret: gitlab-redis-secret
      key: redis-password
    db: 0
    dialtimeout: 10ms
    readtimeout: 10ms
    writetimeout: 10ms
    tls:
      enabled: true
      insecure: true
    pool:
      size: 10
      maxlifetime: 1h
      idletimeout: 300s

클러스터

redis.rateLimiting.cluster 속성은 Redis 클러스터에 연결하기 위한 호스트와 포트의 목록입니다. 예시:

redis:
  cache:
    enabled: true
    host: redis.example.com
    cluster:
      - host: host1.example.com
        port: 6379
      - host: host2.example.com
        port: 6379

Sentinel

redis.cache는 global.redis.sentinels 구성을 사용할 수 있습니다. 로컬 값은 전역 값보다 우선시됩니다. 예시:

redis:
  cache:
    enabled: true
    host: redis.example.com
    sentinels:
      - host: sentinel1.example.com
        port: 16379
      - host: sentinel2.example.com
        port: 16379

Sentinel 비밀번호 지원

• GitLab 17.2에서 도입된 기능입니다.

redis.cache는 또한 Redis Sentinel의 인증 비밀번호를 사용하기 위해global.redis.sentinelAuth 구성을 사용할 수 있습니다. 로컬 값은 전역 값보다 우선시됩니다. 예시:

redis:
  cache:
    enabled: true
    host: redis.example.com
    sentinels:
      - host: sentinel1.example.com
        port: 16379
      - host: sentinel2.example.com
        port: 16379
    sentinelpassword:
      enabled: true
      secret: registry-redis-sentinel
      key: password

Redis rate-limiter

경고: Redis rate-limiting은 개발 중입니다. 추가 기능 세부 정보가 이용 가능해지는 대로 이 섹션에 추가될 것입니다.

redis.rateLimiting 속성은 선택 사항이며 Redis rate-limiter에 관련된 옵션을 제공합니다.

예시:

redis:
  rateLimiting:
    enabled: true
    host: localhost
    port: 16379
    username: registry
    password:
      secret: gitlab-redis-secret
      key: redis-password
    db: 0
    dialtimeout: 10ms
    readtimeout: 10ms
    writetimeout: 10ms
    tls:
      enabled: true
      insecure: true
    pool:
      size: 10
      maxlifetime: 1h
      idletimeout: 300s

Garbage Collection

Docker 레지스트리는 시간이 지남에 따라 쓸데없는 데이터가 축적될 수 있으며 이는 garbage collection을 사용하여 해제할 수 있습니다. 현재로서는 이 차트를 사용하여 가비지 수집을 완전히 자동화하거나 예약된 방식으로 실행할 수 있는 방법이 없습니다.

경고: 메타데이터 데이터베이스를 사용하여 온라인 가비지 수집을 해야 합니다. 메타데이터 데이터베이스에 대해 수동 가비지 수집을 사용하면 데이터 손실이 발생합니다. 온라인 가비지 수집은 수동 가비지 수집을 완전히 대체합니다.

수동 가비지 수집

수동 가비지 수집을 위해서는 레지스트리가 먼저 읽기 전용 모드여야 합니다. Helm을 사용하여 GitLab 차트를 이미 설치하고 mygitlab이라는 이름을 지정하고 gitlabns 네임스페이스에 설치했다고 가정해 봅시다. 아래의 명령어에서 실제 구성에 따라 이 값들을 대체하세요.

# https://github.com/helm/helm/issues/2948로 인해 --reuse-values에 의존할 수 없으므로 현재 구성을 가져옵시다.
helm get values mygitlab > mygitlab.yml
# Helm 설치를 업그레이드하고 레지스트리를 읽기 전용으로 구성합니다.
# --wait 매개변수는 모든 리소스가 준비 상태로 될 때까지 기다리도록 하므로 계속 진행해도 안전합니다.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --set registry.maintenance.readonly.enabled=true --wait
# 이제 우리의 레지스트리는 읽기 전용 모드입니다. 그래서 레지스트리 pod 중 하나의 이름을 얻어봅시다.
# '<registry-pod>' 플레이스홀더를 그 값으로 대체하고 실제로 사용 중인 경우 Windows' cmd.exe에서는 홑따옴표를 쌍따옴표로 바꾸세요.
kubectl get pods -n gitlabns -l app=registry -o jsonpath='{.items[0].metadata.name}'
# 실제 가비지 수집을 실행합니다. 정말 '-m' 매개변수가 필요한 경우 레지스트리의 메뉴얼을 확인하세요.
kubectl exec -n gitlabns <registry-pod> -- /bin/registry garbage-collect -m /etc/docker/registry/config.yml
# 레지스트리를 원래 상태로 되돌립니다.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --wait
# 모두 끝 :)

컨테이너 레지스트리에 대한 관리 명령 실행

관리 명령은 registry 이진 파일과 필요한 구성 모두 사용 가능한 레지스트리 pod에서만 실행할 수 있습니다. 이슈 #2629은 이 기능을 toolbox pod에서 제공하는 방법을 논의하기 위해 열려 있습니다.

관리 명령 실행:

1. 레지스트리 pod에 연결합니다.

   kubectl exec -it <registry-pod> -- bash
   

2. 레지스트리 pod 내부로 진입하면 registry 이진 파일을 PATH에 사용할 수 있으며 직접 사용할 수 있습니다. 구성 파일은 /etc/docker/registry/config.yml에서 사용할 수 있습니다. 다음 예제는 데이터베이스 마이그레이션 상태를 확인합니다.

   registry database migrate status /etc/docker/registry/config.yml
   

자세한 내용 및 사용 가능한 기타 명령에 대해서는 관련 문서를 참조하세요:

• 일반 레지스트리 문서
• GitLab 특정 레지스트리 문서