Mastering deployments with Kubernetes & OpenShift

Rafael Benevides, Director of Developer Experience, at Red Hat spoke on rapidly deploying software on OpenShift with zero downtime.

Throwing software over to an operations team to deploy during a scheduled maintenance window is a thing of the past.  Businesses simply can no longer afford scheduled downtime.  Applications need to be developed such that small, frequent updates can be released continuously via containers.  Rafael shows us how to solve this problem with OpenShift.

Blue/Green Deployments

This is a released strategy where there are two or more release channels in which new software can be pushed to one channel.  Traffic is then safely migrated to the new channel, in a transaction-safe manner, at the proxy layer to the new code.  This gives you a safe failback mechanism while allowing frequent updates without affecting service to customers.  In the case of OpenShift, this means new containers are released to one of the two sides while preserving the older version as long as necessary.

In the OpenShift UI, it is just a matter of changing the route in the blue/green deployment.

Rolling Updates

Rolling updates are the default deployment method used by OpenShift.  This means that when a new container is pushed, OpenShift replaces the existing containers in a controlled way with the new software, as long as health checks are passed.  In non-container environments, rolling updates simply pull one node from the load balancer, update it, and place it back into service.  OpenShift essentially performs the same events, but on the container-level.

Canary Deployments

The canary term comes from the mining industry in which a canary bird was taken down into the mine, essentially detecting harmful conditions.  The software industry takes a more humane approach to canary deployments.  This essentially means the new software is released to a subset of users first for a period of time. OpenShift supports this method using a weighting methodology, all from within the OpenShift UI.  Once the canary traffic has been validated, all remaining containers are replaced.

CI/CD Pipelines

Deployment strategies can then be combined with CI/CD pipelines, ensuring continuous integration and continuous delivery. New software is then constantly tested and deployed. Features and bug fixes can be pushed to production as they are ready rather than as release windows are available.  This dramatically increases the value of development work to an organization. After all, features sitting in some dev branch provide no value to an organization.

In order to realize CI/CD, OpenShift provides a Jenkinsfile template for defining the automated tests and environment pipeline.  There is a large library of canned includes for the Jenkinsfile, making it super easy to just plug in the CI/CD functionality you need without the pain of developing it yourself.

As you can see, OpenShift gives you the tools you need in order to safely and continuously release software, breaking the mold of the traditional release window.


Download and try Red Hat OpenShift Container Platform for free.

For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Share