You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 /
2. Build the binary inside the docker image
In preparation for #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 #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 #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.
The text was updated successfully, but these errors were encountered:
As stated in qvest-digital#154, the binary is currently build against glibc, and deployed in a musl image. This PR fixes this, by moving the build into the Dockerfile.
I tried to take care to not alter the resulting image too much.
As stated in qvest-digital#154, the binary is currently build against glibc, and deployed in a musl image. This PR fixes this, by moving the build into the Dockerfile.
I tried to take care to not alter the resulting image too much.
kernle32dll
added a commit
to kernle32dll/loginsrv
that referenced
this issue
Jan 6, 2020
As stated in qvest-digital#154, the binary is currently build against glibc, and deployed in a musl image. This PR fixes this, by moving the build into the Dockerfile.
I tried to take care to not alter the resulting image too much.
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 #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 #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 #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.
The text was updated successfully, but these errors were encountered: