Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications
- Section Selecting the Appropriate Deployment Strategy
- Guided Exercise: Selecting the Appropriate Deployment Strategy
- Managing Application Deployments
- Guided Exercise: Managing Application Deployments
- Deploying Stateful Applications
- Guided Exercise: Deploying Stateful Applications
- Monitoring Application Health
- Guided Exercise: Monitoring Application Health
- Lab: Managing Red Hat OpenShift Deployments
- Summary
Abstract
| Goal |
Describe the different Red Hat OpenShift deployment strategies and how to monitor the health of applications. |
| Objectives |
|
| Sections |
|
| Lab |
|
Deploying new versions of your application entails a process that you must repeat on every application update. This process requires a deployment strategy that minimizes application downtime and considers a number of aspects, such as:
New and previous deployment versions running simultaneously.
The amount of computing resources that deploying a new version of your application requires. Depending on your deployment strategy you might require extra computing resources.
The acceptable downtime during the deployment process.
With Red Hat OpenShift you can use the Deployment and the DeploymentConfig resources to automate deployments.
These resources define the deployments final state and the deployment process in a declarative manner.
Automating the deployment process reduces human intervention, which allows organizations to release software more often without affecting the system stability.
This automation requires that your applications implement the following Kubernetes good practices:
- Handling the SIGTERM signal
Kubernetes sends the
SIGTERMsignal to terminate your application gracefully when necessary. Your application must respond to the signal, and your containerization must pass the signal to the application.- Implementing health checks
OpenShift uses readiness and health checks to verify when to route requests to a starting pod, or when to restart a failed pod. Implementing these checks ensures that OpenShift routes requests to functioning pods.
To create the Deployment or DeploymentConfig resources you can use tools such as the oc new-app command or the web console.
Also, you can define the resources manually in the YAML format and use a command such as the oc apply command to start the deployment.
The Deployment resource is a Kubernetes native API that uses the ReplicaSet resource to ensure that there is a number of pods running your application at any given time.
Use the Deployment resource if you do not require any additional features provided by the DeploymentConfig resource, or if your deployments must be compatible with other distributions of Kubernetes.
An specific pod called Deployment Pod performs the deployment process. This deployment pod remains available to access deployment logs until a new deployment replaces it.
The Deployment resource has the following specific features:
Implicit configuration change triggers. Any update in the pod template, such as defining a new container image, triggers a deployment process rollout.
The ability to scale and pause an ongoing rollout.
Compatibility with other Kubernetes distributions.
Favors availability over consistency.
Consider the following Deployment YAML file.
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-openshift
spec:
selector:
matchLabels:
app: hello-openshift
replicas: 3 
strategy:
type: RollingUpdate 
rollingUpdate: 
maxSurge: 1
maxUnavailable: 1
template: 
...output omitted...
| Number of pod replicas when the deployment completes. |
| The deployment strategy for the deployment.
Can be of the |
| The |
| The template to define the application pods.
The |
The DeploymentConfig resource, which is OpenShift specific, uses a ReplicationController resource to ensure that there is a number of pods running your application at any given time.
Compared to the Deployment resource, the DeploymentConfig resource provides additional features, such as:
Triggers that start a deployment process.
Custom deployment strategies that run inside a deployment pod.
Lifecycle hooks to define custom behavior during the deployment.
Rollback capabilities in the case of deployment failure.
Prefer consistency over availability.
To favor consistency, if the node running the deployment pod goes down, then the deployment process waits until the node comes back online.
Consider the following DeploymentConfig YAML file.
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: frontend
spec:
selector:
name: frontend
replicas: 3
strategy:
type: Rolling
triggers:
- type: ConfigChange
- imageChangeParams:
automatic: true
containerNames:
- helloworld
from:
kind: ImageStreamTag
name: hello-openshift:latest
type: ImageChange
template:
metadata:
labels:
name: frontend
spec:
containers:
- name: helloworld
image: openshift/origin-ruby-sample
| Number of pod replicas when the deployment completes. |
| The deployment strategy for the deployment.
Can be of the |
| The list of triggers that start a new deployment. |
| The template for the application pod.
The |
The DeploymentConfig triggers can be of the following types:
- ConfigChange trigger
Starts a new deployment process when the pod template definition changes.
- ImageChange trigger
Starts a new deployment process when the image stream tag points to a new container image.
When a DeploymentConfig has no trigger definition it defaults to a ConfigChange trigger.
The Recreate and Rolling strategies support lifecycle hooks.
You can use these hooks to trigger events at predefined points in the deployment process.
OpenShift deployments contain three lifecycle hooks:
- Pre-Lifecycle Hook
OpenShift executes the pre-lifecycle hook before starting the deployment process. This is useful, for example, for validating database schema or validating the environment variables, before OpenShift deploys a new version of your application.
- Mid-Lifecycle Hook
The mid-lifecycle hook, only available for the
Recreatestrategy, runs after all the previous pods in a deployment terminate, but before any new pod start. This is useful, for example, for database schema migration.- Post-Lifecycle Hook
The post-lifecycle hook runs after all new pods for a deployment have started and all the previous pods terminate. This is useful, for example, for database cleanup, or triggering cache warm-up.
These lifecycle hooks are defined in the spec.strategy property under one of the following attributes:
rollingParamsforRollingstrategies. This attribute accepts theperandpostproperties depending on the hook type.recreateParamsforRecreatestrategies. This attribute accepts thepre,midandpostproperties depending on the hook type.
Each hook has a failurePolicy attribute, which defines the action to take when a hook failure is encountered.
There are three policies:
- Abort
The deployment process is considered a failure if the hook fails.
- Retry
Retry the hook execution until it succeeds.
- Ignore
Ignore any hook failure and allow the deployment to proceed.
Consider the following deployment configuration:
apiVersion: apps.openshift.io/v1 kind: DeploymentConfig metadata: name: frontend spec: ...output omitted... strategy: type: Rolling rollingParams: pre:
| The |
| This hook aborts new deployments if the hook command fails. |
| The container from the pod template definition that the hook creates. |
| The command that runs inside the |
lifecycle hooks run in separate containers, which OpenShift removes after the command completes.
OpenShift provides several deployment strategies. These strategies can be organized into two primary categories:
Strategies that use the deployment strategy defined in the application deployment resource.
Strategies that use the OpenShift router to route traffic to specific application pods.
Strategies defined within the deployment resource impact the creation and termination of application pods. Strategies that use the OpenShift router use request routing strategies to define which application version the user reaches.
Strategies that involve changing the deployment definition are listed below:
- Rolling
Rolling deployments in OpenShift are canary deployments; OpenShift tests a new version, the canary, before replacing all previous pods. To verify that a new version pod is ready, this strategy executes the pod readiness probe. The rolling strategy is the default strategy for the
Deploymentand theDeploymentConfigresources. The strategy name isRollingUpdatefor theDeploymentresource, andRollingfor theDeploymentConfigresource.When a deployment starts, if the
maxSurgeattribute exists, OpenShift uses this information to create new version pods above the desired amount. Then, OpenShift scales down the previous pods by using the max unavailable count. In the case of theDeploymentConfig, if a significant issue occurs, then OpenShift cancels the deployment and rolls back to the previous version. OpenShift repeats this process until the deployment reaches the desired amount of new pods and the previous version is scaled down to zero.Use a rolling deployment strategy when:
You require no downtime during an application update.
Your application supports running the previous version and the new version simultaneously.
- Recreate
In this strategy, OpenShift first stops all the pods that are currently running and only then starts pods with the new application version. This strategy incurs downtime because, for a brief period, no instances of your application are running.
Use the
Recreatedeployment strategy when:Your application does not support running the previous version and the new version simultaneously.
Your application uses a persistent volume with the
ReadWriteOnce(RWO) access mode, which does not allow writes from multiple pods.
- Custom
The
Customstrategy, only available in theDeploymentConfigresource, enables you to provide a custom container image in which you define the deployment behavior. This custom image is defined in thespec.strategy.customParams.imageattribute of the application deployment configuration. You can also customize environment variables and the command to execute for the deployment.
The deployment strategies that use the OpenShift router features are listed below:
- Blue-Green Deployment
In Blue-Green deployments, you have two environments running concurrently, where each environment runs a different application version.
The OpenShift router is used to direct traffic from the current production version (Green) to the newer version (Blue). You can implement this strategy by using a route and two services and defining a service for each application version.
The route points to one of the services at any given time, and can be changed to point to a different service when ready, or to ease a rollback. As a developer, you can test the new version of your application by connecting to the new service before routing your production traffic to it. When your new application version is ready for production, change the production router to point to the new service defined for your updated application.
- A/B Deployment
The A/B deployment strategy allows you to deploy a new application version for a limited set of users. You can configure OpenShift to route most requests to the previous application version, and a limited number of requests to the new version.
By controlling the requests that each version receives, you can gradually increase the number of requests sent to the new version. Eventually, you can stop routing traffic to the previous version. As you adjust the request load on each version, you might need to scale the number of pods in each service to provide the expected performance.
References
For more information about differences between Deployment and DeploymentConfig resources, refer to the Comparing Deployment and DeploymentConfig objects section available in the Deployments chapter of the Building Applications guide for Red Hat OpenShift Container Platform 4.12 at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/building_applications/index#deployments-comparing-deploymentconfigs_what-deployments-are
For more information about deployment strategies, refer to the Using deployment strategies section available in the Deployments chapter of the Building Applications guide for Red Hat OpenShift Container Platform 4.12 at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/building_applications/index#deployment-strategies
For more information about deployment strategies using OpenShift routes, refer to the Using route-based deployment strategies section available in the Deployments chapter of the Building Applications guide for Red Hat OpenShift Container Platform 4.12 at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/building_applications/index#route-based-deployment-strategies
An introduction to Blue-Green, canary, and rolling deployments
