自 Docker,Kubernetes 这些容器技术出现以来,已经有四个年头了。现在,有些人认为这些技术已经开始成熟。但我强烈反对这种说法,我认为容器基础设施的实现还有很长的路要走。
这篇博文将聚焦于容器基础设施的其它部分,也就是除了容器之外的所有东西。这些东西才刚起步,远未达到成熟的程度。
2013 年,借助于简化微服务的理念,Docker 为软件行业带来了一次全新的革命。Docker 是一个可以将任何应用程序和它的依赖打包在一个虚拟容器中的工具。
如果想对容器的实现有更多理解,可以看看这一篇 Web 开发者和容器咨询师的之间的对话。
Kubernetes 是由 Google 开发的一款在集群环境中管理容器应用的开源工具。实际上,它就是用来管理Docker 的,通过现代、集群化的基础设施对容器进行解耦。
所以你在头疼,应该使用哪一款容器技术?
在我看来,你应该在你的生产环境里面都使用这两种容器技术。Kubernetes 兼容 Docker,它们可以很好地协同工作。
在容器市场里面,Kubernetes 占据了主要的市场份额,并且拥有良好的社区支持。作为一个自主研发的工具,它的好处在于,开发者和使用者都是“开发者”,遵守一样的守则,但是却缺少灵活性。但 Kubernetes 成为容器行业内的标准可谓是指日可待。
另一方面,Docker Swarm (又名 Docker Compose++) 是真正地为开发而生,因此它可以在开发环境下更轻松地调试。但在生产环境中就没有这么好了。
值得注意的是,上面提到的技术都是开源的。理解开源的真正含义是非常重要的。如果你有兴趣,可以看看开源容器之谜。
从你的容器托管应用显示的一句“Hello world”开始,你将会走过一个陡峭的学习曲线。只有你掌握了容器技术的方方面面,你才脱离新手状态,拥有部署、维护生产环境应用的能力。
所以,开发者在运行容器的基础设施之前,必须要考虑什么呢?别忘了,对于容器策略的选择,会对你的顾客造成正面或负面的影响。
在开发环境下,你可以将你的数据库托管于容器之中,而不需要担心 I/O 性能。但是在生产环境里面,你要考虑的远不止那么少。
你需要考虑数据库存储的组件、备份及复制策略。要达到可以运行现代 Web 应用或为移动设备打造的 API 的量级,你需要一个具有高可用性以及具有可靠的备份/还原策略的数据库,可以应对随服务量上升所带来的 I/O 请求。
选择一个合适的云服务提供商,不管是直接托管在服务器,又或是公有云或混合云。在选择之前,调查一下这个提供商是否能在某个地区提供高可用的服务。
之后,因为云服务提供商的容器部署流程各不相同,应该寻找灵活的解决方案。不要只锁定一家提供商——你不会想要在一棵树上吊死。
部署工作流管理的目标是在不停机的前提下进行部署(即,蓝绿部署)。这可以通过创建一些运行新版本的实例,与此同时,老版本的实例仍然处理全部请求,然后逐渐将请求分配给新版本的实例处理来实现。
选择合适工具是非常重要的,因为部署管理工具从开发环境到生产环境都有不少可供考虑的选项(如 Docker Compose)。迁移到集群环境将会提高复杂度,因此要确保你已经考虑好了从单个容器应用迁移到多个复杂容器镜像集的方方面面,在后者中,每个镜像的多个实例将会由连接到分配请求负载的负载均衡服务器分配请求。
从单容器服务迁移到在一个或多台宿主机上的多个容器需要一个负载均衡器来分配请求。
为了给用户提供无缝的用户体验,一个容器应用应该与其它应用相互通信,并且能够被部署到任何一台服务器或容器集群。
对于微服务的负载均衡来说,一些如 Nginx 或 HAProxy 的工具是非常热门的选择。务必要保证负载均衡工具的配置是最新的,并且提醒自己:不同版本的实例会在同一时间运行。开发者也要面对服务发现带来的网络问题——它会拖慢容器技术应用的进程。
容器其实只是”一段能够实现在共享内核中互相独立运行的代码“而已,因此不能用小型虚拟机的看法来对待,尤其是安全方面。为了支持容器资源的快速扩容,新的安全策略也是必要的。在生产环境中,所有容器的进程会运行在单一的宿主机上,以便降低网络被入侵和遭受多种攻击的风险。
面对容器可能遭受的攻击,首先要确保你配置了合适的防火墙规则,以抵挡拒绝服务或暴力攻击。另外,诸如 Habitus.io 等为 Docker 而生的构建流工具可以帮助你在构建过程中移除和管理对安全较为敏感的层级。
为了确保用户可以在应用上使用必需的功能,应该调查一下市面上的各个全面的容器监控策略,确保容器良好运行。另外,确认当前以及未来的负荷量不会拖慢容器的性能甚至崩溃。最后,务必将故障排除和错误处理方法准备妥当。
还需要对日志管理进行设置,以便将日志收集到一台或多台日志服务器上。别忘了你还要准备查看和搜索日志的方法,以便进行故障排除工作。