A Very Woolful Ghost

A Very Woolful Ghost

It's container month at Reclaim Edtech, so I've been pushing myself to revisit todo list items that might give me a reason to play with containers, and lo and behold I found another Ghost. This time it was a project my special lady friend has been working on related to wool, and I have been delinquent on two counts: 1) getting the email setup right through Mailgun; and 2) updating the version of Ghost to one without a critical vulnerability. I was dropping the candy corn, so to speak.

The Mailgun setup was pretty straightforward given I'd done that before and even wrote about it here on the bava. Below is a look at the Mailgun settings for Woolpine in Cloudflare, including the MX records, CNAME, and TXT records you are given by Mailgun to get setup for sending email through Mailgun over SMTP.

[caption id="attachment_26696" align="aligncenter" width="640"]

A peek at the Mailgun settings for Woolpine in Cloudflare[/caption]

The other things you'll need is to add the SMTP details like username, password, port, etc. (all provided by Mailgun) as variables in the Ghost container. Again, this is covered here already, so I'll spare you the drawn out details. The one new thing I did play with in Mailgun that was the Routes feature. This allows forwarding your domain email to something like a Gmail address. Super useful given we don't want to have an email address setup for woolpine.it, but rather send everything on to Antonella's Gmail account. I gave it a try and it was super easy.*

You simply go to the Receiving section in Mailgun for the specified domain and click on the Create route button

After that you can match the recipient you want to forward email for and then define the forwarding email address. There is more I can do to filter out spam and unwanted emails, but I was in a bit of a hurry, and this was a trial, and it worked!

So with the email for the Ghost site all set, now I had to upgrade Ghost from version 4.38 to the latest release. For some context, I am running this in Reclaim Cloud, and I installed it using the official Ghost Docker image. I have a load balancer in front of it to manage the SSL certificate and custom domain. I did notice a redeploy option in this Ghost node, which noted that the custom data (themes, images, posts, configurations, etc.) would not be written over, so I wanted to test this out.

[caption id="attachment_26700" align="aligncenter" width="640"]

Redeploy Ghost Containers to latest tag[/caption]

I always worry when redeploying a Docker image, so before doing this on the production environment I quickly cloned it in order to make sure I wouldn't lose any data. [Cloning Reclaim Cloud environments is pretty amazing for this kind of testing.]  Looks like this version of Ghost does separate out the volume data so that when you redeploy to the latest version, a.k.a. tag, nothing is lost. This is not the case with all containers, but the fact it worked here means all I had to do was click the big, green Redeploy button on the production site and Ghost was running version 5.24. YEAH!

[caption id="attachment_26701" align="aligncenter" width="640"]

Image of Ghost dashboard signifying upgrade to version 5.24 was successful

Upgrade to v5.24 successful![/caption]

That was a relief, and my learning around Reclaim Cloud and Docker via Ghost continues.

One of the questions this raises is why run an application like Ghost directly from Docker Hub in Reclaim Cloud as a custom image (as I did for this instance) versus going the route of installing Docker Engine and then installing the Ghost Docker container via command line? I believe the answer is with Docker Engine you will often have a more control, access and flexibility with the containers you are running. But this is also where things starts to get confusing because we are talking about a container (Ghost) within a container (Docker Engine), but I know when we ran into issues with Reclaim Roundup's Ghost instance (a Docker Hub install that did not use Docker Engine) we ran into a bug when trying to email more than 500 subscribers. Turns out it was next to impossible for us to resolve the issue given the bug had not been fixed for almost two years on the community image we installed directly.

We decided to migrate it to a custom image Taylor created which resolved the sending issue. And as it happens, soon after migrating the site away the community image resolved the 500+ subscribers sending bug and upgraded to version 5+. I think there is a balance here between understanding the inner workings of containers, comfort level with command line and installation, and long-term maintenance. It is one think to install a container with one-click, it is another to make sure there is a clear and simple upgrading/updating path, and that is definitely one of the bigger long-term challenges of containers. Like with plugins and themes, you are often at the mercy of the developers, so using an image that is not robustly developed and supported means its shelf-life may be limited.

*Turns out Cloudflare has recently introduced the same routing and managing emails feature. I am sticking with Mailgun for now given Ghost works with it out of the box, but if Cloudflare becomes an integrated option that might be interesting.