History

Regarding computer hardware I have had to hand in the last two years or so, things have been in flux, you might say. I have not had ready access to a proper non-work Linux desktop environment where I could happily run Docker and Python. This has meant that keeping my Pelican blog up to date has been rather difficult, and hence the content has somewhat languished.

I’m back to where I want to be now, having procured a new desktop machine quite capable of hosting a Docker environment effortlessly, so thought it was time to look once again at breathing life into this site.

Here follows a description of the new publishing process!

Docker Revisited

In the previous post about this I wrote about how Docker became part of the publishing process, replacing Vagrant which had become a pain to because of such heavy maintenance overheads and the lack of task focus that a Vagrant machine suffered from.

However, at the time, I approached Docker very much in a Vagrant mindset; that is, I prepared Docker images with a view to logging into them once the containers were running. Once logged in I used the pelican bash script to do the usual drafting, publishing and deployment operations.

New Docker Image

With a fresh Linux installation on a new machine, an opportunity arose to do things differently. I created a new Dockerfile with a minimal installation of Python, based on Alpine Linux

FROM alpine:latest

COPY requirements.pip /tmp/
RUN apk add --no-cache python3
RUN pip3 install --upgrade pip && \
    pip3 install -r /tmp/requirements.pip

CMD ["pelican", "-h"]

The requirements.pip is very simple, specifying a pretty minimal set of libraries:

pelican
pelican-minify
markdown
beautifulsoup4

Thus was born a 35.29 MB image, small but perfectly formed and an ideal fit for the task.

File System Layout

Next job was to lay out the file system so that the Pelican plugins, themes and site build requirements were all together in one area.

.
├── pelican-plugins
├── pelican-themes
└── sites
    ├── chrisramsay.co.uk
    │   ├── build
    │   │   ├── configs
    │   │   │    ├── preview_settings.py
    │   │   │    └── publish_settings.py
    │   │   ├── configs
    │   │   ├── content
    │   │   ├── preview.sh
    │   │   └── publish.sh
    │   ├── local
    │   └── publish
    └── someothersite.com

The pelican-plugins and pelican-themes directories are just git clones of Pelican’s Plugins and Themes repos respectively.

The Preview and Publish Scripts

The preview.sh and publish.sh scripts are what are used to render the HTML into either a local development directory or a publish pre-deployment directory. Essentially, these scripts start a container, mounting several volumes and then running the pelican command with the necessary child commands. Let’s have a look at preview.sh:

#! /bin/bash

BASE=/home/user
sudo docker run \
    --rm \
    --volume ${BASE}/sites/chrisramsay.co.uk/build:/site \
    --volume ${BASE}/sites/chrisramsay.co.uk/build/content:/content \
    --volume ${BASE}/sites/chrisramsay.co.uk/local:/output \
    --volume ${BASE}/pelican-themes/pelican-bootstrap3:/theme \
    --volume ${BASE}/pelican-plugins:/plugins \
    chrisramsay/alpine-pelican \
        pelican /content -o /output -t /theme -s /site/configs/preview_settings.py

Once the HTML site has been rendered it’s time to take a look at it using a browser. This is where NGINX comes in.

Using NGINX for Previewing the Site

Here I am using an official Docker image from NGINX; pretty straightforward:

$ sudo docker run --name nginx-cr -p 8080:80 -v /sites/chrisramsay.co.uk/local:/usr/share/nginx/html:ro -d nginx

In the above code I am firing up an instance of and NGINX web server to serve the new static HTML files from the local directory. There is an order to doing things here