
Often, when deploying an app to OpenShift the deployment or deployment config YAML will contain the following.
spec:
triggers:
- type: ConfigChange
If using a deployment config (not a deployment), the oc get deploymentconfigs command can be used to see that TRIGGER BY has config and image.
~]$ oc get deploymentconfigs
NAME REVISION DESIRED CURRENT TRIGGERED BY
my-app 1 1 1 config,image(my-app:latest)
And the oc rollout history command will show there is only one revision.
~]$ oc rollout history deploymentconfig/my-app
deploymentconfig.apps.openshift.io/my-app
REVISION STATUS CAUSE
1 Complete config change
The triggers directive in the deployment or deployment config YAML will cause a new revision of a replica set or replication controller to be created when the deployment or deployment config YAML is changed or when the latest image is updated. For example, if using a deployment (not a deployment config), after the original deploy of the application, the oc get replicaset should have something like this.
~]# oc get replicaset
NAME DESIRED CURRENT READY AGE
my-app-5b9879db6d 1 1 1 55s
If using a deployment config, then the oc get replicationcontroller should have something like this.
~]$ oc get replicationcontroller
NAME DESIRED CURRENT READY AGE
my-app-1 1 1 1 42s
Let's say you make some change to the deployment or deployment config YAML. For example, perhaps you add an environment variable to the deployment or deployment config YAML.
spec:
template:
spec:
containers:
- env:
- name: foo
value: Hello
If using a deployment (not a deployment config), then the oc get replicaset should now have something like this, where there are now two replica sets, the first for the original deployment and the second after the deployment YAML was editted.
~]# oc get replicaset
NAME DESIRED CURRENT READY AGE
my-app-5b9879db6d 0 0 0 8m5s
my-app-f7496486ac 1 1 1 77s
If using a deployment config, then the oc get replicationcontroller should now have something like this, where there are now two replication controllers, the first for the original deployment and the second after the deployment config YAML was editted.
~]$ oc get replicationcontroller
NAME DESIRED CURRENT READY AGE
my-app-1 0 0 0 8m5s
my-app-2 1 1 1 77s
And the oc rollout history command should now show two revisions.
~]$ oc rollout history deploymentconfig/my-app
deploymentconfig.apps.openshift.io/my-app
REVISION STATUS CAUSE
1 Complete config change
2 Complete config change
Let's say you remove the following from the deployment or deployment config YAML.
spec:
triggers:
- type: ConfigChange
If using a deployment config (not a deployment), the oc get deploymentconfigs command can be used to see that TRIGGER BY no longer has config.
~]$ oc get deploymentconfigs
NAME REVISION DESIRED CURRENT TRIGGERED BY
my-app 1 1 1 image(my-app:latest)
And then you make some other change to the deployment or deployment config YAML. For example, perhaps you add another environment variable to the deployment or deployment config YAML.
spec:
template:
spec:
containers:
- env:
- name: bar
value: World
Since the trigger was removed, a new replica set or replication controller will not be created, and as such, new pod will also not be created. The oc rollout latest command can be used to create new pods for the deployment config. A new replication controller will not be created, so this is a good option to prevent a bunch of new replication controllers from being created as changes are made to the deployment config YAML.
~]$ oc rollout latest dc/my-app
deploymentconfig.apps.openshift.io/my-app rolled out
If using a deployment (not a deployment config), the oc rollout restart deployment command can be used.
~]$ oc rollout restart deployment/my-app
deployment.apps.openshift.io/my-app rolled out
Did you find this article helpful?
If so, consider buying me a coffee over at