As more developers work within distributed environments, tools like Kubernetes have become central to keeping application components standardized across dynamic build and production environments. With the increasing complexity of application ecosystems and the growing popularity of Kuberbetes, tools that help manage resources within Kubernetes clusters have become essential.
In this blogpost, I’m usingHelm for setting up WordPress on top of an AKS cluster, in order to create a highly-available website. In addition to leveraging the intrinsic scalability and high availability aspects of Kubernetes, this setup will help keeping WordPress secure by providing simplified upgrade and rollback workflows via Helm.
Like all major cloud vendors, Microsoft Azure has it’s own flavour/spin on Kubernetes in a managed platform aptly named, Azure Kubernetes Service. PaaS Kubernetes offerings are really fantastic way to take advantage of the benefits that Kubernetes without the traditional system administration overhead (securing, patching, scaling etc…).
In this blogpost I’m taking you on the journey of creating an AKS cluster, deploying a (default installation of) WordPress blog using Helm and updating the WordPress version also using Helm.
In this example I’m using the next-next-next installation of WordPress using MariaDB. By default, the WordPress chart installs MariaDB on a separate pod inside the cluster and uses it as the WordPress database. This works for demonstration purposes, but for a production environment I advice you to use an external MySql database. This and other configuration options (such as the default WordPress admin user and password) can be set at installation time, either via command-line parameters or via a separate YAML configuration file. In this example I’m not using a yaml file with specific values for WordPress.
Enter the following to create a Resource Group for the AKS service:
First login to your Azure subscription :
az login
Now make sure you have the right subscription :
az account set -s <mysubscriptionid>
Ok, let’s start by creating a resource group :
az group create --name AKS --location westeurope
Using the admin portal, I can see the resourcegroup is created :
Next, we are going to establish the managed Kubernetes cluster with 3 nodes and send the endpoint to the previously create Resource Group:
az aks create --name AKSCLUSTER --resource-group AKS--node-count 3 --generate-ssh-keys
Using the admin portal, I can see that the AKS cluster has been created :
After the cluster has been established, let’s get the generated keys into our shell’s profile with:
az aks get-credentials --name AKSCLUSTER --resource-group AKS
Ok, next step. We need to install the kubernetes-cli. I prefer this using chocolately. You can install chocolately using :
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
Now let’s proceed install kubernets-cli using choco :
choco install kubernetes-cli
And now install helm using choco :
choco install kubernetes-helm
Now we are going to add the Azure Marketplace repo to the Helm repository :
helm repo add azure-marketplace https://marketplace.azurecr.io/helm/v1/repo
Check running config :
kubectl config get-contexts
Now let’s install a default installation of WordPress using Helm
helm install myblog azure-marketplace/wordpress
After a couple of minutes the WordPress website is deployed. You can check that using the using the following command :
kubectl get pods -w
You can use the kubectl get svc command to see which IP address is in use :
kubectl get svc
Here you see the WordPress website is available using the 51.105.X.X IP Address.
Ok, now you probably want to login to WordPress to check if everything really works. 🙂 But where are my credentials?
You’ve noticed the following screen when deploying WordPress.
By default the admin user is called User and the password is encrypted. This is how you can find the password beloging to the admin user called user. In this blogpost I’ve used the default next-next-next deployment of WordPress but you ofcourse would like to use specific values stored in a values.yaml file. (Will be in a future blogpost)
You can use the commands in the screenshot to find your password. In my case (because I’m using Powershell on a Windows 10 device) i didn’t have access to the base 64 –decode command. This is how to manually find your password :
kubectl get secret
You see the secrets stored for the myblog-wordpress website. Let’s get them! 🙂
kubectl get secret myblog-wordpress -o yaml
Ok, let’s copy that decoded password into a decrypter. When using Linux/Apple you can easily use decode64 for decrypting the password. You can also choose to install a decode64 encrypter/decrypter on your Windows 10 workstation or use any website which does the job for you. I’ve used www.base64decode.org (there is also an base64encode.org website)
Now you see the decrypted password beloning to the specified admin user and we are able to login to the /wp-admin website.
Because of its popularity, WordPress is often a target for malicious exploitation, so it’s important to keep it updated. We can upgrade Helm releases with the command helm upgrade.
To list all of your current releases, run the following command:
helm list
If you want to upgrade a release to a newer version of a chart, first update your Helm repositories with:
helm repo update
Now you can check if there’s a newer version of WordPress avaiable on the specific repo:
helm inspect chart azure-marketplace/wordpress
When there is a new version available, you can easily upgrade using :
helm upgrade myblog azure-marketplace/wordpress
(In future blogpost I’m going into rolling back upgrades)
In this guide, we installed (a default installation of) WordPress on a Kubernetes cluster using the command-line tool Helm. We also learned how to upgrade a WordPress release to a new chart version, and how to find the credentials needed to logon to the WordPress website.