一、程序

　　1、程序代码存储位置

  • 方案一：存储在共享存储中
  • 方案二：存储到docker容器中
探讨：
看是什么语言？ py php可以边车，如果是java。最好直接打进去。否则再编译一次。不是一次打包到处部署的最佳实践。其实按最佳说法。保证制品一次的话。都应当打在一起。
如果不打在一起。看你们分支规范了。怎么确定代码没有被修改。保证发布的代码是qa验证过的。

把代码跟容器分开，我觉得比较好维护，特别是代码需要经常修改的情况，不需要重新build容器；如果你们的运行场景是需要大批量节点部署，那么打包在一起可能更好发布。

总结：
后端不仅仅有Java，还有Node.js和Python，所以需要根据语言制定不同的策略了：

根据语言去确定策略，静态语言直接打好包最简单，动态语言可以把安装依赖的流程写到Dockerfile中去执行或者用sidecar模式去加载。

二、安全防护与配置

　　1、Linux内核的命名空间机制提供的容器隔离安全

　　命名空间提供了最基础也是最直接的隔离。通过命名空间来实现的隔离并不是那么绝对。运行在容器中的应用可以直接访问系统内核和部分系统文件。所以，用户必须保证容器中应用时安全可信的，否则本地系统将可能受到影响，必须保证镜像的来源和自身可靠。

　　docker1.3.0对镜像管理引入了签名系统，用户可以通过签名来验证镜像的完整性和正确性。

　　2、Linux控制组机制对容器资源的控制能力安全

　　控制组是Linux容器机制中的另外一个关键组件，它负责实现资源的审计和限制。

当单容器受到供给或出现异常时，可以保证本地系统和其他容器正常运行而不受影响，从而避免引发“雪崩”灾难。

　　3、Linux内核的能力机制所带来的操作权限安全

　　能力机制（capability）是Linux内核一个强大的特性，可以提供细粒度的权限访问控制。

　　默认情况下，docker启动的容器被严格限制只允许使用内核的一部分能力。使用能力机制对加强docker容器的安全性有很多好处。

　　大部分情况下，容器并不需要“真正的”root权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。这样攻击者取得了root权限，也不能获得本地主机的较高权限，能进行的破坏有限。

  • 禁止任何文件挂载操作
  • 禁止直接访问本地本地主机的套接字
  • 禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等
  • 禁止模块加载

　　4、docker程序（服务端）本身的抗攻击性

　　使用docker容器的核心是docker服务端。docker服务的运行目前还需要root权限的支持，因为服务端安全性十分重要。

　　必须只有可信的用户才能访问到docker服务。docker允许用户在主机和容器见共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。当提供同期创建服务时，要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性容器。

　　docker的REST API使用本地的Unix套接字，保护服务端。Linux命令空间机制将可以实现使用非root用户来运行全功能的容器。

　　5、其他安全增强机制（selinux等）对容器安全性的影响

　　docker默认只启用了能力机制，用户可以选择启用更多的安全方案（selinux）来加强docker主机的安全。

  • 在内核中启动GRSEC和PAX，这将增加更多的变异和运行时的安全检查；并且通过地址随机化机制来避免恶意探测。启用该特性不需要docker进行任何配置。
  • 用户可以自定义访问控制机制来定制安全策略。
  • 在文件系统挂载到容器内部时候，可以通过配置只读（read-only）模式来避免容器内的应用通过文件系统破坏外部环境

　　6、通过第三方工具对docker环境的安全性进行评估

　　自动化检查的开源工具，比较出名的有dockerbench和chair。

三、重建docker网络

　　相信有人也遇到过，在做一些iptable 相关操作时，直接 iptable -F将其清空后的，容器网络无法使用的。

　　1、重建docker网络即可。具体步骤如下:

安装brctl
yum install bridge-utils

停止docker服务
systemctl stop docker

重建 docker 网络
ifconfig docker0 down
brctl delbr docker0

重启docker服务
systemctl start docker