Deployments

In this lesson we examine deployments in OpenShift: what they are, how they relate to Kubernetes concepts, and how to manage them using the console and CLI. Key topics covered: DeploymentConfig, image-based triggers, deployment strategies (Rolling, Recreate, Blue/Green, A/B), and common rollout commands.

Deployment concept recap

Deployments in OpenShift map closely to Kubernetes deployments but use OpenShift-specific API kinds and features. Briefly, the object hierarchy is:

Container image (built with Docker or S2I)
Pod — the smallest deployable unit (one or more containers)
ReplicaSet / ReplicationController — ensures the desired number of Pod replicas
Deployment / DeploymentConfig — manages lifecycle (rolling upgrades, rollbacks, revision history)

Most apps run a single container per Pod, meaning a Pod is typically a single instance of your application. Replication ensures high availability by running multiple Pod instances.

A slide titled "Deployment Controller" showing red container icons representing containers/PODs organized under a Replication Controller and a larger Deployment Controller. The deployment column also includes three hexagon action icons (download, upload, sync).

OpenShift workflow: BuildConfig, ImageStream, DeploymentConfig

When you add an application to a project in OpenShift, the platform typically creates:

A BuildConfig — defines how the image is built.
An ImageStream — a logical reference to images produced by builds.
A DeploymentConfig — controls application deployment and lifecycle.

In the web console you’ll find deployments under Applications → Deployments. A DeploymentConfig commonly references the image produced by a BuildConfig via an ImageStream tag, declares the replica count, and defines the deployment strategy (for example, Rolling). Triggers determine how deployments run:

Manual: Click Deploy in the UI or use the CLI to trigger.
Automatic: An image change trigger starts a deployment when the ImageStream tag referenced by the DeploymentConfig is updated (for example, when a build completes).

Example console output and a manual trigger:

# Sample build/deploy information (console-style)
Image: myproject/sample-webapp-docker:08b7500 211.1 MiB
Build: sample-webapp-docker #5
Source: Update app.py ca92a69 authored by Administrator
Ports: 8080/TCP

# Manually trigger the latest rollout for the DeploymentConfig
oc rollout latest dc/sample-webapp-docker -n myproject

# Image stream reference
myproject/sample-webapp-docker:latest

You can inspect or edit a DeploymentConfig as YAML from the UI (Actions → Edit YAML). The structure resembles a Kubernetes Deployment but uses the OpenShift API group and kind.

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: sample-webapp-docker
spec:
  replicas: 1
  selector:
    deploymentconfig: sample-webapp-docker
  strategy:
    type: Rolling
  template:
    metadata:
      labels:
        app: sample-webapp-docker
        deploymentconfig: sample-webapp-docker
    spec:
      containers:
        - image: myproject/sample-webapp-docker
          imagePullPolicy: Always
          name: sample-webapp-docker
          ports:
            - containerPort: 8080
              protocol: TCP
  triggers:
    - imageChangeParams:
        automatic: true
        containerNames:
          - sample-webapp-docker
        from:
          kind: ImageStreamTag
          name: 'sample-webapp-docker:latest'
          namespace: myproject
        lastTriggeredImage: >-
          172.30.1.1:5000/myproject/sample-webapp-docker@sha256:08b750083d53e8fdfc09ab99bc30549141ea44c90763d3e972be264fbec8d706
      type: ImageChange
    - type: ConfigChange

DeploymentConfig (kind: DeploymentConfig) is OpenShift-specific and provides image-change triggers and lifecycle hooks. Kubernetes uses kind: Deployment; many fields are similar, but the API kinds and some behaviors differ.

You can view and edit strategy-related settings (timeout, maxUnavailable, maxSurge, etc.) from the console when configuring rolling or recreate behavior.

A screenshot of a web UI titled "Edit Deployment Configuration" showing deployment strategy settings for a sample webapp (strategy type set to "Rolling", timeout 600 seconds). It includes fields for maximum unavailable pods and surge pods (both set to 25%).

Deployment history and rollback

The OpenShift web console preserves deployment history. Each deployment increments an internal version number. To roll back, choose an earlier version in the history and select Roll Back.

A slide titled "Rollback" showing two web console panels for "sample-webapp-docker." The panels display deployment history on the left and deployment details (status, replicas, template and a "Roll Back" button) on the right.

Deployment strategies

Recreate: Terminates all existing Pods, then creates new Pods for the updated version. Suitable when you cannot run multiple versions concurrently, but it causes downtime during the transition.
Rolling (default): Updates Pods incrementally so the application remains available. If you don’t choose a strategy, OpenShift uses Rolling by default.

Advanced approaches for safer rollouts:

Blue/Green: Deploy a separate “green” environment alongside the current “blue” one. Test green, then switch traffic from blue to green (for example, via router or load balancer configuration).

A slide titled "Advanced Strategies — Blue/Green" showing a diagram of blue and green application instances. Two blue boxes labeled app:v1 and two green boxes labeled app:v2 are shown with routing arrows indicating traffic switching.

A/B (traffic-splitting): Route a small percentage of real traffic to the new version and monitor metrics. Gradually increase traffic until the new version receives full load.

Table: comparison of common strategies

Strategy	Availability during update	Use case
Rolling	High (incremental updates)	Default; minimal downtime and continuous availability
Recreate	Low (downtime)	When multiple versions cannot run simultaneously
Blue/Green	High (explicit switch)	Complete environment testing before switching traffic
A/B	High (gradual traffic shift)	Canary/testing new behavior with partial traffic

Automatic image-change triggers can start deployments as soon as a build finishes. If you need predictable rollout timing, consider disabling the automatic trigger and triggering deployments manually with oc rollout latest.

Common rollout commands

Trigger a manual rollout
View rollout history or status
Roll back to a prior revision
Inspect the DeploymentConfig resource

Command	Purpose
`oc rollout latest dc/simple-webapp-docker`	Trigger a new deployment (manual rollout)
`oc rollout history dc/simple-webapp-docker`	Show rollout history (revisions)
`oc rollout status dc/simple-webapp-docker`	Show the current rollout status
`oc rollout undo dc/simple-webapp-docker`	Roll back to the previous revision
`oc describe dc/simple-webapp-docker`	Inspect the DeploymentConfig resource

Example CLI summary:

# Trigger a new deployment (manual rollout)
oc rollout latest dc/simple-webapp-docker

# Show the rollout history (revisions)
oc rollout history dc/simple-webapp-docker

# Show the current rollout status
oc rollout status dc/simple-webapp-docker

# Roll back to the previous revision
oc rollout undo dc/simple-webapp-docker

# Inspect the DeploymentConfig resource
oc describe dc/simple-webapp-docker

Introduction

Pre-Requisite - Docker and Kubernetes

Getting Started with OpenShift

OpenShift Concepts - Projects and Users

Concepts - Builds and Deployments

Networks, Services, Routes and Scaling

Storage, Templates and Catalog

Conclusion and APPENDIX

Deployment concept recap

OpenShift workflow: BuildConfig, ImageStream, DeploymentConfig

Deployment history and rollback

Deployment strategies

Common rollout commands

Further reading

Watch Video

​Deployment concept recap

​OpenShift workflow: BuildConfig, ImageStream, DeploymentConfig

​Deployment history and rollback

​Deployment strategies

​Common rollout commands

​Further reading

Watch Video

Deployment concept recap

OpenShift workflow: BuildConfig, ImageStream, DeploymentConfig

Deployment history and rollback

Deployment strategies

Common rollout commands

Further reading