How to get rollback to use the older image instead of staying on the newest (externally built)?

We are moving our build process outside our OpenShift 3.11 cluster and have noticed that when wanting to rollback to an older deployment the docker image used is not the old one but the newest one known to OpenShift.

I saw for images built by an OpenShift source build that this worked, but for our externally built images which are pushed to the openshift external docker registry and then oc new-app registry/foo/bar:master (which creates an image stream for this) this does not work.

Can this be achieved at all?

Do I need extra metadata on my docker image?

Do I need to tell OpenShift more about my image?


Note: Opened https://github.com/openshift/origin/issues/23754 in Origin - the open source project below the Redhat stuff - about this

Upvotes: 5

Views: 9297

Answers (2)

Hendrik M Halkow
Hendrik M Halkow

Reputation: 2312

Use immutable tags.

As you are addressing your images with a tag called master, I assume the you are currently using mutable tags that get updated with every image build. With this, you can just “roll back” by reverting your commit and re-building your old image, but then you still get an updated base image and different metadata.

If you design your whole release process around immutable tags you can do exactly what you want. To achieve that, use one of the following approaches:

(1) Address your image via image digest. In that case, you need a registry that keeps your images even if they are not tagged. For example, Quay.io does not keep untagged images and you can only pull the latest version. To avoid that, just add a dummy tag, e.g. the image digest.

(2) Release your images with semantic versioning, e.g. by using Angular commit messages and adding semantic-release to your build pipeline. Make sure that the base image you are using is immutable, too. To deploy the images to the our cluster, use a GitOps workflow with a tool like Flux CD. Now you can easily roll back by reverting a commit in your GitOps repo.

(3) Reconsider whether you need rollback at all. Alternatively, you can use canary deployments with Istio that comes with OpenShift 4. Instead of rolling back, you just deploy two versions of your app at the same time, then you use Istio to route the traffic to the one or the other until you are happy.

Upvotes: 3

ProllyGeek
ProllyGeek

Reputation: 15856

For rolling back to a specific version you just need to specify the version, newest will be rolled back to automatically if you dont specify deployment version.

DOCs

Image change triggers on the deployment configuration are disabled as part of the rollback to prevent unwanted deployments soon after the rollback is complete. To re-enable the image change triggers:

$ oc deploy <deployment_config> --enable-triggers 

To roll back to aspecific version:

$ oc rollback <deployment_config> --to-version=1

Upvotes: 1

Related Questions