>>>>> "Joe" == Joe Landman <land...@scalableinformatics.com> writes:
Joe> >> I second Gavin.
Prentice> A lot of people have been mentioning LXC and Docker ans
Prentice> cures to this problem, and to paraphrase The Princess
Prentice> Bride, you keep using those words I don't think they mean
Prentice> what you think they mean. Docker and LXC are great for
Prentice> isolating running services: apache, DNS, etc. For the most
Prentice> part, we are stalking about user-space libraries and
Prentice> programs. I don't see how Docker and LXC could be used or
Prentice> provide any benefit in this context.
Joe> We can create a completely repeatable portable mechanism to
Joe> distribute applications with full dependency chains as part of
Joe> the distribution, across machines of any linux distro type,
Joe> without impact core packages (which in the case of specific
Joe> distros are often non-functional for anything but legacy system
Joe> work) ... and you don't see the benefit to this?
Joe> Seriously?
Joe> Quick show of hands: Anyone running an HPC system, ever run
Joe> into, say, a dependency hell/nightmare due to a package
Joe> requirement?
Roland> I think your overemphasizing the upside of this
Roland> approach. Sure, if you have 2-3 apps like this, it's still
Roland> feasible to manage. If it becomes a lot more than that (and
Roland> in a larger compute center it would), you essentially have
Roland> to manage Docker instances like OS installations (minus
Roland> kernel). Do you really want to do that for more than a
Roland> couple of them?
Joe> As with any technology, there is a cost and a benefit.
Joe> Moreover, there are no silver bullets, unicorns, or any other
Joe> magical incantation that will make bad things good, etc.
Joe> One must weigh the costs against the benefits. Part of the
Joe> costs are more vigilance required in security contexts. Part
Joe> of the benefits are much simpler deployment/management.
Mostly agreed. But I think the burden on the management side could
significantly increase, since as mentioned, any container has to be
managed more or less like a separate OS installation. Then again, one can
probably automate that at least for newly setup containers. I see most
problems with apps/containers just lying around (but being used) without
being updated, rotting and starting to become a security problem.
Roland> You might say: Well the software vendors are going to supply
Roland> and manage the Docker instances. Will you trust them? I'd
Roland> say: Welcome to the Android app
Joe> Well, no, I wouldn't say that. I would imagine each center
Joe> would create their own containers, and mange them. Or supply a
Joe> container build/testing environment to their users for them to
Joe> build their own for active deployment.
Joe> This is why in part, the market for pre-build VMs is
Joe> effectively non existent, yet everyone wants to roll their own
Joe> cloud/VMs. Same reason.
Joe> Provide the tech and get out of the way.
Agreed.
Roland> world, trojans, backdoors, other security holes. And I'm not
Roland> really convinced the container isolation is always going to
Roland> protect us from this. I believe nobody wants this in their
Roland> data center.
Joe> Same issues exist at the OS level.
Yes, in principle. But you have much less variety in that case. You try
to keep up with the OS updates of a few OS version instances and you're
mostly fine. A container can contain all kind of variants of libs
etc. needed to make the corresponding app of a certain version
working. And they probably won't be updated, since nobody will have time
to do all the testing again and risk that the desperately needed app
will fail. Hence my worry ...
Joe> Containerization is a weaker form of isolation than a VM. It
Joe> has benefits, it has risks. You can crash a VM without taking
Joe> down the host. You can't crash a container without requiring a
Joe> reboot of the host. Risk is higher, but for a well behaved app
Joe> ... most are ... this shouldn't be a problem.
Not sure about the "most are / will be".
Roland> Don't get me wrong. I also find the Docker concept appealing
Roland> at first sight. But I somehow see a security and/or
Roland> manageability nightmare wave coming up upon us with it ...
Joe> I am not convinced that this is as much of an issue as you
Joe> think on the manageability side. The security side is an issue
Joe> for apps in general.
Joe> But then again, its not that much different than having any
Joe> sort of access to /dev/[k]mem, etc. Bad things can and do
Joe> happen from good apps, and malicious apps as well.
Joe> Docker and its ilk cannot protect you from malicious apps. kvm
Joe> can isolate a VM to contain damage. Intelligent policy,
Joe> alerting, etc. and sane backup/snapshots are a significant line
Joe> of defense.
Joe> C.f. http://www.theregister.co.uk/2014/06/19/docker_security/
I hope you're right and my nightmares won't become true :) In any case,
a well-designed management concept/policy is necessary to keep this
under reasonable control.
Joe> Prentiss opined that he didn't find Docker a beneficial concept
Joe> as compared to others. I (strongly) disagree with this. You
Joe> opine that security and other issues exist. I do agree with
Joe> this. But its non-sequitur as these issues exist independent
Joe> of Docker/containers, and Docker/containers and kvm for that
Joe> matter, do not mask off these issues.
Agreed.
Roland
-------
http://www.q-leap.com / http://qlustar.com
--- HPC / Storage / Cloud Linux Cluster OS ---
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
