V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lijianying10
V2EX  ›  程序员

昨天 RunC 第一个 release 出来了

  •  
  •   lijianying10 · 2015-07-18 15:02:14 +08:00 · 3628 次点击
    这是一个创建于 3176 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    15 条回复    2015-07-19 00:29:07 +08:00
    c742435
        1
    c742435  
       2015-07-18 16:01:15 +08:00
    没明白这个是个啥玩意
    Kabie
        2
    Kabie  
       2015-07-18 16:12:31 +08:00
    。。。还挺快的
    immjun
        3
    immjun  
       2015-07-18 16:12:32 +08:00
    不错 小巧轻便的容器
    zhuang
        4
    zhuang  
       2015-07-18 18:01:54 +08:00   ❤️ 1
    权限的问题,你的 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
        5
    zhuang  
       2015-07-18 18:24:16 +08:00   ❤️ 1
    如果让我说 runC 目前的现状,我的评价是可以用于生产环境了。runC 本身已经足够稳定了。

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


    不过对于真正意义上的“生产”应用来说,runC 还没有实际意义。容器应用的最大问题是 orchestrating,目前除了 docker machine/swarm 那一套,和依赖网络服务发现的方案之外,基本没有选择。很有可能的情况是,在生产机器上用 runC 替换了 docker 之后,又重新造了一个 docker ……
    lijianying10
        6
    lijianying10  
    OP
       2015-07-18 18:31:13 +08:00
    @zhuang 我的环境是CoreOS,原地复制的意思是,原来无法bind的文件夹cp在复制一份出来挂载权限就没有问题了。是这个意思。
    至于说思路不清晰请您指导下,我马上改。
    lilydjwg
        7
    lilydjwg  
       2015-07-18 19:08:17 +08:00
    @lijianying10 好难理解「原地复制」这个概念……你复制了一份然后挂载新目录?新目录的文件权限和复制来源的不一样?
    lijianying10
        8
    lijianying10  
    OP
       2015-07-18 19:11:54 +08:00
    @lilydjwg 是啊是啊,非常诡异。
    比如说A文件夹出bind的时候出现了不好使的情况。
    然后复制A文件夹还是在这个目录名字叫B,然后在bind的时候就好使了。
    目测我自己弄错什么地方了。
    ekeyme
        9
    ekeyme  
       2015-07-18 20:35:59 +08:00
    @lijianying10 首先承认我现在不太懂Docker, 看过你的博客上的文章,感觉好难理解;但我感觉不是你的正在所表达的东西不正确,而是语言的形式我不太理解。比如 **可以直接复制文件到Busybox或者puppy 这种特别小的Linux上就可以运行。** 这句就让我纠结了一会;请原谅我的牢骚!
    zhuang
        10
    zhuang  
       2015-07-18 20:59:20 +08:00
    @lijianying10 你贴个 config.json 链接看看吧
    lijianying10
        11
    lijianying10  
    OP
       2015-07-18 21:34:11 +08:00
    @ekeyme 哎,这并不是牢骚啊亲,这直接证明了我工作沟通能力不够啊。
    嗯嗯,我也在努力的改进,因为我坚持写Blog也是为了能够获得一个比较好的工作沟通能力,对工作内容上的语言表达能力。

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


    @zhuang http://www.philo.top/2015/07/17/RunCSimpleTest/#尝试运行hexo
    已经更新Blog贴在连接的下面了。一眼就能看到。下面有 **这里贴出完整Config.json** 字样。
    zhuang
        12
    zhuang  
       2015-07-18 23:21:42 +08:00   ❤️ 1
    回复排版可能会崩,将就着看吧。

    "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
        13
    lijianying10  
    OP
       2015-07-18 23:42:10 +08:00
    @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
        14
    zhuang  
       2015-07-18 23:56:15 +08:00
    @lijianying10

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

    /mnt 挂载的时候是否有 uid/gid 的参数设置?
    lilydjwg
        15
    lilydjwg  
       2015-07-19 00:29:07 +08:00
    @lijianying10 测试结果表明 cp 默认情况下并不会保留所有权信息,因此,使用 root 复制别人的文件,复制出来的东西会为 root 所拥有。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   946 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 20:49 · PVG 04:49 · LAX 13:49 · JFK 16:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.