背景
在当下的软件应用开发领域中，越来越多的敏捷化企业希望自己的软件开发过程能以超音速、甚至于星际穿梭的速度，来快速响应各种变化，但同时还要保证安全性。DevOps 流水线无疑为这一目标提供了最佳实践。
但是，要完全满足这样的需求，我们应该如何去建立合适的 DevOps 流水线呢？有没有一种很好的方式，能够帮助我们去理解 DevOps 流水线当中 CI/CD 过程，以及容器技术，如 Docker 和 Kubernetes，在其中的角色和影响呢？
其实，DevOps 流水线的建设可以类比为两种模式：火箭式或飞机式。从众多客户的应用实践来看，要想运行一个完善的、可靠的 DevOps 流水线，火箭式的建设是远远不够的，实际遇到的困难要大得多。
火箭发射模式
我们通常把 DevOps 流水线理解为一个简单的、从左到右的线性过程：编写代码、提交、构建、测试、部署，以及作为产品发布。创建出来的软件在流水线当中就像被装船运送一样，有着清晰定义的去向。
在这种模式下，创建一个应用程序就像发射登陆火星的火箭一样。在允许登陆任务继续进行之前，必须要计划、审批、测试，以及验证所有的工作。为了准备发射，所有团队必须紧密地协同工作。我们只有一次机会去发射这个火箭，而且火箭一旦发射，就再没有机会进行修改和更新。从发射台到最终到达火星，火箭的功能是固定的、不可修改的。
火箭发射是一次性的。每一次测试都需要创建一个新的火箭，而这会带来一些未知的风险。新的火箭需要在确认所有系统都准备好了之后才能发射，以完成承担的任务。
这是一个清晰的、经典的工程模型。但是，这不是 DevOps 应有的工作方式。
航班运行模式
上述火箭模式中比较好的 DevOps 实践是在创建和运行服务时，开发和运维团队在研发生命周期的各个阶段都紧密地合作。
然而，DevOps 并不是像高风险火箭发射那样简单的从左到右的线性过程。相反，它是一个频繁触发且不会终止的循环过程，而且每一次触发都会引入一些新的的风险。所以，DevOps更像是现代的航空系统。在任何时间，全球的航空公司都频繁地，事实上是连续地，发送着航班，运载着上百万对其充满信任的旅客。
航空公司管理其飞机和航线的流程，和 DevOps 流水线保证应用发布时效性和可靠性的方法是十分相像的。和软件企业一样，航空公司一样要紧跟技术的发展、快速响应安全问题，以及适应客户需求的变化，同时还要保证整个系统不中断地运行。在日常运营中，航空公司持续对每架飞机进行检查（测试）、维护（打补丁），以及安排运营时间。这个过程和 DevOps 中应用的持续集成、更新和交付过程非常类似的。
和火箭发射的一次性不同，飞机能够反复地执行起飞和下降，最终执行航线任务的和最初通过测试飞行的都是同一架飞机，这充分表明了两种模式的差异性。那么，怎样才能保证 DevOps 流水线运转得更像是一个航空公司，而不是一名火箭兵呢？
起飞前的清理工作
火箭和飞机都是由许多资源组成的产品，不同的生产部门分别负责结构、机械和控制系统等各个部分，而且是由不同的供应商提供大部分的组件，从最基本的如门锁、座椅、地毯等，直到复杂的如导航系统等。
类似的，每一个软件应用也是由组织内的多个团队共同创建的，而且应用运行的大部分代码，例如操作系统和语言框架等，都是以企业外部的远程仓库为来源的。
开发人员可以控制将自己开发代码的哪些部分加入构建。但是，对于从公共仓库下载的外部依赖包，如 npm 或 maven 等，又该如何控制呢？那些包可能会不定期的进行修改，而这是你无法控制的。
如果你的 DevOps 流水线像发射火箭一样，那么针对测试或发布的每次新构建，都会成为偷渡者潜入火箭的机会。如果无法做到持续监控，那些计划之外的东西就可能进入新的构建，从而导致每次构建都不能获得完全相同的结果。
前往跑道
Docker 镜像就像是飞行器，不管是火箭还是飞机，通过构建而成，并封装了应用要执行的所有功能。从发射到着陆，Docker 镜像的能力保持不变。
Docker 引擎，结合镜像仓库，把镜像转换为容器，就像把这些飞行器推送到发射平台。而像 Kubernetes 这样的编排工具就进一步把这些容器发射到航线上去。
Docker 引擎，结合镜像仓库，把镜像转换为容器，就像把这些飞行器推送到发射平台。而像 Kubernetes 这样的编排工具就进一步把这些容器发射到航线上去。
如果像处理火箭一样，每次发射一个新的，那在开发、测试，或发布阶段构建的每个 Docker 镜像，都有可能和前一个有一些不同。
而如果像飞机一样处理，就意味着对发射到空中的内容有更大的确定性。航空公司不会为每次起飞都制造一架新的飞机。他们只是测试飞机，然后在航线上可靠地运行飞机，直到飞机需要更换为止。
构建一个 Docker 镜像，然后在测试到发布的流水线上进行升级，而不是重新构建，能够确保这个镜像带上航线的都能每次、准时、安全地飞翔。
地面控制
正如上述分析的，真正的 DevOps 流水线不是简单的从左到右的线性过程，而是设计、分解和重构的复杂、迭代、网络化的过程。
为了使 DevOps 流水线运转得更像是航空公司， Artifactory 可以作为地勤人员，来保证一切都按计划、平稳地运行。Artifactory 使得开发人员能够控制从代码构建而来的 Docker 镜像，并通过总是在航线中运行同一架飞机来保证可靠性和速度。
首先，Artifactory 解决了一个开发人员面对的关键挑战，那就是利用如 npm 或 maven 这样的外部依赖，也能进行持久、确定的构建。利用 Artifactory，开发人员能够维护外部仓库的本地缓存，从而保证外部代码的变化在没有确认可用之前不会被引入到构建当中。而且，保证外部依赖的本地访问，也能帮助加速构建，提升生产力。
利用 Artifactory 作为 Docker 镜像中心，可以使得 DevOps 流水线中从测试到发布的各个阶段之间升级实不可变的构建产出变得更加容易，而不需要每次都重新构建。同样可以根据需要，利用 Artifactory 为每次构建存储的详尽信息，来创建新的确定性的构建。
飞机飞行需要燃料，而航空公司，就像所有现代化企业一样，基于数据进行运维。航空公司对他们的飞机、客户和工作人员了解得越多，就越能帮助他们最大限度地提高投资回报率。
Artifactory 作为 Kubernetes 的 Docker 镜像中心，可以提供简化、安全实施运维工作所需的数据。除了容器、镜像的列表之外，Artifactory 还可以可视化地展示容器里都有什么，以及这些内容是如何进入容器的。
如果再增加利用 JFrog Xray 对镜像进行扫描，就可以获得更多有关镜像当中代码真实安全性的信息，进一步保护企业和应用。
翱翔天空
不仅仅像本文说的，真正的 DevOps 流水线就像是现代化的航空公司，DevOps 已成为大多数航空公司自身运营的关键实践。联合航空公司、西南航空公司、阿拉斯加航空公司和捷蓝航空公司就是众多航空公司的代表，它们已经为 DevOps 和 CI/CD 做了大量的投资，在网络和移动平台上为其客户提供购票、值机、登机等各种服务。这些航空公司很多都引入了 Artifactory，获得了在全球范围发展 DevOps 的巨大收益。
正如这些高风险企业所展示的，仅仅将 Docker 容器推上跑道，对于真正的 DevOps 是不够的，需要利用 Artifactory 为 CI/CD 提供的支持，来确保它们在天空中安全地飞翔。
文章作者：高欣，JFrog 架构师，专注 DevOps 解决方案，以及企业 DevOps 转型，曾在 IBM 服务近十年，带领团队致力于 DevOps 领域产品，及公有云服务的研发、运维、服务及推广等，在软件产品和云服务的开发与运维、持续集成及交付、DevOps 等领域具备丰富的技术积累和实践经验。
转载于:https://blog.51cto.com/jfrogchina/2354915
