Rafael Wenzel bio photo

Rafael Wenzel

Lead DevOps Engineer

Twitter Github Stackoverflow

Reclaiming Jekyll

After almost 4 years of radio silence on this blog, I am trying to get back in the game. But it is not as flawless as I would have wished for it to be. So I thought, what best to do than just document the process of reclaiming what has been my blog from 4 years ago?

And that’s exactly what I am doing now.

What we will learn today is:

  • How to reclaim a very old jekyll blog of yours
  • Dockerizing the exact version
  • Fixing everything up if something is lost

Where to even begin?

I must confess. My cleanliness in handling my code for this blog was apparently not the best. Turns out I do have an old version of my git repository from, what was now like the 3rd personal laptop migration, and also one large server migration. BUT this seems to miss 2 articles that appear on the homepage, but not within the posts list of my code. What a bummer.

Now, as the posts in my repository appear to be in .markdown extension, but I only seem to have the compiled HTML version, I need to get this re-imported.

So I went off to google, typed “html to markdown”, hit the first link (which was https://www.browserling.com/tools/html-to-markdown), and copied the HTML code parsed from the site into it. This I did for the last 2 articles and just saved the files into the _posts directory of my code.

What did I use again?

Before fixing the broken markup from the converter I need to first find out which engine I am using here. I know that I used Jekyll at one point, but also tried to switch over to Hugo at some point. I remember that Hugo was in Golang, and Jekyll turns out to be written in Ruby, after a quick google search again. So looking at the files in my repository, there is a Gemfile that says jekyll in there. So this must still be the very first version of my blog.

As I don’t want to stay with this engine in the near future, I have other plans, I have a couple of options I can do now.

  • Take the opportunity and just switch right now - although this will take up more time
  • Just fix this up again and start writing articles first - which is faster but will be a throwaway task
  • Start completely anew and lose all the old articles - doesn’t sound good to me

With my masterplan in mind, which already started, but is still a long time underway, I decided to just patch this up first, and be able to blog some more about my journey to get to where I want to be.

And as this is a technical blog, and these are technical tasks, why not write about it and help some people that might have similar problems with this.

Making a plan

Right now I am being a little overwhelmed with thoughts and tasks I see appearing in this endeavor. I need a process for writing, I need to get a process for releasing, I need to install requirements for the blog engine to function again. I need to figure out the little things needed for writing, formatting text, and all the shenenigans.

Now in the last 4 years I grew as a developer. I got really into docker and want now to dockerize all the things. If I am not developing in something, I don’t like installing it on my machine. To be honest, even IF I am developing something, I would not like to clutter my computer with plenty of different environments, which all have their unique way of installation, updating and servicing. Bur first things first. Here is the plan to get the blog up to speed:

  • [ ] Fix up the converted 2 old articles with the proper jekyll/markdown syntax
  • [ ] Figure out the needed versions to install for ruby, jekyll and whatever else is needed
  • [ ] Maybe update versions while we’re at it? (No, I want to switch anyway, so there really is no point)
  • [ ] Make a docker file for the container that will be used to build the blog
  • [ ] Make a script to easily build the blog (which can later be used for automatic update in a modern CI/CD fashion)
  • [ ] While we’re at it, also make a script to update the current site online (which already has been dockerized)

Getting back to business

[x] Fix up the converted 2 old articles with the proper jekyll/markdown syntax

So let’s start fixing up the articles. For this I check the other articles I have, and also my most favorite cheatsheet site (https://devhints.io/markdown) to have a quick overview of all the syntax I need. Cheatsheets are great, I use them all the time, as I just can’t remember all the languages, syntaxes and small things for all the languages, tools, or systems that I know or learn.

All the formating seems to have been properly converted. Nice. I just had to fix the highlighting, which apparently is some kind of plugin for jekyll. Soon I can see if this was all there was to be done to fix it. Fixing the two articles took me less than 10 minutes.

[x] Figure out the needed versions to install for ruby, jekyll and whatever else is needed

Let’s look into the Gemfile.

source "https://rubygems.org"

gem 'jekyll', '2.5.3'
gem 'jekyll-sitemap'
gem 'octopress', '~> 3.0

A look at dockerhub turns out, that We are lucky that the tag 2.5.3 is still available. So let’s prepare a a Dockerfile for the building container.

[x] Make a docker file for the container that will be used to build the blog

I myself like to always use docker-compose. It is easy, straightforward, and just feels more complete than simply using docker by itself. So I just typed up a quick dockerfile, and added it as a service to the docker-compose file.

FROM jekyll/jekyll:2.5.3

ENV APP_HOME /app
VOLUME $APP_HOME
WORKDIR $APP_HOME

ENTRYPOINT ["sh"]

With the following first draft of the docker-compose file, we should be ready to go.

version: '3'

services:
  jekyll:
    build: .
    volumes:
      - ./:/app

A quick docker-compose build shows, that it successfully builds and I can even docker-compose run jekyll into the container to look further. Task seems done for now.

[x] Make a script to easily build the blog (which can later be used for automatic update in a modern CI/CD fashion)

For dockerizing applications, I like to keep a neat docker-entrypoint.sh file as a base for all my things to do. So here is the bare bones file that I use in this project.

#!/bin/sh

while [ $# -gt 0 ]
do
  current=$1

  case "$current" in
    "install")
      bundle install
      ;;

    "bash")
      sh
      ;;

    "start")
      bundle exec jekyll serve
      ;;
  esac
  shift

Checking devhints again, I found out that before serving the testserver, I needed to run bundle install to install all packages. And then I can run bundle exex jekyll serve to run the testserver. Putting all these into the docker-entrypoint.sh file in this manner, I can easily execute multiple commands how I want to. For this I just need to change up the Dockerfile to include this change.

FROM jekyll/jekyll:2.5.3

ENV APP_HOME /app
VOLUME $APP_HOME
WORKDIR $APP_HOME

ENTRYPOINT ["./docker-entrypoint.sh"]
CMD ["start"]

Quick tip Remember the mantra: If the Dockerfile changes, run docker-compose build, if the docker-compose.yml file changes, run docker-compose up -d.

Now just having added the command [“install”, “start”] to the compose file, and we are ready to go.

A quick look at http://localhost:4000 reveals, that the blog has been properly built. Strike, that went pretty smooth.

Checking with the jekyll binary in the container docker-compose run jekyll install bash, the command build will obviously build the blog into a given destination. Per default that is the _site directory. So I quickly add this command to the entrypoint file, and should be done with this task.

The final act is now to make an easily executable script to build the blog.

#!/bin/bash

docker-compose run --rm jekyll install build

[ ] While we’re at it, also make a script to update the current site online (which already has been dockerized)

After comparing the currently online site with the local build, I do still see some differences. Especially in the header graphics and some descriptions. Unfortunately I don’t seem to have those changes around anymore. What do we learn from this? You should always commit after doing your work. And you should have a persistent area to put all your code, all your assets and everything important, really. And also, dockerizing and easing everything up with scripts helps a lot in the long run.

I will not do this task just now, as I want to fully automate this once it is switched to the new platform. For now, I just do this manually.

But at least I successfully reclaimed my blog after abandoning it for 4 years. Thanks to docker, google and some perseverance.