If you're looking for a similar deployment experience, but can't use Golang, we've been using Apptainer (previously Singularity) for a couple years at work. It's really nice to be able to get the benefits of containers while retaining the simplicity of copying and running a single file. Only dependency is installing Apptainer, which is easy as well.
The simplicity of single-file Golang deployments
81–90 of 232 posts
Re: The simplicity of single-file Golang deployments
#82When 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…
Well, system-wise Go app is just a binary that only needs network access, could be run directly from systemd and just have all permissions set there.
Docker is a bunch of file mounts and app running in separate namespaces. So extra daemon, extra layers of complexity. Of course if you're already deploying other docker apps it doesn't really matter, as you'd want to have that one binary in docker container anyway just to manage everything from same place.
Re: The simplicity of single-file Golang deployments
#83When 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…
AWS Lambda is basically cgi-bin. Except, of course, they re-branded it as an exciting new technology, which I think was a clever move on their part.
Re: The simplicity of single-file Golang deployments
#84Earlier quoted context omitted.
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 everythin…
Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.
Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :(
The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.
Re: The simplicity of single-file Golang deployments
#85From 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…
[deleted]
Re: The simplicity of single-file Golang deployments
#86Earlier quoted context omitted.
> 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?
Apache supported it, back in the day before nginix existed. It gives you a single-file web page. You can then have multiple pages on the same server run by different users under different userids.
It also operates on a model of one execution run per request. So CGIs that aren't currently being served consume no resources.
Re: The simplicity of single-file Golang deployments
#87> Fast-forward and we were automatically deploying Scala applications from CI bundled in Docker in the startup of my wife.
> Last forward and I have deployed a Golang application to a cloud server.
Editor hello?
Re: The simplicity of single-file Golang deployments
#88When 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.
You could take it a step further and make the user download a small stub Actually Portable Executable (https://justine.lol/ape.html) which downloads the real binaries.
Re: The simplicity of single-file Golang deployments
#89Re: The simplicity of single-file Golang deployments
#90The 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.
[flagged]
Using a crate is the opposite if reinventing the wheel. Also are we talking about go? The language without a set implementation?