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

The simplicity of single-file Golang deployments

amazingcto.com

Post reply on HN
Print view View original

51–60 of 232 posts

Re: The simplicity of single-file Golang deployments

#51

Post by synergy20 »

drewg123 wrote: post #34

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great.

I run a few Go apps, all are single executables, upgrading to new releases has never been easier.

if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

Re: The simplicity of single-file Golang deployments

#52

Post by yencabulator »

christophilus wrote: post #16
mastax wrote: post #6

> Systemd holding connections and restarting the new binary. How does this work? Or does it just mean it stops new connections while it's restarting?

Systemd effectively acts as a proxy. I don't know that it's actually a proxy, but it keeps accepting connections from what I've seen. I use it for zero-downtime single-binary deploys, and it's great.

No, it's not a proxy, and it's not accepting connections (unless you're using the inetd emulation, but that's rare and inefficient).

It's merely passing the listening socket as an already-open file descriptor to the spawned process.

The "keeps accepting" part is just the listening socket backlog.

Last I looked, systemd socket passing couldn't be used to do graceful shutdown, serving existing connections with the old version while having the new version receive new connections. Outside of that, it's very nice.

Re: The simplicity of single-file Golang deployments

#54

Post by candiddevmike »

drewg123 wrote: post #34

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it.

Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap.

I wonder how much simpler Linux packaging would be if everything was statically linked...

Re: The simplicity of single-file Golang deployments

#55

Post by jerf »

hsn915 wrote: post #53
sneak wrote: post #33

I still put the single file in a docker container because docker isn't complex.

This makes zero sense. I don't like cargo culting.

There are reasons. It's a reasonable security boundary. It integrates with other things that use Docker as the primary abstraction, and there's good odds I've got other docker things that aren't single binaries like databases and other tools. It puts it into a uniform control interface that works with other things as well. It doesn't cost much additional resources over simply running the binary directly because the real runtime cost of a docker container is the mini-OS they often bring up, not the target executable.

It isn't necessary, but it's not nonsense.

Re: The simplicity of single-file Golang deployments

#56

Post by mrkeen »

pjc50 wrote: post #35
masto wrote: post #14

When I was stuck doing a web application in Java 15 years ago, I hated everything about it except for the deployment story, which boiled down to a single .war file being pushed to the server. When we upgraded to Perl, I liked that system so we designed deployment around "PAR" files in a similar way, bundling all of the dependencies together with the application in the CI build process, and I wrote a tiny bit of infra…

> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. Rather than targeting the OS API, which has completely the wrong set of security abstractions because it's built around "users", it defines a new API layer. > "I can deploy by…

What does cgi-bin get you? What does it run on? If I already have a single-file web server, do I need to introduce extra cgi-bin technology also?

Re: The simplicity of single-file Golang deployments

#57

Post by quaintdev »

drewg123 wrote: post #34

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

> The fact that it produces a single static binary is one of the nicest things about golang.

Not only that it can also cross compile for different architecture and operating systems.

Re: The simplicity of single-file Golang deployments

#58

Post by divan »

bojanz wrote: post #38
zer00eyz wrote: post #20

From the article: "Standing here it looks like Docker was invented to manage dependencies for Python, Javascript and Java. It looks strange from a platform that deploys as one single binary." Let me say the quiet part out loud: Docker is covering up the fact that we don't write deployable software any more. Go isn't perfect either. The author isn't dealing with assets (images anyone?). I think there is plenty of room…

Go isn't perfect either. The author isn't dealing with assets (images anyone?). Go supports embedding assets since 1.16, the author mentions embedfs in the post.

And people are using go-bindata since Go<1.0, so Go supports embedding assets since forever.

Re: The simplicity of single-file Golang deployments

#59

Post by acatton »

zer00eyz wrote: post #50
acatton wrote: post #40

Earlier quoted context omitted.

> Go isn't perfect either. The author isn't dealing with assets (images anyone?). From the article: "The Go web application had all files like configurations (no credentials), static css and html templates embedded with embedfs (and proxied through a CDN)." See https://pkg.go.dev/embed

OP here, How are you doing caching without a mod time? https://github.com/golang/go/issues/44854 Are you re-naming or hashing for cache clearing?

I'm not the author of the post, so I can't tell you what the author does.

What I do in my projects is that I tell varnish-cache to cache assets in "/static/..." forever. And I have a "curl -X PURGE " as part of the "ExecStartPre=" of my go binary.

• https://varnish-cache.org/docs/trunk/users-guide/purging.htm...

• https://www.freedesktop.org/software/systemd/man/systemd.ser...

Re: The simplicity of single-file Golang deployments

#60

Post by jjtheblunt »

PaulHoule wrote: post #41
creshal wrote: post #18

Earlier quoted context omitted.

Eh. From an ops perspective there isn't much difference between an executable file that Golang statically compiled all dependencies into and embedded a file system into, and a WAR archive that the Java compiler embedded a file system including dependencies into. Both are self-contained single files you can give to a completely different organization and expect to run on the first attempt with no complications. It's j…

Try Guava or Spring. In either case the framework supplies you with a Factory, FactoryFactory, FactoryFactoryFactory, ... that does the transitive closure so you can just get a "single" object injected into your app where you need it.

"lasciate ogne speranza, voi ch'intrate" (~ lose all hope, who enters) from Dante's Inferno is what comes to mind whenever someone mentions Spring.
Post reply on HN