Building on replication controllers, OpenShift Container Platform adds expanded support for the software development and deployment lifecycle with the concept of deploymentConfig
objects. In the simplest case, a deploymentConfig
object creates a new replication controller and lets it start up pods.
However, OpenShift Container Platform deployments from deploymentConfig
objects also provide the ability to transition from an existing deployment of an image to a new one and also define hooks to be run before or after creating the replication controller.
The deploymentConfig
deployment system provides the following capabilities:
-
A deploymentConfig
object, which is a template for running applications.
-
Triggers that drive automated deployments in response to events.
-
User-customizable deployment strategies to transition from the previous version to the new version. A strategy runs inside a pod commonly referred as the deployment process.
-
A set of hooks (lifecycle hooks) for executing custom behavior in different points during the lifecycle of a deployment.
-
Versioning of your application in order to support rollbacks either manually or automatically in case of deployment failure.
-
Manual replication scaling and autoscaling.
When you create a deploymentConfig
object, a replication controller is created representing the deploymentConfig
object’s pod template. If the deployment changes, a new replication controller is created with the latest pod template, and a deployment process runs to scale down the old replication controller and scale up the new one.
Instances of your application are automatically added and removed from both service load balancers and routers as they are created. As long as your application supports graceful shutdown when it receives the TERM
signal, you can ensure that running user connections are given a chance to complete normally.
The OpenShift Container Platform deploymentConfig
object defines the following details:
-
The elements of a ReplicationController
definition.
-
Triggers for creating a new deployment automatically.
-
The strategy for transitioning between deployments.
-
Lifecycle hooks.
Each time a deployment is triggered, whether manually or automatically, a deployer pod manages the deployment (including scaling down the old
replication controller, scaling up the new one, and running hooks). The deployment pod remains for an indefinite amount of time after it completes the deployment in order to retain its logs of the deployment. When a deployment is superseded by another, the previous replication controller is retained to enable easy rollback if needed.
Example deploymentConfig
definition
apiVersion: v1
kind: deploymentConfig
metadata:
name: frontend
spec:
replicas: 5
selector:
name: frontend
template: { ... }
triggers:
- type: ConfigChange (1)
- imageChangeParams:
automatic: true
containerNames:
- helloworld
from:
kind: ImageStreamTag
name: hello-openshift:latest
type: ImageChange (2)
strategy:
type: Rolling (3)
1 |
A configuration change trigger results in a new replication controller whenever changes are detected in the pod template of the deployment configuration. |
2 |
An image change trigger causes a new deployment to be created each time a new version of the backing image is available in the named image stream. |
3 |
The default Rolling strategy makes a downtime-free transition between deployments. |