Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
executable-dist-plugin
Discontinued A Gradle plugin which makes distribution zips runnable, as a sort of alternative to an uberjar. A London Beach production :guardsman::palm_tree:.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
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.
> Some of this is probably going to have to be done in your application...
FWICT tableflip does exactly this: https://github.com/cloudflare/tableflip
Socket activation via systemd[0] is an option, assuming you are fine with certain requests taking a while (if they arrive while the service is being restarted).
- https://github.com/bojanz/httpx#systemd-setup
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 feel like i'm taking crazy pills (at a low dose) when i read this stuff.
I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1].
That is one step more than deploying a single binary, but it's a trivial step, and both steps are done by a release script, so there is a single user-visible step.
The additional pain associated with deploying a tarball rather than a single binary is negligible. It simply is not worth worrying about [2].
But Go enjoyers make such a big deal of this single binary! What am i missing?
Now, this post does talk about Docker. If you use Docker to deploy, then yes, that is more of a headache. But Docker is not the only alternative to a single binary! You can just deploy a tarball!
[1] We do deploy the JDK separately. We have a script which takes a local path to a JDK tarball and a hostname, and installs the JDK in the right place on the target machine. This is a bit caveman, and it might be better to use something like Ansible, or make custom OS packages for specific JDKs, or even use something like asdf. But we don't need to deploy JDKs very often, so the script works for us.
[2] Although if you insist, it's pretty easy to make a self-expanding-and-running zip, so you could have a single file if you really want: https://github.com/vmware-archive/executable-dist-plugin
You can use Graal Native Image https://www.graalvm.org/22.0/reference-manual/native-image/ to produce a single native executable. Example of a Micro-service framework that has first class support for this is Quarkus (https://quarkus.io/). See https://quarkus.io/guides/building-native-image
I made a cool program for you Go stuff that will check all the supported OS and ARCH combos for your code and compile them all. You just do `release --name "mycoolprogram" --version "0.1.0" and it will output all of your labeled release binaries for every platform your code supports.
check it out! https://github.com/donuts-are-good/release.sh You can see it at work here for this simple markdown blog generator I made, which sports about 39 different platform combos https://github.com/donuts-are-good/bearclaw/release/latest
I made a cool program for you Go stuff that will check all the supported OS and ARCH combos for your code and compile them all. You just do `release --name "mycoolprogram" --version "0.1.0" and it will output all of your labeled release binaries for every platform your code supports.
check it out! https://github.com/donuts-are-good/release.sh You can see it at work here for this simple markdown blog generator I made, which sports about 39 different platform combos https://github.com/donuts-are-good/bearclaw/release/latest
In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).
And there's also "purego" as an implementation that directly generates shellcode.
Maybe those will help you, too?
I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.
[1] https://github.com/Binject/debug
[2] https://github.com/ebitengine/purego
In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).
And there's also "purego" as an implementation that directly generates shellcode.
Maybe those will help you, too?
I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.
[1] https://github.com/Binject/debug
[2] https://github.com/ebitengine/purego