Edited at

Hugoが動くDockerイメージを作る

Hugo を Docker 上で動作させること、Hugo の Docker image を作成することについての知見をまとめます。


Hugo の Docker image

Hugo 公式が提供する Docker image はありません。手っ取り早く Hugo の Docker image が欲しい方は私が管理しているものを良かったら使ってください。新しいリリースがあればその日のうちに更新するようにしています。

CircleCI や GitLab CI/CD で使いたい場合は以下のイメージをどうぞ。

GitHub Actions は以下をどうぞ。


まず Docker を避ける

ローカル環境で動作させる Hugo はなるべくバイナリのものを使うべきです。Install Hugo | Hugo を参考にして


  • macOS なら Homebrew

  • Linux なら Snap や Linuxbrew

  • Windows なら Chocolatey や Scoop

を使ってバイナリをダウンロードして使いましょう。もしくは Releases · gohugoio/hugo から直接ダウンロードもできます。

CI/CD をする場合は Docker を使うことになりますが、手元のPCで動かす Hugo はバイナリのものが良いです。理由は以下の通りです。


Docker 上の Hugo は遅い

Docker 上の Hugo は hugo server の起動に時間がかかります。Hugo の最大の特徴である高速ビルドの恩恵が受けられないので、よほどの理由がなければバイナリを落としてきて使った方が良いでしょう。


イメージサイズが大きい

ただの Hugo を alpine 上で動かすのであれば 60MB くらいには収まります。ですが Hugo extended や v0.56 から導入された Hugo Modules を使いたい場合には glibc, Golang や Git などの依存が必要になり、たちまちイメージサイズが膨れ上がります。すべての機能が使えるイメージを作ると 800MB くらいになります。

この記事で言うところのイメージサイズは docker imagesdocker image ls で確認できる容量のことです。


apline にこだわるな

最近の Hugo は依存も多く、イメージサイズを小さくすることは難しくなりました。

alpine base の小さいイメージを作ることにこだわった時期が私にもあり、Hugo extended が動作する alpine base のイメージを作ったこともありますが、結局、正常に動かすことができず多くの時間を無駄にしました。今では素直に Debian ベースで作ることにしています。


glibc

Hugo には SASS/SCSS のトランスコンパイルができる Hugo extended version が存在します。その Hugo extended が動作する alpine ベースの Docker image を作るには glibc を含める必要があります。


Hugo Modules

v0.56 から導入された Hugo Modules は Go Modules と Git に依存しています。従って Hugo Modules が利用できる Docker image にはGo言語の環境を含めなければなりません。この時点でイメージサイズは alpine 系でも 300MB 近くになります。ここまでのサイズになると、もう alpine なんかどうでもよくなります。(Hugo Modules のおかげで alpine へのこだわりを完全に捨てることができました。もちろん apline 系の Golang のベースイメージでは extended は動きません。)