通过Kubernetes和容器实现DevOps.docx

? ? ? ? ? ? ? 通过 Kubernetes 和容器实现 DevOps ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  目 录 TOC \o 1-3 \h \z \u 通过 Kubernetes 和容器实现 DevOps 1 从瀑布式开发到敏捷开发 3 从敏捷开发到 DevOps 4 DevOps 的技术实现 5 DevOps 的技术实现 1：标准交付物 5 DevOps 的技术实现 2：容器调度平台 6 DevOps 的技术实现 3：DevOps 工具链 7 总结：DevOps 与容器和 Kubernetes 的关系 8 DevOps 工作流展示 8 常用 DevOps 工具介绍 9 Jenkins Pipeline 工作流分析 11 DevOps 工具链演示 13 总结 18  【摘要】近两年，随着容器、Kubernetes 等技术的兴起，DevOps 这个概念被广泛提及并被大量使用。本文将会从DevOps的产生、DevOps 与容器/Kubernetes 之间的关系、DevOps 的技术实现方式几个方面，结合实验展现的方式，让读者真正理解 DevOps 的含义。 DevOps 是什么 DevOps 中的 Dev 指的 Development，Ops 指的是的 Operations，用一句话来说 DevOps 就是打通开发运维的壁垒，实现开发运维一体化。 从瀑布式开发到敏捷开发 谈到 DevOps 的发展史，我们需要先谈一下敏捷开发。首先，敏捷开发是面向软件的，而软件依赖于计算硬件。我们知道，世界上第一台计算机是在 1946 年出现的。因此，软件开发相对于人类历史而言，时间并不长。相对于软件开发方法论的掌握，人们更擅长于工程学，如盖楼、造桥等。为了推动软件开发，1968 年，人们将工程学的方法应用到软件领域，由此产生了软件工程。 软件工程的方式有其优点，但带来了不少问题。最关键一点是：软件不同于工程。通过工程学建造的大桥、高楼在竣工后，人们通常不会对大桥高楼的主体有大量使用需求的变更；但软件却不同。对于面向最终用户的软件，人们对于软件功能的需求是会不断变化的。在瀑布式开发的模式下，当客户对应用有变化的需求时，软件厂商得重新开发软件。这将会使企业的竞争力大幅下降。 传统的软件开发流程是：产品经理收集一线业务部门和客户的需求，这些需求可能是新功能需求，也可能是对产品现有功能做变更的需求。然后进行评估、分析，将这些需求制定为产品的路线图，并且分配相应的资源进行相关工作。接下来，产品经理将需求输出给开发部门，开发工程师写代码。写好以后，就由不同的部门的人员进行后续的代码构建、质量检验、集成测试、用户验收测试，最后给生产部门。这样带来的问题是，开发周期比较长，并且如果有任何变更，都要重新走一遍开发流程，在商场如战场的今天，软件一个版本推迟发布，可能到发布时这个版本在市场上就已经过时了；而竞争对手很可能由于在新软件发布上快了一步，而迅速抢占了客户和市场。 正是由于商业环境的压力，软件厂商需要改进开发方式。 2001 年初，在美国滑雪胜地 snowbird，17 位专家聚集在一起，概括了一些可以让软件开发团队更具有快速工作、相应变化的能力的价值观原则。他们称自己为“敏捷联盟”。 敏捷开发的主要价值观如下： 表 1. 敏捷开发的核心价值观 有了敏捷联盟，有了敏捷开发价值观，必然会产生开发的流派。主要的敏捷开发流派有：极限编程（XP）、Scrum、水晶方法等。 至此，敏捷开发有理念、有方法、有实践。随着云计算概念的兴起，云计算的不断落地，敏捷开发不仅实现了工具化，也得到了升华。 从敏捷开发到 DevOps 谈到了敏捷开发，那么敏捷开发和 DevOps 有什么关系呢？ 敏捷开发是开发域里的概念，在敏捷开发基础之上，有如下阶段：敏捷开发-持续集成-持续交付-持续部署-DevOps。 从敏捷开发到 DevOps，前一个阶段都是后一个阶段的基础；随着阶段的推进，每个阶段概念覆盖的流程越来越多；最终 DevOps 涵盖了整个开发和运维阶段。正式由于每个阶段涉及的范围不同，因此所以每个概念所提供的工具也是不一样的。具体内容我们参照下图： 图 1. 从敏捷开发到 DevOps 的进阶 持续集成（Continuous Integration）指的是：代码集成到主干之前，必须全部通过自动化测试；只要有一个测试用例失败，就不能集成。持续集成的要实现的目标是：在保持高质量的基础上，让产品可以快速迭代。 持续交付（Continuous Delivery）指的是：开发人员频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审