3 ms·
It might be the case that docker was just some enabling technology to go back to static binaries even with dynamic languages that IMHO expect a more complicated
by zeptomu 10y ago
It might be the case that docker was just some enabling technology to go back to static binaries even with dynamic languages that IMHO expect a more complicated runtime setup.
So if one goes with statically compiled web services written in e.g. Go, Rust, Haskell or any other language supporting static binaries (most languages support this actually, but not all of them encourage you to do it), the only thing missing is a deployment framework that distributes your binaries to your (potentially virtual) machines. So am I correct that this is the point where Kubernetes comes in?
So how to use Docker in production is a controversial topic and the consensus seems to change rapidly, but in my opinion is mostly used as a weapon against dependency hell, but this problem is mostly solved using static binaries. Other use it for sandboxing, but I am not sure what security guarantees one can expect here.
If one compares static binaries with Docker containers how do they compare from a security point of view if one is hyperparanoid that the code executed may harm the host?
- majewsky 10y agoI would add another advantage: You get to escape the steaming mess that is configuration management. Our legacy landscape uses VMs configured with Chef, and our new landscape has containers on Kubernetes. I like the latter approach much better since I don't have to care about idempotency or whatever. I just scrap the container, start a new one, and its startup configuration is handled by a (usually trivial) shell script that `exec`s into the application binary at the end.
- zeptomu 10y agoBut if the shell script is trivial, why not just give the binary its runtime constraints via arguments or environment variables? IMHO configuration management overlaps with dependency hell, or could be seen as a dependency. You do not have to bake the dependency into the binary, but just have to setup the runtime environment.
- majewsky 10y agoPutting a shell script in front of a third-party binary is easier than setting up a build pipeline to build that binary with the modifications that you need, and maintaining those patches across releases. (And that's implying that you have the source code for the binary at all.) Of course, the perfect solution is to upstream the necessary changes into the binaries that you need, so that you can supply all configuration via args and env.