Multiple Containers
-
@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.
