• 디자인 선택
  • 필수
  • 선택적
• 구성
• 설치 매개변수
• 차트 구성 예시
  • pullSecrets
  • serviceAccount
  • tolerations
  • affinity
  • 주석
• 서브 차트 활성화
• image 구성
• service 구성
• ingress 구성
• TLS 구성
  • 디버그 포트를 위한 TLS 구성
• networkpolicy 구성
  • 모든 내부 엔드포인트에 대한 연결 방지를 위한 정책 예시
• KEDA 구성하기
  • 모든 내부 엔드포인트에 대한 연결을 방지하기 위한 정책 예시
• Registry 구성 정의
  • httpSecret
  • 알림 비밀
  • Redis 캐시 비밀
  • authEndpoint
  • certificate
  • readiness and liveness probe
  • validation
    • manifests
  • 알림
  • hpa
  • 저장소
  • middleware.storage
    • keypairid 변형
  • debug
  • health
  • reporting
  • profiling
  • database
    • 데이터베이스 관리
  • gc 속성
  • Redis 캐시
    • 클러스터
    • 센티넬
    • 센티넬 비밀번호 지원
  • Redis 속도 제한기
• 가비지 수집
  • 수동 가비지 수집
  • 컨테이너 레지스트리에 대한 관리 명령 실행

컨테이너 레지스트리 사용하기

registry 서브 차트는 Kubernetes에서 전체 클라우드 네이티브 GitLab 배포를 위한 레지스트리 컴포넌트를 제공합니다. 이 서브 차트는
업스트림 차트를 기반으로 하며, GitLab 컨테이너 레지스트리를 포함합니다.

이 차트는 3개의 주요 부분으로 구성됩니다:

• 서비스,
• 배포,
• ConfigMap.

모든 구성은
레지스트리 구성 문서에 따라 /etc/docker/registry/config.yml 변수를 사용하여 Deployment에 제공된 ConfigMap에서 채워집니다. ConfigMap는 업스트림 기본값을 재정의하지만,
기본값을 기반으로 합니다. 아래에서 자세한 내용을 참조하세요:

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

디자인 선택

Kubernetes Deployment는 인스턴스의 간단한 확장을 허용하기 위해 이 차트의 배포 방법으로 선택되었으며,
롤링 업데이트를 허용합니다.

이 차트는 두 개의 필수 비밀과 하나의 선택적 비밀을 사용합니다:

필수

• global.registry.certificate.secret: 관련 GitLab 인스턴스에서 제공하는 인증 토큰을 확인하기 위해 공용 인증서 번들이 포함된 글로벌 비밀입니다. GitLab을 인증 엔드포인트로 사용하는 방법에 대한 문서를 참조하세요.
• global.registry.httpSecret.secret: 레지스트리 포드 간의
  공유 비밀을 포함하는 글로벌 비밀입니다.

선택적

• profiling.stackdriver.credentials.secret: Stackdriver 프로파일링이 활성화되고 명시적인 서비스 계정 자격 증명을 제공해야 하는 경우 이 비밀의 값(기본적으로 credentials 키에 있음)은 GCP 서비스 계정 JSON 자격 증명입니다.
  GKE를 사용하고 워크로드에 서비스 계정을 제공하는 경우
  워크로드 아이덴티티
  (또는 노드 서비스 계정, 권장하지 않음) 를 사용하는 경우 이 비밀은 필요하지 않으며 제공되지 않아야 합니다.
  두 경우 모두, 서비스 계정은 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를 사용하면 개인 레지스트리에 인증하여 팟의 이미지를 가져올 수 있습니다.

개인 레지스트리와 해당 인증 방법에 대한 추가 세부정보는 Kubernetes 문서에서 확인할 수 있습니다.

다음은 pullSecrets의 사용 예시입니다:

image:
  repository: my.registry.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는 선택적 매개변수로, 다음 두 가지 중 하나 또는 모두를 설정할 수 있습니다:

• podAntiAffinity 규칙:
  • 표현식에 해당하는 팟과 동일한 도메인에 팟을 스케줄하지 않도록 설정합니다.
  • 두 가지 모드의 podAntiAffinity 규칙을 설정합니다: 필수(requiredDuringSchedulingIgnoredDuringExecution) 및 선호(preferredDuringSchedulingIgnoredDuringExecution). values.yaml에서 antiAffinity 변수를 사용하여 설정을 soft로 설정하여 선호 모드가 적용되도록 하거나, hard로 설정하여 필수 모드가 적용되도록 합니다.
• nodeAffinity 규칙:
  • 특정 존 또는 존에 속하는 노드에 팟을 스케줄합니다.
  • 두 가지 모드의 nodeAffinity 규칙을 설정합니다: 필수(requiredDuringSchedulingIgnoredDuringExecution) 및 선호(preferredDuringSchedulingIgnoredDuringExecution). soft로 설정할 경우 선호 모드가 적용되며, hard로 설정할 경우 필수 모드가 적용됩니다. 이 규칙은 registry 차트와 gitlab 차트 및 모든 하위 차트에서만 구현됩니다. 단, webservice 및 sidekiq는 제외됩니다.

nodeAffinity는 In 연산자만 구현합니다.

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

다음 예시는 affinity를 설정하며, 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 사용 예시입니다.

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

서브 차트 활성화

우리가 선택한 컴파트먼트 서브 차트 구현 방식은 주어진 배포에서 원하지 않는 구성 요소를 비활성화할 수 있는 기능을 포함합니다. 이러한 이유로 먼저 결정해야 할 설정은 enabled입니다.

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

image 구성

이 섹션은 이 서브 차트의 배포에서 사용되는 컨테이너 이미지의 설정을 자세히 설명합니다.

레지스트리의 포함된 버전과 pullPolicy를 변경할 수 있습니다.

기본 설정:

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

service 구성

이 섹션은 서비스의 이름과 유형을 제어합니다.

이 설정들은 values.yaml로 채워집니다.

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

ingress 구성

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

TLS 구성

Container Registry는 TLS를 지원하여 다른 구성 요소와의 통신을 보호합니다,
nginx-ingress를 포함하여.

TLS 구성을 위한 전제 조건:

• TLS 인증서에는 Registry 서비스 호스트 이름
  (예: RELEASE-registry.default.svc)이 Common
  Name(CN) 또는 Subject Alternate Name(SAN)에 포함되어야 합니다.
• TLS 인증서가 생성된 후:
  • Kubernetes TLS Secret 생성
  • CA 인증서로만 구성된 다른 Secret을 ca.crt 키와 함께 생성합니다.

TLS를 활성화하려면:

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

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

예를 들어:

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 구성

Registry 디버그 포트는 TLS를 지원합니다. 디버그 포트는
Kubernetes 생존성 및 준비 상태 검사에 사용되며, /metrics
엔드포인트를 Prometheus(활성화된 경우)용으로 노출합니다.

TLS는 registry.debug.tls.enabled를 true로 설정하여 활성화할 수 있습니다.
디버그 포트의 TLS 구성에서 사용할 전용 Kubernetes TLS Secret이 registry.debug.tls.secretName에 제공될 수 있습니다.
전용 Secret이 지정되지 않은 경우, 디버그 구성은 레지스트리의 일반 TLS 구성과 registry.tls.secretName을 공유하도록 되돌아갑니다.

Prometheus가 https를 사용하여 /metrics/ 엔드포인트를 스크랩하려면
인증서의 CommonName 속성이나 SubjectAlternativeName 항목에 대한 추가 구성이 필요합니다.
그 요구 사항은
TLS 활성화된 엔드포인트를 스크랩하기 위한 Prometheus 구성을 참조하세요.

networkpolicy 구성

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

모든 내부 엔드포인트에 대한 연결 방지를 위한 정책 예시

Registry 서비스는 일반적으로 오브젝트 스토리지에 대한 egress 연결, Docker 클라이언트로부터의 ingress 연결, DNS 조회를 위한 kube-dns를 필요로 합니다. 이는 Registry 서비스에 다음과 같은 네트워크 제약을 추가합니다:

• 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 및 메모리 트리거가 hpa 섹션에서 설정된 CPU 및 메모리 임계값에 따라 자동으로 추가됩니다:

• triggers가 설정되어 있지 않습니다.
• 해당 request.cpu.request 또는 request.memory.request 설정이 0이 아닌 값으로 설정되어 있습니다.

트리거가 설정되지 않으면 ScaledObject가 생성되지 않습니다.

해당 설정에 대한 더 자세한 내용은 KEDA 문서를 참조하세요.

모든 내부 엔드포인트에 대한 연결을 방지하기 위한 정책 예시

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

• 10.0.0.0/8 포트 53에 대한 모든 egress 요청이 허용됩니다 (kubeDNS를 위해)
• 10.0.0.0/8에 대한 다른 egress 요청은 제한됩니다
• 10.0.0.0/8 외부에 대한 egress 요청은 허용됩니다

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

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

Registry 구성 정의

이 차트의 다음 속성은 기본 registry 컨테이너의 구성과 관련이 있습니다. GitLab과의 통합을 위해 가장 중요한 값만 노출됩니다. 이 통합에서는 JWT 인증 토큰을 통해 registry에 대한 인증을 제어하는 auth.token.x 설정을 사용합니다.

httpSecret

필드 httpSecret은 secret과 key라는 두 가지 항목을 포함하는 맵입니다.

여기서 참조하는 키의 내용은 registry의 http.secret 값과 관련이 있습니다. 이 값은 암호학적으로 생성된 랜덤 문자열로 채워져야 합니다.

shared-secrets 작업은 제공되지 않은 경우 이 비밀을 자동으로 생성합니다. 이는 안전하게 생성된 128자리 알파-넘 문자 문자열로 채워지며 base64로 인코딩됩니다.

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

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

알림 비밀

알림 비밀은 다양한 방식으로 GitLab 애플리케이션에 콜백을 요청하는 데 사용되며, 예를 들어 Geo가 기본 및 보조 사이트 간에 Container Registry 데이터를 동기화하는 데 도움을 줍니다.

제공되지 않은 경우, shared-secrets 기능이 활성화되면 notificationSecret 비밀 객체가 자동으로 생성됩니다.

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

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

그런 다음 설정을 진행합니다:

global:
  # 자신의 비밀을 제공하기 위해
  registry:
    notificationSecret:
        secret: gitlab-registry-notification
        key: secret

  # Geo를 활용하고 컨테이너 레지스트리를 동기화하려는 경우.
  # 이 설정은 기본 사이트 구성에서만 정의합니다.
  geo:
    registry:
      replication:
        enabled: true
        primaryApiUrl: <기본 레지스트리에 대한 URL>

위에서 생성한 비밀의 secret 값을 설정해야 합니다.

Redis 캐시 비밀

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

shared-secrets 기능이 활성화되면, 제공되지 않은 경우 gitlab-redis-secret 비밀 객체가 자동으로 생성됩니다.

이 비밀을 수동으로 생성하려면 Redis 비밀번호 지침을 참조하세요.

authEndpoint

authEndpoint 필드는 문자열로, registry가 인증할 GitLab 인스턴스의 URL을 제공합니다.

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

기본적으로 이 필드는 Global Settings에서 설정한 GitLab 호스트 이름 구성으로 채워집니다.

certificate

certificate 필드는 secret 및 key라는 두 항목을 포함하는 맵입니다.

secret은 GitLab 인스턴스에서 생성한 토큰을 검증하는 데 사용될 인증서 번들을 포함하는 Kubernetes Secret의 이름을 포함하는 문자열입니다.

key는 인증서 번들을 포함하는 Secret에서 제공될 key의 이름으로, registry 컨테이너에 auth.token.rootcertbundle으로 제공됩니다.

기본 예시:

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

readiness and liveness probe

기본적으로 /debug/health에서 포트 5001로 확인하는 readiness 및 liveness probe가 구성되어 있습니다. 이는 디버그 포트입니다.

validation

validation 필드는 registry에서 Docker 이미지 검증 프로세스를 제어하는 맵입니다. 이미지 검증이 활성화되면 registry는 manifests.urls.allow 필드 내에서 명시적으로 해당 레이어 URL을 허용하지 않는 한 외래 레이어가 있는 Windows 이미지를 거부합니다.

검증은 manifest 푸시 중에만 발생하므로, 이 섹션의 값 변경에 영향을 받지 않는 이미지는 이미 registry에 존재할 수 있습니다.

이미지 검증은 기본적으로 비활성화되어 있습니다.

이미지 검증을 활성화하려면 registry.validation.disabled: false를 명시적으로 설정해야 합니다.

manifests

manifests 필드는 manifests에 특정한 검증 정책 구성을 허용합니다.

urls 섹션에는 allow 및 deny 필드가 모두 포함되어 있습니다. 검증을 통과하는 URL이 포함된 manifest 레이어는 allow 필드의 정규 표현식 중 하나와 일치해야 하며, deny 필드의 정규 표현식에는 일치하지 않아야 합니다.

알림

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 필드는 Kubernetes Secret 및 관련 키를 참조합니다. 이 비밀의 내용은 Registry Configuration: storage에서 직접 가져옵니다. 더 자세한 내용은 해당 문서를 참조하십시오.

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

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

S3의 경우, 올바른 registry storage 권한을 부여했는지 확인하십시오. 저장소 구성에 대한 더 많은 정보는 Container Registry storage driver 관리 문서에서 확인할 수 있습니다.

storage 블록의 내용을 비밀에 넣고 다음 항목을 storage 맵에 제공하십시오:

• secret: YAML 블록을 포함하는 Kubernetes Secret의 이름.
• 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

저장소 드라이버에 대해 리디렉션을 비활성화할 수 있습니다, 이렇게 하면 모든 트래픽이 다른 백엔드로 리디렉션되는 대신 Registry 서비스로 흐릅니다:

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

filesystem 드라이버를 사용하기로 선택한 경우:

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

회복력과 단순성을 위해 s3, gcs, azure 또는 기타 호환 가능한 객체 저장소와 같은 외부 서비스를 사용하는 것이 좋습니다.

참고: 차트는 기본적으로 사용자가 지정하지 않는 한 이 구성에 delete.enabled: true를 채워 넣습니다. 이는 기본적으로 MinIO의 사용 및 Linux 패키지와 일치하도록 기대되는 동작을 유지합니다. 사용자가 제공한 값은 이 기본값을 초과합니다.

middleware.storage

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

구성은 꽤 일반적이며 유사한 패턴을 따릅니다:

middleware:
  # https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware 참조
  storage:
    - name: cloudfront
      options:
        baseurl: https://abcdefghijklmn.cloudfront.net/
        # `privatekey`는 privatekey Secret의 내용으로 자동 채워집니다.
        privatekeySecret:
          secret: cloudfront-secret-name
          # "key" 값은 PEM 저장소의 파일 이름을 생성하는 데 사용됩니다:
          #   /etc/docker/registry/middleware.storage/<index>/<key>
          key: private-key-ABC.pem
        keypairid: ABCEDFGHIJKLMNOPQRST

위 코드 내 options.privatekeySecret는 PEM 파일 내용에 해당하는 generic Kubernetes 비밀입니다:

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

업스트림에서 사용되는 privatekey는 privatekey Secret에서 차트에 의해 자동 채워지며 지정된 경우 무시됩니다.

keypairid 변형

다양한 공급자는 동일한 구조에 대해 서로 다른 필드 이름을 사용합니다:

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

debug

디버그 포트는 기본적으로 활성화되어 있으며, 생존성/준비성 프로브에 사용됩니다. 추가적으로, metrics 값을 통해 Prometheus 메트릭을 활성화할 수 있습니다.

debug:
  addr:
    port: 5001

metrics:
  enabled: true

health

health 속성은 선택적이며, 저장 드라이버의 백엔드 저장소에 대한 주기적인 건강 검사를 위한 기본 설정을 포함합니다. 자세한 내용은 Docker의 구성 문서를 참조하세요.

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

reporting

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

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

profiling

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

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

database

• 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

센티넬

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

센티넬 비밀번호 지원

• 도입됨 GitLab 17.2에서.

redis.cache는 또한 global.redis.sentinelAuth 구성을 사용하여 Redis 센티넬의 인증 비밀번호를 사용할 수 있습니다. 로컬 값은 제공될 수 있으며 글로벌 값보다 우선합니다. 예를 들어:

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 속도 제한기

경고:

Redis 속도 제한 기능은 개발 중입니다.

기능에 대한 자세한 내용은 제공되는 대로 이 섹션에 추가됩니다.

redis.rateLimiting 속성은 선택 사항이며 다음과 관련된 옵션을 제공합니다.

Redis 속도 제한기.

예를 들어:

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

가비지 수집

Docker 레지스트리는 시간이 지남에 따라 불필요한 데이터를 축적하며, 이를 사용하여 가비지 수집을 통해 해제할 수 있습니다.

현재로는 이 차트와 함께 가비지 수집을 실행하는 완전 자동화되거나 예약된 방법이 없습니다.

경고:

메타데이터 데이터베이스와 함께 온라인 가비지 수집을 사용해야 합니다. 메타데이터 데이터베이스로 수동 가비지 수집을 사용하면 데이터 손실이 발생합니다. 온라인 가비지 수집은 수동 가비지 수집을 완전히 대체합니다.

수동 가비지 수집

수동 가비지 수집을 위해서는 먼저 레지스트리를 읽기 전용 모드로 전환해야 합니다. 이미 Helm을 사용하여 GitLab 차트를 설치했으며, 이를 mygitlab라고 명명하고 gitlabns 네임스페이스에 설치했다고 가정합니다.

아래 명령어에서 이러한 값을 실제 구성에 맞게 교체하세요.

# https://github.com/helm/helm/issues/2948로 인해 --reuse-values에 의존할 수 없으므로 현재 구성을 가져옵니다.
helm get values mygitlab > mygitlab.yml
# Helm 설치를 업그레이드하고 레지스트리를 읽기 전용으로 설정합니다.
# --wait 매개변수는 Helm이 모든 리소스가 준비 상태가 될 때까지 기다리게 하므로 안전하게 계속할 수 있습니다.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --set registry.maintenance.readonly.enabled=true --wait
# 이제 레지스트리가 읽기 전용 모드에 있으므로 레지스트리 Pod 중 하나의 이름을 가져옵니다.
# 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에서 툴박스 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 전용 레지스트리 문서