Looking to achieve production grade Drupal deployment using Kubernetes? Find out the business value of running your Drupal site on OpenShift, the industry’s most advanced Kubernetes distribution.
Somewhere around 2017, I recall migrating my blog(running Drupal 8 at that time) to Kubernetes, just to test the then uncharted Kubernetes waters attempting to understand the buzz behind the technology. Not a lot of documentation was around, especially for a non-12-factor app like Drupal, it was a long journey, but was worth it. This, despite the fact that I’d already jumped the docker bandwagon.
By deploying changes automatically after doing a proverbial git push, I could taste immediate success. I then ported a couple of average traffic production sites to Kubernetes running in different flavors(or clouds). Ever since Kubernetes never ceases to amaze me. I found myself using a set of repeated patterns over Kubernetes, and discovered that OpenShift does is already for me.
In this series, I want to walk you through how to set up your Drupal site on OpenShift and what value it might add to your life/work/business. So, if you are a developer, business owner running Drupal or a DevOps engineer, you will get a little something out of this. I’d also want to take this opportunity to introduce a product I’ve been developing around the Drupal + Kubernetes space.
Business value of OpenShift
We will first address the what and why of things. Why would you want to run Drupal on OpenShift?
To answer this, we will have to see what business value OpenShift provides.
Optimal usage of resources
After outliving the VM era and moving to container era, I realized that one of the byproducts of containers and Kubernetes is the optimal resource consumption. The number of applications you could run per unit of compute(or per VM) considerably increases if you use containers. You reap this benefit even without using any orchestration solution. An orchestration layer(like Kubernetes) furthers this by optimally allocating resources required to run your app. This is a clear and immediate win if you switch to containers from VMs.
Uniform and modular code across the team
How many times you have had newcomers to your team face onboarding issues when setting up the environments? Do you have clear and consistent steps to create a production replica for your QA to analyze that bug? You get to fix both these issues by using Kubernetes. For the first case, you just check in the app setup code, Docker file specs, the Kubernetes workloads as part of your code base for any developer in the team to consume. For the second case, you just fire a deploy script with the above Kubernetes workload and create a new environment in moments. One of the consequences of a uniform and modular infrastructure-as-code approach is the delightful developer experience your team gets.
Ship features faster
With the actual task of deployment automated and out of the way, it becomes a lot easier to ship code frequently and get early feedback. This is accelerated by practices like per-branch environments and continuous delivery. If anything, this advantage alone would substantially benefit an organization of any size.
Scale as your business scales
Nowadays, no matter where you run your code on, scaling out your app is an easy operation. In the case of Kubernetes, it is a given/staple aspect of your application lifecycle. Besides, you can do much more than just scale, like rolling out updates in batches, blue-green deployments(although it is debatable how effectively this can be done for Drupal) and rolling back to older versions.
You’d have noticed that I use Kubernetes in most of the examples, but the title is “business value of OpenShift”. I’ll address that in a moment.
It is easy to spin a Kubernetes cluster and quickly reap the above benefits by containerizing your app. There are 2 things which stand in the way of successful Kubernetes adaption.
The steep learning curve of Kubernetes
The leap from containers and docker files to Kubernetes constructs is a big one. You ahve to bump up your team’s devops literacy so that they are suddenly aware of things like persistent storage, environment variables, different services powering the app etc. These are things they didn’t previously didn’t worry about.
This is compounded by the complexity of running Kubernetes itself. Although most cloud providers offer Kubernetes as part of their services, it is still hard to maintain a Kubernetes cluster. How do you set the correct roles and permissions? How to add a node to your cluster? How to wire your container registry with your cluster? All these questions can consume your energy which is otherwise spent in shipping your code.
There is also the nontrivial effort to containerize your application so that it operates well in a Kubernetes context.
The best Kubernetes service at the time of writing this is Google’s Kubernetes offering. You still have to configure this and make it work for you for best results, or you can run OpenShift Origin.
OpenShift Origin(also known as OKD) is a Kubernetes distribution, which comes packaged with an assorted set of components. These help you run your Kubernetes workloads quickly without spending a lot of time in analysis-paralysis. For the curious ones, you can read what are the technical differences between OpenShift and plain vanilla Kubernetes.
Why should you run OpenShift?
1. It is open source and built on open standards. You can always port your app to run on plain Kubernetes setup if needed and there isn’t any sort of vendor lock-in.
2. OpenShift is cloud-agnostic. You can run an OpenShift cluster on any popular cloud provider and you don’t incur the risk of marrying a specific provider. Also, you can run OpenShift on your own datacenters and bare-metal servers. This is a huge advantage for teams who can’t use cloud providers but want to get the advantages of using Kubernetes.
3. Done-for-you choices. OpenShift is boring and in a good way. It takes all the set of best practices and components proven to work well and bundles it for you. Also, it points to a more stable version of Kubernetes so that you are being powered by software which is stabilized over time.
Wishlist of features
We have knocked down why we have to use Kubernetes, and which distribution best fits our needs. Now, let’s define what we want Kubernetes to do for us. Over course of time, I’ve come to groom a set of features which are preferred across teams of all sizes. This is very Drupal-specific but can be adapted to other stacks as well.
Per branch environments
I want my cluster to spin a new production clone for every feature branch I create in git. This is a popular feature offered by many commercial platforms as well. I think this is a must for a modern Kubernetes based solution.
I’d like to scale up/down my application based on a certain metric, like CPU usage. Optionally, this could be automatic as well, where my cluster monitors my app and adds new nodes to cater the demand.
Sync git push with deploy
Git push automatically triggers a new deployment to my environment. This is a bit hard to wire up in a plain Kubernetes setup, but a staple part of OpenShift.
The cluster automatically backs up application artifacts like files and DB and provides the ability to restore them.
Copy files and db from production
This is a subset of per branch environments where new environment created automatically copies the files and DB from production snapshots.
We have established the value add provided by Kubernetes(and in turn OpenShift) and clearly cut a path on what we want out of such a system. Stay tuned for the next post where we will walk the core of our actually implementing our Drupal setup.