Deploying Drupal to Kubernetes, no previous knowledge required
Kubernetes is a way of deploying resilient, scalable applications to the cloud.
- Resilient because Kubernetes is designed to recover if something goes wrong.
- Scalable because with Kubernetes, your application is not linked to a single virtual machine (VM), but rather to a cluster of VMs which you can scale up or down transparently.
What Kubernetes is not is a magic bullet. Before investing too much in Kubernetes, you are encouraged to read “Let’s use Kubernetes!” Now you have 8 problems, by Itamar Turner-Trauring, Python Speed, March 4th, 2020.
In this article, we will create a Kubernetes cluster and deploy a minimum viable Drupal installation to it, with the following features (this list will be our success criteria at the end of this article):
- Minimal vendor lock-in: we will avoid vendor-specific resources such as database and volume storage where possible, prefering our own containers.
- Deployment of Drupal alongside other applications: we will deploy applications other than Drupal to demonstrate how your Drupal app can coexist nicely on a Kubernetes cluster.
- Secret management: Your Drupal application probably has secrets: environment-specific information such as API keys, or database passwords which should not be in the codebase. We will see how to manage these in Kubernetes.
- LetsEncrypt: We will serve our different cluster applications via HTTPS using an Nginx reverse proxy, with set-it-and-forget-it automatic certificate renewals.
- Volumes: Our Kubernetes applications will store their data in volumes which can be backed up. In the case of Drupal, the MySQL database and the
/sites/default/files
directory will be on volumes. All application code will be on containers, as we will see later. - Automation of incremental deployments: deployment should generally be as automated as possible; most modern applications see deployments to production several times daily. In the context of this tutorial we are not recommending Kubernetes on production just yet, but rather to serve development environments; the performance and security concerns related to Kubernetes on production are outside the scope of this article, and frankly at the time of this writing I haven’t yet used Kubernetes on production myself.
- Easy local development: although having a local version of Kubernetes is possible, it can make your laptop really, really hot. We will use Docker and docker-compose rather than Kubernetes to develop our code locally.
- Branch staging environments: we will spin up environments per GitHub branch and destroy the environments when the branch gets deleted.
Notice that I haven’t gotten into the jargon of Kubernetes: nodes, pods, deployments, services; for me this has taken a while to get my head around, so my approach in this article will be to introduce concepts only as we need them. You can always refer to the glossary at the end of this article if you’d like quick definitions.
This tutorial is presented in several sections for your convenience:
- Setup
- Creating a cluster
- API, not GUI
- Getting the latest Kubernetes YAML file
- Interacting with Kubernetes
- Introducing Helm
- Helm on Docker
- Install Drupal via Helm
- Using a reverse-proxy ingress
- Configuring the reverse proxy
- Letsencrypt
- Customizing the Helm template
- Secure wildcard subdomains
- Custom Docker images
- Jenkins
- Next Steps
- Glossary
- Resources