Reputation: 75406
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
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
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.
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