- What Are Deployment Strategies?
- Rolling Strategy
- Canary Deployments
- When to Use a Rolling Deployment
- Rolling Example
- Recreate Strategy
- When to Use a Recreate Deployment
- Custom Strategy
- Lifecycle Hooks
- Pod-based Lifecycle Hook
- Using the Command Line
What Are Deployment Strategies?
A deployment strategy is a way to change or upgrade an application. The aimis to make the change without downtime in a way that the user barely notices theimprovements.
The most common strategy is to use ablue-greendeployment. The new version (the blue version) is brought up for testing andevaluation, while the users still use the stable version (the green version).When ready, the users are switched to the blue version. If a problem arises, youcan switch back to the green version.
A common alternative strategy is to use A/B versions that are both active at thesame time and some users use one version, and some users use the other version.This can be used for experimenting with user interface changes and otherfeatures to get user feedback. It can also be used to verify proper operation ina production context where problems impact a limited number of users.
A canary deployment tests the new version but when a problem is detected itquickly falls back to the previous version. This can be done with both of theabove strategies.
The route based deployment strategies do not scale the number of pods in theservices. To maintain desired performance characteristics the deploymentconfigurations may need to be scaled.
There are things to consider when choosing a deployment strategy.
Long running connections need to be handled gracefully.
Database conversions can get tricky and will need to be done and rolledback along with the application.
If the application is a hybrid of microservices and traditional componentsdowntime may be needed to complete the transition.
You need the infrastructure to do this.
If you have a non-isolated test environment, you can break both new and old versions.
Since the end user usually accesses the application through a route handled by arouter, the deployment strategy can focus on deployment configuration featuresor routing features.
Strategies that focus on the deployment configuration impact all routes that usethe application. Strategies that use router features target individual routes.
Many deployment strategies are supported through the deployment configurationand some additional strategies are supported through router features. Thedeployment configuration-based strategies are discussed in this section.
Rolling Strategy and Canary Deployments
Recreate Strategy
Custom Strategy
Blue-Green Deployment using routes
A/B Deployment and canary deployments using routes
One Service, Multiple Deployment Configurations
The Rolling strategy is the default strategy used ifno strategy is specified on a deployment configuration.
A deployment strategy usesreadinesschecks to determine if a new pod is ready for use. If a readiness check fails,the deployment configuration will retry to run the pod until it times out. Thedefault timeout is 10m
, a value set in TimeoutSeconds
indc.spec.strategy.*params
.
Rolling Strategy
A rolling deployment slowly replaces instances of the previous version of anapplication with instances of the new version of the application. A rollingdeployment typically waits for new pods to become ready via a readinesscheck before scaling down the old components. If a significant issue occurs,the rolling deployment can be aborted.
Canary Deployments
All rolling deployments in OpenShift Dedicated are canary deployments; a newversion (the canary) is tested before all of the old instances are replaced. Ifthe readiness check never succeeds, the canary instance is removed and thedeployment configuration will be automatically rolled back. The readiness checkis part of the application code, and may be as sophisticated as necessary toensure the new instance is ready to be used. If you need to implement morecomplex checks of the application (such as sending real user workloads to thenew instance), consider implementing a custom deployment or using ablue-green deployment strategy.
When to Use a Rolling Deployment
When you want to take no downtime during an application update.
When your application supports having old code and new code running at the same time.
A rolling deployment means you to have both old and new versions of your coderunning at the same time. This typically requires that your application handleN-1 compatibility.
The following is an example of the Rolling strategy:
strategy: type: Rolling rollingParams: updatePeriodSeconds: 1 (1) intervalSeconds: 1 (2) timeoutSeconds: 120 (3) maxSurge: "20%" (4) maxUnavailable: "10%" (5) pre: {} (6) post: {}
1 | The time to wait between individual pod updates. If unspecified, this value defaults to 1 . |
2 | The time to wait between polling the deployment status after update. If unspecified, this value defaults to 1 . |
3 | The time to wait for a scaling event before giving up. Optional; the default is 600 . Here, giving up meansautomatically rolling back to the previous complete deployment. |
4 | maxSurge is optional and defaults to 25% if not specified. See the information below the following procedure. |
5 | maxUnavailable is optional and defaults to 25% if not specified. See the information below the following procedure. |
6 | pre and post are both lifecycle hooks. |
The Rolling strategy will:
Execute any
pre
lifecycle hook.Scale up the new replication controller based on the surge count.
Scale down the old replication controller based on the max unavailable count.
Repeat this scaling until the new replication controller has reached the desiredreplica count and the old replication controller has been scaled to zero.
Execute any
post
lifecycle hook.
When scaling down, the Rolling strategy waits for pods to become ready so it candecide whether further scaling would affect availability. If scaled up podsnever become ready, the deployment process will eventually time out and result in adeployment failure. |
The maxUnavailable
parameter is the maximum number of pods that can beunavailable during the update. The maxSurge
parameter is the maximum numberof pods that can be scheduled above the original number of pods. Both parameterscan be set to either a percentage (e.g., 10%
) or an absolute value (e.g.,2
). The default value for both is 25%
.
These parameters allow the deployment to be tuned for availability and speed. Forexample:
maxUnavailable=0
andmaxSurge=20%
ensures full capacity is maintainedduring the update and rapid scale up.maxUnavailable=10%
andmaxSurge=0
performs an update using no extracapacity (an in-place update).maxUnavailable=10%
andmaxSurge=10%
scales up and down quickly withsome potential for capacity loss.
Generally, if you want fast rollouts, use maxSurge
. If you need to take intoaccount resource quota and can accept partial unavailability, usemaxUnavailable
.
Rolling Example
Rolling deployments are the default in OpenShift Dedicated. To see a rolling update,follow these steps:
Create an application based on the example deployment images found inDockerHub:
$ oc new-app openshift/deployment-example
If you have the router installed, make the application available via a route (oruse the service IP directly)
$ oc expose svc/deployment-example
Browse to the application at
deployment-example.<project>.<router_domain>
toverify you see the v1 image.Scale the deployment configuration up to three replicas:
$ oc scale dc/deployment-example --replicas=3
Trigger a new deployment automatically by tagging a new version of the exampleas the
latest
tag:$ oc tag deployment-example:v2 deployment-example:latest
In your browser, refresh the page until you see the v2 image.
If you are using the CLI, the following command will show you how many pods are on version 1 and how manyare on version 2. In the web console, you should see the pods slowly being added to v2 and removed from v1.
$ oc describe dc deployment-example
During the deployment process, the new replication controller is incrementallyscaled up. Once the new pods are marked as ready (by passing their readinesscheck), the deployment process will continue. If the pods do not become ready,the process will abort, and the deployment configuration will be rolled back toits previous version.
Recreate Strategy
The Recreate strategy has basic rollout behavior and supportslifecycle hooks for injecting code into the deploymentprocess.
The following is an example of the Recreate strategy:
strategy: type: Recreate recreateParams: (1) pre: {} (2) mid: {} post: {}
1 | recreateParams are optional. |
2 | pre , mid , and post are lifecycle hooks. |
The Recreate strategy will:
Execute any
pre
lifecycle hook.Scale down the previous deployment to zero.
Execute any
mid
lifecycle hook.Scale up the new deployment.
Execute any
post
lifecycle hook.
During scale up, if the replica count of the deployment is greater than one, thefirst replica of the deployment will be validated for readiness before fullyscaling up the deployment. If the validation of the first replica fails, thedeployment will be considered a failure. |
When to Use a Recreate Deployment
When you must run migrations or other data transformations before your new code starts.
When you do not support having new and old versions of your application code running at the same time.
When you want to use a RWO volume, which is not supported being shared between multiple replicas.
A recreate deployment incurs downtime because, for a brief period, no instancesof your application are running. However, your old code and new code do not runat the same time.
Custom Strategy
The Custom strategy allows you to provide your own deployment behavior.
The following is an example of the Custom strategy:
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 thedeployment behavior. The optional command
array overrides any CMD
directivespecified in the image’s Dockerfile. The optional environment variablesprovided are added to the execution environment of the strategy process.
Additionally, OpenShift Dedicated provides the following environment variables to thedeployment process:
Environment Variable | Description |
---|---|
| The name of the new deployment (a replication controller). |
| The name space of the new deployment. |
The replica count of the new deployment will initially be zero. Theresponsibility of the strategy is to make the new deployment active using thelogic that best serves the needs of the user.
Learn more aboutadvanced deployment strategies.
Alternatively, use customParams
to inject the custom deployment logic into theexisting deployment strategies. Provide a custom shell script logic and call theopenshift-deploy
binary. Users do not have to supply their custom deployercontainer image, but the default OpenShift Dedicated deployer image will be usedinstead:
strategy: type: Rolling customParams: command: - /bin/sh - -c - | set -e openshift-deploy --until=50% echo Halfway there openshift-deploy echo Complete
This will result in following deployment:
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--> SuccessComplete
If the custom deployment strategy process requires access to the OpenShift Dedicated API or theKubernetes API the container that executes the strategy can use the service account tokenavailable inside the container for authentication.
Lifecycle Hooks
The Recreate and Rollingstrategies support lifecycle hooks, which allow behavior to be injected intothe deployment process at predefined points within the strategy:
The following is an example of a pre
lifecycle hook:
pre: failurePolicy: Abort execNewPod: {} (1)
1 | execNewPod is a pod-based lifecycle hook. |
Every hook has a failurePolicy
, which defines the action the strategy shouldtake when a hook failure is encountered:
| The deployment process will be considered a failure if the hook fails. |
| The hook execution should be retried until it succeeds. |
| 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 onlysupported hook type, specified by the execNewPod
field.
Pod-based Lifecycle Hook
Pod-based lifecycle hooks execute hook code in a new pod derived from thetemplate in a deployment configuration.
The following simplified example deployment configuration uses theRolling strategy. Triggers and some other minor detailsare omitted for brevity:
kind: DeploymentConfigapiVersion: v1metadata: name: frontendspec: 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 theopenshift/origin-ruby-sample image from the helloworld container. The hookpod will have the following properties:
The hook command will be
/usr/bin/command arg1 arg2
.The hook container will have the
CUSTOM_VAR1=custom_value1
environment variable.The hook failure policy is
Abort
, meaning the deployment process will fail if the hook fails.The hook pod will inherit the
data
volume from the deployment configuration pod.
Using the Command Line
The oc set deployment-hook
command can be used to set the deployment hook fora deployment configuration. For the example above, you can set thepre-deployment hook with the following command:
$ oc set deployment-hook dc/frontend --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \ -v data --failure-policy=abort -- /usr/bin/command arg1 arg2