Containerize Go and SQLite with Docker
awstip.com
Containerize Go and SQLite with Docker
1–10 of 90 posts
Re: Containerize Go and SQLite with Docker
#2Add -ldflags '-s -w' to go build to strip DWARF, symbol table and debug info.
See also: -trimpath
Re: Containerize Go and SQLite with Docker
#3This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
Re: Containerize Go and SQLite with Docker
#4This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
Distroless works well.
Still no shell, but comes with “what’s usually missing in scratch”.
Re: Containerize Go and SQLite with Docker
#5Add -ldflags '-s -w' to go build to strip DWARF, symbol table and debug info. See also: -trimpath
And if you can spare an extra ~150ms startup time:
https://blog.filippo.io/shrink-your-go-binaries-with-this-on...
Re: Containerize Go and SQLite with Docker
#6This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
We drop a statically compiled BusyBox binary on images like that as "sh". If we need more we can symlink to it in /tmp at debug time (or just call it directly). It strikes a good balance between slim and debuggable.
Re: Containerize Go and SQLite with Docker
#7This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
Instead of a container, just statically build the golang program with sqlite. Single binary deployment.
Re: Containerize Go and SQLite with Docker
#8Add -ldflags '-s -w' to go build to strip DWARF, symbol table and debug info. See also: -trimpath
And if you can spare an extra ~150ms startup time: https://blog.filippo.io/shrink-your-go-binaries-with-this-on...
That article is about -s -w and goupx.
goupx is not necessary after go 1.6. https://github.com/pwaller/goupx#update-20160310
Re: Containerize Go and SQLite with Docker
#9This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
In Kubernetes 1.22+, you can use ephemeral containers: https://kubernetes.io/docs/tasks/debug-application-cluster/d...
Re: Containerize Go and SQLite with Docker
#10This is really interesting. Copying to the scratch container is powerful and I’ve used it a lot, regularly, but occasionally something comes up where I need to use a more fully featured base to support things. One other downside I’ve encountered with Scratch is no shell so doing docker exec or kubectl exec doesn’t work. Does anyone know a good solution to this problem?
The Kubernetes folks' solution to this is the addition of `kubectl debug` (added as `kubectl alpha debug` in Kube 1.18, graduated to `kubectl debug` in Kube 1.20) as an alternative to `kubectl exec`. It takes an existing Pod and lets you attach a new container with whichever image you like, so that your production images don't need debugging tools.