5 ms·
Here's what a container gives you: - Isolation of networking - Isolation of process namespace - Isolation of filesystem namespace - CPU and Memory limi
by throwaway892238 3y ago
Here's what a container gives you:
- Isolation of networking
- Isolation of process namespace
- Isolation of filesystem namespace
- CPU and Memory limit enforcement
- A near-universal format for packaging, distributing, and running applications, with metadata, and support for multiple architectures
- A simple method for declaring a multi-step build process
- Other stuff I don't remember
You're certainly welcome to go without them, but over time, everybody ends up needing at least one of the features containers bring. I get the aversion to adding more complexity, but complexity has this annoying habit of being useful.
- marcus_holmes 3y agoA VM provides the first 4 anyway - if you're deploying to a cloud instance then having these in the container is redundant. If you're deploying to bare metal then it's possibly useful, but only if you're deploying multiple containers to the same machine. Go doesn't need a format for packaging - it's one file. It's becoming common practice to embed everything else into the binary. (side note: I haven't done this with env files yet, and tend to deploy them separately, but I don't see any reason why we don't do this and produce binaries targetted at the specific deployment environments. I might give it a go). I kinda prefer makefiles for the build stuff, or even just a script. The whole process of creating a Docker instance, pushing source files to it, trigging go build and then pulling back the binary seems redundant; there's no advantage of doing this in a container over doing it on the local machine. And it's a lot faster on the local machine. Talking to people, it appears to be as mholt said: everyone just does everything in containers so apparently we do this too.
- dilyevsky 3y agoAre you suggesting to setup a separate VM for each process that may only require like 0.25 cpu? Another thing you can’t do with VMs is oversubscribe (at least not with cloud ones)
- lmm 3y agoYou can't have both oversubscription and isolation, almost by definition. If you want isolation, VMs are great. If you want oversubscription, OSes are still better than container runtimes at managing competing processes on the same host.
- dilyevsky 3y agoOK but I can tho - oversub cpu, isolate memory, systems resources (like ports) etc. > OSes are still better than container runtimes at managing competing processes on the same host. OSes and container runtimes are the same thing
- marcus_holmes 3y ago> OSes and container runtimes are the same thing For a subset of OSes
- marcus_holmes 3y agoGo binaries tend not to be that lightweight, because we have goroutines for that. And yes, setting up a separate VM for each instance of a process is perfectly feasible. That's what all this cloud business was about in the first place.
- nurple 3y agoThis goes against everything we've learned about effectively deploying and managing software at runtime. Using the golang binary as a packaging format for your app has the same energy as crafting it exclusively from impenetrable one-liners.
- marcus_holmes 3y agoSorry, I don't understand this. What's the difference between a Docker image made from a script and a Go binary made from a script?
- throwaway892238 3y agoThe Docker image is more useful
- marcus_holmes 3y agoI think we're back to square one here. Yes for other languages the Docker image is more useful, but for Go the image just contains a single binary file. It's just more bloat rather than more utility.
- fhuici 3y agoAt Unikraft (OSS unikernel project) we do a bit of both: if wanted, people can specify via a Dockerfile what they want/need in their filesystem, and then we have a tool that compiles (if needed) and packs the files into a (OCI formatted) unikernel (which we then deploy via kraft.cloud ).