赞!建立所有这些需要什么?我们花了将近1.5年的时间。那值得吗?

通过构建其他工具，遥测并重新部署每个应用程序的方式，我们花了将近1.5年的时间来稳定这种复杂的CI设置。为了实现开发/产品平价，我们也必须将所有这些微服务都部署到生产中，否则，基础架构和部署设置之间的偏差将使应用程序难以为开发人员辩护，并且本应为开发人员做出选择一个噩梦。

我们对这个话题有不同的看法。回顾过去，我们认为解决连续集成的问题变得更加糟糕，因为将所有微服务推向生产以实现开发/产品平价的复杂性使得实现更快的CI的挑战变得更加复杂和困难。在使用Kubernetes之前，我们将Ansible与Hashicorp Consul和Vault一起用于基础架构供应，配置管理和部署。慢吗?是的，一点没错。但是我们认为我们可以通过Consul引入服务发现并优化Ansible部署，从而在合理的较短时间内就足够接近我们的目标。

我们应该迁移到Kubernetes吗?是的，一点没错。使用Kubernetes有很多好处-服务发现，更好的成本管理，弹性，治理，对云基础架构基础架构的抽象等等。今天，我们也收获了所有这些好处。但这并不是我们开始时的主要目标，也许没有必要施加自己的压力和痛苦来实现自己的方式。

对我们来说，一大收获是，我们本可以采用另一种且抗性较小的方式来采用Kubernetes。我们只是被Kubernetes收购，这是我们甚至不在乎评估其他选项的唯一解决方案。

我们将在此博客文章中看到，在Kubernetes上进行迁移和操作与在云VM或裸机上进行部署不同。您的云工程和开发团队有一条学习曲线。对于您的团队来说，值得一试。但是，现在您需要做的是这个问题。您必须尝试清楚地回答。

（编辑：潍坊站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!