Multiple Containers
-
@scottalanmiller said in Multiple Containers:
In many ways, VMs, Containers and Applications are all similar things. A VM is just a series of things converted to run as an application on top of a hypervisor. A Container is a series of applications converted to run as a simple application on an OS. An application is already an application running on an OS.
Once you want to make your containers so lean that they represent a single process, you are just adding overhead to applications that has no purpose. There is nothing for the container to bundle, it's too small. This is when you just deploy applications.
The purpose to containers would only be if you needed to isolate bundles of things as individual units, not one Apache process and one MySQL process or whatever. Just run those processes and you are all set, the OS already keeps them apart from each other using the same underlying mechanism as containers.
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, flannel, fleet/Kubernetes the system can move the container to any system in your cluster.
-
@stacksofplates said in Multiple Containers:
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, and flannel the system can move the container to any system in your cluster.
Sure, IF this is about autoscaling and physical load balancing... but I mentioned that
But moving containers around like that for databases doesn't really work. So this is only about the PHP application. And to make that work, each one needs a VM on which to be moved to. So that brings all of the overhead that he thought that he was avoiding back into the picture. So in the only scenario where it would make sense, it defeats that purpose for which it exists. -
This is just like the SAN conversations of yesteryear (and sadly still today). Sure the tech is great - but 9 time outta 10, you just don't need it. It doesn't fit your situation.
-
@scottalanmiller said in Multiple Containers:
@stacksofplates said in Multiple Containers:
To be fair this is how a lot of people spreading the information describe containers should work. One service per container. Then using something like CoreOS, etcd, and flannel the system can move the container to any system in your cluster.
Sure, IF this is about autoscaling and physical load balancing... but I mentioned that
But moving containers around like that for databases doesn't really work. So this is only about the PHP application. And to make that work, each one needs a VM on which to be moved to. So that brings all of the overhead that he thought that he was avoiding back into the picture. So in the only scenario where it would make sense, it defeats that purpose for which it exists.For the DB you'd most likely be using a backing store so you should be able to migrate. But anyway, I'm not arguing with you. Just saying there is a legitimate reason people arrive at this conclusion. Even docker is kind of confusing in their own definitions.
https://valdhaus.co/writings/docker-misconceptions/
There are great theoretical arguments for having a process per container, but in practice, it's a bit of a nightmare to actually manage. Perhaps at extremely large scales that approach makes more sense, but for most systems, you'll want role-based containers (app, db, redis, etc).
The app, db, and redid are all separate processes so I don't know what they're saying here.
-
Unless they are saying all of those are included in the container, which to me seems like a weird way to write that.
-
@stacksofplates said in Multiple Containers:
For the DB you'd most likely be using a backing store so you should be able to migrate. But anyway, I'm not arguing with you. Just saying there is a legitimate reason people arrive at this conclusion.
.... marketing.
Sadly it mostly just comes down to concept marketing. Everyone is talking about containers in IT so now they seem like they will be the solution to everything. They have their place, but like SANs or ZFS, when we've had them for a decade like we have with containers and no one cares until there is hype around it... it just can't be that important. Otherwise people would have been all over it long ago.
-
@stacksofplates said in Multiple Containers:
Unless they are saying all of those are included in the container, which to me seems like a weird way to write that.
I believe that this is the interpretation. At which point they are just using containers like lightweight VMs. Which is totally sensible if you have no need for VMs and can remove your VM infrastructure and replace it with a container one. Then a single container for the entire osTIcket system makes total sense - but the container is just a VM. Which is what we've called them for a really long time... Type-C VMs.
-
Ya there is no way Docker does as good of a job as SELinux at containing processes.
-
But the impression I have here is that he's just "wrapping" each process in a container adding crazy amounts of overhead (more human than computer) and redundant encapsulation and making interfacing between containers unnecessarily complex so that there is loads of headroom needed for what used to be light and fast. Like you get stuck using the full network stack instead of a loopback or even a socket.
-
@stacksofplates said in Multiple Containers:
Ya there is no way Docker does as good of a job as SELinux at containing processes.
Exactly. More work, less benefit.
