企业Docker实施面面观
概述当下Docker容器化的架构备受欢迎,越来越多的企业开始利用容器来构建自己的基础架构。通常是自己建立了Docker注册表,部署在服务器上安装Docker,安装Jenkins通过Docker插件Jenkins CI管道管理Docker容器。更大一点规模的则会使用K8S或者Swarm编排集群。对一个企业而言有开始尝试使用容器到逐渐深入,扩大规模要经历一系列的问题和踩坑的过程,那么如何规范化、安全的实施容器化,如何尽量避免踩坑呢?本文虫虫给列出企业尝试容器化架构需要考虑的各方各面问题,希望可以对大家有所帮助。 镜像问题 容器注册表 Docker服务都需要一个注册表(可不是我们常说的windows注册表),Docker注册表是Docker镜像的存储和在线(Web)版本仓库(类似于代码的github仓库)。有很多公有云自有容器注册表服务,比如Docker官方的Docker Hub,很多公有云都提供自己Docker注册表服务: 除了这些公开的注册表,基于安全、网络访问速度、规范化等考虑企业维护一个自建的Docker注册表(Docker私服)也是必须的。构建Docker私服可以使用Docker官方的Distribution,它是Docker官方推出的Docker Registry 2开源产品,使用Golang开发,极大提高了安全和性能。 知名的Git服务器端Gitlab也提供了Gitlab 容器注册表,部署Gitlab企业可以直接考虑使用这个组件,实现统一管理和集成。当然除了开源的,也可以使用商用的产品的比如Vmware开源的Harbor: 企业选择容器注册表需要考虑以下问题:
企业可能已经有包文件库,内部的Artefact存储等(比如maven,npm,Gitlab等)。在理想的架构中,容器注册表应该是它的一个功能。如果架构上是分开的,那么久要考虑两者的集成和管理开销。 镜像扫描 这是很重要的部分。当镜像上传到自建容器注册表时,需要检查它们是否符合标准。例如,检查诸如此类的问题:
可以通过静态镜像分析来检查这些问题。我们需要注意的是,这些扫描可能不是十全十美的,可能会错过一些非常明显漏洞,所以它也不是解决一切安全问题的灵丹妙药,而是一种必要的手段,特别非常适合用解决:
这些问题是组成了镜像扫描评估的基础,当然也需要考虑集成的成本。常见的镜像扫描工具有Clair,Anchore,OpenSCAP,Dockerscan等。 镜像构建 如何构建镜像?企业要支持哪些构建方法?如何将这些方组合在一起? Dockerfiles最常用标准的方法之一,也可以使用S2I,Docker +Chef/Puppet/Ansible,甚至是手工方法构建。 使用那种CM(配置管理,如果已经使用的话)工具管理。 是否可以重复使用标准治理流程来和配置管理交互? 任何人都可以构建镜像吗? 业界的经验表明Dockerfile方法是一个使用广泛而且通用的方法,而且具有大量的社区文档和问题反馈支持。尝试更复杂的CM工具用来符合VM的公司标准的则通常有一定实施门槛。通过S2I或Chef/Puppet/Ansible方法则更加便捷,也能很好的实现代码(playbook)重用。 镜像完整 需要确保系统上运行的镜像在从构建到运行之间没有被篡改过。 是否可以使用安全密钥来对镜像进行签名? 是否有可以重复使用的密钥库? 密钥库可以与选择的工具集成吗? 即使Docker流行了很多年,镜像的完整性仍然是一个新兴领域。很多的供应商的对此还持观望态度。 Docker 公司在这方面做了一些有益的工作,比如Notary(Docker开源签名解决方案,已经转到CNCF基金会下)在Docker企业数据中心产品之外部署。 第三方镜像 如果希望使用一键部署,那么供应商的镜像则可以直接使用。 是否拥有验证供应商镜像的管理流程? 我们不光需要知道镜像是否安全,还需要知道谁可以在必要时更新镜像? 这些镜像可被其他镜像重用么? 这里有潜在的许可问题。是否有办法阻止其他项目/团队重用镜像? 是否强制要求运行于特定的环境(例如DMZ)? Docker是否可以在这些环境中使用? 例如许多网络级应用程序运行在网络设备类似环境,并且需要认证,所以,它必须与其他容器或项目工作环境隔离。是否有可能在这些环境中运行镜像,需要考虑。 SDLC (编辑:ASP站长网) |