How Deployments Work - Deployments | Developer Guide

What Is a Deployment?

OpenShift Origin deployments provide fine-grained management over common user applications. They are described using three separate API objects:

A deployment configuration, which describes the desired state of a particular component of the application as a pod template.
One or more replication controllers, which contain a point-in-time record of the state of a deployment configuration as a pod template.
One or more pods, which represent an instance of a particular version of an application.

Users do not need to manipulate replication controllers or pods owned by deployment configurations. The deployment system ensures changes to deployment configurations are propagated appropriately. If the existing deployment strategies are not suited for your use case and you have the need to run manual steps during the lifecycle of your deployment, then you should consider creating a custom strategy.

When you create a deployment configuration, a replication controller is created representing the deployment configuration’s pod template. If the deployment configuration 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 replication controller.

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.

Features provided by the deployment system:

A deployment configuration, which is a template for running applications.
Triggers that drive automated deployments in response to events.
User-customizable 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 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.

Creating a Deployment Configuration

Deployment configurations are deploymentConfig OpenShift Origin API resources which can be managed with the oc command like any other resource. The following is an example of a deploymentConfig resource:

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

1	The pod template of the `frontend` deployment configuration describes a simple Ruby application.
2	There will be 5 replicas of `frontend`.
3	A configuration change trigger causes a new replication controller to be created any time the pod template changes.
4	An image change trigger trigger causes a new replication controller to be created each time a new version of the `origin-ruby-sample:latest` image stream tag is available.
5	The Rolling strategy is the default way of deploying your pods. May be omitted.
6	Pause a deployment configuration. This disables the functionality of all triggers and allows for multiple changes on the pod template before actually rolling it out.
7	Revision history limit is the limit of old replication controllers you want to keep around for rolling back. May be omitted. If omitted, old replication controllers will not be cleaned up.
8	Minimum seconds to wait (after the readiness checks succeed) for a pod to be considered available. The default value is 0.