Chris's Wiki :: blog/sysadmin/DockerVersusUs Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/DockerVersusUs?atomcommentsDWiki2015-07-28T13:55:52ZRecent comments in Chris's Wiki :: blog/sysadmin/DockerVersusUs.By Lim on /blog/sysadmin/DockerVersusUstag:CSpace:blog/sysadmin/DockerVersusUs:4f5794673e5a289718e17da47ae3843a42b1d6faLim<div class="wikitext"><blockquote><p>do NFS mounts inside themselves</p>
</blockquote>
<p>Rocket's pod concept fits here quite well. One process runs nfs and exposes the filesystem to the worker.</p>
<p>If one process dies, the pod gets shut down.</p>
</div>2015-07-28T13:55:52ZBy Paulo Almeida on /blog/sysadmin/DockerVersusUstag:CSpace:blog/sysadmin/DockerVersusUs:e7a57bb5c36a2fba9c898d9704cf8158057fa45ePaulo Almeida<div class="wikitext"><p>I haven't thoroughly explored containers yet, so my opinion may change, but things like this are why I'm currently more interested in LXC/LXD than Docker. I'm used to managing Linux machines, I'm not sure the added complexity of learning the Docker way will be worth it for my needs.</p>
</div>2015-07-28T09:58:43ZBy Miksa on /blog/sysadmin/DockerVersusUstag:CSpace:blog/sysadmin/DockerVersusUs:0abf668474ade4687b5766291b76a4ee39cf272eMiksa<div class="wikitext"><p>Just this week I came up with a use-case for Docker at the university, computation servers for researches.</p>
<p>Several research groups have powerful servers and some of them are maintained by the IT department with RHEL or Ubuntu LTS OSes. Problem is that researches need to run all sort of unmentionable software which often isn't available from the standard repos or any repo at all, or the versions are outdated. Just taking peek at what they have done to our pristine servers may make you nauseous.</p>
<p>Docker would seem the easiest solution for this. Keep the host clean and let the researches launch containers that suit their need, for example recent Fedora, debian, Bio-Linux, Scientific Linux or something else they need. The host will just provide them CPU, RAM and storage space. Would probably be quite a bit easier than KVM or XEN virtual machines.</p>
<p>But first we need to figure a solution for the security issues. My understanding is that if you give users the permission to launch containers you basically give them root to the host. Either we need to have the sudo-users in the groups set up the containers or we need to craft a launcher script that will only launch whitelisted container images with approved settings.</p>
</div>2015-07-26T09:59:19ZBy David on /blog/sysadmin/DockerVersusUstag:CSpace:blog/sysadmin/DockerVersusUs:3e59e97324286685527226ce06ba76be5f814c6eDavidhttp://david.wragg.org/<div class="wikitext"><p>The Docker data volume support, where docker creates and manages the data volume dirs for you, is a bit half-baked. E.g. it's easy to end up with dangling data volumes taking up disk space without any way provided by the docker tools to manage them. I don't think such data volumes are much used, and I wouldn't describe them as "the Docker way".</p>
<p>What is widely used is the ability to mount directories (or individual files) from the host filesystem into a container. Confusingly, that Docker documentation page calls this "mounting a host directory as a data volume", but to me the term "data volume" seems odd in this context (i.e. where docker does not manage the directory on the host filesystem). The option is the same for both approaches (-v) but the argument syntax is distinct when you explicitly supply the host directory to be mounted into the container. From inside the container, the effect is similar: There is a directory in the containers filesystem namespace that did not come from the container image, but rather refers to some directory elsewhere on the host filesystem).</p>
<p>It sounds like mounting bits of your NFS filesystems into containers should work fine for you. Other reasons may make Docker unattractive in your environment, but I don't think this is it.</p>
</div>2015-07-26T09:15:43Z