昨天 RunC 第一个 release 出来了

[lijianying10]

出来后第一件事，热泪盈眶去试试。
结果被坑。
尤其是最后那个不原地复制一下，权限就不好使，真是诡异。
求高手分析。
我的爬坑日记： http://www.philo.top/2015/07/17/RunCSimpleTest/

[c742435]

没明白这个是个啥玩意

[Kabie]

。。。还挺快的

[immjun]

不错 小巧轻便的容器

[zhuang]

权限的问题，你的 blog 描述不是很清晰，不过我大概有个推断，你可以参考一下。

因为你在用 mac 系统，文章里也提到了挂载文件系统的事情，那么很大可能你的容器镜像只包含可执行文件，而资源文件是通过挂载卷的方式映射到容器当中的。

假设某资源在 mac 的所有者是 user:staff，那么所对应的 uid:gid 是 502:20。（mac 系统中 uid 从 501 开始，502 一般是第二个帐号，staff 组的 id 就是 20）

你把它映射到 docker 宿主系统时，仅仅能传递 502:20 这个信息，宿主系统去寻找宿主系统中映射的 uid:gid，而 linux 的习惯是 uid 从 1000 开始，那么就无法对应到具体的所有者，所以 ls 直接显示 502，至于 dialout 组，它的习惯 gid 也是 20。

runC 是 docker 的纯运行时，所以和 docker 的工作机制是完全一样的。

至于“原地复制一份”，其实我不太理解这句话的意思，但我猜你在容器环境进行的复制操作。容器内部默认 root:root 的（具体机制是映射到宿主系统的 root:root），那么新的副本自然是由 root:root 所有。

[zhuang]

如果让我说 runC 目前的现状，我的评价是可以用于生产环境了。runC 本身已经足够稳定了。

因为 runC 只是个运行时，比起在生产环境中部署 docker，部署 runC 的依赖成本小太多了。从某种意义上来说，runC 从出生就是为生产环境准备的。比较合理的使用模式是开发环境用 docker，测试和生产环境只需要 runC。


不过对于真正意义上的“生产”应用来说，runC 还没有实际意义。容器应用的最大问题是 orchestrating，目前除了 docker machine/swarm 那一套，和依赖网络服务发现的方案之外，基本没有选择。很有可能的情况是，在生产机器上用 runC 替换了 docker 之后，又重新造了一个 docker ……

[lijianying10]

@zhuang 我的环境是CoreOS，原地复制的意思是，原来无法bind的文件夹cp在复制一份出来挂载权限就没有问题了。是这个意思。
至于说思路不清晰请您指导下，我马上改。

[lilydjwg]

@lijianying10 好难理解「原地复制」这个概念……你复制了一份然后挂载新目录？新目录的文件权限和复制来源的不一样？

[lijianying10]

@lilydjwg 是啊是啊，非常诡异。
比如说A文件夹出bind的时候出现了不好使的情况。
然后复制A文件夹还是在这个目录名字叫B，然后在bind的时候就好使了。
目测我自己弄错什么地方了。

[ekeyme]

@lijianying10 首先承认我现在不太懂Docker， 看过你的博客上的文章，感觉好难理解；但我感觉不是你的正在所表达的东西不正确，而是语言的形式我不太理解。比如 **可以直接复制文件到Busybox或者puppy 这种特别小的Linux上就可以运行。** 这句就让我纠结了一会；请原谅我的牢骚！

[zhuang]

@lijianying10 你贴个 config.json 链接看看吧

[lijianying10]

@ekeyme 哎，这并不是牢骚啊亲，这直接证明了我工作沟通能力不够啊。
嗯嗯，我也在努力的改进，因为我坚持写Blog也是为了能够获得一个比较好的工作沟通能力，对工作内容上的语言表达能力。

给你理解上造成的问题表示抱歉。


@zhuang http://www.philo.top/2015/07/17/RunCSimpleTest/#尝试运行hexo
已经更新Blog贴在连接的下面了。一眼就能看到。下面有 **这里贴出完整Config.json** 字样。

[zhuang]

回复排版可能会崩，将就着看吧。

"mounts": [
{
"type": "bind",
"source": "/mnt/blogWork/blog",
"destination": "/hexo",
"options": "rbind,rw"
},

这一节，相当于在宿主机（即你的 CoreOS）执行
mount -rbind /mnt/blogWork/blog /path/to/container/rootfs/hexo
容器中的 /hexo 将继承宿主机 /mnt/blogWork/blog 的权限设置。

本质是容器访问内部 /hexo 时访问了容器外的内容，是数据持久化的一种方法。无论是容器内 /hexo 还是宿主的 /mnt/blogWork/blog，都是访问的同一目标，对任何一方的改动都会即时反映在另一方中。

具体到你所说的“好使”和“不好使”的情况，区别在于，/mnt/blogWork/blog 的权限不同

好使的时候，所有者是 root:root
不好使的时候，所有者是 502:dialout

鉴于 /mnt 是用来持久化 docker 的，我猜 /mnt/blogWork/blog 也是某种形式的挂载？宿主中的 /mnt/blogWork/blog 的权限可能




一点补充

"process": {
"terminal": true,
"user": {
"uid": 0,
"gid": 0,
"additionalGids": null
},
"args": [
"bash"
],
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/hexo"
},

这一节，指定容器启动时以容器内的 uid:0 gid:0 即 root:root 运行 bash

由于没有启用 user 类型的 namespace，容器中的 root:root 会直接映射为宿主的 root:root，理论上不存在无法访问的问题。






关于“表达”的问题：

“好使”“不好使”的标准是什么？

“原地复制”的具体命令是什么，在宿主还是容器中复制？

[lijianying10]

@zhuang 首先感谢深夜解决问题
1. 我的CoreOS是通过开机启动装载到内存中的。具体方式（http://www.philo.top/2015/07/16/pc-docker/）
2. host 中 /mnt 挂载的位置在硬盘的/dev/sda2 ext4分区
3. 原地复制的意思：
cp -rf /mnt/blogWork/blog /mnt/blogWork/blogcp
然后修改配置文件 "source": "/mnt/blogWork/blog", -> "source": "/mnt/blogWork/blogcp",
然后权限就正常了。
4. 好使不好使区别在于查看文件权限的时候对不对。 具体可对比blog中的输出。

[zhuang]

@lijianying10

你在宿主 CoreOS 中查看 blog 和 blogcp 的权限分别是什么？

/mnt 挂载的时候是否有 uid/gid 的参数设置？

[lilydjwg]

@lijianying10 测试结果表明 cp 默认情况下并不会保留所有权信息，因此，使用 root 复制别人的文件，复制出来的东西会为 root 所拥有。