Rolling Back a Deployment

Rollbacks revert an application back to a previous revision and can be
performed using the REST API, the CLI, or the web console.

To rollback to the last successful deployed revision of your configuration:

$ oc rollout undo dc/<name>

The deployment configuration’s template will be reverted to match the deployment
revision specified in the undo command, and a new replication controller will be
started. If no revision is specified with --to-revision, then the last
successfully deployed revision will be used.

Image change triggers on the deployment configuration are disabled as part of
the rollback to prevent accidentally starting a new deployment process soon after
the rollback is complete. To re-enable the image change triggers:

$ oc set triggers dc/<name> --auto

Deployment configurations also support automatically rolling back to the
last successful revision of the configuration in case the latest deployment
process fails. In that case, the latest template that failed to deploy stays
intact by the system and it is up to users to fix their configurations.

Executing Commands Inside a Container

You can add a command to a container, which modifies the container’s startup
behavior by overruling the image’s ENTRYPOINT. This is different from a
lifecycle hook,
which instead can be run once per deployment at a specified time.

Add the command parameters to the spec field of the deployment
configuration. You can also add an args field, which modifies the
command (or the ENTRYPOINT if command does not exist).

Viewing Deployment Logs

To stream the logs of the latest revision for a given deployment configuration:

$ oc logs -f dc/<name>

If the latest revision is running or failed, oc logs will return the logs of
the process that is responsible for deploying your pods. If it is successful,
oc logs will return the logs from a pod of your application.

You can also view logs from older failed deployment processes, if and only if
these processes (old replication controllers and their deployer pods) exist and
have not been pruned or deleted manually:

$ oc logs --version=1 dc/<name>

For more options on retrieving logs see:

$ oc logs --help

Setting Deployment Triggers

A deployment configuration can contain triggers, which drive the creation of
new deployment processes in response to events inside the cluster.

If no triggers are defined on a deployment configuration, a ConfigChange
trigger is added by default. If triggers are defined as an empty field, deployments
must be started manually.

Configuration Change Trigger

The ConfigChange trigger results in a new replication controller whenever
changes are detected in the pod template of the deployment configuration.

If a ConfigChange trigger is defined on a deployment configuration,
the first replication controller will be automatically created soon after
the deployment configuration itself is created and it is not paused.

Example 1. A ConfigChange Trigger

triggers:
- type: "ConfigChange"

ImageChange Trigger

The ImageChange trigger results in a new replication controller whenever the
content of an
image
stream tag changes (when a new version of the image is pushed).

If the imageChangeParams.automatic field is set to false,
the trigger is disabled.

With the above example, when the latest tag value of the origin-ruby-sample
image stream changes and the new image value differs from the current image
specified in the deployment configuration’s helloworld container, a new
replication controller is created using the new image for the helloworld container.

If an ImageChange trigger is defined on a deployment configuration (with a
ConfigChange trigger and automatic=false, or with automatic=true) and the
ImageStreamTag pointed by the ImageChange trigger does not exist yet, then
the initial deployment process will automatically start as soon as an image is
imported or pushed by a build to the ImageStreamTag.

Using the Command Line

The oc set triggers command can be used to set a deployment trigger for a
deployment configuration. For the example above, you can set the
ImageChangeTrigger by using the following command:

Setting Deployment Resources

A deployment is completed by a pod that consumes resources (memory and CPU) on a
node. By default, pods consume unbounded node resources. However, if a project
specifies default container limits, then pods consume resources up to those
limits.

You can also limit resource use by specifying resource limits as part of the
deployment strategy. Deployment resources can be used with the Recreate,
Rolling, or Custom deployment strategies.

In the following example, each of resources, cpu, and memory is
optional:

type: "Recreate"resources:
limits:
cpu: "100m"(1)memory: "256Mi"(2)

1

cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3).

2

memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20).

However, if a quota has been defined for your project, one of the following two
items is required:

A resources section set with an explicit requests:

type: "Recreate"resources:
requests: (1)cpu: "100m"memory: "256Mi"

1

The requests object contains the list of resources that correspond to
the list of resources in the quota.

Manual Scaling

In addition to rollbacks, you can exercise fine-grained control over
the number of replicas from the web console, or by using the oc scale command.
For example, the following command sets the replicas in the deployment
configuration frontend to 3.

$ oc scale dc frontend --replicas=3

The number of replicas eventually propagates to the desired and current
state of the deployment configured by the deployment configuration frontend.

Pods can also be autoscaled using the oc autoscale command. See Pod Autoscaling
for more details.

Assigning Pods to Specific Nodes

You can use node selectors in conjunction with labeled nodes to control pod
placement.

Cluster administrators
can set the
default node selector for your project in order to restrict pod placement to
specific nodes. As an OpenShift Container Platform developer, you can set a node selector on
a pod configuration to restrict nodes even further.

To add a node selector when creating a pod, edit the pod configuration, and add
the nodeSelector value. This can be added to a single pod configuration, or in
a pod template:

apiVersion: v1
kind: Pod
spec:
nodeSelector:
disktype: ssd
...

Pods created when the node selector is in place are assigned to nodes with the
specified labels.

For example, if a project has the type=user-node and
region=east labels added to a project by the cluster administrator, and you
add the above disktype: ssd label to a pod, the pod will only ever be
scheduled on nodes that have all three labels.

Labels can only be set to one value, so setting a node selector of region=west
in a pod configuration that has region=east as the administrator-set default,
results in a pod that will never be scheduled.

Running a Pod with a Different Service Account

You can run a pod with a service account other than the default:

Edit the deployment configuration:

$ oc edit dc/<deployment_config>

Add the serviceAccount and serviceAccountName parameters to the spec
field, and specify the service account you want to use: