Some time ago (319 days ago, to be precise) I logged into/signed up for Google Cloud Platform.
I got around to giving it a nudge a couple of weeks ago (my work is heavily AWS/Azure) and I’m wondering what to do with $300 of entirely untouched credits. They expire in the next couple of months
Perhaps trying a modest cluster of [email protected] containers running under Kubernetes.
Or… if I’m thinking about isolating my GCP infrastructure away from my normal Google account for a little more security will I feel better about getting a fresh pile of credits and not asking Google to take them away if I haven’t used the ones they gave me this time…
Sunday mornings are a good time to pause for reflection.
The last couple of weeks I’ve occasionally glanced at Jetpack and then dismissed it as probably too bloated with premium features to have it running on my site.
Today I decided that the features of Jetpack probably merit an install (preferable to maintaining three or four other light plugins) , and there is a page to explicitly disable any surplus modules in the plugin (although not linked from the GUI).
All correct, I thought. Then I found the centralised management – which lets the associated wordpress.com login install arbitrary (uploaded!) plugins and invite new admin users.
Suddenly the wordpress.com user is high value and merits two factor authentication, recovery codes and explicit Sign Out clicks.
There’s good indication that there should be a related module to disable – the categories in in Jetpack modules show “Centralised Management (1)” but it doesn’t list anything when selected.
I’ve finally taken more of a dip into docker than “docker run hello-world”.
If you haven’t heard of docker before (I don’t judge!) here’s what Docker.com says:
Docker is a platform for developers and sysadmins to develop, deploy, and run applications with containers. The use of Linux containers to deploy applications is called containerization. Containers are not new, but their use for easily deploying applications is.
My requirements are pretty simple. Someone mentioned a thing called “WordPress” on the weekend which is, apparently, a thing.
Spoiled by a first look with an AWS marketplace image I wanted to get the shiniest, bells and whistles version of WordPress going on my permanent server. Boo! My server is running Ubuntu 16.04 – and its idea of modern packages leaves a bit to be desired.
To the rescue comes a WordPress docker container – which bundles in all the prerequisites that would be a pain to get going on 16.04.
I already have an Apache web server, Postfix mail server and MariaDB database server, so I just needed to spin up the container and wire it in to the existing services.
Simple right? And see how nicely the arrows extend the stick figure legs – it’s stilt walking day.
It works like this:
Browser contacts the Apache server
Apache terminates the SSL connection and proxies request over HTTP to the WordPress container (on port 8080)
The WordPress container does its thing (pulling content from the existing (non-docker) MariaDB server, and the page is returned by Apache.
WordPress inside a container works nicely, but if we want the uploaded content and any changes to configuration files to persist across container starts it has to have some persistent storage.
After creating a folder for the html content we can expose it to the container with “-v /var/lib/docker/datadir/wp-testingtesting/html:/var/www/html”
Networking and Security
The default network connectivity for a container is to use a bridged docker network. For simplicity I used –add-host to put a “dockerhost” entry in the container’s host resolution file:
docker container run --add-host dockerhost:172.17.0.1 ...
My Postfix allows connections from anywhere (it hosts my domain, so needs to accept mail). As the bridged docker subnet doesn’t use the local address range Postfix won’t let it relay – which is fine for now, and easily fixed by adding to the Postfix main.cf if/when I open registration/subscription from the internet.
ErrorInfo: SMTP Error: The following recipients failed: [email protected]: : Relay access denied
MariaDB did need some changes, it was only listening on the loop back address (127.0.0.1). A simple change to listening on 0.0.0.0 (so mariadb would listen on all addresses) and then inserting a firewall rule allowing connections from the docker0 interface got it going:
That all looks right, so why was WordPress responding with bizarre redirections like http://127.0.0.1 or even http://testingtesting.netwp-admin/…
It turns out that WordPress really, really doesn’t handle reverse proxy, and doesn’t cope with HTTPS termination well either. A few lines of PHP added at the start of wp-config.php gave WordPress enough context to return pages with the right redirections. I’m still pertty disappointed that it’s using absolute links which include the site path, but there’s probably an exceptionally good reason…