Installing vanilla Drupal with Helm
Our initial setup is complete, time to install our first Drupal site on Kubernetes!
We will not actually create a fully-functional customized Drupal site, but rather use a community chart, just to wake us up slightly.
helm repo add bitnami https://charts.bitnami.com/bitnami
# "stable" has been added to your repositories
helm upgrade --install my-first-vanilla-drupal bitnami/drupal
If everything went well, this should result in something like:
NOTES:
*******************************************************************
*** PLEASE BE PATIENT: Drupal may take a few minutes to install ***
*******************************************************************
1. Get the Drupal URL:
You should be able to access your new Drupal installation through
http://drupal.local/
2. Login with the following credentials
echo Username: user
echo Password: $(kubectl get secret --namespace default my-first-vanilla-drupal -o jsonpath="{.data.drupal-password}" | base64 --decode)
You can now see Drupal in your list of Helm-deployed applications:
helm list
# NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
# my-first-vanilla-drupal default 1 2020-03-07 02:21:56.9271403 +0000 UTC deployed drupal-6.2.8 8.8.2
Let’s take a look at our services:
kubectl get services
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 35d
# vanilla-drupal-drupal LoadBalancer 10.245.210.73 <pending> 80:32232/TCP,443:30494/TCP 50s
# vanilla-drupal-mariadb ClusterIP 10.245.86.36 <none> 3306/TCP 50s
Services define your application as an abstraction layer: underlying resources (storage, computing power) may die or change; your service will always be available. In the above example, we have created a database service, and a Drupal service (the Drupal codebase along with a webserver). The external IP of the LoadBalancer service is how we’ll access Drupal. In the above example, the external IP is <pending>; rerun kubectl get services until you see an external IP for the LoadBalancer service. When I tried this I got 138.197.224.150, so after waiting five minutes for things to warm up, when I used a browser to visit http://138.197.224.150, I saw an actual running Drupal site. Yay! If after fifteen minutes you’re still not seeing a Drupal site, you might have a problem; if you see your Drupal site, let’s move on!
If you are not seeing a Drupal site when visiting the URL, it might be useful to visit the DigitalOcean Kubernetes dashboard to see if all your resources have deployed successfully. Adding resources (nodes) to your Kubernetes cluster via the DigitalOcean website might be helpful here. In such cases I have found it useful to delete the application and reinstall it.
First things first
Let’s not get too excited just yet. I just wanted to show you a Drupal site so you’d keep reading. However, our site is not set in a way that’s optimal for our needs:
- It exposes itself to the outside world via a LoadBalancer instead of ClusterIP. This is great if you want to quickly look at a site, but in our case we don’t want to access our site directly; rather we’ll use a reverse proxy to manage LetsEncrypt. Plus, each LoadBalancer is tied to our cloud provider DigitalOcean charges you $10 a month per LoadBalancer.
- It sets up two 8Gb persistent volumes to store data outside of Kubernetes, you can see these by typing
kubectl get pvc. These are charged at $0.10 a month by Gb, for a total of $1.60 a month.
We’ll prefer a more cost effective way to store data and to access our sites, but that entails a bit more work.
Let’s, therefore, delete our first site before moving on:
helm delete my-first-vanilla-drupal
You might have a volume (or, rather a PVC – persistent volume claim – see the glossary) lying around which was not deleted (and thus keeps incurring charges), you can delete it like this:
kubectl get pvc
# NAME
# data-my-first-vanilla-drupal-mariadb-0
# ...
kubectl delete pvc data-my-first-vanilla-drupal-mariadb-0
# persistentvolumeclaim "data-my-first-vanilla-drupal-mariadb-0" deleted