Conversation
This commit just makes use of docker multi-stage builds. Since Go links *everything* statically, and we only need `libc` at runtime, and not the plethora of tools in the Go base image, we run from a distroless image with just the binary and the static assets.
| go get -u github.com/valyala/quicktemplate | ||
| go get -u golang.org/x/text/language | ||
| go get -u golang.org/x/text/message | ||
| go get -u ./... |
There was a problem hiding this comment.
Out of curiosity, is there documentation on what this actually does?
I assume it just pulls everything needed as specified in the go.mod, but I'd prefer to be certain.
There was a problem hiding this comment.
from https://go.dev/ref/mod#go-get
Upgrade modules that provide packages imported by packages in the main module.
it's just easier to do this than keep the list up to date here as well.
There was a problem hiding this comment.
Ohh okay. I will resolve this specific change once I test locally to see if it does do go.mod / go.sum upgrades as expected.
| ADD . /heartbeat | ||
| WORKDIR /heartbeat | ||
| RUN mkdir -p /heartbeat/config | ||
| COPY . . |
There was a problem hiding this comment.
Does this still create the heartbeat folder inside of /data as needed? Including the empty folders?
Mainly, we need the contents of /heartbeat/config inside of /heartbeat so when it is mounted, the config files reside inside of /data/heartbeat
There was a problem hiding this comment.
the data path is deliberately not created because it's intended to be a volume mount. at the time of writing, i did not know that the VOLUME instruction exists. making the config directory avoids permission issues when mounting files alone. it's not the best solution, admittedly, but hardening is probably for another PR.
There was a problem hiding this comment.
Ah okay. I'm also unfamiliar with VOLUME, we do need to make changes to the internal server in order for it to work with the configuration that you have here? As far as I can tell?
Please let me know if I'm mistaken or if there's something I'm missing.
There was a problem hiding this comment.
I do remember testing this at the time, and it didn't seem to require any further modification. I'll test this again as soon as possible, but I don't think I'll have time until February. I see that there is a merge conflict so I might have failed to notice changes in the meantime.
2 participants
This commit just makes use of docker multi-stage builds. Since Go links everything statically, and we only need
libcat runtime, and not the plethora of tools in the Go base image, we run from a distroless image with just the binary and the static assets.This brings down the image size by ~62.5% (1.13GiB --> 30.2MiB)