docker 镜像的用户密码的问题？

[rizon]

突然想起这个问题。之所以问这个问题，是因为我最近使用 jupyter 的官方镜像，但是发现登陆的用户不是 root，缺少一些权限。

1. docker 镜像默认是不是没有密码？
2. 那么一些镜像如果用户不是 root 用户该怎么切换用户呢？（只有 使用--user参数这一种方法吗？）
3. 如果我修改了用户的密码，那么 docker 的 exec 命令还可以直接进入到 bash 吗？如果可以想问一下这个 exec 命令是什么原理？为什么不用关心用户权限。

[rizon]

@raysonx 谢谢，懂了，是 docker daemon 创建子进程，所以不需要密码。

[rizon]

@zmj1316 嗯，这样说的确是当虚拟机用了。。。可是，，，可是这样用是真的好用啊。做环境隔离和业务场景隔离，docker 和虚拟机比起来，实在是太好用了啊。。。

[raysonx]

@rizon 然而就你们这么个用法，容器的优点并没有最大发挥出来。容器最大的优点在于“一次构建，到处运行”，听起来是不是很熟悉？

[ipwx]

@zmj1316 你这管理员对于机器的管理怎么这么弱？。。。 我这边直接怼回去，要么学，要么别用。

[wwhio]

额，我和楼主的方法差不多，实验室里的一台 GPU 服务器被整个学院的同学分享，每个人都有自己的需求，于是最后做了几个不同的镜像，镜像里只提供 cuda + sshd，设置容器内 root 账户的密码后把密码和 ssh 端口提供给同学使用。

看了楼上的大佬发言，我大概说一下需求，借楼问下有什么好的解决方案。

1. 用户间不能互访数据，环境独立
2. 可以限制 CPU、内存、GPU 等资源
3. 不能拿到主机的 root 权限
4. 可以 apt

其实我这边的用户并没有使用 docker 的需求。另外，LXD 我会去看的，先谢谢大佬们。

[passerbytiny]

@zmj1316 #28 问一下，有没有出现过容器占用空间爆掉的情况，印象中容器中也是分层的，占用空间只增不减。
@ipwx 你也看一下，他这种这么懒的情况，估计也不太可能把易变的目录都挂载成卷。

[zmj1316]

@passerbytiny docker 的文件系统应该都是有 COW 的，只开容器不修改的话基本不占用空间，占空间的只有 image 本身。

如果出现容器空间爆了，一般是有人在容器里面除了数据卷之外的地方放了大量文件，
这个我是直接告知，放在数据卷之外地方的文件不保证数据安全，所以目前他们应该还是乖乖放数据卷里面的

[ipwx]

@passerbytiny 我对容器没有多大限制，不过因为我们这边部署了 MooseFS，所以每个人的 /home 有配额限制。是按路径来的，不是按用户来的，所以当多人合作一篇论文的时候，哪怕都用 root 启动 docker，-v 挂载进去，配额还是在的。你总不好意思把你的文件放到别人 /home 下面不是？至于每台计算节点本身，不好意思，随时可能重装，不做备份警告。

[ipwx]

@passerbytiny MooseFS 是分布式文件系统，我单独开了五台服务器，和那十几台计算节点是独立的。

[ipwx]

@zmj1316 @wwhio 我一直是觉得，能够用管理的方法解决的问题就用管理的方法解决，不要什么都让技术做。所以我很强硬地推行了裸机无运行环境（包括无 CUDA ）、分布式文件系统、配额，以及 Docker。配额是每个人的个人目录不超过 50 万个 inode 和不超过 2T 的数据。因为 50 万的 inode 限制，所以用 Anaconda 这种方式自己部署 Python 环境，是比较吃力的，所以他们不得不去学习 Docker 的用法。

这些措施倒是一点点来的，最后一个 Docker 化是一年前完成的。不过讲道理一开始我们这边的这套集群计算系统（计算节点和存储节点集中管理，还包括 LDAP 集中式用户系统）就是我搭起来的，也没啥太大阻力。。。目前运行良好。说实话作为用户来说，这些东西的用法都很好学，明明是计算机专业的，根本不可能学不会，不会就是懒。

[ipwx]

@passerbytiny 回到正题吧。Docker 容器空间爆炸的事情？我这边是完全不考虑的。假设某台机器因为 Docker 镜像太多而磁盘占满了，大不了重装呗。再说我会不定时运行 docker system prune，不会占满的。

你和 @zmj1316 会有这个顾虑，是因为你们俩希望 Docker 对用户透明，并且在 Docker 里面开了 sshd 让用户为所欲为。这个事情很难搞，说实话。因为 Docker 设计上就不是这么用的。

而我这边就没这个顾虑，因为我一开始就教育用户，要把文件放在 MooseFS 的路径上。Docker 容器里面想用，就挂载进去用。其实只要教给他们普通用法就行了，他们一般不会出错的。更高级的用法他们可以自学，学会了自然更不会出错了。另外我还提供一项额外服务，就是给新手一个模板脚本，在 Docker 里面启动一个 Jupyter Notebook，并且正确地挂载他们的 /home。

如果不是这么一套管理方法，10+ 的 CPU 计算节点和 3 台 GPU 计算节点，我不是得管死。。。

[zmj1316]

@ipwx 管这么多机器，这已经是真 SA 了，换成我得加钱 2333333

[ipwx]

@zmj1316 其实还好，除了刚开始搭建这套系统用了不少时间，但因为用的都是尽可能鲁棒的体系，搭完之后基本不用维护 wwwww

[rizon]

@ipwx 问个事情啊，容器只能在启动之前挂载本地目录，是这样吧？ 那如果一个容器在使用过程中突然发现有个目录需要映射到本地，这时候该怎么办呢？

[rizon]

@ipwx 你说的“因为我一开始就教育用户，要把文件放在 MooseFS 的路径上。Docker 容器里面想用，就挂载进去用。”这句我不是很理解，moosefs 就是类似 haoop hdfs 的东西？你说的“容器里想用就挂载进去”这句话 是怎么挂载进去？？

[ipwx]

@rizon

1. 关掉容器，删掉容器，重新建立容器。
2. MooseFS 不是类似 Hadoop HDFS 的东西。MooseFS 实现了全功能的 Posix Filesystem，可以像本地磁盘一样 mount 到本地目录上。所以可以 docker -v 挂载进容器。

你看，因为 Docker 的限制，它的用法和虚拟机是很不同的。Docker 容器的正确用法是不在容器里面放持久数据。我选择的策略就是通过 MooseFS 给用户一个跨机器能持久存储数据的“本地文件系统”，用起来和普通的本地文件系统没有区别。在此基础上，他们可以使用跨机器的 Anaconda （如果不超过 50 万个文件的配额，我特别设置的），或者使用 Docker -v 挂载。事实上我这边，用户的整个 /home 目录都是在 MooseFS 上的。

[rizon]

@ipwx 好的，明白了，谢谢哈～

@raysonx 谢谢哈～

[passerbytiny]

@ipwx 你的这种方式，是要使用人自己定义镜像的，自然可以进一步限制他们不能用 yum install/apt-get install，不能编辑 /usr/local/systemd ……等等，所以没啥可担心的。然而他哪种懒惰的方式，估计是啥也不会限制，等用户一通 install/remove 后，容器占用空间就可能爆了。

[ipwx]

@passerbytiny 我不太理解，如果持久数据不存在计算节点上，爆空间有啥可担心的，大不了重装一下裸机呗。再说服务器好歹少说 3T 一般都是 6T 以上的，哪这么容易爆。

我反正没限制用户在 docker 容器里面 apt-get install。至于什么 -v 本机根目录然后 chroot，这种高端操作我这边用户都不会呢。再说哪怕搞坏了，参考前面说的，大不了重装一下呗。反正我有 ansible 脚本。

所以综上所述，唯一最重要的一点就是持久性的数据要存在分布式文件系统上，不要放在计算节点上。