I make my living working with ASP.NET sites, but I really like static web sites. That’s why I chose Jekyll for publishing this blog.
Old Build Process
I spend most of my time working on Windows. Jekyll and Windows can be made to play well together, but it isn’t easy or intuitive, and if you obsess over using the most recent versions of things, it gets complicated.
I got super excited when I was finally able to use the Windows Subsystem for Linux because I was able to edit my blog code in Windows, and run the Jekyll tools from Linux without having to run a VM or dual boot. But it’s still a lot more work than I’d like:
- Open Ubuntu
- Navigate to the Windows file system where I store my blog code
- From a Windows command prompt, run my deploy script
New Build Process
Thanks to Docker, here’s my new build process:
- Run a batch file from a Windows command prompt
How Does It Work?
The Jekyll folks have a few official Docker images. I’m using the one with all the build tools.
First, I created a
docker-compose.yml file in the root of my project:
jekyll: image: jekyll/builder command: jekyll serve --watch --incremental ports: - 4001:4001 volumes: - .:/srv/jekyll
This file says:
- Create a service called
- When you run that service, run
jekyll serve --watch --incremental
- Map the container’s port 4001 to local port 4001
- Place the current directory (
.) in the container’s file system at
Then I added an exclusion for this to my Jekyll
port: 4001 exclude: [docker-compose.yml] name: Bryan Slatner job_title: Software Developer, Foodie, Cigar Lover
Now, I can simply type
docker-compose up to have Jekyll start serving up my blog locally on port 4001.
Automating the Build and Deploy
I can finally automate the whole build and deploy process with a simple batch file:
docker-compose run jekyll jekyll build fsi _scripts\deploy.fsx
This batch file uses docker-compose to run the Jekyll build inside the container. Since I’ve mapped my current
directory to the container’s file system, the build output goes right where I expect it to. The
deploy.fsx script is a simple script I wrote to compare the output of the previous build and the new
build and upload the deltas to S3 for hosting.
I blog a lot less than I’d like, but automating away all those mouse clicks and keystrokes means I might be more inclined to do more if it. I can only hope.