[Beowulf] Gentoo in the HPC environment

[rf at q-leap.de]

>>>>> "Joe" == Joe Landman <landman at 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 ---