$ oc create -f gluster-endpoints-service.yaml $ oc create -f gluster-endpoints.yaml $ oc create -f gluster-pv.yaml $ oc create -f gluster-pvc.yaml
This topic reviews how to attach a GlusterFS persistent volume to the Docker Registry.
It is assumed that the Docker registry service has already been started and the Gluster volume has been created.
The docker-registry was deployed without configuring storage.
A Gluster volume exists and glusterfs-fuse is installed on schedulable nodes.
Definitions written for GlusterFS endpoints and service, persistent volume (PV), and persistent volume claim (PVC).
For this guide, these will be:
gluster-endpoints-service.yaml
gluster-endpoints.yaml
gluster-pv.yaml
gluster-pvc.yaml
A user with the cluster-admin role binding.
For this guide, that user is admin.
All |
First, make the Gluster volume available to the registry.
$ oc create -f gluster-endpoints-service.yaml $ oc create -f gluster-endpoints.yaml $ oc create -f gluster-pv.yaml $ oc create -f gluster-pvc.yaml
Check to make sure the PV and PVC were created and bound successfully. The expected output should resemble the following. Note that the PVC status is Bound, indicating that it has bound to the PV.
$ oc get pv NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE gluster-pv <none> 1Gi RWX Available 37s $ oc get pvc NAME LABELS STATUS VOLUME CAPACITY ACCESSMODES AGE gluster-claim <none> Bound gluster-pv 1Gi RWX 24s
If either the PVC or PV failed to create or the PVC failed to bind, refer back to the GlusterFS Persistent Storage guide. Do not proceed until they initialize and the PVC status is Bound. |
Before moving forward, ensure that the docker-registry service is running.
$ oc get svc NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE docker-registry 172.30.167.194 <none> 5000/TCP docker-registry=default 18m
If either the docker-registry service or its associated pod is not running, refer back to the docker-registry setup instructions for troubleshooting before continuing. |
Then, attach the PVC:
$ oc volume deploymentconfigs/docker-registry --add --name=v1 -t pvc \ --claim-name=gluster-claim --overwrite
Deploying a Docker Registry provides more information on using the Docker registry.
In non-production cases where the dnsmasq server is located on the same node as the OpenShift Enterprise master service, pods might not resolve to the host machines when mounting the volume, causing errors in the docker-registry-1-deploy pod. This can happen when dnsmasq.service fails to start because of a collision with OpenShift dns on port 53. To run the dns server on the master host, some configurations needs to be changed.
In /etc/dnsmasq.conf, add:
# Reverse dns record for master host-record=master.example.com,<master-IP> # Wildcard dns for OpenShift Applications - Points to Router address=/apps.example.com/<master-IP> # Forward .local queries to Skydns server=/local/127.0.0.1#8053 # Forward reverse queries for service network to Skydns. # This is for default OpenShift SDN - change as needed. server=/17.30.172.in-addr.arpa/127.0.0.1#8053
With these settings, dnsmasq will pull from the /etc/hosts file on the master node.
Add the appropriate host names and IPs for all necessary hosts.
In master-config.yaml, change bindAddress
to:
dnsConfig: bindAddress: 127.0.0.1:8053
When pods are created, they receive a copy of /etc/resolv.conf, which typically contains only the master dns server so they can resolve external dns requests. To enable internal dns resolution, insert the dnsmasq server at the top of the server list. This way, dnsmasq will attempt to resolve requests internally first.
In /etc/resolv.conf all scheduled nodes:
nameserver 192.168.1.100 (1) nameserver 192.168.1.1 (2)
1 | Add the internal dns server. |
2 | Pre-existing external dns server. |
Once the configurations are changed, restart the OpenShift Enterprise master and dnsmasq services.
$ systemctl restart atomic-openshift-master $ systemctl restart dnsmasq