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

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

すべての設定は、公式のレジストリ設定ドキュメントに従い、ConfigMap. ConfigMapNET FrameworkからDeployment に提供された/etc/docker/registry/config.yml 変数を使用して行われます。 上流のデフォルトを上書きしますが、それに基づいています。 詳細は以下を参照してください：

デザインの選択

このChartのデプロイ方法として、インスタンスをシンプルにスケーリングでき、かつローリングアップデートが可能なKubernetesDeployment が選択されました。

このChartは2つの秘密しか使っていません：

  • global.registry.certificate.secret関連する GitLab インスタンスによって提供される認証トークンを検証するための公開証明書バンドルが含まれるグローバルシークレット。 GitLab を認証エンドポイントとして使用する際のドキュメントを参照してください。
  • global.registry.httpSecret.secretレジストリポッド間で共有されるグローバルシークレット。

設定

以下、コンフィギュレーションの主要な部分について説明します。 親チャートからコンフィギュレーションを行う場合、これらの値は次のようになります： 

registry:
  enabled:
  maintenance:
    readOnly:
      enabled: false
  image:
    tag: 'v2.9.1-gitlab'
    pullPolicy: IfoNtPresent
  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
  storage:
    secret:
    key: storage
    extraKey:
  compatibility:
    schema1:
      enabled: false
  validation:
    disabled: true
  notifications: {}
  tolerations: []
  ingress:
    enabled: false
    tls:
      enabled: true
      serviceName: redis
    annotations:
    proxyReadTimeout:
    proxyBodySize:
    proxyBuffering:
  networkpolicy:
    enabled: false
    egress:
      enabled: false
      rules: []
    ingress:
      enabled: false
      rules: []

このChartをスタンドアローンとしてデプロイする場合は、トップレベルのregistry 。

インストールコマンドラインオプション

パラメータ デフォルト 説明
annotations   ポッド注釈
authAutoRedirect true Auth 自動リダイレクト (Windows クライアントの場合は true にする必要があります)
authEndpoint global.hosts.gitlab.name 認証エンドポイント（ホストとポートのみ）
certificate.secret gitlab-registry JWT証明書
compatiblity   互換性設定の構成
debug   デバッグポートとPrometheusメトリクス
deployment.terminationGracePeriodSeconds 30 ポッドが優雅に終了するのに必要な秒数を指定します。
draintimeout '0' SIGTERMシグナルを受信した後、HTTPコネクションが排出されるまでの待機時間 (例:'10s')
relativeurls false Location ヘッダで相対 URL を返すようにレジストリを有効にします。
enabled true レジストリ有効フラグ
hpa.cpu.targetAverageUtilization 75 HPAを支配する全関連ポッドのリソースメトリクスの平均値の目標値
hpa.customMetrics [] autoscaling/v2beta1 メトリクスには、希望するレプリカ数を計算するために使用するコンテナが含まれています（targetAverageUtilizationで設定された平均CPU利用率のデフォルト使用を上書きします）。
hpa.minReplicas 2 最小レプリカ数
hpa.maxReplicas 10 レプリカの最大数
httpSecret   httpsの秘密
image.pullPolicy   レジストリイメージのプルポリシー
image.pullSecrets   画像リポジトリに使う秘密
image.repository registry レジストリ画像
image.tag v2.9.1-gitlab 使用する画像のバージョン
init.image.repository   initContainer イメージ
init.image.tag   initContainer画像タグ
log {level: warn, fields: {service: registry}} ロギングオプションの設定
minio.bucket global.registry.bucket レガシーレジストリバケット名
maintenance.readOnly.enabled false レジストリの読み取り専用モードの有効化
securityContext.fsGroup 1000 ポッドを起動するグループID
securityContext.runAsUser 1000 ポッドを起動するユーザID
tokenService container_registry JWTトークンサービス
tokenIssuer gitlab-issuer JWTトークン発行者
tolerations [] ポッド割り当てのためのトレラベル
updateStrategy {} デプロイによって使用されるアップデート戦略を設定できます。

チャート構成例

プルシークレット

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: 'v2.9.1-gitlab'
  • pullPolicy: 'IfNotPresent'

を設定します。service

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

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

名称 タイプ デフォルト 説明
name 文字列 registry サービス名の設定
type 文字列 ClusterIP サービスのタイプを設定します。
externalPort イント 5000 サービスが公開するポート
internalPort イント 5000 サービスからのリクエストを受け付けるためにポッドが使用するポート
clusterIP 文字列 null 必要に応じてカスタムクラスタIPを設定可能
loadBalancerIP 文字列 null 必要に応じてカスタムのロードバランサーIPアドレスを設定できます。

を設定します。ingress

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

名称 タイプ デフォルト 説明
annotations 文字列   このフィールドは、KubernetesIngressの標準annotations と完全に一致します。
enabled ブーリアン false Ingressオブジェクトをサポートするサービスに対してIngressオブジェクトを作成するかどうかを制御する設定。false の場合、global.ingress.enabled の設定が使用されます。
tls.enabled ブーリアン true falseに設定すると、レジストリサブチャートのTLSを無効にします。 これは主に、Ingress Controllerの前にTLS終端プロキシがある場合など、ingress-levelでTLS終端を使用できない場合に便利です。
tls.serviceName 文字列 redis レジストリ URL に対して有効な証明書とキーを含む Kubernetes TLS シークレットの名前。 設定されていない場合は、代わりにglobal.ingress.tls.secretName が使用されます。 デフォルトは設定されていません。

を設定します。networkpolicy

こ のセ ク シ ョ ン はオプシ ョ ンであ り 、 レ ジ ス ト リ の Egress と Ingress を特定の エ ン ド ポ イ ン ト に制限す る ために使用 さ れます。

名称 タイプ デフォルト 説明
enabled ブーリアン false この設定は、レジストリのネットワークポリシーを有効にします。
ingress.enabled ブーリアン false trueに設定すると、Ingress ネットワークポリシーが有効になります。ルールが指定されていない限り、すべての Ingress 接続がブロックされます。
ingress.rules 配列 [] 詳細はhttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource と以下の例を参照してください。
egress.enabled ブーリアン false trueに設定すると、Egress ネットワークポリシーが有効になります。ルールが指定されていない限り、すべてのイグレス接続がブロックされます。
egress.rules 配列 [] 詳細はhttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource と以下の例を参照してください。

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

レジストリサービスには通常、オブジェクトストレージへのegress接続、DockerクライアントからのIngress接続、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
    # 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

authEndpoint

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

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

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

証明書

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

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

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

デフォルトの例： 

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

互換性

compatibility フィールドは、コンフィギュレーション・ファイルの互換性セクションに直接関連するマップです。

デフォルトの内容です： 

compatibility:
  schema1:
    enabled: false

レディネス＆ライブネス・プローブ

デフォルトでは、デバッグ・ポートであるポート5001 の/debug/health をチェックするように、準備完了プローブと生存プローブが設定されています。

スキーマ1

schema1 セクションは、Docker マニフェストスキーマのバージョン 1 とのサービスの互換性を制御します。この設定は、1.10より前の Docker クライアントをサポートする手段として提供され、それ以降はスキーマ v2 がデフォルトで使用されます。

_どうしても_古いバージョンのDockerクライアントをサポートしたい場合は、registry.compatbility.schema1.enabled: true.

確認

validation フィールドは、レジストリ内のDockerイメージ検証プロセスを制御するマップです。 イメージ検証を有効にすると、レジストリは外部レイヤーを持つWindowsイメージを拒否します。

画像の検証はデフォルトではオフになっています。

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

通知

notifications フィールドはレジストリ通知を設定するために使用されます。 デフォルト値として空のハッシュがあります。

名称 タイプ デフォルト 説明
endpoints 配列 [] 各項目がエンドポイントに対応する項目のリスト。
events ハッシュ {} イベント通知で提供される情報

設定例は以下のようになります： 

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

ストレージ 

storage:
  secret:
  key: config
  extraKey:

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

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

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

storage ブロックの storage 中身を storage シークレットに storage入れ、マップstorage にアイテムとして以下を提供 storageします：

  • secretYAML ブロックを格納する Kubernetes Secret の名前。
  • keyデフォルトはconfigです。
  • extraKey:(オプション)コンテナ内の/etc/docker/registry/storage/${extraKey} にマウントされる、secret 内の追加キーの名前。これは、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

filesystem ドライバを選択した場合：

  • このデータ用に永続ボリュームを用意する必要があります。
  • hpa.minReplicasは次のように設定する必要があります。1
  • hpa.maxReplicasは次のように設定する必要があります。1

弾力性と簡素化のために、s3、gcs、azure またはその他の互換性のある Object Storage などの外部サービスを利用することをお勧めします。

注：Chartは、ユーザーが指定しない場合、デフォルトでこの設定にdelete.enabled: true 。 これは、Omnibus GitLabと同様に、MinIOのデフォルトの使用に合わせて期待される動作を維持します。 ユーザーが指定した値は、このデフォルトに優先します。

デバッグ

デバッグ・ポートはデフォルトで有効になっており、ライブネス／準備完了プローブに使用されます。 さらに、Prometheusメトリクスを有効にすることもできます。 

debug:
  addr:
    port: 5001
  prometheus:
    enabled: true
    path: '/metrics'

健康

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

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

ゴミ収集

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 :)