mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
104 lines
3.4 KiB
Plaintext
104 lines
3.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * applications/deployments/deployment-strategies.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="deployments-lifecycle-hooks_{context}"]
|
|
= Lifecycle hooks
|
|
|
|
The rolling and recreate strategies support _lifecycle hooks_, or deployment hooks, which allow behavior to be injected into the deployment process at predefined points within the strategy:
|
|
|
|
.Example `pre` lifecycle hook
|
|
[source,yaml]
|
|
----
|
|
pre:
|
|
failurePolicy: Abort
|
|
execNewPod: {} <1>
|
|
----
|
|
<1> `execNewPod` is a pod-based lifecycle hook.
|
|
|
|
Every hook has a _failure policy_, which defines the action the strategy should take when a hook failure is encountered:
|
|
|
|
[cols="2,8"]
|
|
|===
|
|
|
|
.^|`Abort`
|
|
|The deployment process will be considered a failure if the hook fails.
|
|
|
|
.^|`Retry`
|
|
|The hook execution should be retried until it succeeds.
|
|
|
|
.^|`Ignore`
|
|
|Any hook failure should be ignored and the deployment should proceed.
|
|
|===
|
|
|
|
Hooks have a type-specific field that describes how to execute the hook. Currently, pod-based hooks are the only supported hook type, specified by the `execNewPod` field.
|
|
|
|
[id="deployments-lifecycle-hooks-pod-based_{context}"]
|
|
== Pod-based lifecycle hook
|
|
|
|
Pod-based lifecycle hooks execute hook code in a new pod derived from the template in a `DeploymentConfig` object.
|
|
|
|
The following simplified example deployment uses the rolling strategy. Triggers and some other minor details are omitted for brevity:
|
|
|
|
[source,yaml]
|
|
----
|
|
kind: DeploymentConfig
|
|
apiVersion: apps.openshift.io/v1
|
|
metadata:
|
|
name: frontend
|
|
spec:
|
|
template:
|
|
metadata:
|
|
labels:
|
|
name: frontend
|
|
spec:
|
|
containers:
|
|
- name: helloworld
|
|
image: openshift/origin-ruby-sample
|
|
replicas: 5
|
|
selector:
|
|
name: frontend
|
|
strategy:
|
|
type: Rolling
|
|
rollingParams:
|
|
pre:
|
|
failurePolicy: Abort
|
|
execNewPod:
|
|
containerName: helloworld <1>
|
|
command: [ "/usr/bin/command", "arg1", "arg2" ] <2>
|
|
env: <3>
|
|
- name: CUSTOM_VAR1
|
|
value: custom_value1
|
|
volumes:
|
|
- data <4>
|
|
----
|
|
<1> The `helloworld` name refers to `spec.template.spec.containers[0].name`.
|
|
<2> This `command` overrides any `ENTRYPOINT` defined by the `openshift/origin-ruby-sample` image.
|
|
<3> `env` is an optional set of environment variables for the hook container.
|
|
<4> `volumes` is an optional set of volume references for the hook container.
|
|
|
|
In this example, the `pre` hook will be executed in a new pod using the `openshift/origin-ruby-sample` image from the `helloworld` container. The hook pod has the following properties:
|
|
|
|
* The hook command is `/usr/bin/command arg1 arg2`.
|
|
* The hook container has the `CUSTOM_VAR1=custom_value1` environment variable.
|
|
* The hook failure policy is `Abort`, meaning the deployment process fails if the hook fails.
|
|
* The hook pod inherits the `data` volume from the `DeploymentConfig` object pod.
|
|
|
|
[id="deployments-setting-lifecycle-hooks_{context}"]
|
|
== Setting lifecycle hooks
|
|
// out of scope for this PR - needs a separate module
|
|
|
|
You can set lifecycle hooks, or deployment hooks, for a deployment using the CLI.
|
|
|
|
.Procedure
|
|
|
|
. Use the `oc set deployment-hook` command to set the type of hook you want: `--pre`, `--mid`, or `--post`. For example, to set a pre-deployment hook:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc set deployment-hook dc/frontend \
|
|
--pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
|
|
--volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2
|
|
----
|