In a recent attempt to get rid of my hacky, Mastodon-based way of posting short status updates to this very site, I learned about both Micropub—an “IndieWeb” way of more conveniently posting to one’s own site—and, a little later, Microsub.
A Microsub server—like Aperture, which I ended up installing—is very much like an RSS feed aggregator, though it supports more than just RSS, like JSON, and even Microformats.
Most if not all Microsub servers also require a separate client-side application. An IndieWeb reader, if you like. Notable examples are Monocle, a web-based Microsub client, and Indigenous, a native mobile app with versions for iOS and Android.
Quick remark: Even after I’ve sort of got things working, I still read blogs almost exclusively from my feed reader—Miniflux, currently. That said, Microsub does support Microformats and will thus better interpret richer, “IndieWeb” content.
If you’re happy with your current LEMP (or LAMP) setup, there’s probably no reason to use Docker at all. If, however, you’re running a multitude of services, built on different technologies, on a single server, it may be handy to use containers to keep ’em separated.
So, I set up a repo on GitHub, including a somewhat readable
README.md. The code itself is dead-simple and thus fairly readable, too. I’ll also be porting more info to this site (and update this very post when I do).
Aperture has quite a few dependencies, and comes with a fairly hefty
composer.json. On top of that, it needs a Redis server, and relies on Watchtower—note: not the popular Docker service—to keep track of feed updates, and a Camo-compatible image proxy to rewrite HTTP URLs to HTTPS and thus avoid mixed-content warnings.
Watchtower, then, needs a set of PHP packages itself, and Beanstalkd to handle queues. (Both Watchtower and Aperture use a MySQL database, too.)
In order to link all of these services together, and ensure they boot in the correct order, I decided to go the Docker Compose route.
Redis, Beanstalkd and MySQL—or, in my case, MariaDB—come with either official or well-supported Docker images. The Camo repository includes a Dockerfile and can easily be built.
For Aperture and Watchtower, I created my own set of very simple Dockerfiles, based on PHP’s minimal, Alpine-based images. Most of the magic, like downloading the actual application code and converting top-level
.env file values into usable config files, however, happens in each
For things to work, Camo, Watchtower and Aperture obviously need to be accessible over the web, so I added NGINX entries—any web server’s okay, though—and Let’s Encrypt certificates for all of them. I should probably include some example files in the Docker images repos.
Somewhat unrelated: Watchtower relies on a system service, so I included one (for Ubuntu, at least). (I’m not entirely sure why I can’t simply just hit
scripts/cron.php every 5 minutes using a regular cron job. I mean, you have to, but the service bit is required, too.)
A Word of Caution
Updates are a bit of an issue, still. You could enter the different containers and
git pull followed by
composer update—yes, I’ve actually included Composer in the Watchtower and Aperture containers—and then restore file ownership.
Or force delete each service’s entire
html folder, but leave
db intact, and then bring all containers up again. (This last step would download the latest code, and recreate the necessary config files. Which will break if the source repositories’ config files ever change.) And regenerate a Laravel app key, for Aperture.
It kinda sucks, but there are no version numbers, yet. Aperture and Wachtower are both in beta, it seems, and not (yet) versioned. I could use PHP versions for tags, but I’m not sure why. I mean, I’m choosing a certain version, for now, and don’t intend to support any other PHP variants.