51–60 of 180 posts
It feels like the Linux Kernel Library project would be a way to do this - redirect all the filesystem calls into mapped portions of the binary to abstract over the filesystem which I think would get you 90% of the way there practically?
In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what's the difference?
* With containers I can put a Python app right alongside my binary but with total isolation. No need to futz around with chroots or making a static build of Python and embedding my scripts into it.
* What if I need libc, for example to link to SQLite or something? Suddenly my Go binary requires libc. The isolation is broken!
* Systemd can use Cgroups to limit RAM or CPU, but schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there's no equivalent tooling for doing this with fat binaries.
* Without Docker, I have to manually manage each container port. Can't run two apps with pprof servers on the same box. With Docker, I only have to care about public ports, and can port-forward into debug ports manually, and with Kubernetes I never have to care about port conflicts.
* Kubernetes, with enough hackery to work around bugs, can actually do seamless deployments where it checks your internal health endpoint or command before making the container available. As far as I know, the alternative to this is writing crappy scripts that try to do this without declarative logic to back it.
You could go on and on. It doesn't have to be Docker. Could use rkt as well, or really any container engine. The point is that the container engine + scheduler pattern is immensely useful, and if it weren't, Google would already be on the next thing.
If you're just setting up a single server with a single program, fine. Drop a binary on it and call it a day. But when you want to implement CI/CD and schedule applications across multiple servers and do load balancing and so on, you might feel like you're reinventing the wheel a bit considering those problems were all already solved by Kubernetes.
* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat…
This is probably true, but it isn't good.
> Docker is a tool that allows you to continue to use tools that were perfect for the1990s and early 2000s. You can create a web site using Ruby On Rails, and you’ll have tens of thousands of files, spread across hundreds of directories, and you’ll be dependent on various environmental variables. What ports are in use? What sockets do you use to talk to other apps? How does the application server talk to the web serv…
I admit: I find the argument for "fat binaries"[1] over containers compelling. There's just one problem... ...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future. I can just about see how we c…
For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.
This works for one Go or Rust executable but any real system is a mix of technologies e.g A Go service talking to a Java application server proxied with a C webserver that was configured with a bash script. Once you have a mix of different technologies its easier to just say "everything in Docker". The ship container analogy on the old Docker website was a great illustration of this. Its a shame the new website is no…
Does it even work well for go or rust executables? I seem to recall that Docker itself was written in golang because "fat binaries1111", but now docker is one of the hardest to install applications that I know of, and certainly isn't simply one executable file to be copied onto the system. Managing resource files in fat binaries is really problematic.
* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat…
This argument appears to be: when the application is crap, putting it in a container lets me deal with it without getting my hands dirty. This is probably true, but it isn't good.
Containers are not only a solution for dependencies. It's also protection boundary.
It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. We just didn't have a massive PR budget
You can easily break out of a chroot jail: http://pentestmonkey.net/blog/chroot-breakout-perl
Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Docker gives you networking isolation and especially RAM/CPU usage limitation, which is a real headache doing with chroot.