{"id":49302,"date":"2025-05-07T15:28:16","date_gmt":"2025-05-07T15:28:16","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=49302"},"modified":"2025-07-12T05:56:25","modified_gmt":"2025-07-12T05:56:25","slug":"openshift-tutorials-for-deploymentconfigs","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/openshift-tutorials-for-deploymentconfigs\/","title":{"rendered":"Openshift Tutorials for DeploymentConfigs"},"content":{"rendered":"\n<p><strong>OpenShift DeploymentConfigs<\/strong> are a core resource in OpenShift used to manage the deployment and lifecycle of applications. While Kubernetes uses <strong>Deployments<\/strong> to manage the rolling updates of applications, OpenShift introduces the concept of <strong>DeploymentConfigs<\/strong> with additional features specific to OpenShift that help with deployment strategies, triggers, and more.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key Differences:<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Feature<\/strong><\/th><th><strong>Kubernetes Deployment<\/strong><\/th><th><strong>OpenShift DeploymentConfig<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>Basic Purpose<\/strong><\/td><td>Declarative updates to applications.<\/td><td>Declarative updates with additional features for OpenShift.<\/td><\/tr><tr><td><strong>Triggers<\/strong><\/td><td>Manual updates.<\/td><td>ImageChange, ConfigChange, Manual triggers.<\/td><\/tr><tr><td><strong>Deployment Strategies<\/strong><\/td><td>Rolling updates by default.<\/td><td>Rolling, Recreate, and Custom strategies.<\/td><\/tr><tr><td><strong>Rollback Support<\/strong><\/td><td>No automatic rollback, manual intervention required.<\/td><td>Automatic rollback on failure, making it more resilient.<\/td><\/tr><tr><td><strong>Integration with CI\/CD<\/strong><\/td><td>Standard Kubernetes CI\/CD pipelines.<\/td><td>Integrated with OpenShift BuildConfig, ImageStreams, and CI\/CD.<\/td><\/tr><tr><td><strong>Health Check Mechanism<\/strong><\/td><td>Standard Kubernetes health checks (readiness and liveness).<\/td><td>Additional hooks for pre\/post-deployment actions.<\/td><\/tr><tr><td><strong>Use Case<\/strong><\/td><td>Ideal for simpler use cases.<\/td><td>Ideal for OpenShift-specific workflows and more complex needs.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Key Features of OpenShift <strong>DeploymentConfig<\/strong>:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Deployment Strategy<\/strong>:<br>DeploymentConfigs allow you to specify different deployment strategies to handle updates:\n<ul class=\"wp-block-list\">\n<li><strong>Rolling<\/strong>: The default strategy where the deployment is gradually updated without downtime. Pods are updated one by one, ensuring that some are always running.<\/li>\n\n\n\n<li><strong>Recreate<\/strong>: All the old pods are killed and replaced with new ones at the same time. This is used when you need a clean slate for the deployment.<\/li>\n\n\n\n<li><strong>Custom<\/strong>: Allows you to specify your own custom strategy, for more advanced use cases.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Triggers<\/strong>:<br>DeploymentConfigs support various triggers that can automatically initiate a deployment. These include:\n<ul class=\"wp-block-list\">\n<li><strong>Image Change Trigger<\/strong>: A new deployment is triggered automatically when the image in the container registry is updated.<\/li>\n\n\n\n<li><strong>Config Change Trigger<\/strong>: A deployment is triggered when there is a change in the DeploymentConfig itself (e.g., a change in environment variables or configuration).<\/li>\n\n\n\n<li><strong>Manual Trigger<\/strong>: A manual deployment is triggered by the user.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Rollback<\/strong>:<br>OpenShift provides the ability to <strong>rollback<\/strong> to a previous version of the DeploymentConfig if something goes wrong with the current deployment. This is handy for maintaining application stability.<\/li>\n\n\n\n<li><strong>Replicas<\/strong>:<br>Like Kubernetes Deployments, DeploymentConfigs manage the number of replicas of the application running. It ensures that the specified number of replicas are maintained, and OpenShift will create, scale, and manage these pods as necessary.<\/li>\n\n\n\n<li><strong>Environment Variables<\/strong>:<br>DeploymentConfigs allow you to define environment variables, which can be injected into your application containers. These are often used to provide configuration to the application at runtime.<\/li>\n\n\n\n<li><strong>Health Checks<\/strong>:<br>DeploymentConfigs allow you to configure readiness and liveness probes to ensure that pods are running properly. If a pod fails these checks, it is replaced automatically.<\/li>\n\n\n\n<li><strong>Deployment Hooks<\/strong>:<br>DeploymentConfigs support <strong>hooks<\/strong> that allow you to execute commands at different stages of the deployment lifecycle. For example:\n<ul class=\"wp-block-list\">\n<li><strong>Pre-deployment hooks<\/strong>: Run before a new deployment starts.<\/li>\n\n\n\n<li><strong>Post-deployment hooks<\/strong>: Run after a deployment has completed.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Example of a DeploymentConfig YAML:<\/h3>\n\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-1\" data-shcb-language-name=\"JavaScript\" data-shcb-language-slug=\"javascript\"><span><code class=\"hljs language-javascript\">apiVersion: apps.openshift.io\/v1\n<span class=\"hljs-attr\">kind<\/span>: DeploymentConfig\n<span class=\"hljs-attr\">metadata<\/span>:\n  name: myapp\n<span class=\"hljs-attr\">spec<\/span>:\n  replicas: <span class=\"hljs-number\">3<\/span>\n  <span class=\"hljs-attr\">selector<\/span>:\n    app: myapp\n  <span class=\"hljs-attr\">template<\/span>:\n    metadata:\n      labels:\n        app: myapp\n    <span class=\"hljs-attr\">spec<\/span>:\n      containers:\n      - name: myapp-container\n        <span class=\"hljs-attr\">image<\/span>: myrepo\/myapp:latest\n        <span class=\"hljs-attr\">ports<\/span>:\n        - containerPort: <span class=\"hljs-number\">8080<\/span>\n  <span class=\"hljs-attr\">strategy<\/span>:\n    type: Rolling\n  <span class=\"hljs-attr\">triggers<\/span>:\n    - type: ImageChange\n      <span class=\"hljs-attr\">imageChangeParams<\/span>:\n        automatic: <span class=\"hljs-literal\">true<\/span>\n        <span class=\"hljs-attr\">from<\/span>:\n          kind: ImageStreamTag\n          <span class=\"hljs-attr\">name<\/span>: <span class=\"hljs-string\">\"myapp:latest\"<\/span>\n<\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-1\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">JavaScript<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">javascript<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n\n<h3 class=\"wp-block-heading\">Breakdown of the Example:<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Metadata<\/strong>:\n<ul class=\"wp-block-list\">\n<li><code>name<\/code>: The name of the DeploymentConfig, in this case, <code>myapp<\/code>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Spec<\/strong>:\n<ul class=\"wp-block-list\">\n<li><code>replicas<\/code>: The number of instances (pods) of the application to run. In this case, 3 replicas are specified.<\/li>\n\n\n\n<li><code>selector<\/code>: This selects the pods that this DeploymentConfig manages by the <code>app: myapp<\/code> label.<\/li>\n\n\n\n<li><code>template<\/code>: Defines the pod template, including the container image and ports. It specifies that the <code>myapp-container<\/code> will be using the <code>myrepo\/myapp:latest<\/code> image and exposing port 8080.<\/li>\n\n\n\n<li><code>strategy<\/code>: Defines the deployment strategy, here it&#8217;s set to <code>Rolling<\/code> for zero-downtime updates.<\/li>\n\n\n\n<li><code>triggers<\/code>: Configures an image change trigger that automatically triggers a new deployment whenever the <code>myapp:latest<\/code> image in the ImageStream is updated.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Key Differences Between Deployment and DeploymentConfig:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>DeploymentConfig<\/strong> has more OpenShift-specific features like triggers (e.g., ImageChange, ConfigChange) and deployment strategies that are optimized for OpenShift.<\/li>\n\n\n\n<li><strong>Deployment<\/strong> is a standard Kubernetes resource and doesn\u2019t include OpenShift-specific features like triggers or the advanced deployment strategies.<\/li>\n\n\n\n<li>In OpenShift, <strong>DeploymentConfig<\/strong> is the preferred method for managing deployments of applications, especially for more complex use cases that require integrated triggers or detailed management of deployment processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When to Use DeploymentConfig in OpenShift:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>When you need <strong>advanced deployment strategies<\/strong> and control over the lifecycle of your pods.<\/li>\n\n\n\n<li>When you need <strong>automatic triggers<\/strong> (like ImageChange triggers) to trigger deployments based on image changes.<\/li>\n\n\n\n<li>When working within the OpenShift ecosystem and utilizing <strong>OpenShift-specific features<\/strong> like deployment hooks, rollback support, and integrated build and image stream workflows.<\/li>\n<\/ul>\n\n\n\n<p><strong>Note<\/strong>: While <strong>DeploymentConfig<\/strong> is used in OpenShift, it is worth noting that Kubernetes has moved more toward using <strong>Deployments<\/strong> as the standard for managing workloads. OpenShift still supports DeploymentConfig for compatibility and its additional features.<\/p>\n\n\n\n<p>The difference between <strong>Kubernetes Deployments<\/strong> and <strong>OpenShift DeploymentConfigs<\/strong> can be subtle, but there are significant distinctions, especially when comparing them in the context of OpenShift, which builds on Kubernetes and adds its own features.<\/p>\n\n\n\n<p>Here\u2019s a detailed comparison:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. <strong>Deployment (Kubernetes)<\/strong>:<\/h3>\n\n\n\n<p>A <strong>Kubernetes Deployment<\/strong> is a resource that provides declarative updates to applications. It ensures that the desired number of replicas of a pod are running and automatically manages the rolling updates of the application. Kubernetes Deployments are part of the core Kubernetes API.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Key Features:<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rolling Updates<\/strong>: Kubernetes Deployment manages the rolling updates, meaning new pods are gradually created, and old ones are terminated, ensuring no downtime.<\/li>\n\n\n\n<li><strong>Replicas<\/strong>: It controls the desired number of replicas for scaling.<\/li>\n\n\n\n<li><strong>Pod Health Checks<\/strong>: Deployments use readiness and liveness probes to ensure that pods are healthy and can be restarted if necessary.<\/li>\n\n\n\n<li><strong>No Triggers<\/strong>: In Kubernetes Deployments, you manually trigger updates or rollbacks (e.g., by changing the image version).<\/li>\n\n\n\n<li><strong>No Built-in Rollbacks<\/strong>: If a deployment fails, Kubernetes doesn\u2019t automatically revert to the previous state. Rollbacks are done manually by applying the previous deployment configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example of Kubernetes Deployment:<\/h3>\n\n\n<pre class=\"wp-block-code\"><span><code class=\"hljs\">apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: myapp\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: myapp\n  template:\n    metadata:\n      labels:\n        app: myapp\n    spec:\n      containers:\n      - name: myapp-container\n        image: myrepo\/myapp:latest\n        ports:\n        - containerPort: 8080\n<\/code><\/span><\/pre>\n\n\n<h3 class=\"wp-block-heading\">2. <strong>DeploymentConfig (OpenShift)<\/strong>:<\/h3>\n\n\n\n<p><strong>DeploymentConfig<\/strong> is a custom OpenShift resource that is similar to Kubernetes Deployments but with added OpenShift-specific features like <strong>deployment triggers<\/strong>, <strong>deployment strategies<\/strong>, and <strong>rollback mechanisms<\/strong>.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Key Features:<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Triggers<\/strong>:\n<ul class=\"wp-block-list\">\n<li><strong>Image Change Trigger<\/strong>: Automatically triggers a new deployment whenever the container image is updated (e.g., new version of the image is pushed to the registry).<\/li>\n\n\n\n<li><strong>Config Change Trigger<\/strong>: Automatically triggers a deployment when the configuration (such as environment variables) changes.<\/li>\n\n\n\n<li><strong>Manual Trigger<\/strong>: You can manually trigger a deployment.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Deployment Strategies<\/strong>:\n<ul class=\"wp-block-list\">\n<li><strong>Rolling<\/strong>: Gradual update with zero downtime (like Kubernetes).<\/li>\n\n\n\n<li><strong>Recreate<\/strong>: All old pods are terminated before new pods are created.<\/li>\n\n\n\n<li><strong>Custom<\/strong>: Allows you to define your own deployment strategy.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Rollback<\/strong>: OpenShift provides <strong>automatic rollback<\/strong> to a previous version if a deployment fails, offering more stability and easier recovery compared to Kubernetes deployments.<\/li>\n\n\n\n<li><strong>Health Checks<\/strong>: DeploymentConfigs support <strong>deployment hooks<\/strong>, which run commands before or after the deployment process.<\/li>\n\n\n\n<li><strong>Integration with OpenShift Build and Image Streams<\/strong>: OpenShift integrates DeploymentConfigs tightly with its <strong>BuildConfig<\/strong> and <strong>ImageStream<\/strong> resources. This allows automatic deployment when new images are built using OpenShift\u2019s integrated CI\/CD pipeline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example of OpenShift DeploymentConfig:<\/h3>\n\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-2\" data-shcb-language-name=\"JavaScript\" data-shcb-language-slug=\"javascript\"><span><code class=\"hljs language-javascript\">apiVersion: apps.openshift.io\/v1\n<span class=\"hljs-attr\">kind<\/span>: DeploymentConfig\n<span class=\"hljs-attr\">metadata<\/span>:\n  name: myapp\n<span class=\"hljs-attr\">spec<\/span>:\n  replicas: <span class=\"hljs-number\">3<\/span>\n  <span class=\"hljs-attr\">selector<\/span>:\n    app: myapp\n  <span class=\"hljs-attr\">template<\/span>:\n    metadata:\n      labels:\n        app: myapp\n    <span class=\"hljs-attr\">spec<\/span>:\n      containers:\n      - name: myapp-container\n        <span class=\"hljs-attr\">image<\/span>: myrepo\/myapp:latest\n        <span class=\"hljs-attr\">ports<\/span>:\n        - containerPort: <span class=\"hljs-number\">8080<\/span>\n  <span class=\"hljs-attr\">strategy<\/span>:\n    type: Rolling\n  <span class=\"hljs-attr\">triggers<\/span>:\n    - type: ImageChange\n      <span class=\"hljs-attr\">imageChangeParams<\/span>:\n        automatic: <span class=\"hljs-literal\">true<\/span>\n        <span class=\"hljs-attr\">from<\/span>:\n          kind: ImageStreamTag\n          <span class=\"hljs-attr\">name<\/span>: <span class=\"hljs-string\">\"myapp:latest\"<\/span>\n<\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-2\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">JavaScript<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">javascript<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n\n<h3 class=\"wp-block-heading\">When to Use Which:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Kubernetes Deployment<\/strong>: If you\u2019re working with standard Kubernetes and need basic management for application updates with rolling deployments, then <strong>Kubernetes Deployment<\/strong> is the way to go.<\/li>\n\n\n\n<li><strong>OpenShift DeploymentConfig<\/strong>: If you&#8217;re working within OpenShift and need more advanced features like automatic rollback, integration with OpenShift\u2019s build system, deployment triggers, and greater flexibility in deployment strategies, then <strong>DeploymentConfig<\/strong> is a better option.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Summary:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Kubernetes Deployment<\/strong> is part of the Kubernetes core API, providing basic deployment functionality.<\/li>\n\n\n\n<li><strong>OpenShift DeploymentConfig<\/strong> extends Kubernetes Deployments with OpenShift-specific features like triggers, custom deployment strategies, automatic rollback, and integration with the OpenShift ecosystem (e.g., ImageStreams and BuildConfig).<\/li>\n<\/ul>\n\n\n\n<p>In simple terms:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deployment<\/strong> = Standard Kubernetes resource.<\/li>\n\n\n\n<li><strong>DeploymentConfig<\/strong> = OpenShift\u2019s extended version with additional management features, triggers, and rollback capabilities.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>OpenShift DeploymentConfigs are a core resource in OpenShift used to manage the deployment and lifecycle of applications. While Kubernetes uses Deployments to manage the rolling updates of applications, OpenShift introduces&#8230; <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[5153],"tags":[],"class_list":["post-49302","post","type-post","status-publish","format-standard","hentry","category-openshift"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=49302"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49302\/revisions"}],"predecessor-version":[{"id":49303,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49302\/revisions\/49303"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=49302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=49302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=49302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}