Demo Deployments

Welcome — this lesson walks through creating an OpenShift DeploymentConfig to deploy a Docker image you previously built. We cover:

A reusable DeploymentConfig template
Common validation errors and fixes
How ImageStream tags and DeploymentConfig triggers work
A simple end-to-end test using a code change that triggers build → image → deployment

Prerequisite: You already have a project (namespace) in OpenShift and an ImageStream (or build) that will provide the image tag referenced by the DeploymentConfig.

Quick overview

DeploymentConfig manages application lifecycle in OpenShift (rolling updates, triggers, scaling).
ConfigChange triggers a deployment when the DeploymentConfig spec changes.
ImageChange triggers a deployment when the referenced ImageStreamTag is updated (for example, after a build pushes a new image).

Below is a template DeploymentConfig you can use as a starting point.

kind: "DeploymentConfig"
apiVersion: "apps.openshift.io/v1"
metadata:
  name: "frontend"
spec:
  template:
    metadata:
      labels:
        name: "frontend"
    spec:
      containers:
        - name: "helloworld"
          image: "openshift/origin-ruby-sample"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 5
  triggers:
    - type: "ConfigChange"
    - type: "ImageChange"
      imageChangeParams:
        automatic: true
        containerNames:
          - "helloworld"
        from:
          kind: "ImageStreamTag"
          name: "origin-ruby-sample:latest"
  strategy:
    type: "Rolling"
  paused: false
  revisionHistoryLimit: 2
  minReadySeconds: 0

Use this template to adapt the metadata, labels, container name, and image name to match your application.

Example: initial DeploymentConfig used during testing

For a typical test deployment I used a minimal configuration (replicas set to 1):

kind: "DeploymentConfig"
apiVersion: "apps.openshift.io/v1"
metadata:
  name: "simple-webapp-docker"
spec:
  template:
    metadata:
      labels:
        name: "simple-webapp-docker"
    spec:
      containers:
        - name: "simple-webapp-docker"
          image: "simple-webapp-docker"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 1
  triggers:
    - type: "ConfigChange"
    - type: "ImageChange"
      imageChangeParams:
        automatic: true
        containerNames:
          - "simple-webapp-docker"
        from:
          kind: "ImageStreamTag"
          name: "simple-webapp-docker"
  strategy:
    type: "Rolling"

Important: ImageStreamTag format

When importing this YAML into the OpenShift web console (Add to Project → Import YAML or JSON), OpenShift validates the manifest and returns errors for invalid fields. In my case the server returned:

Unable to create the deployment config 'simple-webapp-docker'.
Reason: DeploymentConfig "simple-webapp-docker" is invalid:
spec.triggers[1].imageChangeParams.from.name: Invalid value: "simple-webapp-docker": must be in the form of `name:tag`

The error indicates the imageChangeParams.from.name must include an explicit tag (for example :latest). Update from.name to an ImageStream tag in the form name:tag to satisfy validation. Here is the corrected DeploymentConfig — note the change to from.name: "simple-webapp-docker:latest":

kind: "DeploymentConfig"
apiVersion: "apps.openshift.io/v1"
metadata:
  name: "simple-webapp-docker"
spec:
  template:
    metadata:
      labels:
        name: "simple-webapp-docker"
    spec:
      containers:
        - name: "simple-webapp-docker"
          image: "simple-webapp-docker"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 1
  triggers:
    - type: "ConfigChange"
    - type: "ImageChange"
      imageChangeParams:
        automatic: true
        containerNames:
          - "simple-webapp-docker"
        from:
          kind: "ImageStreamTag"
          name: "simple-webapp-docker:latest"
  strategy:
    type: "Rolling"
  paused: false
  revisionHistoryLimit: 2
  minReadySeconds: 0

After applying the corrected YAML, OpenShift creates the DeploymentConfig and starts one replica. You can also click the Deploy button in the UI to trigger a manual deployment.

Always specify ImageStream tags in the format name:tag (for example my-app:latest) when using ImageStreamTag in DeploymentConfig triggers. If you omit the tag, validation will fail.

Triggers — quick reference

Trigger type	Behavior	Typical use
`ConfigChange`	Deploys when the DeploymentConfig spec changes	Updating environment variables, resource requests, labels
`ImageChange`	Deploys when the specified `ImageStreamTag` is updated	New image pushed by a build or image import

Example snippet for ImageChange in a DeploymentConfig:

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true
      containerNames:
        - "simple-webapp-docker"
      from:
        kind: "ImageStreamTag"
        name: "simple-webapp-docker:latest"

End-to-end flow recap

Your build configuration produces a new image and updates an ImageStream tag (for example, simple-webapp-docker:latest).
The ImageChange trigger on the DeploymentConfig watches that ImageStream tag.
When the tag updates, OpenShift automatically starts a new deployment using the updated image.

To test the full flow, make a small code change, push it to your source repository, and let the automated build run. When the build finishes and updates the ImageStream tag, OpenShift will automatically create a new deployment.

Example Flask change (triggers a build if your build config reacts to source changes)

import os
from flask import Flask
app = Flask(__name__)

@app.route("/")
def main():
    return "Welcome! Update 2"

@app.route("/how-are-you")
def hello():
    return "I am good, how about you?"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Exposing the application externally

Note: This lesson does not expose the application to external traffic. To make your app reachable from outside the cluster, create a Service and a Route (or configure an Ingress depending on your cluster setup). See the OpenShift documentation for examples and best practices.

If you expose your application externally, ensure proper network policies, TLS, and authentication are in place for production workloads. Misconfigured routes or unsecured services can expose sensitive data.

Quick troubleshooting checklist

If you see validation errors for imageChangeParams.from.name — ensure it is name:tag (for example my-app:latest).
If automatic deployments do not trigger after a build:
- Confirm the build updated the ImageStream tag you referenced.
- Confirm the DeploymentConfig ImageChange trigger references the same ImageStreamTag.
- Check build logs and the ImageStream tags with oc get is and oc describe is/<name>.

Links and references

That’s it for this demo — you should now be able to author a DeploymentConfig, fix the common ImageStream tag validation error, and verify automatic deployments from builds.

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

Quick overview

Example: initial DeploymentConfig used during testing

Important: ImageStreamTag format

Triggers — quick reference

End-to-end flow recap

Example Flask change (triggers a build if your build config reacts to source changes)

Exposing the application externally

Quick troubleshooting checklist

Links and references

Watch Video

​Quick overview

​Example: initial DeploymentConfig used during testing

​Important: ImageStreamTag format

​Triggers — quick reference

​End-to-end flow recap

​Example Flask change (triggers a build if your build config reacts to source changes)

​Exposing the application externally

​Quick troubleshooting checklist

​Links and references

Watch Video

Quick overview

Example: initial DeploymentConfig used during testing

Important: ImageStreamTag format

Triggers — quick reference

End-to-end flow recap

Example Flask change (triggers a build if your build config reacts to source changes)

Exposing the application externally

Quick troubleshooting checklist

Links and references