This is a collection of things, that caught my attention and/or interest.
1. Leverage docker multi-stage builds
While it is fine to build the binary outside the docker context, there is still something to gain from docker multi-stage builds. For example, for a fully static binary build, it is not necessary to use the "full" alpine image. Instead, an additional "FROM scratch" layer could be used, which copies the htpasswd and ca-certificates from the alpine layer. Like so:
FROM alpine as builder
RUN apk --update --no-cache add ca-certificates
RUN addgroup -S loginsrv
RUN adduser -S -g loginsrv loginsrv
# ----------
FROM scratch
ENV LOGINSRV_HOST=0.0.0.0 LOGINSRV_PORT=8080
EXPOSE 8080
ENTRYPOINT ["./loginsrv"]
COPY --from=build /etc/passwd /etc/passwd
USER loginsrv
COPY --from=build /etc/ssl/certs/ /etc/ssl/certs/
COPY loginsrv /
Currently, the binary is build on a glibc system, and then inserted into an Alpine (musl) container. This is a very hot dance, and prune to fail some day.
I imagine that by statically building against musl, we could also save a few bytes - but thats probably neglectable.
3. Fix docker image push
This is actually an oversight of https://github.com/tarent/loginsrv/pull/144/. Since we now not only build on tip, but go 1.12 and go 1.13, the push script must be adjusted to only run for go 1.13. Currently, the build result for the latest tag is undefined! :/
4. Use versioned alpine image
Also related to https://github.com/tarent/loginsrv/pull/144/. Stabilizing the go version was a start, but the build is still not 100% predictable. A concrete version of the alpine docker base image should be used.
This is a collection of things, that caught my attention and/or interest.
1. Leverage docker multi-stage builds While it is fine to build the binary outside the docker context, there is still something to gain from docker multi-stage builds. For example, for a fully static binary build, it is not necessary to use the "full" alpine image. Instead, an additional "FROM scratch" layer could be used, which copies the htpasswd and ca-certificates from the alpine layer. Like so:
2. Build the binary inside the docker image In preparation for https://github.com/tarent/loginsrv/pull/153, the actual binary build should be moved into the dockerfile.
Currently, the binary is build on a glibc system, and then inserted into an Alpine (musl) container. This is a very hot dance, and prune to fail some day.
I imagine that by statically building against musl, we could also save a few bytes - but thats probably neglectable.
3. Fix docker image push This is actually an oversight of https://github.com/tarent/loginsrv/pull/144/. Since we now not only build on tip, but go 1.12 and go 1.13, the push script must be adjusted to only run for go 1.13. Currently, the build result for the latest tag is undefined! :/
4. Use versioned alpine image Also related to https://github.com/tarent/loginsrv/pull/144/. Stabilizing the go version was a start, but the build is still not 100% predictable. A concrete version of the alpine docker base image should be used.