Self Publishing Sites with 11ty

17 July 2020 | Andrew Duffy

This blog has been a new direction for me. Previous iterations of blogging/creative writing has predominantly been in Wordpress which has suited my style for 2 reasons:

  • When creating content I want an editor that make it easy for me to focus on what I'm writing
    • Read as easily distracted
    • Ideally avoid spend time styling and focus on the content
  • When publishing, I want fine grained control over the final output

That was something that Wordpress ticked the boxes for me pretty well, sure it has a heavyweight PHP stack to wade through to adapt its themes, but generally the plugin ecosystem has been varied enough to cater for most of my needs.

But gradually I was just being inundated by needs to continually maintain and patch the instance, plugins, the theme occasionally, as well as dealing with a never ending stream of increasingly sophisticaled spam comments and attacks on the admin portal by russian based bots (I checked the IP sources, I'm not just generalising). I also suffered through a point when the managed hosting provider I picked decided to perform unscheduled patching schedule and corrupted the database instance I was using... so much for quickstarts being nice and easy. (And my manual backup wasn't exactly brilliant at that point).

I've always subconciously wanted to do it on the cheap (I'm Scottish, its a fair stereotype). And that isn't a goal I'd achieved through Wordpress at all, between paying for its hosting costs and my own time in maintaining the site it was sucking up more effort than I was happy with.

So this is an attempt to simplify all that by stripping things right back to basics as far as I can.

Make an image here of a simple html page

Ok... maybe not that basic. It's not 1993 anymore and I'm not so tight for time that I'd leave everything as pure unstyled syntax.

Find a writing environment

So for me, what's a happy middle ground?

Probably:

  1. having a clean uncluttered way of editing quick posts and mid-length articles

  2. don't lost my content if someone other than me messes up

    bonus points if I can recover it if I mess up

  3. have a way to stop drafts being mixed in with public work

  4. find a way to host it for free, or pennies

  5. minimise the amount of spam noise the site generates

So thats given me some acceptance criteria:

  1. write in something simple - Markdown

  2. Find somewhere to keep it safe - BitBucket

    At some point I'll summarise my views of BitBucket vs Github

  3. Use branches for published and draft contenent - Git Feature Branch

  4. Host content on a cheap static storage, using the cheapest storage I can and use a CDN

    I don't care about it being lost, I've got a way to recreate it again

  5. Keep the content static when its published so no one can edit anything I care about - 11ty

I'll probably revisit that last one at some point, for now, I'm sorry I'm being anti-social, but I'd rather respond to people than spam. If you really do want to grab me, you should be able to find a way to do that on my homepage (if you can prove you're a real person... suitably advanced robots also welcome).

That's given me a way to write posts, check them into version control and somewhere to let people see them... ok it's a start. Now how do I satisfy lazy writing me even further?

blog automation workflow

Ah... CI/CD.

What a writer needs? Nope...

Overkill for a blog? Probably...

An interesting way to experiment with pipelines and web hooks? Yup, well interesting for me at least... watch this space for how this will grow into an API Workflow.

Self Publishing Workflow

To be honest, there's not a great deal of technical interest from that point on, all that's required:

  1. Setup a S3 Bucket and Cloudfront Distribution
  2. Create a dedicated IAM user for BitBucket and give it an access key
  3. Create a simple policy so that it can write to S3 (no need for read permissions here)
  4. Setup a BitBucket repository and enable pipelines
  5. Provide it with your AWS Access Keys, and a target bucket in its settings (make sure to check the keep secured flags for your keys)
  6. Commit a bitbucket-pipelines.yml file to establish the pipeline from only the master branch and push to master
image: node:10.15.0

pipelines:
   branches:
    master:
      - step:
          name: Build artifact
          script:
            - npm install
            - npm run build
          artifacts:
            - _site/**
      - step:
          name: Deploy to S3
          deployment: production
          script:
           - pipe: atlassian/aws-s3-deploy:0.3.8
             variables:
               AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
               AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
               AWS_DEFAULT_REGION: 'eu-west-1'
               S3_BUCKET: $S3_TARGET_BUCKET
               LOCAL_PATH: '_site'
               ACL: 'private'
               STORAGE_CLASS: 'ONEZONE_IA'

After that, its just a case of editing markdown files, committing them and merging these into the master branch, and waiting for the pipelines to publish the content.

It's even got the bonus of emailing me if the build fails for some reason rather than me relying on noticing it. There's a bonus.

But... doesn't BitBucket charge for Pipelines?

Yes... well spotted, but on its free tier Atlassian provides you with 50 build minutes per month. My compilation and publishing tests run for around 2 minutes, which means unless I get remarkably productive and start publishing 20 posts a month I shouldn't even come close to that.

One fly in the ointment... Using S3 as a private bucket with a CDN in front of it doesn't play so well with the way 11ty transforms its Markdown files into html and we need a lambda registered with our Cloudfront distribution to forward on the references to the index.html files without having to manually add them to every link (and to me keeping the URLs neater).

But I'll write a more detailed post about that so others don't have to wade through all this to find it.

Update

I've also discovered how to reduce my build times even further, through the use of the Bitbucket Pipelines cache. This was actually something that was on my list to look at to optimise once I had a feeling how often I'd actually publish, but looking through the pipelines I discovered 1m 37s of my 2m build time was bringing down the node dependancies...

So that means by enabling that I've started caching node's dependancies, my build times are down to 59s for most builds, and a 2m build each week when Bitbucket purges the node cache. So back to being more cost effective with my build minutes.

Find me on ...