mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 06:46:26 +01:00
85 lines
3.5 KiB
Plaintext
85 lines
3.5 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * applications/deployments/what-deployments-are.adoc
|
|
|
|
[id="deployments-and-deploymentconfigs_{context}"]
|
|
= DeploymentConfigs
|
|
|
|
Building on ReplicationControllers, {product-title} adds expanded support for
|
|
the software development and deployment lifecycle with the concept of
|
|
_DeploymentConfigs_. In the simplest case, a DeploymentConfig creates a new
|
|
ReplicationController and lets it start up pods.
|
|
|
|
However, {product-title} deployments from DeploymentConfigs 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 ReplicationController.
|
|
|
|
The DeploymentConfig deployment system provides the following capabilities:
|
|
|
|
- A DeploymentConfig, 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, a ReplicationController is created
|
|
representing the DeploymentConfig's Pod template. If the DeploymentConfig
|
|
changes, a new ReplicationController is created with the latest Pod template,
|
|
and a deployment process runs to scale down the old ReplicationController 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 {product-title} `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
|
|
ReplicationController, 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 ReplicationController is retained to enable
|
|
easy rollback if needed.
|
|
|
|
.Example DeploymentConfig definition
|
|
[source,yaml]
|
|
----
|
|
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 `ConfigChange` trigger causes a new Deployment to be created any time the ReplicationController template changes.
|
|
<2> An `ImageChange` trigger causes a new Deployment to be created each time a new version of the backing image is available in the named imagestream.
|
|
<3> The default `Rolling` strategy makes a downtime-free transition between Deployments.
|