Bootstrap FreeKB - OpenShift - Deploy a new version of an application using the oc rollout command
OpenShift - Deploy a new version of an application using the oc rollout command

Updated:   |  OpenShift articles

An image contains the code used to create a deployment. Then, a deployment can be created from an image, which should then create a replica set (which is the number of pods that should be created), and then the pods should be created.

If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

When deploying an application using the oc new-app command, if the --as-deployment-config flag is not used, the application will be created as a deployment, not a deployment config. In this scenario, you would need to delete the current deployment and the deploy the application again from the latest image. On the other hand, if the --as-deployment-config flag is used to deploy the application, the oc rollout command can be used to update the deployment from the latest image.

The oc get deploymentconfigs command can be used to list the deployments configs in the currently selected project. Notice in this example that TRIGGER BY has config and image.

~]$ oc get deploymentconfigs
my-app    1          1         1         config,image(my-app:latest)


In the deployment config YAML, you should see triggers for config and image change. This means that when the deployment config YAML is changed or when the latest image is updated:

  1. The current replication controller will be set to 0 pods
  2. The current pods will be terminated
  3. A new replication controller will be created
  4. New pods will be deployed

Check out my article on triggers for more details on this.

  - type: ConfigChange
  - imageChangeParams:


The oc rollout latest command can be used to update the deployment to the latest image.

~]$ oc rollout latest deploymentconfig/my-app rolled out


And then the oc rollout history command can be used to see that the latet image was rolled out. In this example, revision 1 is the original deployment and revision 2 is the roll out.

~]# oc rollout history deploymentconfig/my-app
1           Complete    config change
2           Complete    manual change


If some problem occurs with the new deployment, the oc rollout undo command can be used to go back to a prior revision.

~]# oc rollout undo --to-revision 1 deploymentconfig/my-app rolled back


Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee


Add a Comment

Please enter 00668d in the box below so that we can be sure you are a human.