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

31–40 of 232 posts

Re: The simplicity of single-file Golang deployments

#31

Post by zer00eyz »

ElevenLathe wrote: post #22
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…

Anymore? When were we writing "deployable" software in the past?

I'll bite!

We used to ship software, on discs, and we didn't have the Internet to update it.

There is plenty of software out there that works via your linux distress package manager. Note that this isn't everything you can get from your package manager. Plenty of things that are available are broken or miersable to get working unless you get the container/vm version.

Re: The simplicity of single-file Golang deployments

#32

Post by marcosdumay »

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…

You can always share ports.

But the one way to do no downtime deployments is to have more than one server.

Re: The simplicity of single-file Golang deployments

#34

Post by drewg123 »

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.

Re: The simplicity of single-file Golang deployments

#35

Post by pjc50 »

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 scping the file from my workstation to the server"

I kind of miss cgi-bin. If we're ever to get back to a place where random "power users" can knock up a quick server to meet some computing need they have, easy deployment has to be a big part of that. Can we make it as easy to deploy as to post on Instagram?

Re: The simplicity of single-file Golang deployments

#36

Post by somehnguy »

marcosdumay wrote: post #25
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. When you distribute your software to other people, it cuts the step of installing the correct interpreter... at the cost of requiring the correct computer architecture. It is very likely a gain.

Exactly - I primarily write Java and fat-jars are great when developing apps for environments I control. But if I want to send an app to a friend it's a few additional steps to make sure they have the correct version of Java, paths are setup correct, etc. This isn't always trivial if they already have a different version of Java and want things to play nice side by side.

Just bundle everything into a native executable, so many little annoyances just disappear. From what I understand Java does have facilities to bundle the runtime now but I haven't had the opportunity to really play with it yet.

Re: The simplicity of single-file Golang deployments

#37

Post by joncfoo »

dividuum wrote: post #13
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.

Rough psuedocode to do this with the built-in http.Server where startServer(..) would use the reuseport library to create the listener so multiple servers can listen within the same process:

  func reloadConfig(config) {
    if newServer, err := startServer(config); err != nil {
      // gracefully shutdown previous server
      // no new connections will go to old server
      oldServer.Shutdown(...)
      oldServer = newServer
    }
  }

Re: The simplicity of single-file Golang deployments

#38

Post by bojanz »

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.

Re: The simplicity of single-file Golang deployments

#39

Post by joncfoo »

klodolph wrote: post #24
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…

Some of this is solved by using e.g. systemd, depending on your needs. > I couldn't have the old and the new version of my service running on the same port... You can, actually! You just can’t open the port twice by default. So one or both of the processes needs to inherit the port from a parent process, get passed the port over a socket (Unix sockets can transmit file descriptors), or use SO_REUSEADDR. There are som…

> Some of this is probably going to have to be done in your application...

FWICT tableflip does exactly this: https://github.com/cloudflare/tableflip

Re: The simplicity of single-file Golang deployments

#40

Post by acatton »

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?).

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

Post reply on HN