• 디자인 선택 사항
  • 필수
  • 선택적
• 구성
• 설치 매개변수
• 차트 구성 예시
  • pullSecrets
  • tolerations
  • annotations
• 서브 차트 활성화
• image 구성
• service 구성
• ingress 구성
• TLS 구성
  • 디버그 포트용 TLS 구성
• networkpolicy 구성
  • 모든 내부 엔드포인트로의 연결 방지 정책 예시
• KEDA 구성
• 레지스트리 구성 정의
  • httpSecret
  • 알림 시크릿
  • Redis 캐시 시크릿
  • authEndpoint
  • certificate
  • readiness 및 liveness probe
  • validation
    • manifests
  • notifications
  • hpa
  • storage
  • middleware.storage
    • keypairid 변형
  • debug
  • health
  • reporting
  • profiling
  • database
    • 데이터베이스 관리
  • gc 속성
  • Redis cache
    • Sentinels
• 가비지 수집
  • 매뉴얼 가비지 수집
  • 컨테이너 레지스트리에 대한 관리 명령 실행

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

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

이 차트는 3개의 기본 부분으로 구성되어 있습니다:

• 서비스
• 배포
• ConfigMap.

모든 구성은 /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: 레지스트리 pod 간의 공유 비밀을 포함할 전역 시크릿입니다.

선택적

• 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.0.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: []
  ingress:
    enabled: false
    tls:
      enabled: true
      secretName: redis
    annotations:
    configureCertmanager:
    proxyReadTimeout:
    proxyBodySize:
    proxyBuffering:
  networkpolicy:
    enabled: false
    egress:
      enabled: false
      rules: []
    ingress:
      enabled: false
      rules: []
  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

tolerations

tolerations는 오염된 워커 노드에서 pod을 예약할 수 있도록 합니다.

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

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

annotations

annotations는 레지스트리 pod에 주석을 추가할 수 있도록 합니다.

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

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

서브 차트 활성화

구획화된 서브 차트를 구현하는 방법은 특정 배포에서 원치 않는 컴포넌트를 비활성화하는 능력을 포함합니다. 따라서, 결정해야 할 첫 번째 설정은 enabled입니다.

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

image 구성

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

기본 설정:

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

service 구성

이 섹션은 서비스의 이름 및 유형을 제어합니다. 이러한 설정은 values.yaml에 의해 채워질 것입니다.

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

ingress 구성

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

TLS 구성

컨테이너 레지스트리는 nginx-ingress와 같은 다른 컴포넌트와의 통신을 보안하는 TLS를 지원합니다.

TLS를 구성하려면 선행 조건:

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

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에 전달해야 합니다. 이는 레지스트리의 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을 공유합니다.

https를 사용하여 Prometheus가 /metrics/ 엔드포인트를 스크레이핑하려면 인증서의 CommonName 속성 또는 SubjectAlternativeName 항목에 대한 추가 구성이 필요합니다. 자세한 내용은 TLS 활성 엔드포인트의 Prometheus 스크랩 구성을 참조하십시오.

networkpolicy 구성

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

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

레지스트리 서비스는 일반적으로 객체 리포지터리로의 이그레스 연결, Docker 클라이언트로부터의 인그레스 연결, 그리고 DNS 조회를 위한 kube-dns에 연결이 필요합니다.
이는 레지스트리 서비스에 다음과 같은 네트워크 제한 사항을 추가합니다.

• 10.0.0.0/8의 로컬 네트워크로의 모든 이그레스 요청은 허용됩니다(큐브DNS용으로 포트 53)
• 10.0.0.0/8의 다른 로컬 네트워크로의 이그레스 요청은 제한됩니다
• 10.0.0.0/8 외부의 이그레스 요청은 허용됩니다

레지스트리 서비스는 외부 객체 리포지터리에 있는 이미지를 위해 공개 인터넷과의 외부 연결이 필요함에 유의하십시오.

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 설명서를 참조하세요.

| 이름 | 유형 | 기본값 | 설명 | | :—————————- | :—–: | :—— | :—————————————————————————————————————————————————————————— | | enabled | 불리언 | false | HorizontalPodAutoscalers 대신 KEDA ScaledObjects 사용 여부 | | pollingInterval | 정수 | 30 | 각 트리거를 확인하는 간격 | | cooldownPeriod | 정수 | 300 | 마지막 트리거가 활성 상태를 보고한 후 리소스를 0으로 축소하기까지 대기하는 기간 | | minReplicaCount | 정수 | | KEDA가 리소스를 축소하는 데 사용하는 최소 레플리카 수, hpa.minReplicas로 기본 설정됨 | | maxReplicaCount | 정수 | | KEDA가 리소스를 확장하는 데 사용하는 최대 레플리카 수, hpa.maxReplicas로 기본 설정됨 | | fallback | 맵 | | KEDA 폴백 구성, 설명서 참조 | | hpaName | 문자열 | | KEDA가 생성할 HPA 리소스의 이름, keda-hpa-{scaled-object-name}으로 기본 설정됨 | | restoreToOriginalReplicaCount | 불리언 | | ScaledObject가 삭제된 후 대상 리소스를 원래 레플리카 수로 축소해야 하는지 여부를 지정함 | | behavior | 맵 | | 확장 및 축소 동작에 대한 사양, 기본적으로 hpa.behavior로 설정됨 | | triggers | 배열 | | 대상 리소스의 스케일링을 활성화하는 트리거 디렉터리, 기본적으로 hpa.cpu 및 hpa.memory에서 계산된 트리거로 설정됨 | ### 모든 내부 엔드포인트로의 연결 방지 정책 예시

레지스트리 서비스는 일반적으로 객체 리포지터리로의 이그레스 연결, Docker 클라이언트로부터의 인그레스 연결, 그리고 DNS 조회를 위한 kube-dns에 연결이 필요합니다.
이는 레지스트리 서비스에 다음과 같은 네트워크 제한 사항을 추가합니다.

• 10.0.0.0/8의 로컬 네트워크로의 모든 이그레스 요청은 허용됩니다(큐브DNS용으로 포트 53)
• 10.0.0.0/8의 다른 로컬 네트워크로의 이그레스 요청은 제한됩니다
• 10.0.0.0/8 외부의 이그레스 요청은 허용됩니다

레지스트리 서비스는 외부 객체 리포지터리에 있는 이미지를 위해 공개 인터넷과의 외부 연결이 필요함에 유의하십시오.

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

레지스트리 구성 정의

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

httpSecret

httpSecret 필드는 secret와 key 두 항목을 포함하는 맵입니다.

이 참조하는 키의 내용은 레지스트리의 http.secret 값과 상응합니다. 이 값은 암호학적으로 생성된 무작위 문자열로 채워져야 합니다.

shared-secrets 작업은 제공되지 않으면 이 시크릿을 자동으로 생성합니다. 안전하게 생성된 128자 알파벳-숫자 문자열을 base64로 인코딩한 값으로 채워집니다.

이 시크릿을 매뉴얼으로 생성하려면:

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

알림 시크릿

알림 시크릿은 다양한 방식으로 GitLab 애플리케이션을 호출할 때 사용됩니다. 예를 들어 Geo에서 주요 및 보조 사이트 간 컨테이너 레지스트리 데이터 동기화를 지원하는 데 사용됩니다.

notificationSecret 시크릿 개체는 shared-secrets 기능이 활성화되면 제공되지 않으면 자동으로 생성됩니다.

이 시크릿을 매뉴얼으로 생성하려면:

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 캐시 시크릿

global.redis.auth.enabled가 true로 설정되어 있는 경우 Redis 캐시 시크릿이 사용됩니다.

shared-secrets 기능이 활성화되면 시크릿 개체 gitlab-redis-secret가 제공되지 않으면 자동으로 생성됩니다.

시크릿을 매뉴얼으로 생성하려면 Redis 비밀번호 지침을 참조하세요.

authEndpoint

authEndpoint 필드는 GitLab 인스턴스에 대한 registry의 URL을 제공하는 문자열입니다.

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

기본적으로 이 필드는 전역 설정에서 설정한 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 및 liveness probe

기본적으로 /debug/health의 5001 포트를 확인하는 준비 및 수명 검사가 구성되어 있습니다. 이는 디버그 포트입니다.

validation

validation 필드는 레지스트리에서 Docker 이미지 유효성 검사 프로세스를 제어하는 맵입니다. 이미지 유효성 검사가 활성화되면 레지스트리는 윈도우 이미지에 외부 레이어가 있는 경우 manifests.urls.allow 필드가 명시적으로 해당 레이어 URL을 허용하도록 설정되지 않는 한 해당 이미지를 거부합니다.

유효성 검사는 매니페스트 푸시 중에만 발생하므로 레지스트리에 이미 존재하는 이미지는이 섹션의 값에 대한 변경에 영향을받지 않습니다.

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

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

manifests

manifests 필드를 사용하면 매니페스트에 특정한 유효성 검사 정책을 구성할 수 있습니다.

urls 섹션에는 allow 및 deny 필드가 포함되어 있습니다. 유효성 검사를 통과하는 URL을 포함하는 매니페스트 레이어를 위해 allow 필드의 정규식 중 하나와 일치해야 하고, deny 필드의 정규식 중 어떤 것도 일치해서는 안 됩니다.

notifications

notifications 필드는 Registry notifications를 구성하는 데 사용됩니다. 기본값은 빈 해시입니다.

다음과 같은 예시 설정을 사용할 수 있습니다:

notifications:
  endpoints:
    - name: FooListener
      url: https://foolistener.com/event
      timeout: 500ms
      threshold: 10
      backoff: 1s
    - name: BarListener
      url: https://barlistener.com/event
      timeout: 100ms
      threshold: 3
      backoff: 1s
  events:
    includereferences: true

hpa

hpa 필드는 registry 인스턴스 수를 조정하는 객체입니다. 이것은 기본적으로minReplicas 값을 2, maxReplicas 값을 10으로 설정하고 cpu.targetAverageUtilization를 75%로 구성합니다.

storage

storage:
  secret:
  key: config
  extraKey:

storage 필드는 Kubernetes Secret 및 관련된 키에 대한 참조입니다. 이 Secret의 내용은 직접 Registry Configuration: storage에서 가져옵니다.

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

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

S3를 사용하는 경우 올바른 registry storage 권한을 부여해야 합니다. 리포지터리 구성에 대한 자세한 내용은 관리 문서의 Container Registry storage driver를 참조하십시오.

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

• secret: YAML 블록을 포함하는 Kubernetes Secret의 이름.
• key: Secret의 키의 이름. 기본값은 config.
• extraKey: (선택사항) Secret의 추가 키의 이름은 컨테이너 내의 /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

filesystem 드라이버를 사용하는 경우:

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

신뢰성 및 간편함을 위해 s3, gcs, azure 또는 기타 호환되는 객체 리포지터리 등 외부 서비스를 사용하는 것이 좋습니다.

차트는이 구성에 기본적으로 delete.enabled: true를 채울 것입니다. 그렇지 않은 경우 MinIO 및 Linux 패키지의 기본 사용을 예상하고 사용자 지정 값이이 기본값을 무시합니다.

middleware.storage

middleware.storage의 구성은 upstream 규칙을 따릅니다:

구성은 상당히 일반적이며 비슷한 패턴을 따릅니다:

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 secrets입니다:

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 변형

여러 공급 업체가 동일한 구조에 대해 다른 필드 이름을 사용합니다:

debug

디버그 포트는 기본적으로 활성화되며, 라이브/준비 상태 검사에 사용됩니다. 추가로, Prometheus 메트릭은 metrics 값을 통해 활성화될 수 있습니다.

debug:
  addr:
    port: 5001

metrics:
  enabled: true

health

health 속성은 선택 사항이며, 스토리지 드라이버의 백엔드 스토리지에 대한 주기적인 건강 상태를 선호합니다. 자세한 내용은 Docker의 구성 문서를 참조하세요.

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

reporting

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에서 소개됨, 베타 기능으로 지원됨.

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

이것은 베타 기능입니다. 이 기능을 활성화하기 전에 피드백 이슈 및 관련 문서를 참조하세요.

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

데이터베이스 관리

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

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 cache

redis.cache 속성은 선택 사항이며, Redis cache와 관련된 옵션을 제공합니다. 레지스트리와 함께 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

Sentinels

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

가비지 수집

Docker Registry는 시간이 지남에 따라 불필요한 데이터가 축적될 수 있으며 가비지 수집을 사용하여 데이터를 해제할 수 있습니다. 현재 이 차트를 사용하여 완전 자동화되거나 예약된 가비지 수집 방법은 없습니다.

매뉴얼 가비지 수집

매뉴얼 가비지 수집에는 레지스트리가 먼저 읽기 전용 모드 여야합니다. 이미 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
# 이제 레지스트리가 읽기 전용 모드입니다. 그래서 레지스트리 Pods 중 하나의 이름을 얻습니다.
# 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에서만 실행할 수 있습니다. Issue #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 특정 레지스트리 문서