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

11–20 of 232 posts

Re: The simplicity of single-file Golang deployments

#11

Post by iamjackg »

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

If you really don't want to use different ports you can handle it with Docker. Since each container has its own IP, they can all expose the same port. Otherwise, for non-containerized deployments you'll have to resort to two different ports.

In either case, you will need a reverse proxy like Traefik/Nginx in front to smartly "balance" incoming requests to the two instances of the service.

Re: The simplicity of single-file Golang deployments

#12

Post by [deleted] »

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

[deleted]

Re: The simplicity of single-file Golang deployments

#13

Post by dividuum »

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

Can't help with how to implement this, but just to be sure: You should be able to use the same port in multiple instances if you bind those with SO_REUSEPORT. A quick search points to https://github.com/libp2p/go-reuseport for an implementation. Now you just need a mechanism to drain the old process.

Re: The simplicity of single-file Golang deployments

#14

Post by masto »

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 infrastructure that essentially moved a symlink to make the new version live.

Google uses MPM and hermetic packaging of configuration with binaries: https://sre.google/sre-book/release-engineering/#packaging-8...

The way I see it, Docker is basically this same thing, generalized to be independent of the language/application/platform. As a practical matter, it still fundamentally has the "one file" nature.

I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. In any system at scale, you still have to solve for the more important problems of managing the infrastructure. "I can deploy by scping the file from my workstation to the server" is kind of a late 90s throwback, but golang is a 70s throwback, so I guess it fits?

Re: The simplicity of single-file Golang deployments

#15

Post by hnarn »

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

This doesn’t sound Go-specific, if you use something like haproxy targeting multiple nodes you can take them down one by one to perform a rolling upgrade.

Re: The simplicity of single-file Golang deployments

#16

Post by christophilus »

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.

Re: The simplicity of single-file Golang deployments

#17

Post by Edd314159 »

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

I guess this is a problem inherent not just in a single-file go app, but in any deployment where the whole stack is contained within a single process.

The post says the process starts up quick enough that the process being temporarily unavailable isn't noticeable - but what if the process _doesn't come back_? It's also impossible to do blue/green deployments this way.

It's clearly not a solution suitable to large-scale deployments. The simplicity has its trade-offs.

Re: The simplicity of single-file Golang deployments

#18

Post by creshal »

thefounder wrote: post #10
PaulHoule wrote: post #5

Earlier quoted context omitted.

You can definitely pack a Java application into a single JAR file and skip the Docker. Java's xenophobia (allergy to linking libraries) is the real root of "write once run everywhere" so often all you need is the Java runtime.

You still need jre so it's not really a "single file" like on Go

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 just that the latter needs Tomcat (not an issue, realistically) and has to be written as EnterpriseFactoryPatternFactorySingletonAbstractBaseFactorySingletonProvider that makes you feel dead inside just from looking at the documentation; while Golang (and similar newer languages) give you a lot more flexibility and better ergonomics on the developer side.

Re: The simplicity of single-file Golang deployments

#19

Post by hnarn »

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?

Could be what's described in this post: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket...

Re: The simplicity of single-file Golang deployments

#20

Post by zer00eyz »

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 for innovation here, and were over due for some change.

Post reply on HN