Parameters

The parent key for all of the following parameters is openshift4_registry.

`config`

type	dictionary
default	Default image registry.

A dictionary holding the .spec for the image registry config. The component will overwrite config.routes with the processed contents of parameter routes if that parameter exists.

See the OpenShift docs for available parameters.

`config.routes`

type	array
default	undefined

Using this parameter is deprecated starting from component version v1.0.0. Use parameter openshift4_registry.routes to configure custom routes for the registry instead.

`config.storage`

type	dictionary
default	undefined

Configure the registry storage based on the cloud provider.

It’s suggested to define this higher up the config hierarchy. Most probably the one of the cloud region.

`routes`

type	dictionary
default	`{}`

To create custom routes for exposing the registry, create entries in this dictionary (see Example). Each value of the dictionary should be another dictionary. Keys hostname and secretName can be used to configure the hostname and TLS secret for each entry.

Each entry in the dictionary is transformed into an entry in the image registry config .spec.routes array. The key of each entry is used as the value for field name of the resulting entry in .spec.routes. If key secretName isn’t provided for an entry, the router’s default wildcard certificate is used for that route.

`preferredRegistryRoute`

type	string
default	`~` (null)

This parameter can be used to specify which route’s hostname should be used in the field .status.publicDockerImageRepository of ImageStream resources. The parameter should be set to a key which is present in parameter routes. If the default value inferred by the cluster should be used, leave the value of this parameter set to null.

If the value of the parameter doesn’t match a key in parameter routes, the component will print a warning and ignore the configuration.

`secrets`

type	dictionary
default	`{}`

Each entry in parameter secrets is deployed onto the cluster as a Kubernetes Secret with type=kubernetes.io/tls. Entries with null values are skipped. This allows users to remove secrets which were configured higher up in the hierarchy. All secrets are deployed in namespace openshift-image-registry.

The component has basic validation to ensure the secret contents are a plausible Kubernetes TLS secret.

The dictionary keys are used as metadata.name for the resulting Secret resources. The dictionary values are directly merged into a Secret resource which only has type=kubernetes.io/tls set. The secrets are created in the namespace indicated by parameter namespace.

`cert_manager_certs`

type	dictionary
default	`{}`

Each entry in parameter cert_manager_certs is deployed onto the cluster as a cert-manager Certificate resource. Entries with null values are skipped. This allows users to remove certificates which were configured higher up in the hierarchy. All Certificate resources are deployed in namespace openshift-image-registry.

The dictionary keys are used as metadata.name and spec.secretName for the resulting Certificate resources. The dictionary values are then directly directly merged into the mostly empty Certificate resources.

`pruning`

type	dictionary
default	Default pruning options.

A dictionary holding the .spec for the image pruning config.

See the OpenShift docs for available parameters.

To disable image pruning, set the paramteter pruning.suspend to true.

`s3Credentials`

type	dictionary
default	undefined

A dictionary holding a set of S3 credentials. If set, the secret image-registry-private-configuration-user will be created containing the credentials. Use this when configuring an S3 type for config.storage.

`accessKey`

type	string
default	undefined

Access key for an S3 type storage.

`secretKey`

type	string
default	undefined

Secret key for an S3 type storage.

`pvc`

type	dictionary
default	`{}`

This parameter allows customizing the registry PVC when config.storage.pvc is set. The PVC is created with the name given in config.storage.pvc.claim. The parameter contents are used verbatim for the PVC resource.

The component doesn’t verify whether the PVC configuration and the contents of parameter config will result in a working image registry. Please make sure you configure the registry appropriately for the provided PVC definition.

For example, you could use the following snippet to configure the registry to use an RWO PVC:

parameters:
  openshift4_registry:
    config:
      replicas: 1
      rolloutStrategy: Recreate
      storage:
        pvc:
          claim: image-registry-storage

    pvc:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Gi

Example

parameters:
  openshift4_registry:
    routes: (1)
      primary-route:
        hostname: registry.example.com
        secretName: primary-route-tls
      secondary-route:
        hostname: registry.cluster.example.org
        secretName: secondary-route-tls
    preferredRegistryRoute: primary-route (2)
    cert_manager_certs:
      primary-route-tls: (3)
        spec:
          dnsNames:
            - registry.example.com
          issuerRef:
            kind: ClusterIssuer
            name: letsencrypt-staging
    secrets:
      secondary-route-tls: (4)
        stringData:
          tls.key: '?{vaultkv:...}'
          tls.crt: '?{vaultkv:...}'
    config:
      storage:
        s3:
          bucket: ${cluster:name}-image-registry
          region: somewhere
          regionEndpoint: https://objects.example.com
    s3Credentials:
       accessKey: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4_registry/s3_access_key}'
       secretKey: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4_registry/s3_secret_key}'
    pruning:
      schedule: '13 */2 * * *'

1	Configure routes in top-level parameter `routes`. This configuration will result in the following contents for `config.routes`: `- name: primary-route hostname: registry.example.com secretName: primary-route-tls - name: secondary-route hostname: registry.cluster.example.org secretName: secondary-route-tls`
2	This configuration ensures that `ImageStream` resources on the cluster will have `registry.example.com` as hostname in their `publicDockerImageRepository` value.
3	Configure a cert-manager `Certificate` resource to generate the TLS secret for route `primary-route`.
4	Directly configure a TLS secret for route `secondary-route`. As shown in the example, the TLS key and certificate can be fetched from Vault by using secret references.