Fix Docker/Dockerhub situation

[kav]

I'm aware that in #4155 @ellerbrock created dockerhub and quay accounts and @bep mentioned a different dockerhub account and @skoblenick proposed that one day hugo should be an Official image and #4518 incorporated all @ellerbrock's changes into the dockerfile.

However...

Neither Quay nor Dockerhub currently have a remotely up to date version of hugo at present in any of the above mention locations.

What would it take to get automatic publishing on dockerhub tied to this repo at either of the gohugo or gohugoio dockerhub accounts?

[bep]

Some months ago I would probably have answered "why do you need a Docker version?", but with the recent libsass extensions, I can see the need.

I have one Docker image living in my account that belongs to Gohugo, and we should also get a binary version in here. I remember vaguely the person behind the gohugoio said he was willing to transfer ownership.

[kav]

Well it’s less so needing or not needing to run Hugo on Docker. It’s pretty straightforward to clone the repo and use the existing file to do that.

It’s more a case that one might expect to find Hugo on Dockerhub or Quay and naively use one of the existing out of date images.

I’m not sure what you mean by a binary version in here. Can you explain a bit more?

[ghost]

Would be very handy to see a BusyBox tag, Alpine for dev and then copy the binary into scratch for custom build pipelines with CI/CD as suggested in #4693 by adding another layer to multistage build. BusyBox will enable theme maintainers an easy way to move themes into containers to run alongside the final binary without having to pull the top layers.

[bep]

I’m not sure what you mean by a binary version in here. Can you explain a bit more?

The current Dockerfile builds the current development version from source, which is different from a Dockerfile with a given Hugo binary version.

I have not followed the history of the current Dockerfile -- I don't need it. For me, Docker in this context is all about CI and reproducibility -- i.e. the Hugo 0.46 Docker image will continue to build my 0.46 site for decades.

[nizsheanez]

FYI: i using klakegg/hugo:0.46-ext-alpine this repo is very good: automatically releasing new versions, has extended hugo, it's small. but this repo a bit doesn't follow standard hugo folders structure, for example it has /src and /target volumes.

In my CI it looks this way:

docker run --rm -v $(pwd)/:/src -v $(pwd)/public:/target -e "HUGO_ENV=production" klakegg/hugo:0.46-ext-alpine --baseURL="https://mywebsite.com/"

[maiki]

Pinging @felicianotech, as they build felicianotech/docker-hugo => https://hub.docker.com/r/cibuilds/hugo/, and update it in the release notes (0.46, for example).

[dkarlovi]

FYI: i using klakegg/hugo:0.46-ext-alpine

It might be my inexperience about Hugo, but I've updated this one to use 0.48 and it seems 0.48 extended doesn't work as it should? The file says it's dynamically linked?

FROM busybox:1.28 AS fetch-standard
ARG VERSION=0.48
ADD https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_${VERSION}_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz
RUN ["/hugo", "version"]

FROM busybox:1.28 AS fetch-extended
ARG VERSION=0.48
ADD https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_extended_${VERSION}_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz

FROM alpine:latest
RUN apk add --no-cache file
COPY --from=fetch-standard /hugo /bin/hugo
COPY --from=fetch-extended /hugo /bin/hugo-extended
# ENTRYPOINT ["/bin/hugo-extended"]
CMD ["--help"]

/site $ file /bin/hugo-extended 
/bin/hugo-extended: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=469449216871b6bc6d846f86cf47a4af7922a5c8, stripped

[dkarlovi]

If anybody is looking for Hugo extended in Alpine base image, I've created an automated build: https://hub.docker.com/r/dkarlovi/docker-hugo/

Repo here https://github.com/dkarlovi/docker-hugo

If you're interested, I could PR to this repo with the Dockerfiles and a complete automated setup on Dockerhub (if anybody has access to the account, I'll describe what needs to be setup for it to work).

[FelicianoTech]

Since I was tagged in here, just wanted to say,

1) I do maintain a Docker image, cibuilds/hugo. This image is designed to be run well in a CI environment first and foremost. Though you can use it locally.

2) One of the things I'll be adding to the image for 2019 is a better website testing suite built in Go as well as a nightly (or similar) tag so that people can use non-release versions of Hugo.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[yajo]

This is a feature request, but I think it's still relevant because the job of creating a static blog is most likely to be done via a CI/CD system, and all of them nowadays work or support natively Docker/OCI images to execute those jobs.

Besides, some dependencies for some parts of hugo are not clear in the docs, and having a image where everything is available and installed makes it easier to maintain, because:

• If an issue cannot be reproduced in the image, it's a problem in your installation.
• If it cannot be reproduced outside the image, it's a problem in the image.

So you have one supported distribution that works everywhere. It's good!

FTR I currently use registry.gitlab.com/pages/hugo, which seems to be a properly maintained image.

[bep]

We will eventually get around to this. I have registered that GitHub now has a Docker registry, which should simplify the account/permission situation. I have a Docker release image (used to build Hugo releases) living under my account which I plan to move below /gohugoio ... when I get my priorities straight....

[bep]

We're (the gohugoio org) now in the GitHub Package Registry program, which should at least lay the foundation for this.

https://help.github.com/en/articles/about-github-package-registry?utm_source=announcement&utm_medium=email&utm_campaign=ww-gpr-beta

[MatthiasLohr]

Is there any progress on this, instead of just moving it from one milestone to another?

I think a major reason for providing a ready-to-use Docker image is very simple: Using hugo in CI/CD environments. Typically, these systems are currently based on Docker images. For example, I want to create a static documentation site using hugo, but are forced to rely on an unofficial build. Would it be so hard just to link the Dockerhub auto build feature? I'm pretty sure, a lot of people would be willing of updating the Dockerfile, including me. With using the repository tags as build argument, would be quite simple to have a almost maintenance free Docker image support.

Any thoughts on that?

[peaceiris]

I will share my workflow here. I hope it is useful for this org.

I am managing my Docker images for Hugo like this: peaceiris/hugo-extended-docker: Alpine Base Docker Image for Hugo (Hugo extended and Hugo Modules)

• Build Docker images with GitHub Actions
• Publish the images to GitHub Packages and Docker Hub.

Building images with GitHub Actions is faster than Docker Hub. So I recommend you to build with Actions, not the building system of Docker Hub.

In addition, Docker is not the only way to run Hugo on CI/CD virtual machines. We can download the Hugo binary and this approach is faster than using Docker in most cases. cf. Setup Hugo on GitHub Actions

[yajo]

FTR I use currently these images, which are maintained by Gitlab: https://gitlab.com/pages/hugo/container_registry

Just in case someone comes here searching for a solution, it could help.

[systemkern]

Hi everyone,

1st I am also happy to contribute/setup/help/manage an official docker repository. I have extended relevant experience with docker, ci pipelines, and release management.

I also have already contributed a small fix to Hugo's Dockerfile.

2nd

I'd like to make a further point point why a docker image is very helpful apart from running in CI. It allows you to manage development environment setup within a project's source repo. I am already doing this on most of my projects and even Visial Studio Code is introducing a mode where the whole IDE including Node/Java/Golang runs inside a docker container.

Essentially what you do is to write a small script which runs then runs npm,maven,gradle,hugo,... inside a docker container.

This way every developer (finally 😉) has exactly the same version on his machine without needing to worry about updates and incompatibilities with other projects.

With Hugo this works flawlessly ... even hot reloading the page while run hugo server works.

Here is the source of my current Hugo "dockerization" which works like a charm

All the best and many thanks to the Hugo team for this great software. cheers

#!/bin/sh
# This shell script provides a predictable docker-based version of the application in use.
# Thereby creating a predictable environment for development, building, and debugging

# Klakegg image recommended in official Hugo documentation
# https://gohugo.io/getting-started/installing/#docker
IMAGE="klakegg/hugo:0.81.0-ext-alpine-ci"
COMMAND="hugo"

# Bash parameter expansion will only replace _null_ with --interactive --tty
# the first "-" is for configuring the expansion mode
export DOCKER_OPTS="${DOCKER_OPTS:--it}"

# Publish the server port if hugo is started in local dev mode
if [ $1 = server ]; then
    DOCKER_OPTS="--publish 1313:1313"
fi

exec docker run --rm $DOCKER_OPTS \
  --volume  "$(pwd)":"$(pwd)"     \
  --workdir "$(pwd)"              \
  "$IMAGE" "$COMMAND" "$@"

source: https://github.com/systemkern/Works-on-my-Machine/blob/master/bin/hugo

[antoniovazquezblanco]

As a recent user, I expected Hugo to have an official docker image for several reasons. The one that really means something to me is that Hugo sites are very good candidates to auto generate in a pipeline for automatic deployment and Docker seems to be one of the de-facto standards for doing so.

When looking for a suitable image for performing CI/CD, tons of duplicated efforts show up in Docker hub, Quay, Gitlab CI image repositories... But no official image.

I would really love to see an official docker image that allows users to skip the step of having to build their own and to skip the step to go over another users implementations to see if they trust them or not...

Following Hugo documentation in the installation section I quickly found that @klakegg docker images (https://github.com/klakegg/docker-hugo) are suggested instead of an official image (https://gohugo.io/getting-started/installing/#docker).

At this point I dove into the implementations of the images and I've seen the number of docker pulls of the images and wondered why they were not part of the official Hugo project. I've opened an issue in @klakegg repo (https://github.com/klakegg/docker-hugo/issues/54) and found that maybe he is willing to cooperate towards an official Docker image a little bit more complex than the one in the root of this repository.

Only after @klakegg response I've found about this thread and the history of the Hugo project and Docker so I am sorry to have opened an issue at the docker-hugo repo instead of properly researching and finding this thread.

From what I can see, a lot of people seems interested in this and is willing to contribute to a fix in the issue but the issue seems to reman stale and hopping from one release to the next one. I think that your user base has been working around this issue and that everybody would benefit from joining their efforts inside the Hugo project and it seems that even the people that you recommend for your product use is willing to contribute towards this common goal.

I do not have a solution to this but I would like to maybe share some ideas that may be aligned with @bep priorities:

• Maybe splitting docker related stuff into a new repo that can work and automate docker image things will help with Hugo issues and PR handling. No more Docker related stuff in Hugo repo but in a separate place. Docker image building may be triggered based on Hugo releases for example.
• From previous PRs, @bep clearly recongnizes that running external docker images is a thread (https://github.com/gohugoio/hugo/pull/9024) and us, the users, feel the same about non official images. If @klakegg images seem to be recommended by the Hugo project, maybe allowing him to perform contributions or reviews towards better official image support can be a way to improve the status of this issue.

I hope to not be stepping out of my bounds! Just want to see a great tool be even easier to use for lazy people like me that don't want to repeat the effort of bulding the same image a ton of times.

Thank you!

[gliptak]

https://github.com/gohugoio/hugo/pull/8700 proposed setting up a Github hosted Docker images (requiring no transfer of ownership, etc.) and could be implemented today assuring a trusted source

[MatthiasLohr]

Any news on that?

[stefanoj3]

Bump? since the image is already defined as part of this project should be relatively easy to set up an integration with docker hub and host an image for free.

I'd be happy to contribute if it is accepted.

[jmooring]

Moving conversation to https://github.com/gohugoio/hugo/issues/10760

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.