0
votes

I'm trying to work out that if an image change trigger can fire based on an update to an image in a different OpenShift cluster.

e.g.: If I have a cluster non-prod and prod cluster, can I have a deployment configured in cluster prod with an image change trigger, with the image coming from the cluster non-prod's image registry?

I followed documentation here:

  1. https://dzone.com/articles/pulling-images-from-external-container-registry-to
  2. https://docs.openshift.com/container-platform/4.5/openshift_images/managing_images/using-image-pull-secrets.html

And based on above document ,

  1. I created docker-registry secret in prod Cluster with docker-password = default-token-value from non-prod/project secret. The syntax used:

oc create secret docker-registry non-prod-registry-secret --namespace <<prod-namespace>> --docker-server non-prod-image-registry-external-route --docker-username serviceaccount --docker-password <<base-64-default-token-value>> --docker-email [email protected]

  1. Also link builder, deployer and default SA with the new secret created above.

  2. I also create image-stream in prod cluster like this:

oc import-image my-image-name --from=non-prod-image-registry-external-route/project/nonprodimage:latest --confirm --scheduled=true --dry-run=false -n prod-namespace

The imagestream was created successfully in the prod cluster and was referring to the latest sha:xxx identifier in the prod-namespace.

However when creating a deployment thru oc new-app my-image-name:latest --name mynewapp on the above imagestream, it generates ImagePullBAckOff. Here is the exact error message:

Failed to pull image "non-prod-image-registry-external-route/non-prod-namespace/nonprodimage:shaxxx": rpc error: code = Unknown desc = error pinging docker registry non-prod-image-registry-external-route: Get https://non-prod-image-registry-external-route/v2/: x509: certificate signed by unknown authority

1

1 Answers

0
votes

I have this setup working following a similar process. Since our organization requires periodic password resets, creating a docker-registry secret based on my credentials was not a good solution.

Instead, we created a dedicated service account in the non-prod environment, pulled down the associated docker config and created an "image promotion" secret based on it in stage and prod environments.

Only comment I had based on your post and the error message:

x509: certificate signed by unknown authority

is to use the insecure sub-command option:

--insecure=false: If true, allow importing from registries that have invalid HTTPS certificates or are hosted via HTTP. This flag will take precedence over the insecure annotation.