OpenShift Online 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
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