Use it as a local development and testing environment

DockPress can be leveraged for testing and developing your plugins and themes using a fresh WordPress installation in a local Docker environment.

Simply spin up a MySQL or MariaDB server, add your database credentials to the file secrets/credentials.json and run the following command from the DockPress directory:

docker run --env MARIADB_ROOT_PASSWORD=my_amazing_password \
           --env MARIADB_DATABASE=wordpress \
           mariadb:latest

docker run -dp 80:80 \
  --mount type=bind,src=$(pwd)/secrets,dst=/secrets \
  --mount type=bind,src=/path/to/my/theme,dst=/var/www/html/wp-content/themes/mytheme \
  dockpress

But that is not what this post is about. However, it would be very interesting to see others using DockPress as a part of their development process. (Hint: A Docker Compose file is on the agenda, which would help here in case anyone wants to contribute one.)

Use it in a Kubernetes cluster

This is what this post is actually about. DockPress can spin up and configure a resilient and flexible WordPress installation that runs in the cloud using Kubernetes.

Kubernetes is a system for deployment, scaling, and management of containerised server applications that can run as a cluster. It can scale up and enable resilience during times of high server demand, conduct rolling restarts instead of taking everything down with it during maintenance and potentially saves costs by only using the resources that it needs when it needs it.

Dockpress includes basic documentation on how to deploy WordPress in a Kubernetes container with a simple service on port 80, including YAML files for persistent storage configuration, service exposure and deployment.

The documentation is oriented towards Google Kubernetes Engine but can be adapted to other cloud providers. (Hint: Google Cloud Services have a rather detailed instructions on how to do this properly with a managed TLS certificate, while currently the aim here is to provide more of a platform-agnostic quick start guide.)

In fact, this blog is running on a Kubernetes cluster. (Albeit, usually only running a single pod.)

The benefits of scalable WordPress using DockPress and Kubernetes

Traditional shared hosting is the way to go for most WordPress sites and I would not recommend anything else in most cases, for small businesses or bloggers.

Hosting your own cluster in Kubernetes is far from being beginner friendly but it is one of the best ways to ensure resilience and uptime when your online presence is crucial for your business.

Broadcasters, news organisations, online retailers, airlines, railways, universities, critical healthcare providers and the public sector should seriously consider hosting their websites in a resilient and failure-proof way and the benefits of using vertically scalable Kubernetes for such critical services can be invaluable.

Scalability for WordPress sites

Arguments about the vertical scalability and resilience of WordPress (or any other web framework or CMS for that matter) can usually be attributed to a lack of knowledge about how things work and of best practices.

Most of us are used to the pros and cons of traditional shared and dedicated WordPress hosting. Both ways have their issues with resource ceilings, which tools can be used effectively and communication lines if things fail.

Vertical scaling in the cloud means that your infrastructure does not need to be running at full speed 24/7. If you are dealing with sudden traffic rushes and periodical spikes, you only need to pay for the sufficient capacity to deal with the spikes as they happen, which in some cases results in lower costs.

Cloud friendly configuration management

On deployment (as a part of the entrypoint script), DockPress automatically creates a new wp-config.php file and populates it with values from the credentials.json file and performs other configuration actions such as configuring and installing the Memcached object cache, disabling automatic updates and file editing, filtering URLs for static assets to point to your CDN service and removing built-in plugins.

Here is an example credentials.json file:

{
    "mysql_server":       "10.123.80.3:3306",
    "mysql_db":           "wordpress",
    "mysql_user":         "root",
    "mysql_password":     "9YC&_BiN8y}5d'br",
    "new_relic_app_name": "",
    "new_relic_key":      "",
    "memcached_servers":  ["10.123.81.131:11211"],
    "memcached_key_salt": "38ukPY7GbqzRpkyxxU24JSMm",

    "auth_key":          "R[69McKM;cWxL_X0krBHU@c=FAEuK7,n~`,P_*^)g7d+}W3E^u(g}}B>kR|ewA*[",

    "secure_auth_key":   "2@Q}K08Wy(AjCF^Fa)JS{^*ZZ-sQ,S&~c`{%.Q(=Y{h$CXo@,0&vG~*pK6k51xgu",

    "logged_in_key":     "YG%ew+S;[c7>Up=r0FA{e ~!O%* 3T`li+{!]EbcQhk+-}j^Ae#bbUkZteFEuvG<",

    "nonce_key":         "%qtolv2;Nza]=RUjX9or$O@em<5X%!]z_$SG0,>R>?P|3li3 d@xU[22v@zv,y/K",

    "auth_salt":         "tX,J*^e2msSXY6ZA{FtYV_J~HD&nX7eBt-y&72f-W]-,~}J67zi@#8,@ix&QiPG=",

    "secure_auth_salt":  "5V>_?y?k06sTiD&/m-(L<Ad`uCP`q,dBjKoeCPpH*zBIB88;yT,yxBbtDaz;kU~p",

    "logged_in_salt":    "91yb?|%0zWSnU#`]) UgZFv5w=Y3$3=mY]TUVAs,8#Cz@YYy*>OgrktHj]Lcik/j",

    "nonce_salt":        "xL:g1=wU.TfO]{b0_xvuSSE0~a7:%rU?re6l[FYwmZb<G(5I4BRrVm&J<ccMyy@)"
}

This is a step up from depending on a static configuration file and leverages the Kubernetes secrets management system (or ConfigMaps if you want to go that route instead). It is as easy as the following to deploy once you have set up your Kubernetes cluster:

kubectl create secret generic credentials \
        --from-file secrets/credentials.json

Note that DockPress does not overwrite an already-existing wp-config.php file, unless it is forced to, as besides the deployment stage, DockPress is built with the assumption that your WordPress setup is immutable.

Leverage your cloud provider’s services

Every supporting service for WordPress can be spun up in the cloud. This includes the MySQL databases, file services, storage buckets and caching services. Virtual machines and individual Docker containers can be provisioned as well for the same roles in order to save costs.

Cloud hosting providers also provide advanced backup facilities for their customers. You can provision, monitor, move and restore your infrastructure on your own, so in case of your WordPress site being critical to your mission, monitoring and disaster recovery can be done in-house.

Instead of relying on a WordPress specific CDN service or a 3rd party proxy service, you can use your cloud provider’s own CDN facilities to serve static content faster to your users.

Monitoring and problem solving with New Relic

Generally, when assisting clients with ongoing issues, a typical WordPress consultant very often has little or no tools other than the server logs, educated guessing and an unclear description on the issue at had to go by; if anything.

On top of the monitoring tools used for keeping an eye on the cloud infrastructure itself, application monitoring can be a godsend to anyone monitoring different aspects of a web app, including WordPress sites.

With New Relic it is possible to follow up on things such as slow database queries, which plugin is the biggest bottleneck in your stack and even monitoring data egress for GDPR compliance and front-end performance issues.

This removes the guessing game that consultants and agencies, stops the blame shifting that may happen between clients, agencies and hosting providers and enables anyone in the chain of responsibility to know what is going on.

Hosting providers generally do not offer this tool or anything similar to their customers, except in the case of boutique offerings in the 500 EUR range by the likes of WPEngine, while running a small Kubernetes cluster and related services usually costs a fraction of that.

DockPress configures and installs New Relic as long as the New Relic App Name and Key attributes are set in your credentials file.

Immutability prevents code injection

In case of an automatic installation, DockPress assumes your WordPress installation (including the core, plugins and themes) to be immutable and that those files do not change, except during the next deployment or restart.

The most catastrophic failures for WordPress sites lie in code injection vulnerabilities in certain plugins and themes or user credentials ending up in the wrong hands.

This in combination with the official recommendation of giving the WordPress installation write access to itself in the name of enabling features such as automatic updates and the built-in plugin editor may result in all sorts of havoc and liabilities down the road.

Immutability also ensures that every pod in your cluster is running the same version of the WordPress core, plugins and themes if it is not running WordPress from a network volume.

The wp-content/uploads directory on the other hand is of course assumed to be writeable and needs to be a network volume in order to stay persistent (so that your files don’t disappear on restart.)

Image processing that just works

Some Linux distributions used by WordPress hosting providers do not allow ImageMagick — which WordPress depends on for image processing — to process PDF files and related formats.

DockPress compiles, installs and configures all the necessary underlying software such as ImageMagick and GhostScript for getting things such as image thumbnails and previews for PDFs working.

Run WordPress from a network volume

If DockPress does not find a WordPress installation in its expected location, it proceeds to download, install and configure a fresh installation of the WordPress Core as it starts up.

This is fine for the purpose of testing plugins and themes or to quickly spin up a momentary site that does not require any plugins or persistent storage — but for serious use, using persistent network volumes is the way to go.

GCS and AWS each offer their own flavours of NFS file servers that can be used for this purpose, in addition to backup and restore services. (You can also run a virtual machine for this as well if it sounds better for your budget.)

This enables you to retain the same WordPress installation and uploaded files between restarts and to fine-tune file system access according to your needs, especially in case absolute immutability is not what you need.

The readme file provides instructions on mounting local directories as persistent volumes in Docker. DockPress also includes documentation on how to provision network storage on Google Cloud and mounting the volumes in Kubernetes.

Use WP-CLI

As DockPress installs WP-CLI on each pod, it can be invoked by administrative users with access to the cluster using kubectl exec -it $pod_name -- wp cache flush --allow-root. where $pod_name is the name of one of the pods in your cluster. (In a local Docker setup, the docker exec command can be used.)

The only caveat here is that WP CLI will warn you if you are running the command as root (which makes sense to warn about in a traditional hosting environment but don’t worry about it here) so you will need to add the --allow-root flag to your WP CLI commands as you go.