Containers are something that we use to run our applications and, normally, we dispose of the whole container when we build a new version of the application or need to upgrade something in the setup. This means that containers are generally having a short lifespan.

However, in this case, I want to show you how to build something that exists for an even shorter period of time and that can be used as an alternative to a local setup for building and testing applications locally before pushing it to test, staging, production, etc.

This is a simplified example of what is being done on a much bigger scale with moving your CI/CD pipelines to such disposable containers, and with libraries like Testcontainers.

In this case, I would like to show you how to setup Jekyll applications, but this can be easily applied to any kind of applications written in any of your favorite languages, like Java or Python. Until recently, I have been running a Jekyll installation locally with all dependencies installed on my machine. However, it has been a bit challenging when moving between machines and reinstalling operating systems. To simplify the process, I decided to containerize the local build and test processes.

I wanted the following:

• To build my code from and to the local folder on my (host) machine
• Run the application (in this case this blog) from a local folder on my (host) machine
• Avoid setting up the environment, or have a minimal and portable setup
• Avoid environment clean-up – I didn’t want to hold on to the unnecessary containers and container images

TL;DR: The solution

(see next section for the explanation)

$ export JEKYLL_VERSION=3.8
$ docker run --rm --volume="$PWD:/srv/jekyll" \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll build
$ docker run --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts

Explanation – line by line

So, let’s take a closer look at each of the lines:

1: export JEKYLL_VERSION=3.8

Just setting up versions that will be used later – a bit of housekeeping. Nothing exciting here.

2: docker run --rm --volume="$PWD:/srv/jekyll" \
        -it jekyll/jekyll:$JEKYLL_VERSION jekyll build

Here, we build the code and output it to the same disk volume as the source code, i.e. the volume that is shared with my host machine. Now I have the built version on my machine without the hassle of setting up the local build environment. In addition to that, I will be doing some clean-up, by deleting the build container after the build job is finished.

• --rm – just execute the command and clean-up (remove the container, file system, etc.)
• --volume – mapping the current directory to /srv/jekyll in the container
• -it instructs Docker to allocate a pseudo-TTY connected to the container’s stdin; creating an interactive shell in the container
  • -i – attach container’s STDIN
  • -t – allocate a pseudo-TTY
• jekyll/jekyll:$JEKYLL_VERSION – Docker image to use and the tag
• jekyll build – command to run

3. docker run --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
        -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts

This will create another container that will be running our application. Here we will need to add a few other parameters – like mapping the container ports to the ports on the local machine and giving the container a name.

• --name newblog – give your container a name
• --volume – mapping the current directory to /srv/jekyll in the container
• -p – bind port 4000 of the container to TCP port 4000 (-p host_machine:container)
• -it instructs Docker to allocate a pseudo-TTY connected to the container’s stdin; creating an interactive shell in the container
  • -i – attach container’s STDIN
  • -t – allocate a pseudo-TTY
• jekyll/jekyll:$JEKYLL_VERSION – Docker image to use and the tag
• jekyll serve --watch --drafts – command to run

Now you can stop the container with CTRL+c, and restart it again with:

$ docker start newblog -i

If you don’t want the container being persistent on your system, you can simply add --rm as in the previous command:

$ docker run --rm --name newblog --volume="$PWD:/srv/jekyll" -p 4000:4000 \
       -it jekyll/jekyll:$JEKYLL_VERSION jekyll serve --watch --drafts

• What’s going on?
• Setting the date in the front matter
• Setting the time zone in the Jekyll configuration file

What’s going on?

So, you have written a brand new post. You have run tests on a local Jekyll server, and everything looks great. You finally commit the changes to your GitHub site repository and push the changes to the server. You are excited and full of anticipation to see your new blog post online, you hit refresh in your browser, and… nothing. Another refresh – still nothing.

One of the reasons for this is that you have specified a date/time for your post in the YAML front matter in the header.

By setting a date in the front matter, you can override the date/time assigned to the post in the format YYYY-MM-DD HH:MM:SS. However, this notation will use the local time zone, set by your operating system. This works fine when running a local installation of Jekyll. However, if your Jekyll installation is running on a remote server (e.g., on the GitHub Pages server) the time on that server is likely not to be the same as the time on your local machine. Jekyll will then wait before processing the contents of the post until the specified time hits the clock on the server.

For your post to be processed according to your time zone, you can either add a UTC offset for your time zone for the post in question or specify a time zone in the Jekyll configuration file.

Setting the date in the front matter

To specify the UTC offset for each post use the following format: YYYY-MM-DD HH:MM:SS +/-TTTT, e.g. 2016-06-12 11:04:00 +0200. This might be useful if you want to specify the offset for some specific posts.

---
title: "Your title"
layout: post
date: 2016-06-12 11:04 +0200
---
Your content.

Setting the time zone in the Jekyll configuration file

If you want an offset to be applied to all of the dates on your site, you should configure Jekyll by setting the time zone for site generation in _config.yml.

Any entry from the IANA Time Zone Database is a valid value, e.g., Europe/Oslo. Wikipedia also has a list of all available values.

# set timezone
timezone: Europe/Oslo

If not specified, Jekyll will use the local time zone, as set by your operating system.

• Welcome
• What is this thing?
• Now what?

Welcome!

Finally, the site is up and running! The plan is to use it for mostly two things - geeky stuff and family history. Labs is where you will find posts about programming, software development, tech and all other geeky awesomeness. Family is where you will find the promised dash of family history and posts from other family members.

What is this thing?

Now, over to geeky stuff. I wanted the site itself to be a part of the technology playground I will be writing about here. I wanted it to be simple, extensible, responsive, and open-source. I also wanted to experiment with a site without a database, logins and all those (hackable) bells and whistles. The concerns were not as much about the security, but more about the simplicity of operation - things like upgrades, back-ups, deployment, and versioning.

After spending some time searching, doing the research and comparing different alternatives, I ended up choosing Jekyll - the engine behind, amongst others, GitHub. Static files, markdown, version control, GitHub integration, open-source, great themes and templates. Check, check and check! What else can you wish for?

Now what?

The site was up and running in no time, it was simple to customize, and here is the first post. Now I will just have to automate the deployment. Right now I am looking at several options, and more information about this will be posted here soon.

Looking forward to seeing how the site will develop and to the future posts. Stay tuned!