New Blog Infrastructure

Ben Madley, 14 Oct 2018

Hi all! This is a place where I’m tracking my own personal investigations and experimentations. Starting with this website. The eventual plan is for this to become a place with real advice for real people. For now I can look back on this as a reference and reminder for the things I’ve done and to cringe at the things I’ve said.

Infrastructure

The blog is written in Jekyll with continuous deployment from Travis to an AWS S3 bucket which hosts the website. I’ve made a GitHub Release which has the website just as all of this infrastructure was first created.

The rest of this blog post will be going through why I chose these platforms and which tutorials and troubleshooting I had to do to get up and running.

S3 Hosting

I chose to host the website on S3 for a few reasons:

1. I’m looking to get more involved with the AWS ecosystem.
2. I have some knowledge of AWS (the AWS Essentials course on Linux Academy).
3. I assumed it would be really simple to get started. It was.

I used this guide supplied by AWS. It was really easy to follow and I only had two sticking points:

• At step 2.5, “Test Your Endpoint and Redirect”, I didn’t know what it meant by the endpoint. It is found in the properties of the bucket and then clicking on the “Static website hosting” box.

• At step 4, “Testing” I didn’t see the note saying that changes may take time to take effect. This left me wondering why my site wasn’t there. Eventually it appeared.

Jekyll Blogging

I knew that I wanted to have a source controlled website, for the source control itself and so that I could set it up with a CI/CD system.

I didn’t want to set up and manage a database or make new posts via an interface.

Some bonuses that came along with Jekyll:

• Blogging in markdown.
• Really nice systems for repeated layouts and repeatedly used elements.
• A build step that was interesting to work into the CI/CD.
• jekyll serve for locally hosting the site automatically builds changes.

In the end I worked through Jekyll’s Step by Step Tutorial which was an absolute dream. The only problem I had is that you have to restart jekyll serve every time you change the _config.yml file.

Travis Deployment

Again, Travis was in the sweet spot of something that I want to experiment with but have some knowledge of. To set it up I used two resources:

• Travis S3 Deployment
• Jekyll Travis CI

Deploying to S3 was remarkably easy, possibly due to the experience I already had. One thing that I didn’t know (but in retrospect it’s pretty important!) was that Travis won’t complete deploy steps on pull request builds. I had initially turned of “Build pushed branches” to limit the number of builds I was running.

I also got the error message “No Rakefile found” on some of my earliest builds as I hadn’t specified a language, so Travis defaulted to ruby, but there was no ruby present. In the end the “GitHub and Travis CI” section of this blog by Michal Frystacky provided me what I needed.

Building and testing Jekyll had another issue. I got the error The command "eval bundle install --jobs=3 --retry=3 --deployment --path=${BUNDLE_PATH:-vendor/bundle} " failed. On some further research I found an issue on GitHub which told me that I couldn’t commit my Gemfile.lock. This was pretty sad, but for the sake of an easy life right now I settled for it. Until I look into it further, the only other solution I could see is doing work on this blog in a VM.

Next Steps

Potential next steps include:

• Infrastructure as Code!
• Integrating some of my previous projects (more info on some of these are to come)
• New projects! We all love new projects!