当我还是个学徒的时候，我被教导要把服务员当宠物对待。我会小心对待他们。我会确保他们健康和吃饱。如果其中一个人生病了，找到治疗方法是最重要的。我甚至给了他们名字。一个是加菲猫，另一个是甘道夫。我工作过的大多数公司都有一个命名服务器的主题。神话生物，漫画人物，动物等等。今天，当使用集群时，方法是不同的。云改变了一切。宠物变成了牛。当他们中的一个生病了，我们就杀了他们。我们知道几乎有无限多的健康标本，所以治愈一个生病的标本是浪费时间。出了问题，就把它毁了，再创造一个新的。我们的应用程序在构建时考虑了可伸缩性和容错性，因此单个节点的临时丢失不是问题。这种方法与建筑。如果我们希望能够轻松高效地部署和扩展，我们希望我们的服务更小。小事情更容易推理。今天，我们正朝着更小、更易于管理、寿命更短的服务方向发展，不围绕微服务定义体系结构的借口已经不复存在。他们产生了太多与行动有关的问题。毕竟，部署的东西越多，基础设施部门在配置和监视所有东西时遇到的问题就越多。使用容器，每个服务都是自给自足的，不会造成基础设施混乱，因此微服务对许多人来说是一个有吸引力的选择场景。与将微服务打包在容器中并部署到集群中，需要一组不同的工具。需要集群协调。因此，我们得到了Mesos、Kubernetes和Docker Swarm（仅举几个例子）。有了这些工具，手动SSH到服务器的需求就消失了。我们有一种自动化的方法来部署和扩展服务，在发生故障时可以重新安排。如果容器停止工作，它将被再次部署。如果整个节点发生故障，在其上运行的所有内容都将转移到正常节点。所有这些都是在没有人为干预的情况下完成的。我们设计一种行为，让机器来接管，我们比以往任何时候都更接近于广泛使用不需要的自愈系统我们。而为了解决一些问题，集群编排工具创造了新的问题。也就是说，如果我们事先不知道我们的服务将在哪里运行，我们如何配置它们？devops2.0工具包如果您喜欢本文，您可能会对devops2.0toolkit感兴趣：使用容器化微服务自动化连续部署管道书。那个这本书讲述了不同的技术，这些技术帮助我们以一种更好、更有效的方式构建软件，将微服务打包成不可变的容器，连续测试并部署到使用配置管理工具自动配置的服务器上。它是关于快速、可靠和连续的部署，无停机时间和回滚能力。它涉及到可扩展到任意数量的服务器，设计能够从硬件和软件故障中恢复的自愈系统，以及集中记录和监视群集。输入换句话说，这本书包含了使用一些最新和最好的实践和工具的完整的微服务开发和部署生命周期。我们将使用Docker、Ansible、Ubuntu、Docker Swarm和Docker Compose、Consul、etcd、registor、confd、Jenkins、nginx等等。我们会经历很多练习，甚至更多，工具这本书可以从亚马逊上买到(亚马逊网站以及其他全球网站）和LeanPub。