My own self-hosted WordPress installation served you this article. In this article, I’ll describe how I built my WordPress infrastructure using docker. I’ll also share some reasons for using docker, as opposed to some other deployment method. The source code is available on my gitlab.
WordPress dictates a couple technology choices. The biggest one is MySQL (or Mariadb) as the database implementation. WordPress is not database agnostic, and so I cannot use Postgresql as I would like to. It is written in PHP, so we’ll need some kind of PHP execution framework. I used the fast-cgi with nginx container. Alternatives include Apache with mod_php, or Apache with fastcgi.
The primary concern was honestly trying to avoid building my own blog system instead of writing the blog. I still wanted to self-host whatever I used, because I have the hardware and it’s enjoyable, but the primary focus was to blog, not to build software. I didn’t completely avoid it, as I did build a bit of infrastructure for this self-hosted WordPress. It was a compromise for my tinkering and my desire to just get things done. There are some downsides to choosing a popular blogging framework, which I tried to mitigate with automated updates. Since it is the most common, it is the most likely to be compromised, and keeping it up to date is the most important thing I can do.
I require 3 things from my WordPress Installation:
- Secure
- Easy to use
- Performant
Secure
I am concerned that using the most popular blogging framework out there would expose me to the most popular hacking tools. I wanted to take steps to make this more secure. There’s a few ways to attack web applications, and so security is not just one solution. The easiest step is to use a secure password to log in, one you don’t use anywhere else. I recommend using bitwarden as a password vault to help with this. Bitwarden is open-source software and can be self-hosted.
Self Contained
For security, my self-hosted WordPress installation is self-contained. If (when?) it does get compromised, the attacker will have as little access as possible. There are several ways to do this, and I chose to use Docker. Docker provides some security features out of the box. WordPress provides a docker image that they maintain, and that was a factor influencing my decision. As well, I chose to self-contain the MariaDB database in a docker container. This way, the attacker can only gain access to only the blog posts stored there, and no other data. Limit the scope the attacker can get to. The only thing that WordPress can see is the database beyond the local file system it is on.
Up to date
I also chose docker as an easy way to keep the site up to date. Ouroborus and watchtower provide polling of the source of your deployed image for updates. The docker container for WordPress updates a day or so after their release. That’s not quite as good as automated updates that they provide out of the box, which makes me think about switching to another style of deployment. Additionally, I use some additional PHP modules that aren’t part of the default WordPress image, so I have to provide some way of re-building my image. Fortunately, gitlab can provide that, trivially. I have a nightly pipeline that runs pulling and updating the base WordPress image, and then applying my necessary changes. The pipeline publishes the image to my HomeLab Docker Registry that I wrote about previously. Ouroborus picks that up and then automatically updates and restarts my self-hosted WordPress. It does the same for the MariaDB instance.
Easy to Use
WordPress is much more impressive than I remember it being. I used it shortly, probably nearly 10 years ago. Maybe a bit longer than that. I think WordPress has been around that long? I ended up using Serendipity instead, at the time. Needless to say, WordPress is extremely easy to use. It is the most popular blog engine for a good reason. I don’t get caught up in markdown formatting rabbit holes, or implementing fancy tag libraries to post content.
Performance
I handle site performance a few ways. Probably the largest contributor to performance is CloudFlare. They provide a free tier that is perfect for my blog at this stage. I have still used W3 Total Cache to provide object caching and page caching. Fortunately, it also communicates with CloudFlare and provides easy cache busting when a new post is uploaded. There are many articles out there to cover performance, but I’ve chosen to purchase Technical Blogging: Second Edition. It has a plethora of specific advice, which helped me focus on the blogging, rather than getting caught up in the technology.
You can find the source code for my blog’s infrastructure automation on my gitlab instance. And you’re looking at the actual WordPress it’s providing, right now!
