Real word Kubernetes… that is a slightly tongue in cheek title however in reading through a lot of blogs and how-to’s around Kubernetes, I never get a sense of real world application for Infrastructure and Platform Ops who are trying to get their hands dirty or even just understand what it is to run production level applications on Kubernetes platforms compared to traditional hosting platforms. Using the example of WordPress, i’m going to start writing a little bit about my experiences in trying to work out how to best migrate this blog over from a LAMP stack to a containerised instance running on Kubernetes. Often, simple tasks that could be performed on traditional hosting platforms are not as easy to achieve when applications are wrapped up in a container… this becomes even more challenging when Kubernetes comes into the mix.
To get myself to a point where I am confidently creating and running stateful applications on Kubernetes, I have gone through a learning journey through tinkering on my lab deployments of Kubernetes and focusing around storage and networking within Kubernetes. Just as a refresher, i’ve listed some of the core learnings around that below.
- Managed Kubernetes for Labs and Learning
- ROOK – Ceph Backed Object Storage for Kubernetes Install and Configure
- A Quick and Easy Load Balancer for Kubernetes Labs with MetalLB
Working with .htaccess files for WordPress
For the first post around this “real world” application, I will look at how to do something that is pretty easy when working with traditional APACHE based hosting platforms. That is, using the .htaccess file to modify default server configurations were applicable and allowed from within the working directory of a web server.
The .htaccess is a distributed configuration file, and is how Apache handles configuration changes on a per-directory basis.
In my case, as I work towards migrating this website off LAMP while getting comfortable working with WordPress on Kubernetes, I wanted to test the export/import process of my site using the All-In-One WP Migration Plugin. The problem I came across was that, by default when you deploy WordPress using HELM Charts, the maximum upload size of a file is only 80MB, meaning that the 2.1GB export file I had to import was too large.
With old school hosting, this was an easy fix and my first instinct was to try get into the shell of the WordPress container to add/make the change. I quickly realised that this wasn’t going to work due to a number of different reasons, but mainly not understanding the mechanics of the container hosting the WordPress website, I was not sure any file and file content I added was going to stick or be kept long term.
Using Config Maps to Leverage Custom .htaccess settings
Looking through the WordPress HELM Chart options for the deployment of the application, I came across a couple of options talking about using Kubernetes Config Maps in addition to setting some specific flags against the HELM chart deployment. In general the concept on Config Maps and how to attach and inject them into PODs is pretty confusing and convoluted (that’s typically Kubernetes/Containers). An similar example of what old school web hosters would know is with the php.ini file. Here is an example of how to get that injected into a pod.
For performance and security reasons, it is a good practice to configure Apache with the AllowOverride None directive. Instead of using .htaccess files, Apache will load the same directives at boot time. These directives are located in /opt/bitnami/wordpress/wordpress-htaccess.conf.
By default, the container image for WordPress includes all the default .htaccess files in WordPress together with the default plugins. To modify this you need to insert the new settings via a Config Map. To make them work, you create a custom wordpress-htaccess.conf file with all the required directives as show below
I added a few more directives to ensure the file could be uploaded and imported without issue. After creating the file, create a Kubernetes ConfigMap from the file. If you already have a namespace into which the application is deployed, you can specify that.
Once this is done, you can install/update the chart with the correct parameters as shown below (together with the rest of the commands used) to enable HELM to use the customer .htaccess file directives.
//* Create ConfigMap from File
% k create --namespace=asn configmap asnwpcustom --from-file wordpress-htaccess.conf
% k get cm -n asn asnwpcustom -o yaml
php_value upload_max_filesize 4096M
php_value post_max_size 4096M
php_value memory_limit 256M
php_value max_execution_time 600
php_value max_input_time 600
//* Create/Update HELM Deployment with the specific override flags
% helm install anthonyspiterinet bitnami/wordpress --set wordpressUsername=anthony --set wordpressPassword='password$12' /
--set wordpressBlogName='Virtualization is Life!' --set persistence.size=30Gi --set allowOverrideNone=false --set customHTAccessCM='wpcustom' --namespace=asn
LAST DEPLOYED: Mon Dec 6 21:09:01 2021
TEST SUITE: None
CHART NAME: wordpress
CHART VERSION: 12.2.2
APP VERSION: 5.8.2
** Please be patient while the chart is being deployed **
Once that’s been done, heading back to WordPress… the Maximum file size has now been set to 4GB
Some plugins permit editing the .htaccess file and it may be necessary to persist it in order to keep those edits.
Kubernetes may offer up a heap of advantages in terms of application mobility for they type of modern cloud native applications being written today, but when it comes to porting or migrating older applications from traditional platforms, some of the easy things we used to take for granted become a little more complicated. No doubt it is a learning curve for most… but it’s one persisting with. Now I can focus on other areas of this migration!