The simplicity of single-file Golang deployments
amazingcto.com
The simplicity of single-file Golang deployments
1–10 of 232 posts
Re: The simplicity of single-file Golang deployments
#2Interesting. Are you saying for a big project run something to minimize the .go files into just one? Assuming there is just one package.
Re: The simplicity of single-file Golang deployments
#3Interesting. Are you saying for a big project run something to minimize the .go files into just one? Assuming there is just one package.
Probably referring to the fact that when you build a go executable there's just a single file to deploy (the executable).
Re: The simplicity of single-file Golang deployments
#4Interesting. Are you saying for a big project run something to minimize the .go files into just one? Assuming there is just one package.
Probably referring to the fact that when you build a go executable there's just a single file to deploy (the executable).
Go has a facility for embedding build time files within the resulting binary such that they can be read as if in a runtime file system, because the Go file access routines know about this file system type.
Re: The simplicity of single-file Golang deployments
#5Earlier quoted context omitted.
Probably referring to the fact that when you build a go executable there's just a single file to deploy (the executable).
Go has a facility for embedding build time files within the resulting binary such that they can be read as if in a runtime file system, because the Go file access routines know about this file system type.
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.
Re: The simplicity of single-file Golang deployments
#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?
Re: The simplicity of single-file Golang deployments
#7I feel docker in many cases is a hack for languages and runtimes that don’t support single file static linked binaries.
Often a single binary is a simpler and better option instead of a docker container.
Re: The simplicity of single-file Golang deployments
#8I feel docker in many cases is a hack for languages and runtimes that don’t support single file static linked binaries. Often a single binary is a simpler and better option instead of a docker container.
Often ?
It's 100% scenario. Complex apps (like Gitea for example) delivered as a single binary is basically the pinnacle of deployment.
Re: The simplicity of single-file Golang deployments
#9How 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 pretty quickly. I'm talking about deployment of new version of service on the same machine/server as the old version was running.
Re: The simplicity of single-file Golang deployments
#10Earlier quoted context omitted.
Go has a facility for embedding build time files within the resulting binary such that they can be read as if in a runtime file system, because the Go file access routines know about this file system type.
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