Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker build fix #4077

Closed
wants to merge 2 commits into from
Closed

Docker build fix #4077

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
80e8c93
Docker build fix
gruebel Nov 11, 2017
b8cd273
go dep with wendor-only; bump to go 1.9.2; format Dockerfile
gruebel Nov 21, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 14 additions & 11 deletions Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,23 +1,26 @@
FROM golang:1.9.0-alpine3.6 AS build
FROM golang:1.9.2-alpine3.6 AS build

RUN apk add --no-cache --virtual git musl-dev
RUN go get github.com/golang/dep/cmd/dep
RUN apk add --no-cache \
git \
musl-dev \
&& go get github.com/golang/dep/cmd/dep
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why using multiple lines and a single layer of cache here?

I find short single lines more readable personally

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always use multi-line for package listing, it makes it much easier to read and also PR to review. In the offical Dockerfile best practice is a short passage about sorting multi-line, which points already in the right direction of using multi-line in general for package listing https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#sort-multi-line-arguments

I definitley agree on using a oneliner, if you just install one package, but with two I prefer to use multi-line and starting with three there is no other choice, then going multi-line.

Regarding the merge of the two layers, it is just about saving a bit of storage, few kbs, https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#minimize-the-number-of-layers and speed, because Docker doesn't have to save the intermediate layer.

68667e787a6e        24 hours ago        /bin/sh -c go get github.com/golang/dep/cm...   39MB
5eb1bd0ea57e        24 hours ago        /bin/sh -c apk add --no-cache     git     ...   31.6MB

7218153155d7        24 hours ago         /bin/sh -c apk add --no-cache     git     ...   70.5MB

And lastly it's about constistancy, if you look at the final stage of the Dockerfile, there is both used multi-line package listing and merging two layers ;)

hugo/Dockerfile

Lines 12 to 15 in 42fbf15

RUN \
adduser -h /site -s /sbin/nologin -u 1000 -D hugo && \
apk add --no-cache \
dumb-init

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the consistency nor the size are adding value here.

We are in the middle of the 'compilation' stage of a multi-stage build, both stages solves different problems.
At this stage, layers stays on the builder host and will never be pushed, compared to the latest stage where layers are actually pushed and where it is interesting to lower their number to gain on the image size.
At the same time, having more layers during this stage adds more steps for the user to use cache, interesting when it comes to re-building an image

However, I don't think that, in the current case, it has a significative impact, just a general thinking about guidelines and spirit of guidelines :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in the end it depends totally one personal taste.

The build stage is just garbage stage where you put all in, which you don't want to use in your final image, but need to make it.

And you are right, which ever approach we choose here it has almost no impact :D

So anyone else has an opinion on it? Then he/she could decide, which way to go.


COPY Gopkg.lock Gopkg.toml /go/src/github.com/gohugoio/hugo/
WORKDIR /go/src/github.com/gohugoio/hugo
RUN dep ensure
ADD . /go/src/github.com/gohugoio/hugo/
RUN dep ensure -vendor-only
COPY . /go/src/github.com/gohugoio/hugo/
RUN go install -ldflags '-s -w'

FROM alpine:3.6
RUN \
adduser -h /site -s /sbin/nologin -u 1000 -D hugo && \
apk add --no-cache \

RUN adduser -h /site -s /sbin/nologin -u 1000 -D hugo \
&& apk add --no-cache \
dumb-init
COPY --from=build /go/bin/hugo /bin/hugo
USER hugo
USER hugo
WORKDIR /site
VOLUME /site
EXPOSE 1313
VOLUME /site
EXPOSE 1313

ENTRYPOINT ["/usr/bin/dumb-init", "--", "hugo"]
CMD [ "--help" ]