挑战
Crowdfire帮助内容创建者创建自己的内容在互联网上的任何地方和发布它在其他地方以正确的格式。自2010年推出以来,它已发展到1600万个用户。作为整体产品开始应用程序上运行Google App Engine,在2015年,该公司开始转型microservices运行在Amazon Web服务Elastic Beanstalk。最初“这是好的对于我们的用例,但是随着服务数量的增加,开发团队和规模部署,自愈能力和资源利用率开始成为我们的问题,”软件工程师Amanpreet辛格说,领导Crowdfire的基础架构团队。
解决方案
“我们意识到,我们需要一个更原生云的方法来处理这些问题,”辛格说。团队决定实现一个自定义设置Kubernetes基于起程拓殖和Ansible。
影响
“Kubernetes帮助我们减少部署时间从15分钟不到一分钟,”辛格说。“由于Kubernetes自然自愈,运营团队不需要做任何手动干预的一个节点或豆荚失败。”Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."
对于大多数内容创造者,只有一半的那部电影引用有可能是真的。当然,平台Wordpress, YouTube和Shopify简单几乎任何人都开始网上发布新内容,但吸引观众并不是那么容易。Crowdfire”帮助用户内容发布到所有可能的地方,观众存在,“Amanpreet辛格说,软件工程师在公司总部位于孟买,印度。Crowdfire获得了超过1600万的用户博客作者和艺术家制造商和小以来在2010年推出。
这种增长的高需求用户新特性和连续改进的Crowdfire幕后团队努力跟上。2015年,他们把他们的庞然大物Amazon Web服务的Java应用程序Elastic Beanstalk并开始将它分解成microservices。
这是一个很好的第一步,但团队很快意识到他们需要更进一步的进行路径,这将导致他们Kubernetes。最初“这是好的对于我们的用例,但是服务和开发团队的数量增加,我们进一步扩展,部署,自愈能力和资源利用率开始成为问题,”辛格说,领导团队在Crowdfire的基础设施。“我们意识到,我们需要一个更原生云的方法来处理这些问题。”
作为解决方案,他四下看了看辛格Crowdfire所需要的清单。“我们想要保留一些事情分开,这样他们可以独立于其他装运;这将有助于消除阻滞剂,让不同的团队按照自己的节奏工作,”他说。“我们也赚很多数据驱动的决策,所以航运功能及其快速迭代是一个必须”。
Kubernetes检查所有的盒子,然后一些。“的最好的事情之一是内置的服务发现,”他说。“当你有一堆microservices需要打电话给对方,能够随时了解内部DNS和服务ip和端口自动设置环境变量大有帮助。”Plus, he adds, "Kubernetes's opinionated approach made it easier to get started."
还有另外一个引人注目的业务进行方法的原因。“在当今世界不断变化的业务需求,使用原生云技术提供了各种选择甚至运行服务的能力在混合云环境中,”辛格说。“企业可以让服务在一个地区最接近用户,从而受益于高可用性和弹性”。
所以在2016年2月,辛格建立一个测试Kubernetes集群使用kube-up脚本提供。“我探索的特性,能够部署一个应用程序很容易,”他说。“然而,这似乎是一个黑盒,因为我完全不了解这个组件,和不知道什么kube-up脚本。所以当它打破了,很难找到问题并解决它。”
为了更好地理解,辛格鸽子的内部Kubernetes,阅读代码的文档,甚至一些。和他看起来Kubernetes社区更多的洞察力。“我过去每天晚上都熬夜有点晚(很多用户活动只有晚上的时候在印度),并将试图回答问题Kubernetes社区从用户开始松弛,”他说。“我也会密切关注其他的对话。我必须承认我能够避免很多问题在我们的设置中,因为我知道别人都面临着同样的问题。”
他所获得的知识的基础上,辛格决定实现一个自定义设置Kubernetes基于起程拓殖和Ansible。起程拓殖推出“我写Kubernetes大师和节点(自动伸缩功能组)和一个Ansible剧本安装所需的组件,”他说。(该公司最近转向使用预烘干埃米斯让节点bringup更快,计划改变其网络层。)
首先,研究小组从Elastic Beanstalk几个分期服务迁移到新的Kubernetes分期集群,然后一个月后建立一个生产集群部署一些服务。结果是令人信服的。“到2016年3月底,我们建立的,所有的新服务必须部署在Kubernetes,”辛格说。“Kubernetes帮助我们减少部署时间从15分钟不到一分钟。由于Kubernetes的自愈特性,运营团队不需要做任何手动干预的一个节点或豆荚失败。”On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."
在接下来的六个月中,该团队在迁移的所有服务Kubernetes Elastic Beanstalk,除了少数被弃用,很快就会被终止。服务一次,和他们的性能监控每两到三天。今天,“我们完全迁移,我们在Kubernetes运行所有的新服务,”辛格说。
Kubernetes的影响是相当大的:该公司经历了90%的成本节省弹性负载平衡器,目前仅用于公开,面向用户的服务。他们的EC2营业费用已经减少了50%。
30 Crowdfire的工程师都在船上。“我给了一个内部的讨论,我共享的基本组件和演示使用kubectl,”辛格说。“每个人都很兴奋,使用Kubernetes高兴。开发人员有更多的控制和可见性在生产中运行的应用程序。最重要的是,他们满意低部署时间和自我修复服务。”
他们更富有成效。“我们用来做每天大约5部署,”辛格说,“现在我们正在做30 +生产和50 +分期几乎每天都部署。”
辛格指出,几乎所有的工程师每天与分期集群交互,这创造了一个在Crowdfire文化变革。“开发人员更清楚现在的云基础设施,”他说。“他们已经开始云最佳实践更喜欢健康检查后,结构化的日志发送到stdout(标准输出),并通过文件或环境变量配置。”
Crowdfire Kubernetes的承诺,辛格希望扩大公司的原生云栈。团队已经使用普罗米修斯监控,他说他正在评估Linkerd和特使代理作为一种“获取更多关于请求延迟和失败的指标,处理它们更好。”Other CNCF projects, includingOpenTracing和gRPC也在他的雷达。
辛格发现原生云社区在印度正逐渐成长,特别是在班加罗尔。“很多创业公司和新公司开始Kubernetes上运行他们的基础设施,”他说。
当人们问他关于Crowdfire的经验,他已经提供这条建议:“Kubernetes是一个伟大的技术,但它可能不适合你,如果你只有一个或两个服务或应用程序并不容易在集装箱中运行环境,”他说。“评估你的情况和价值,Kubernetes提供所有在前。如果你决定使用Kubernetes,确保你理解在引擎盖下运行的组件和它们在顺利运行集群中扮演的是什么角色。要考虑的另一件事是如果你的应用程序是“Kubernetes-ready,”意义如果他们有适当的健康检查和处理终止信号关闭优雅。”
如果你的公司符合概要文件,就去做吧。Crowdfire明显而且现在收获的好处。“15个月,我们一直在使用Kubernetes,惊人的对我们,”辛格说。“这使我们能够快速迭代,提高开发速度,不断向我们的用户提供新的特性和bug修复,同时保持我们的运营成本和基础设施管理开销控制。”