应用服务与CD流水线

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

与每一种成为数据中心热门话题的技术一样，DevOps目前也面临着“定义疲劳”。事实上，我认为现在已经到了“定义枯竭”的程度，只是两者之间的界限很难确定。可以肯定的是，DevOps与云和SDN一样，远未形成一个普遍接受的定义。

但DevOps的独特之处在于，其包含的概念也经常被混淆，甚至被视为同一概念。例如，CD既可以指“持续交付”，也可以指“持续部署”。两者并不相同，不应混淆或混为一谈。Puppet Labs在一篇博客文章中清晰地说明了两者的区别：

可以看到，两者的根本区别在于生产环境部署是“手动”完成（持续交付），还是“自动”完成（持续部署）。

问题在于，那个标有“部署到生产环境”的橙色小框中包含大量必须实现自动化的工作。这不仅包括部署应用及其依赖项（数据库、其他服务、基础设施等），还包括部署所需的所有网络和应用服务，以便将该应用交付给最终用户。应用服务正是在这里发挥作用，而应用交付（指生产层面的交付，而非开发层面的交付）也由此进入持续部署流水线。

要在持续部署流水线中实现“部署到生产环境”步骤的自动化，需要对许多相互关联的组件进行预置、配置和测试。这涵盖从基础网络、安全服务（如防火墙）、可用性服务（负载均衡）到性能服务（加速、缓存等）的方方面面。平均而言，组织会使用11种不同的应用交付服务，以满足应用快速、安全且可用的需求。每项服务都必须完成部署（预置和配置），其中一些服务还依赖其他服务先行部署。

其中每一项此类服务（对于一路算到这里的读者来说，这就像圣艾夫斯谜题一样）都有数量不等的特性需要配置，包括将选项设为true或false、选择算法、建立路由等……

换句话说，从“手动”切换到“自动”远没有听起来那么容易。

是什么阻碍了网络发展？

这些流程实现自动化的一大障碍，在于共享组件与每个应用专属组件之间存在差异。基础设施即代码之所以能应用于应用基础设施领域，正是因为我们可以为某个应用分配专用基础设施（例如Web服务器或负载均衡器）。这意味着其配置文件有些类似于微服务：它仅在本地发挥作用，专注于为单个应用提供服务。

但在网络和应用服务领域，情况并非总是如此。例如，路由器或交换机本身就是为多个应用提供连接和转发服务而设计的。这意味着配置文件必然涵盖多个应用。虽然版本控制可能有所帮助，但配置仍然与设备而非应用紧密关联。应用服务和安全领域也是如此。

因此，虽然我们都在迈向以API取代CLI的时代，这是件好事，但也必须满足支持按应用（也可称为以应用为中心）模式的需求，以便按应用管理配置。

这意味着需要转向微服务式网络架构，在这种架构中，服务按应用进行部署和配置。具体可以采用专用“设备”（虚拟设备或硬件设备，外形规格与本次讨论无关），也可以采用应用专属配置，例如模板。

我们实现了吗？

我们正逐步接近目标。用于配置和管理的声明式模型可利用API按应用部署模板（即基础设施即代码），但我们尚未完全实现目标。要充分支持持续部署顺利实施，仍需开展大量工作，以确定如何编排所需的自动化流程。

要将“部署到生产环境”这一关键步骤从“手动”转为“自动”，从而完成从持续交付到持续部署的转变，就必须将网络、基础设施、应用服务和安全等各个孤立领域纳入其中。这意味着不仅要在自动化层面投入更多工作，还需要进行全局编排，以实现对相关流程的全面自动化，最终推动持续部署进入生产环境。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章