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 Folding@Home 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.
A quick shout out to Gitea (“GIT with a cup of tea”) – a smart HTTPS GIT server written in Go.
It’s fast, light, wise in authentication and has enough activity on the repository to make me think it’s a good option going forward.
It runs fast from a docker container on my rubber band powered test box, and may well become my token repo for things I don’t want advertised on Github.
Oh! Time to update the front page graphic and I can change the repo origin at the same time!
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.
Who wants to be an admin anyway?
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.
Data persistence
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
Host: dockerhost
Port: 25
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:
The reverse proxy (Apache) was more troublesome – mainly because of WordPress.
I put in a site file to answer the SSL and forward to http://127.0.0.1:8080. I’ll leave the forwarding of HTTP to the HTTPS site as an exercise for the reader.
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…
