• 設計の選択
  • 必須
  • オプション
• 設定
• インストールパラメータ
• Chart設定例
  • プルシークレット
  • 許容範囲
  • 注釈
• サブチャートを有効にします。
• 設定image
• 設定service
• 設定ingress
• TLSの設定
  • デバッグポートのTLS設定
• 設定networkpolicy
  • 全ての内部エンドポイントへの接続を防止するポリシーの例
• KEDAの設定
  • 全ての内部エンドポイントへの接続を防止するポリシーの例
• レジストリ設定の定義
  • httpSecret
  • 通知シークレット
  • Redisキャッシュのシークレット
  • authEndpoint
  • 証明書
  • 準備とiveness Probe
  • 検証
    • マニフェスト
  • 通知
  • hpa
  • ストレージ
  • ミドルウェア.ストレージ
    • keypairid バリアント
  • デバッグ
  • 健康
  • レポーター
  • プロファイリング
  • データベース
    • データベースの作成
  • gc プロパティ
  • Redisキャッシュ
    • センチネル
• ガベージコレクション
  • 手動ガベージコレクション
  • コンテナレジストリに対する管理コマンドの実行

コンテナレジストリの使用

registry サブチャートは、Kubernetes上での完全なクラウドネイティブGitLabデプロイへのレジストリコンポーネントを提供します。このサブチャートは、Dockerディストリビューションを含むアップストリームレジストリコンテナを利用します。このChartは3つの主要な部分で構成されています：Service、Deployment、ConfigMapです。

すべての設定は、公式のレジストリ設定ドキュメントに従って処理されます。ConfigMap. ConfigMapMapからDeployment に提供される/etc/docker/registry/config.yml 変数を使用します。ConfigMap.Mapは ConfigMapアップストリームのデフォルトを上書きしますが、それに基づいています。詳細は以下を参照してください：

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

設計の選択

このChartのデプロイ方法としてKubernetesDeployment が選ばれたのは、インスタンスをシンプルにスケーリングできるようにすると同時に、ローリングアップデートを可能にするためです。

このチャートでは、2つの必須シークレットと1つのオプションのシークレットを使用しています：

必須

• 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: 'v3.80.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 を削除してください。

インストールパラメータ

Chart設定例

プルシークレット

pullSecrets を使用すると、非公開レジストリで認証してポッドのイメージをプルできるようになります。

非公開レジストリとその認証方法の詳細については、Kubernetesのドキュメントを参照してください。

以下は、pullSecrets の使用例です：

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

許容範囲

tolerations 汚染されたワーカーノードでポッドのスケジューリングが可能

以下は、tolerations の使用例です：

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

注釈

annotations を使用すると、レジストリポッドに注釈を追加することができます。

以下はannotations

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

サブチャートを有効にします。

コンパートメント化されたサブチャートを実装するために選択した方法には、特定のデプロイで不要なコンポーネントを無効にする機能が含まれています。このため、最初に決めるべき設定はenabled です。

レジストリはデフォルトで有効になっています。無効にしたい場合は、enabled: false を設定します。

設定image

このセクションでは、このサブチャートのデプロイで使用するコンテナイメージの設定について詳しく説明します。レジストリの内部バージョンを変更したり、pullPolicy 。

デフォルト設定：

• tag: 'v3.80.0-gitlab'
• pullPolicy: 'IfNotPresent'

設定service

このセクションでは、サービスの名前とタイプを制御します。これらの設定はvalues.yaml によって入力されます。

デフォルトでは、サービスは次のように設定されています：

設定ingress

このセクションでは、レジストリIngressを制御します。

TLSの設定

コンテナレジストリは、nginx-ingress を含む他のコンポーネントとの通信をセキュアにする TLS をサポートしています。

TLS を設定するための前提条件：

• TLS 証明書は、Common Name（共通名）(CN) または Subject Alternate Name（サブジェクト代替名）(SAN)にレジストリ・サービス・ホスト名（たとえば、RELEASE-registry.default.svc ）を含める必要があります。
• TLS証明書が生成された後：
  • Kubernetes TLSシークレットの作成
  • ca.crt キー付きTLS証明書のCA証明書のみを含む別のシークレットを作成します。

TLSを有効にするには

1. registry.tls.enabled をtrueに設定します。
2. global.hosts.registry.protocol をhttpsに設定します。
3. registry.tls.secretName とglobal.certificates.customCAs にシークレット名を渡します。

registry.tls.verify がtrue の場合、registry.tls.caSecretNameに CA 証明書のシークレットネームを渡す必要があります。これは、自己署名証明書とカスタム認証局に必要です。このシークレットはNGINXがレジストリの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設定

レジストリデバッグポートはTLSもサポートしています。このデバッグポートは、Kubernetesの有効性と準備のチェック、およびPrometheus用の/metrics エンドポイントの公開（有効な場合）に使用されます。

TLSは、registry.debug.tls.enabled をtrue に設定することで有効にできます。KubernetesのTLSシークレットは、デバッグポートのTLS設定で使用するために専用のregistry.debug.tls.secretName 。専用のシークレットが指定されていない場合、デバッグ設定はレジストリの通常のTLS設定とregistry.tls.secretName を共有するようにフォールバックします。

Prometheus がhttps を使用して/metrics/ エンドポイントをスクレイピングするには、証明書の CommonName 属性または SubjectAlternativeName エントリの追加設定が必要です。これらの要件については、TLS対応エンドポイントをスクレイピングするPrometheusの設定を参照してください。

設定networkpolicy

このセクションでは、レジストリNetworkPolicy を制御します。この設定はオプションで、レジストリの Egress および Ingress を特定のエンドポイントに制限するために使用します。

全ての内部エンドポイントへの接続を防止するポリシーの例

レジストリサービスは通常、オブジェクトストレージへのegress接続、DockerクライアントからのIngress接続、およびDNSルックアップ用のkube-dnsを必要とします。これにより、レジストリサービスに次のネットワーク制限が追加されます：

• 10.0.0.0/8 ポート 53 の内部ネットワークへのすべてのイグレス要求が許可されます (kubeDNS の場合)。
• 10.0.0.0/8 のローカルネットワークへのその他のegressリクエストは制限されています。
• 10.0.0.0/8 の外部へのegressリクエストは許可されています。

レジストリサービスは、外部オブジェクトストレージ上のイメージのために公開インターネットへのアウトバウンド接続を必要とすることに注意してください。

networkpolicy:
  enabled: true
  egress:
    enabled: true
    # The following rules enable traffic to all external
    # endpoints, except the local
    # network (except DNS requests)
    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 セクションで設定された値にデフォルト設定されます。

以下が真である場合、hpa セクションで設定された CPU とメモリのしきい値に基づいて、CPU とメモリのトリガーが自動的に追加されます：

• triggers がセットされていません。
• 対応するrequest.cpu.request またはrequest.memory.request の設定もゼロ以外の値に設定されます。

トリガーが設定されていない場合、ScaledObject は作成されません。

これらの設定の詳細については、KEDAのドキュメントを参照してください。

全ての内部エンドポイントへの接続を防止するポリシーの例

レジストリサービスは通常、オブジェクトストレージへのegress接続、DockerクライアントからのIngress接続、およびDNSルックアップ用のkube-dnsを必要とします。これにより、レジストリサービスに次のネットワーク制限が追加されます：

• 10.0.0.0/8 ポート 53 の内部ネットワークへのすべてのイグレス要求が許可されます (kubeDNS の場合)。
• 10.0.0.0/8 のローカルネットワークへのその他のegressリクエストは制限されています。
• 10.0.0.0/8 の外部へのegressリクエストは許可されています。

レジストリサービスは、外部オブジェクトストレージ上のイメージのために公開インターネットへのアウトバウンド接続を必要とすることに注意してください。

networkpolicy:
  enabled: true
  egress:
    enabled: true
    # The following rules enable traffic to all external
    # endpoints, except the local
    # network (except DNS requests)
    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の2つの項目を含むマップです。

このキーが参照するキーの内部は、レジストリの http.secret の値と関連しています。この値には暗号的に生成されたランダムな文字列を指定します。

shared-secrets のジョブは、指定がなければ自動的にこの秘密を作成します。この値は、base64 エンコードされた 128 文字の英数字からなるセキュリティで生成された文字列で埋められます。

このシークレットを手動で作成するには、次のようにします：

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

通知シークレット

通知シークレットは、プライマリサイトとセカンダリサイト間のコンテナレジストリデータの同期を管理するためのGeoなど、様々な方法でGitLabアプリケーションにコールバックするために利用されます。

shared-secrets 機能を有効にすると、notificationSecret シークレットオブジェクトが自動的に作成されます。

このシークレットを手動で作成するには、次のようにします：

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

次に

global:
  # To provide your own secret
  registry:
    notificationSecret:
        secret: gitlab-registry-notification
        key: secret

  # If utilising Geo, and wishing to sync the container registry
  geo:
    registry:
      replication:
        enabled: true
        primaryApiUrl: <URL to primary registry>

secret の値が、上記で作成したシークレットの名前に設定されていることを確認します。

Redisキャッシュのシークレット

Redis キャッシュのシークレットは、global.redis.auth.enabled がtrue に設定されている場合に使用されます。

shared-secrets 機能が有効な場合、gitlab-redis-secret シークレットオブジェクトが提供されなければ自動的に作成されます。

このシークレットを手動で作成するには、Redisパスワードの説明を参照してください。

authEndpoint

authEndpoint フィールドは文字列で、レジストリで認証する GitLab インスタンスの URL を指定します。

値にはプロトコルとホスト名のみを含める必要があります。Chart テンプレートは、必要なリクエストパスを自動的に追加します。結果の値は、コンテナ内部でauth.token.realm に入力されます。例えばauthEndpoint: "https://gitlab.example.com"

デフォルトでは、このフィールドにはグローバル設定で設定された GitLab ホスト名が入力されます。

証明書

certificate フィールドは、secret とkeyの2つの項目を含むマップです。

secret は、GitLabインスタンスによって作成されたトークンを検証するために使用される証明書バンドルを格納するKubernetesシークレットの名前を含む文字列です。

はauth.token.rootcertbundleとしてレジストリコンテナに提供される証明書バンドルを格納するSecret 内のkey 名前 keyです。

デフォルトの例：

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

準備とiveness Probe

デフォルトでは、デバッグ・ポートであるポート5001 の/debug/health をチェックするために、Readiness and Liveness Probe が設定されています。

検証

validation フィールドはレジストリ内のDockerイメージ検証プロセスを制御するマップです。画像検証を有効にすると、検証スタンザ内のmanifests.urls.allow フィールドが明示的にそれらのレイヤーの URL を許可するように設定されていない限り、レジストリは外部レイヤーを含む Windows イメージを拒否します。

検証はマニフェストのプッシュ時にのみ行われるため、レジストリに既に存在するイメージはこのセクションの値の変更によって影響を受けません。

画像の検証はデフォルトでオフに設定されています。

画像検証を有効にするには、明示的にregistry.validation.disabled: false を設定する必要があります。

マニフェスト

manifests フィールドでは、マニフェスト固有の検証ポリシーを設定できます。

urls セクションはallow とdeny フィールドの両方を含みます。URL を含むマニフェストレイヤーがバリデーションを通過するには、そのレイヤーがallow フィールドの正規表現のいずれかにマッチし、かつdeny フィールドの正規表現にはマッチしない必要があります。

通知

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 フィールドはオブジェクトで、セットの一部として作成するレジストリ・インスタンスの数を制御します。デフォルトでは、minReplicas の値は2 、maxReplicas の値は 10、cpu.targetAverageUtilization の値は 75% に設定されます。

ストレージ

storage:
  secret:
  key: config
  extraKey:

storage フィールドはKubernetesシークレットと関連キーへの参照です。このシークレットの内容は、レジストリ設定:storageから直接取得されます。詳細については、そのドキュメントを参照してください。

AWS s3とGoogle GCSドライバの例は、examples/objectstorageにあります：

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

S3 の場合、レジストリストレージに正しい権限が与えられていることを確認してください。ストレージ設定の詳細については、管理ドキュメントのコンテナレジストリストレージドライバを参照してください。

storage ブロックの内容をシークレットに storage配置し、マップのstorage 項目として以下を指定 storageします：

• secretYAML ブロックを格納する Kubernetes シークレットの名前。
• key: シークレットで使用するキーの名前。デフォルトはconfig 。
• extraKeyコンテナ内の/etc/docker/registry/storage/${extraKey} にマウントされます。これは、gcs ドライバにkeyfile を提供するために使用できます。

# Example using S3
kubectl create secret generic registry-storage \
    --from-file=config=registry-storage.yaml

# Example using GCS with JSON key
# - Note: `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 またはその他の互換性のあるオブジェクトストレージなどの外部サービスを利用することをお勧めします。

ミドルウェア.ストレージ

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 file name for PEM storage:
          #   /etc/docker/registry/middleware.storage/<index>/<key>
          key: private-key-ABC.pem
        keypairid: ABCEDFGHIJKLMNOPQRST

上記のコードoptions.privatekeySecret 内にはgeneric Kubernetes シークレットコンテンツがあり、PEM ファイルのコンテンツに対応しています：

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

privatekey 使用されるアップストリームは、privatekey SecretからChartによって自動入力され、指定された場合は無視されます。

keypairid バリアント

さまざまなベンダーが、同じ構造体に対して異なるフィールド名を使用しています：

デバッグ

デバッグポートはデフォルトで有効になっており、Liveness/Readiness Probeに使用されます。さらに、Prometheusメトリクスは、metrics の値を使用して有効にできます。

debug:
  addr:
    port: 5001

metrics:
  enabled: true

健康

health プロパティはオプションで、ストレージドライバのバックエンドストレージの定期的なヘルスチェックの設定を含みます。詳細はDockerの設定ドキュメントを参照してください。

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

データベース

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
  pool:
    maxidle: 25
    maxopen: 25
    maxlifetime: 5m
    maxidletime: 5m
  migrations:
    enabled: true
    activeDeadlineSeconds: 3600
    backoffLimit: 6
  discovery:
    enabled: true
    nameserver: 'nameserver.fqdn'
    port: 53
    primaryrecord: 'primary.record.fqdn.'
    tcp: false

データベースの作成

レジストリデータベースが有効になっている場合、レジストリはその状態を追跡するために独自のデータベースを使用します。

以下の手順に従って、手動でデータベースとロールを作成してください。

1. データベースのパスワードでシークレットを作成します：

   kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring
   

2. データベースインスタンスにログインしてください：

   kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash
   

   PGPASSWORD=${POSTGRES_POSTGRES_PASSWORD} psql -U postgres -d template1
   

3. データベースユーザーを作成します：

   CREATE ROLE registry WITH LOGIN;
   

4. データベースユーザーのパスワードを設定します。

   1. パスワードを取得してください：

      kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode
      

   2. psql プロンプトでパスワードを設定します：

      \password registry
      

5. データベースを作成します：

   CREATE DATABASE registry WITH OWNER registry;
   

6. PostgreSQL コマンドラインから安全に終了し、exit を使用してコンテナから終了します：

   template1=# exit
   ...@gitlab-postgresql-0/$ exit
   

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.cache プロパティはオプションで、Redis キャッシュに関連するオプションを指定 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

センチネル

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レジストリには時間の経過とともに余計なデータが蓄積され、ガベージコレクションを使用して解放することができます。現在のところ、このChartでガベージコレクションを実行する完全自動化された方法やスケジュールされた方法はありません。

手動ガベージコレクション

手動でガベージ・コレクションを行うには、まずレジストリを読み込み専用モードにする必要があります。すでにHelmを使ってGitLab Chartをインストールし、mygitlab という名前をつけて名前空間gitlabns にインストールしたとしましょう。以下のコマンドで、これらの値を実際の設定に合わせて置き換えてください。

# Because of https://github.com/helm/helm/issues/2948 we can't rely on --reuse-values, so let's get our current config.
helm get values mygitlab > mygitlab.yml
# Upgrade Helm installation and configure the registry to be read-only.
# The --wait parameter makes Helm wait until all ressources are in ready state, so we are safe to continue.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --set registry.maintenance.readonly.enabled=true --wait
# Our registry is in r/o mode now, so let's get the name of one of the registry Pods.
# Note down the Pod name and replace the '<registry-pod>' placeholder below with that value.
# Replace the single quotes to double quotes (' => ") if you are using this with Windows' cmd.exe.
kubectl get pods -n gitlabns -l app=registry -o jsonpath='{.items[0].metadata.name}'
# Run the actual garbage collection. Check the registry's manual if you really want the '-m' parameter.
kubectl exec -n gitlabns <registry-pod> -- /bin/registry garbage-collect -m /etc/docker/registry/config.yml
# Reset registry back to original state.
helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --wait
# All done :)

コンテナレジストリに対する管理コマンドの実行

管理コマンドをコンテナレジストリに対して実行できるのは、registry バイナリと必要な設定の両方が利用可能なレジストリポッドからのみです。イシュー#2629では、この機能をツールボックスポッドから提供する方法について議論しています。

管理コマンドを実行するには

1. レジストリポッドに接続します：

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

2. レジストリポッドの内部では、PATH にregistry のバイナリがあり、直接使用することができます。設定ファイルは/etc/docker/registry/config.ymlにあります。次の例は、データベースのマイグレーションの状態をチェックします：

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

その他の詳細や使用可能なコマンドについては、関連ドキュメントを参照してください：

• レジストリに関する一般的なドキュメント
• GitLab固有のレジストリドキュメント