本章内容概览

Docker，以及更广泛的容器化技术，建立了一种全新的软件打包、运行和协调方式。这对我们如何在生产环境中交付和管理软件产生了重大影响，也就不足为奇了。如果你对运维（Operations）经验不多，尤其是现在 Docker 已经成为其中的一部分，这个世界可能会让你感觉像走进迷宫一样。

因此，在我们动手准备将应用部署到类似生产环境之前，首先需要熟悉一下当前的环境。本章将从回顾在生产环境中交付和运行软件的含义开始。

接下来，我们将探讨 Docker 如何改变这一格局，以及拥抱 Docker 后软件交付会是什么样子。我们将介绍各种托管选项、你会遇到的各种工具及其用途，以及在选择生产环境时需要权衡的利弊。

本章的独特之处在于：它完全是信息性内容，没有实际操作步骤。所以，请放松身心，稍作休息，享受节奏的变化。

DevOps 中的“Ops”

作为软件开发者，我们的关注点通常集中在开发阶段，包括发现、分析、测试和构建等活动。根据你的工作环境，你可能或多或少地参与了运维（Operations，简称 Ops），即在生产环境中交付和运行软件的工作。

运维的各个领域划分

我们可以将生产环境中的软件交付与运行分解为多个不同的领域：

尽管你可能对这些概念已有大致了解，但让我们逐一说明，以确保我们理解一致。

配置资源（Provisioning）

也称为创建资源。软件需要计算机和资源才能运行。配置资源的一个重要部分是确保有足够的计算资源可用，若不可用则需创建。

软件运行所需的资源有哪些？

不仅仅是机器或实例。在将应用部署到云环境时，我们还可能需要其他物理或虚拟基础设施，例如：

• 网络，也称为虚拟私有云（VPC）
• 网络地址转换（NAT）网关
• 路由器
• 防火墙
• 互联网网关
• 代理
• 安全规则

配置管理（Configuration management）

创建之后，我们的原始基础设施通常无法立即发挥其真正作用，必须进行配置。对于某些基础设施（可能是虚拟的，如路由器或防火墙），这意味着确保它们具备正确的设置或规则。对于服务器而言，通常意味着安装运行应用程序所需的所有软件包和依赖项。

发布管理（Release management）

大多数系统都需要定期维护或持续开发，这意味着需要不断部署或发布新版本。我们通常希望能够轻松、频繁地发布，且对系统用户的影响最小甚至无感。这可以通过自动化、良好的工具以及蓝绿部署或灰度发布等技术实现。此外，当出现问题时，能够回滚到已知良好的软件版本将极为宝贵。

监控与告警（Monitoring and alerting）

在理想世界中，一旦部署，我们的应用将永远按预期运行。但现实中总会出问题：服务器故障、软件存在缺陷、我们的假设不再成立。与其视而不见，不如主动采取措施来掌握软件的健康状况及其运行表现。这通常涉及跟踪系统的健康指标，并在问题出现时及时收到告警。

运行维护（Operating）

在日常生产系统的运行中，我们可能需要执行一些常见任务，例如：扩展以应对负载增加、缩减以节省成本、诊断和调试问题，以及总体上保持系统稳定运行。优秀的运维团队会尽可能实现自动化，以减少人为错误，并释放时间用于主动预防问题，而非被动救火。

采用 Docker 会改变我们对上述许多领域的思考方式。

以配置管理为例。尽管 Chef、Puppet 或 Ansible 等工具非常流行，但在容器化环境中，它们的作用显著减弱。使用 Docker 时，每个软件组件的依赖都已固化在其镜像中，与其他容器中的依赖隔离。这极大地简化了问题。由于应用级别的依赖由应用自身在 Dockerfile 中管理，配置基础设施实例基本上只需确保 Docker 已正确安装即可。

正如我们即将看到的，Docker 还在其他方面具有深远影响，尤其是在软件发布和运维方式上。