首先说一下 USER 这个指令哈。USER 的意思是工作用户。 是说用哪个用户执行下面的命令。你的例子里面就是用 root 用户执行下面的命令，并且容器启动以后，entrypoint 和 CMD 都是用 root 去执行的。 用 docker exec 命令进入容器的里面也是 root 用户。 如果换了另一个用户，例如 work。 你再用 docker exec 命令进去容器的时候就会发现当前使用的用户是 work 了。类似的还有 WORKDIR 这个指令。意思是工作目录。

再说就是楼主说的镜像的共享的问题。楼主主要是通过 dockerfile 来达到镜像共享的问题。他人通过拿到你的 dockerfile 重新 build 一个镜像的方式来使用。其实我是十分不推荐这种做法的。 楼主可能觉得一个镜像比较大，传递起来比较麻烦耗时。 但是有些时候重新 build 一个镜像是更耗时的。尤其是这个镜像有好几层的时候。或者 dockerfile 里写了很多安装工具的 shell，例如安装一个 jdk 就比较耗时。我这里有一个编译的基本镜像。从 gcc 到 thrift 到 jdk 到 scala 应有尽有，build 这么个镜像没半个小时一个小时的是结束不了的。这时候反倒是拉现有的镜像比较快。 而且重新 build 一个镜像的话你是控制不了对方给这个镜像起什么名字，用什么 tag 的。非常的不好管理。 有时候会造成一个机器里同一个镜像有好多个名字和 tag 的情况。

所以我比较建议楼主在内网搭建一个镜像仓库。build 好一个镜像以后直接 push 上去。 别人想用的话直接拉下来就好了。 不用你主动的发包给他。你只要维护好镜像仓库上的镜像版本就好了。有点像你在内网搭建了一个 docker hub 的感觉。 在以后测试环境变多，docker 单节点扩展到多节点。 引入编排工具的时候，例如我用的 k8s。 在多个节点之间共享镜像用的也同样是镜像仓库。 这类的容器编排工具都会提供 image pull policy。通过你选择的策略去决定是否从镜像仓库中重新拉取最新的镜像。

1. 乱码不是因为系统编码问题，是因为系统没有安装对应的字体。毕竟镜像是老外做的，没有中文的那些字体是比较正常的。你可以继承它的镜像做自己的定制，安装你想要的字体，例如我装的是微软的雅黑字体。如下是我做的：
   
   另外不要一个节点只启动一个浏览器，那样很浪费资源。传递环境变量进去可以改变配置。如下：
   

   1. chrome node 的镜像有很多版本的。像我用的是 3.2.0。 你可以去 github 和 docker hub 上查看一下信息

另外你也可以用像 1 中的方法。自己定制一个镜像，把 chrome 的版本换了

依然在招哈

双方都没必要剑拔弩张的。到头来双方都是吃亏的

pytest 有数据驱动模块的。 不用写 for 循环。

我没测试过哈，只是我们运维推荐我用的

多谢提醒

听说微软在做 windows 的 docker。不过我没用过哈

但是集群化以后，就没办法固定 ip 了。只能端口映射。我们转集群的时候大家抱怨最多的就是没办法 ssh 进去看 log 了。要多几个步骤才能进入到容器里面

赞一个，补充一下如果想用 vnc 连接，需要自己设置密码，要改一下镜像。

鼓励楼主还有哪些 docker 方面的实践，都分享出来。 另外如果楼主是单点 docker 的话。 建议删除 docker0. 新建 br0 虚拟网桥然后把 docker 和宿主机都连到 br0 上来。然后用 none 模式启动，pipework 设置静态 ip。 这样就不用做宿主机:容器 端口映射了。 外部可直接通过 ip 访问

看我上面的回答哈

主要是重构方面的。当初我的同事用惯了 eclipse 了。 eclipse 的重构功能不能覆盖到字符串搜索。所以元素变量名改变的时候比较麻烦。不像 idea 中可以全局搜索字符串来帮你进行重构。我也不好强迫他们改用 idea。

case 之间不要做成相互依赖的。 如果一定要相互依赖，也要确保相互依赖的 case 在一台机器上有序的运行

是的，我们目前还是处于 POC(Proof of Concept) 阶段。对于搭建私有云的客户还是需要到场地内建模并做各种测试以证明符合客户需求。以后要尝试 POT(Proof of Technology)。直接从产品的各个维度提供业界认可的权威报告。这个被老大列在了今年的计划当中。

可怜我司就是做平台的。。。。所以我还是得硬着头皮去造数~~~ 最近跟某行合作。他们直接对测试用例，性能测试和测试数据提出了要求~。ToB 的业务想卖出去就是费事~~，我们还得派人去场地内在他们的环境上跑一遍性能测试以证明我们的产品能够支持他们的需求。

主要是维护起来是个噩梦。本来业务变化就很大，不仅要改 case 还得改框架，我觉得维护成本太高。 为了能让不会写代码的人使用。要封装的东西太多，例如如何让不懂代码的人调试和 debug？光这一项就够让我头疼了。又例如我还被要求过提供一个酷炫的 UI。总之各种坑。

恩？ 没更新头像的不是不能发帖了么？ bug 了？

python 的 json 模块不能搞这些事么？

没有。。。。测试类型不一样。。。我这边是做数据测试。所以才用这玩意。你不做这种测试就随便看看了解一下就行了。。。

额，最近在家比较闲

恩，如果单从以后你面试的角度来看的话。 其实接触服务端的东西反而会给你加分的。创业公司人手少，本就不会区分的那么严格。 一线大厂也都喜欢有能力 own 一整个模块的。 所以我觉得如果为了以后的发展来考虑的话，反而应该多接触接触后端的东西。

额，这个话题不用匿名的。有疑问挺好的一事儿。做服务端也挺好的，可以丰富你的经历。 而且现在很多公司的测试不分客户端服务端的。 就是一个人全做。多学点没啥坏处的。

额，为什么你一定认为测试开发是脱离了业务的呢~~~ 而且我也不太明白为什么你这么认定技术与业务是对立的~~~可能你没有碰到靠谱的技术人吧。我觉得其实不管什么职位，技术都是用来服务业务的。要求技术好，是因为技术越好越能服务业务。 就像我们招开发要招技术好的，招运维要招技术好的。为什么到了测试就一定得招技术不好的？难道测试已经不属于技术部门了么？技术好的人有能力让产品质量更好，有能力把技术转换成生产力提高效率。所以我们为什么要这么抵触技术 这么个东西呢？有了技术这么个东西，测试人员可以一键部署一整套产品环境，可以无人值守的维护整个团队几十上百的测试环境。 有了技术这么个东西，持续集成跑起来，可以提前发现 N 多个 bug。有了技术这个东西，devops 走起来，一键出包部署。有了技术这个东西，自动化测试走起来，原来要执行几天的测试现在可能只要几小时。所以我们不要排斥技术这个东西。而是要排斥不能服务于业务的技术。 如果要问我再工作中用到了多少技术， 我可以这么说，我要是变成一个不懂技术的人，我现在立马失业。 因为我现在 90% 以上的任务是没有技术做不了的。