1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-06 06:46:26 +01:00
Files
openshift-docs/modules/deployments-custom-strategy.adoc
2020-08-10 16:14:35 +00:00

88 lines
2.6 KiB
Plaintext

// Module included in the following assemblies:
//
// * applications/deployments/deployment-strategies.adoc
[id="deployments-custom-strategy_{context}"]
= Custom strategy
The Custom strategy allows you to provide your own deployment behavior.
.Example Custom strategy definition
[source,yaml]
----
strategy:
type: Custom
customParams:
image: organization/strategy
command: [ "command", "arg1" ]
environment:
- name: ENV_1
value: VALUE_1
----
In the above example, the `organization/strategy` container image provides the
deployment behavior. The optional `command` array overrides any `CMD` directive
specified in the image's `Dockerfile`. The optional environment variables
provided are added to the execution environment of the strategy process.
Additionally, {product-title} provides the following environment variables to the
deployment process:
[cols="4,8",options="header"]
|===
|Environment variable |Description
.^|`OPENSHIFT_DEPLOYMENT_NAME`
|The name of the new deployment (a ReplicationController).
.^|`OPENSHIFT_DEPLOYMENT_NAMESPACE`
|The name space of the new deployment.
|===
The replica count of the new deployment will initially be zero. The
responsibility of the strategy is to make the new deployment active using the
logic that best serves the needs of the user.
Alternatively, use `customParams` to inject the custom deployment logic into the
existing deployment strategies. Provide a custom shell script logic and call the
`openshift-deploy` binary. Users do not have to supply their custom deployer
container image; in this case, the default {product-title} deployer image is
used instead:
[source,yaml]
----
strategy:
type: Rolling
customParams:
command:
- /bin/sh
- -c
- |
set -e
openshift-deploy --until=50%
echo Halfway there
openshift-deploy
echo Complete
----
This results in following deployment:
[source,terminal]
----
Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
Scaling custom-deployment-1 down to 1
Scaling custom-deployment-2 up to 2
Scaling custom-deployment-1 down to 0
--> Success
Complete
----
If the custom deployment strategy process requires access to the {product-title}
API or the Kubernetes API the container that executes the strategy can use the
service account token available inside the container for authentication.