I never quite understood containers and this article makes them seem kind of similar to what OSs already do.
How is a container different from just installing all the dependencies along with an application? Coming from a Windows background, this is pretty common to avoid DLL hell. Nobody distributes a Windows application that requires the user to go and install some 3rd party library before it'll work.
Isolation from each other seemed like one advantage, but that's not even security strength isolation so you can't count on it to protect the host OS from malware in a container.
A claim I often see, and that's repeated here, is that containers can run anywhere. But can they really run in any more places than an ordinary application with dependencies included, or even statically compiled into it? You still need Linux and the same CPU architecture, right?
> How is a container different from just installing all the dependencies along with an application?
Once the image is built, you can get another installation that is guaranteed to be identical. You can do that with VM images too, but you can not reasonably do that if you try to install multiple applications side by side in a single VM without further isolation - there are too many ways they can interact.
> Isolation from each other seemed like one advantage, but that's not even security strength isolation so you can't count on it to protect the host OS from malware in a container.
That's only true to the extent that they don't have a long enough track record. Many container technologies do have a decent track record when it comes to security.
But even so there are plenty of reasons for isolation in cases where the security requirements are not the primary reason for further isolation. E.g. making it impossible for an app to accidentally reading/writing files it shouldn't is in itself helpful.
> A claim I often see, and that's repeated here, is that containers can run anywhere. But can they really run in any more places than an ordinary application with dependencies included, or even statically compiled into it? You still need Linux and the same CPU architecture, right?
Try to get an application - statically compiled or not - to run across different Linux distributions, and you will see why this matters.
Needing Linux and the same CPU architecture isn't much of a limiting factor on servers. Being able to not having to account for distribution peculiarities or version differences is a big deal.
What most people don't realize is that a large part of Docker's value is in being a generic static compiler for languages that don't have that feature.
Pretty soon you can expect raw process support in many "container" management systems, where you just provide it a linux binary which are then run in isolated cgroups and namespaces.
Does it never do DNS lookups? Open files? Do you not want to tie into process management? Logging? Do you really have no dependencies on a functioning locale? Network settings? Are you sure it won't try to exec anything?
An application with no other dependencies is exceedingly rare. Small tools, sure. Sometimes. But even then I see people making silly assumptions all the time, which makes using a container as a suitable straightjacket very useful.
E.g. I run all kinds of tools "with no other dependencies" all the time, that turns out to have all kinds of dependencies when you actually try to put it in the smallest container possible.
I think this is too strong a statement. To have "no other dependencies" you would have to statically link in (1) the operating system (including device drivers) and (2) the hardware model, to be absolutely sure. Only virtual machines (possibly including Java VM) can give you such guarantee.
As far as I know, this isn't the case. That's why using Nix [0] for deployment is a much saner approach than Docker. But after installation and configuration has been done, containers are a viable technology for the rest.
You are correct. The issue they really fix is that it is extremely difficult to actually distribute all dependencies along with an app on Linux. If you link with glibc they you are screwed.
There are starting to be ways around glibc, like muscl. And Go doesn't even use a C standard library at all - there's no way you can say that Docker is easier than just copying a single statically linked binary around. But I guess Docker came along before those solutions have become really popular, and it is easier to apply to existing apps.
I think the security isolation is a side-benefit that is used to obscure the real reason for docker (distributing apps on Linux sucks).
Containers (and especially multi container orchestration software like docker compose or Kubernetes Pods) let you describe an application that might contain multiple processes (so a really simple example could be a web server with a database backend) in a single file and have that deployed to any system that runs the containerization software.
So to that extent its more flexible than a single app. which bundles its dependencies.
The other advantage is that you're not reliant on the software vendor or OSS project to create the package, so you as a user of the application, can create your own packages with your own customization.
As to where you can run them, yep at the moment the image is tied to an OS and architecture, so either Linux or Windows depending on the Docker engine version, although there are moves afoot for Multi-arch support on the registries (https://github.com/docker/docker/issues/15866)
Those things are usually included in the installer, or at least downloaded on the fly so you don't notice. So it's still self-contained from the user's point of view. Yes, sometimes they're installed globally like DirectX, so that can cause yucky interactions between applications.
How is a container different from just installing all the dependencies along with an application? Coming from a Windows background, this is pretty common to avoid DLL hell. Nobody distributes a Windows application that requires the user to go and install some 3rd party library before it'll work.
Isolation from each other seemed like one advantage, but that's not even security strength isolation so you can't count on it to protect the host OS from malware in a container.
A claim I often see, and that's repeated here, is that containers can run anywhere. But can they really run in any more places than an ordinary application with dependencies included, or even statically compiled into it? You still need Linux and the same CPU architecture, right?