Kahibaro
Discord Login Register ☰
☰
Previous
Up
Next

DeploymentConfigs and Deployments

Table of Contents

Understanding DeploymentConfigs vs Deployments in OpenShift

OpenShift supports two main controllers for managing application rollout and lifecycle:

They solve the same problem—managing how pods are created, updated, and rolled back—but with different capabilities and integration points. In OpenShift you will often encounter both, especially in existing clusters and templates.

This chapter focuses on:

Conceptual Overview

Shared purpose

Both DeploymentConfig and Deployment:

They are controllers that own lower-level replication resources and ensure the desired state is maintained.

Key differences at a glance

In modern OpenShift clusters, Deployment is the preferred default for new applications unless you specifically need DeploymentConfig features such as image change triggers or custom hooks.

DeploymentConfigs in OpenShift

Resource overview

API group and kind:

A DeploymentConfig definition usually includes:

The creation of new pods is typically indirect: DeploymentConfig creates a ReplicationController to manage actual pods.

Triggers

Triggers are one of the main distinctive features of DeploymentConfig. They determine when a new deployment is created.

Common trigger types:

  1. ConfigChange
    • Activated when the DeploymentConfig spec (e.g., environment vars, pod template) changes.
    • When configChange is present, any change to the pod template will start a new deployment automatically.
  2. ImageChange
    • Activated when an ImageStreamTag referenced in the pod template is updated (new image version).
    • Ties deployments directly to OpenShift ImageStreams, enabling automatic rollouts when new images are built/pushed.
  3. Manual
    • No automatic trigger; rollouts are started explicitly by the user or CI/CD tool.

Example trigger section: 

spec:
  triggers:
    - type: "ConfigChange"
    - type: "ImageChange"
      imageChangeParams:
        automatic: true
        containerNames:
          - myapp
        from:
          kind: ImageStreamTag
          name: myapp:latest

Key details:

Strategies

DeploymentConfig supports three strategies under spec.strategy.type:

  1. Rolling (default for most apps)
  2. Recreate
  3. Custom
Rolling strategy

Performs a rolling update: gradually replace old pods with new ones while keeping the application available.

Key parameters: 

spec:
  strategy:
    type: Rolling
    rollingParams:
      maxUnavailable: 25%
      maxSurge: 25%
      intervalSeconds: 1
      timeoutSeconds: 600
      updatePeriodSeconds: 1
Recreate strategy

Stops all old pods before starting new ones. Useful for:

Example: 

spec:
  strategy:
    type: Recreate
Custom strategy

Allows running a custom deployment process in a container you provide. The custom container is responsible for creating/updating pods.

High level structure: 

spec:
  strategy:
    type: Custom
    customParams:
      image: myorg/custom-deployer:latest
      command:
        - /usr/local/bin/deploy
      environment:
        - name: DEPLOY_ENV
          value: production

Use cases:

This is powerful but also more complex; most applications should use Rolling or Recreate instead.

Lifecycle Hooks

Hooks are another distinctive capability of DeploymentConfig. They run user-defined actions at specific points in the deployment lifecycle.

Hook types (defined under spec.strategy.rollingParams or recreateParams):

Each hook can perform different actions:

Example pre-hook with Rolling strategy: 

spec:
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          command:
            - /opt/app/pre-migrate.sh
          containerName: myapp
          env:
            - name: MIGRATION_STEP
              value: "pre"

Key options:

Typical hook use cases:

Managing DeploymentConfigs in practice

Common operations (using the oc CLI):

A typical workflow in older OpenShift setups:

  1. Build image via S2I or pipeline into an ImageStream.
  2. ImageChange trigger detects new ImageStreamTag.
  3. DeploymentConfig automatically starts a new rollout.
  4. Hooks (if any) run before/after the rollout.
  5. oc rollout used for monitoring, pausing, or rollback.

Kubernetes Deployments in OpenShift

While DeploymentConfig is OpenShift-specific, Deployment is the standard Kubernetes resource and is used heavily in contemporary OpenShift environments.

Resource overview

Key fields:

Under the hood, a Deployment manages ReplicaSets, which then own the pods.

Strategies

Deployment supports:

  1. RollingUpdate (default)
  2. Recreate

Example RollingUpdate: 

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Behavior is broadly similar to DeploymentConfig’s Rolling strategy, but the configuration and semantics are Kubernetes-standard.

Triggers and updates

Deployment does not have explicit trigger objects like DeploymentConfig. A new rollout happens whenever:

Typical patterns:

Examples: 

  oc set image deployment/myapp myapp=myregistry/myapp:v2
  oc rollout restart deployment/myapp

Advanced options

Some features commonly used with Deployments:

Since these are standard Kubernetes features, third-party tools (Helm, Operators, GitOps controllers) expect and target Deployment objects by default.

When to Use DeploymentConfig vs Deployment

Choose Deployment (recommended for most new apps)

Prefer Deployment when:

Typical modern pattern:

Choose DeploymentConfig (special cases)

Prefer DeploymentConfig when:

In many organizations, DeploymentConfig remains common where older OpenShift patterns (S2I with image change triggers) are entrenched.

YAML Comparison

Sample DeploymentConfig

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: image-registry.openshift-image-registry.svc:5000/myproj/myapp:latest
          ports:
            - containerPort: 8080
  strategy:
    type: Rolling
  triggers:
    - type: ConfigChange
    - type: ImageChange
      imageChangeParams:
        automatic: true
        from:
          kind: ImageStreamTag
          name: myapp:latest
        containerNames:
          - myapp

Equivalent Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myregistry.example.com/myproj/myapp:latest
          ports:
            - containerPort: 8080
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Notice:

Migration Considerations

When moving from DeploymentConfig to Deployment:

In many cases, migration simplifies the resource but requires more explicit CI/CD logic.

Practical Guidelines

Understanding the trade-offs between DeploymentConfig and Deployment allows you to:

Previous
Up
Next

Views: 15

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro

Visitors: 1619 / 24h

Impressum / Imprint

Datenschutz / Data Policy