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.

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.

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.

Wrap Up

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!