{{ template "chart.header" . }}

{{ template "chart.versionBadge" . }}{{ template "chart.typeBadge" . }}{{ template "chart.appVersionBadge" . }}

{{ template "chart.requirementsSection" . }}

## Getting started
The docker registry helm chart has a flag that enables the service, `enabled`, which is true by default. To disable it, just set `--set docker-registry.enabled=false` when doing `helm install`.

## Local testing


```sh

kubectl port-forward pod/docker-registry-0 5001:5000
docker pull hello-world
docker tag hello-world localhost:5001/hello-world
docker push localhost:5001/hello-world

# Do other docker cool stuffs

```

**Note**  To test it locally, you probably need to set the forwarded service in the `insecure-registries` as an entry. 

## Adding more configurationss

The docker registry service is highly customizable. Yet, instead of providing a full `config.yaml`, we override values from the `config` field in the `values.yaml`. To read more about, we refer you to https://distribution.github.io/distribution/about/configuration/#override-specific-configuration-options. As an example, we set the registry to support `delete` operations, see [values.yaml](./values.yaml)


## Patch container engine for trusting private registries

If the value of `tamperContainerEngine` is true, a daemonSet will start to tamper the container engine in the underlying host nodes. This tampering ensures that kubelet trusts the private registry mounted by this helm chart. This ensures that kubelet uses it to pull images without complaining about secure registries. For example, `kubectl run tet2 --image=localhost:30443/filebeat:4.0.0-SNAPSHOT --restart=Never` will run without issues as soon as the tampering is done.

**We already tested this flag in OVH and it works** 

**Note** that the daemon set runs in privileged mode. While we only use it for internal container operations, it might carry some security issues.

**Note** if the CI integration tests pass, it only means that this hack works for CRI-O. OVH uses containerd + docker. Thus, we cover these three cases.

## Catching the certificate to trust

We have two options to mount the certificate. First, the certifciate could come from the secret generated by the certs-operator, in which case we mount it as a volume and use the root certificate. To use this option set the value `trustCA = USE_ROOT_HOPSWORKS_CA`.

Second, instead of mounting the same certificate as the one generated for our registry, we make a call as `openssl s_client -connect registry.domain > ca.hops.root.crt`. This allows to use *self-signed* registries outside the cluster. Otherwise, we would need that the registry always use the same certificate we mount from the certs-operator root CA cert.
To use this option set the values `trustCA = RETRIEVE_FROM_ENDPOINT` and `trustCA = USE_ROOT_HOPSWORKS_CA`.

**Note** the `USE_ROOT_HOPSWORKS_CA` flag has precedence over `RETRIEVE_FROM_ENDPOINT`.

## Experimental object storage with MinIO

If the `config` value is not changed, the docker registry will use MinIO as the default storage. See the `minio` subchart for more info.

## Production Notes

**OVH** For OVH, set the system wise tampering instead of editing the config.toml file. To do so set the following value `docker-registry.tamperContainerEngine.patchOS=true`

{{ template "chart.valuesSection" . }}