思源基于Docker和OpenStack的私有云平台实践
思源基于Docker和OpenStack的私有云平台实践
2016-01-19 10:35:33 来源：36大数据
抢沙发
2016-01-19 10:35:33 来源：36大数据
摘要：本次分享从以下三方面进行：使用Docker对OpenStack平台压力测试实践、使用Docker加速Sahara-Hadoop、Docker在 Nova项目的使用和实践。
关键词：
Docker
OpenStack
6. 未来
Cobbler puppet in Docker 快速部署OpenStack 。
Magnum + Kubernetes的微服务架构管理。
Neutron 插件服务用Docker替换 Netns。
Q&A
Q ：能否详细叙述一下幽灵容器问题?
A：从低于1.5(包括1.5)向高于1.6及其以上进行docker daemon过程中，如果没有关闭所有的Containe。那么当高版本Docker Daemon启动后再次start新的Container时，这些Container将无法关闭。大量操作都会报错。
执行stop或者remove命令将会有如下报错：Server Error: Internal Server Error (“Cannot stop container XXX: [2] Container does not exist: container destroyed”)
Remote API 针对该Contianer的报错如下：json, stats, changes, top, logs returned valid responses;stop, pause, wait, kill reported 404 (!)
复现方法：
在1.5版本的Docker中run一个Container。
将docker daemon升级为1.7。
重新start该Container。
尝试执行stop 该 Container。
高版本Docker的升级过程：
当docker Daemon非正常关闭的情况下，所有Container首进程都会失去父进程，从而被 init 收养。此时Contaienr内部进程逃逸。
当docker Daemon重新启动时，将会针将已经处于关闭状态的Container原有已经逃逸的进程 Kill 掉。
1.5版本之前向高版本升级过程：
当docker Daemon非正常关闭的情况下，所有Container首进程都会失去父进程，从而被 init 收养。此时Contaienr内部进程逃逸。
当docker Daemon重新启动时，Docker Daemon 无法杀死老版本Docker创建的现在已经逃逸的进程。
当逃逸进程对应的Container启动时，逃逸进程将会和新进程同时存在。
当该Contaienr关闭时，新进程被杀死，逃逸进程依旧存活。Container标记Destroyed。
解决方案：
目前来看方案如下只能重启物理服务器来解决。由于我们内部Contianer首进程一定是Supervisor，可以先关闭Docker Daemon后杀死全部的幽灵Supervisor后再重启Docker Daemon后就没问题了。
预防方案还是要在升级过程中，保证关闭所有的Container，首先保证不会有逃逸进程，从而避免形成Ghost Container。
Q：Hostname DNS 贵方 用什么方案固定?
A：首先Container创建之初，hostname和DNS都是通过Docker API来设置的。Hostname是nova instance的name，DNS是公司内部设置。如果想修改Container默认设置也是可以的，我们在内部镜像预留了一个目录，该目录下的 hosts、hostname、DNS如果存在都会在Container启动后主动覆盖Container外部挂载的内容。
Q：在使用Docker去封装nova compute模拟大规模集群测试时，运行一段时间后总出现部分使用Docker封装的nova compute服务出现down的状态，不知道你们是否遇到过这样的问题?
A：我们这边没有遇到，有没有可能是模拟的nova compute进程数量过多消息有所积压。NOVA方面考虑增加NOVA时间戳超时设置。Docker方面建议Docker的网络使用host模式，并在 NOVA配置文件中设置不同的host，以便成为不同的hypervisor node。
Q：Sahara在使用Docker替代KVM创建Hadoop集群时，是直接使用heat创建Docker，还是使用nova-docker?Sahara相关的代码是否需要改动，遇到过哪些坑?
A：我们是使用nova docker的driver创建docker container的，Sahara本身相关的代码有部分改动，但是不大，主要改动在使用container和虚机的差别，比如hostname、cloudinit的部分配置等等。
Q：Docker 的网络模式中，中间添加一层linux bridge的原因是什么，这么做是否会有性能问题?
A：这个还是为了安全组，实际上我们支持配置两种模式，linux bridge并不是默认配置的。OpenvSwitch 2.4以后可以根据流表设置安全组。
Q：Container限速是如何实现的，是否有必要针对Container进行限速?
A：我们的环境中使用的OpenvSwitch，通过veth pair的方式建立虚拟网络设备的关系。限速主要是使用tc，毕竟OpenvSwitch的限速也是使用tc做的。
Q：NOVA组件中Docker的高级特性无法使用你怎么看，是否使用docker api来控制容器?
A：上面已经说过这个问题了，其实通过flavor metadata的设置，nova docker driver 可以实现生成一组容器。nova docker这块过去确实是直接调用Docker API的，但是为了应对不断变化的API，我们使用了docker-py作为Client，并在nova 配置文件中增加了API版本的设置。从而尽可能拿到Docker本身升级带来的福利。
Q：OPS已经有超分设置，你设置超分的意义是什么?
A：我们Docker和KVM都在一个openstack平台中，而nova的超分实在NOVA Conductor中生效的。Nova compute Libvirt Driver是直接上报的服务器核数。而我们认为Docker在密度上存在比KVM密度更高的需求，所以在Compute上支持超分是有必要的。
Q：使用CPU share是否会出现单个容器负载很高的场景，出现这种情况如何处理?
A：还是会出现的，记得有个容器CPU占用1600%的场景(32核心)。通常这种情况还是应用出现了问题，最简单的方法是通过 cgroup本身的命令进行限制。容器重启之后该限制就会丢失。限制方法例如： cgset -r cpuset.cpus=20-23 cpuset:/docker/91d943c55687630dd20775128e2ba70ad1a0c9145799025e403be6c2a7480cb2
Q：Docker 的监控和scale-auto是如何实现的?
A：监控方面目前主要是通docker stats api 和 部分脚本来实现，集成到Zabbix中，后面会考虑使用CAdvisor。
后者目前不支持，计划上会在Kubernetes平台中支持，而非heat或NOVA中。毕竟这是Kubernetes、Mesos它们的专长。
Q：你的三层镜像中，第一层和第二层都是系统层，为什么不合并成为一层?
A：首先我们的第一层镜像并不是通过dockerfile创建的，而是依据官方文档从0建立的最小的镜像，这一层是很少变动的。而第二层的设置是为上层设计的通用层，涉及到进程管理器、SSH设置、pam设置、入侵检测设置、开机初始化设置、还是有很大可能变动的，我们希望有关配置都应该放入dockerfile以便管理。
第四十一届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
