Hugo and VS Code Dev Containers
September 19, 2019
Estimated reading time: 4 minutesThis post was published some time ago. The world of technology is rapidly evolving, and in some extreme cases even posts just one month old will be out-dated. So there is a chance that some of the concepts, technology or pricing in this post is no longer applicable.
Last month I revamped my old blog. I figured I wanted to write more blog articles and needed a easy platform to do so. I had previously been using Jekyll and had been quite happy. But after a look at Hugo I wanted to give that a try. Really just for the “kicks of it”.
Both are static website generators. But Hugo offers some more bells and whistles that I wanted to make use of like Shortcodes
and easy templating.
Jekyll had some of the same features, but I would have to get my hands dirty in some Ruby code if I wanted to create such things.
And not needing to have Ruby installed for building the site locally is a huge plus.
Hugo is a single executable, and easy to move around, or even commit as a part of the site git repository.
This post is not really on Hugo and its capabilities but how to set up a easy dev container that you can use to get started quickly using Hugo on VS Code.
Disclaimer: This is strictly just over engineering. Just committing the executable as a part of the git repo is the easiest path to take.
And the results would be the same. But.. It would not be “as cool”, “as hip” or whatever you may call it. And since Dev Containers
are a bit hyped right now. So why not?
Dev containers is a new feature in the Visual Studio Code editor that enables you to use a docker container, your local WSL or a remote server as your development environment directly in VS Code. No need to install or set up any dev dependencies. Just open project and the container gets spun up. You can debug and run the code just as you normally would locally. There is little that indicates that you are developing on anything else than your local computer.
I have used this new feature for a while now and have ended up using it for most of my development. Just because it is so easy to switch computers without having to install a whole lot of dependencies when I pop on my laptop and want to work on the project I started on my desktop computer. I can get working on my project without any real downtime having to install anything. That is nice!
If you want to know more about how Dev Containers work and how to get started using it. Then have a look at this site: Developing inside a container.
VS Code Hugo Dev Container
So let us get in to the details here. Lets see how a dockerfile for such a container looks!
devcontainer.json
{
"name": "Hugo site",
"dockerFile": "Dockerfile",
"appPort": 1313,
"extensions": ["streetsidesoftware.code-spell-checker"],
"settings": {
"files.exclude": {
"**/resources": true
}
},
"runArgs": [ "-u", "vscode" ]
}
Dockerfile
FROM debian:9
# Avoid warnings by switching to noninteractive
ENV DEBIAN_FRONTEND=noninteractive
# Or your actual UID, GID on Linux if not the default 1000
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID
# Configure apt and install packages
RUN apt-get update \
&& apt-get -y install --no-install-recommends apt-utils dialog 2>&1 \
&& apt-get -y install git procps lsb-release wget \
&& wget https://github.com/gohugoio/hugo/releases/download/v0.58.3/hugo_extended_0.58.3_Linux-64bit.deb \
&& dpkg -i hugo_extended_0.58.3_Linux-64bit.deb \
&& rm hugo_extended_0.58.3_Linux-64bit.deb \
#
# Create a non-root user to use if preferred - see https://aka.ms/vscode-remote/containers/non-root-user.
&& groupadd --gid $USER_GID $USERNAME \
&& useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME \
# Add sudo support for non-root user
&& apt-get install -y sudo \
&& echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
&& chmod 0440 /etc/sudoers.d/$USERNAME \
#
# Clean up
&& apt-get autoremove -y \
&& apt-get clean -y \
&& rm -rf /var/lib/apt/lists/*
# Switch back to dialog for any ad-hoc use of apt-get
ENV DEBIAN_FRONTEND=
All done!
So that is it! There is “nothing more too it”. Even though this is way more than one would normally need to do to get this up and running. But why engineer when one can over engineer! (I am looking at you Javascript developers!)