Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Containerize Go and SQLite with Docker

awstip.com

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Containerize Go and SQLite with Docker

#31

Post by jrockway »

encryptluks2 wrote: post #28
alexjurkiewicz wrote: post #27

Earlier quoted context omitted.

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc

I think people use the word Docker to mean "produce an OCI-compliant image that a CRI runtime can run".

Re: Containerize Go and SQLite with Docker

#32

Post by newman314 »

pstuart wrote: post #5
latchkey wrote: post #2

Add -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...

Serious question: Is upx worth the tradeoff in 2022?

Trying to decide if it's worth working into the containers that I maintain.

Re: Containerize Go and SQLite with Docker

#34

Post by cpach »

ttwwmm wrote: post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

In a production environment one would probably deploy using something like Fargate, Kubernetes or Fly.io.

Re: Containerize Go and SQLite with Docker

#35

Post by harpratap »

hardwaresofton wrote: post #20
LukeShu wrote: post #10

Earlier quoted context omitted.

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.

Also, before `kubectl debug`[0] existed, you could always edit a Deployment and add a sidecar container of `alpine` or `busybox` and enable process namespace sharing[1] get some leverage to debug with. A bunch of other options in the docs as well [0]: https://kubernetes.io/docs/tasks/debug-application-cluster/d... [1]: https://kubernetes.io/docs/tasks/configure-pod-container/sha...

That would trigger a restart, no? What if you want to live debug without restarting the scratch container?

Re: Containerize Go and SQLite with Docker

#36

Post by mrweasel »

ed25519FUUU wrote: post #15
tomohawk wrote: post #7

Earlier quoted context omitted.

Instead of a container, just statically build the golang program with sqlite. Single binary deployment.

Default SQLite package requires gcc so you need to use one of the alternatives.

In the article they statically link in SQLite, It’s the reason the Go program can just be copied to a scratch image and still work.

You only need gcc during the build fase, that doesn’t change just because you run without Docker.

There’s nothing preventing you from statically link C programs either and have a single binary to deploy either. You just have to rebuild everything every single time security updates are a available. But that no different from Docker images, they need to be rebuild constantly as well.

Re: Containerize Go and SQLite with Docker

#38

Post by fivea »

ttwwmm wrote: post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

> If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

Dependencies is not really a problem with Docker, nor the thing it is designed to solve. If dependencies was the problem people cared about, everyone would just go with the single statically linked executable/fat JAR and no one would ever be bothered with Docker.

Docker is primarily about containerization, but it's also about ease of packaging and deployment. It's also a deployment format that provides horizontal scaling for free.

Also, the one-database-per-service architecture pattern is quite common, as well as ephemeral databases and local caching, and keep in mind that SQLite also supports in-memory databases.

Re: Containerize Go and SQLite with Docker

#39

Post by daptaq »

I'm currently being forced to use Docker against my will, with exactly this setup. The CGO overhead every time the container is built is absurd, making developemnt and testing painful. I habe to try this article out, but it doesn't seem like it solves the problem. Does anyone have advice how to solve this without too much Docker magic?

Re: Containerize Go and SQLite with Docker

#40

Post by fivea »

encryptluks2 wrote: post #28
alexjurkiewicz wrote: post #27

Earlier quoted context omitted.

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc

> Docker has a pretty terrible deployment story (...)

This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments.

It even shines as a stand-alone barebones clustering solution with Docker swarm mode.

Post reply on HN