17、使用 Puppet 配置云应用

使用 Puppet 配置云应用

1. Puppet 的典型应用范围

Puppet 最初是为服务器配置的自动化和集中维护而设计的。随着社区的发展，Puppet 在发展过程中衍生出了更多的功能，并且这种趋势很可能会持续下去。目前，Puppet 适用于不同的目的和用户群体。
- 计算机技术人员的好帮手 ：Puppet 允许用户编写和共享简单的一次性清单，这使得它成为所有计算机技术人员的不错选择。无论是开发、质量保证、运维还是其他领域，都可以依靠 Puppet 不仅记录特定任务的系统要求，还能实现高级的“脚本”来强制执行这些要求，甚至可以在不同的平台上使用。不过，虽然 Puppet 清单在管理特定系统细节时可以起到类似脚本的作用，但严格来说它并不是脚本。在某些情况下，脚本可能比清单更合适，例如当清单包含大量链式 exec 类型资源时；而当可以使用其他原生资源时，Puppet 则更强大，清单可以比 shell 脚本更简单、更灵活。
- Vagrant 实例的配置 ：Puppet 在配置 Vagrant 实例方面的应用越来越受欢迎。Vagrant 是一种工具，它允许开发团队以管理虚拟机器的形式简化开发环境的创建过程。对于那些在测试环境的复杂设置过程中遇到困难的软件团队来说，Vagrant 是必不可少的工具。Vagrant 支持在虚拟机实例的配置过程中集成 Puppet 清单和模块。
- 网络和数据中心管理 ：大多数 Puppet 安装仍然是用于管理机器网络，主要集中在数据中心的服务器和计算节点。一些站点还会通过 Puppet 管理桌面，这在对工作站有复杂要求的大型网络中是合理的。
- 操作系统平台支持 ：Puppet 主要用于基于 Linux 的系统，特别是 Debian 或 Red Hat 系列的系统。其他 Linux 发行版和 BSD 系统虽然不太常见，但也得到了很好的支持。对 Windows 的支持也在稳步推进，Puppet 在该平台上的应用也越来越广泛。
- 网络组件管理 ：除了通用服务器，Puppet 还可以管理专用的网络组件，如交换机、路由器和其他智能硬件。更多信息可以参考 http://puppetlabs.com/blog/puppet - network - device - management 。

2. 数据中心常见用法 - 角色和配置文件模式

在使用 Puppet 管理整个网络时，效率始终是主要目标之一。为了避免不必要的代码冗余，我们可以将重复的情况整合到通用类中，从而减少未来的维护开销。而 Craig Dunn 提出的“角色和配置文件（Roles and Profiles）”模式就是一种非常成功且广泛应用的设计模式。
- 角色（Roles） ：角色是外层抽象，每个服务器（或工作站）只能选择一个角色。例如 internal_webserver 、 key_distribution_center 或 accounting_desktop 等。从技术上讲，角色就是一个类，通常将角色组织在 role 或 roles 模块中。设计目标是每个节点块只包含一个角色类，尽量避免其他 include 语句和资源声明。变量声明是可以接受的，但通常更倾向于使用 Hiera。示例代码如下：

node falstaff {
    include role::key_distribution_center
}

• 配置文件（Profiles） ：配置文件代表系统的各个方面。在服务器领域，典型的配置文件包括 apache_server 、 nginx_proxy 、 postgres_server 或 ldap_master 等。配置文件也应该组织在一个专用模块中。角色类通常只包含一个或多个配置文件类的 include 语句。配置文件本身理想情况下应该只包含从 Hiera 获取数据的模块选择，也可以在清单中直接传递一些模块参数，但这样做可能会带来兼容性和评估顺序依赖的风险。示例代码如下：

class role::key_distribution_center {
    include profile::heimdal_server
    include profile::firewall_internal
}

class profile::heimdal_server {
    include heimdal
    class { 'ssh': restricted => true }
}

3. 将 Puppet 引入云环境

现在让我们聚焦云环境，这里主要关注基础设施即服务（IaaS）范式。IaaS 云由连接到互联网的虚拟机网络组成，每台机器运行管理员选择的基本操作系统。
- IaaS 云与数据中心的异同 ：从 Puppet 的角度来看，IaaS 云与数据中心并没有太大区别，因为这种云的设计初衷就是替代物理数据中心，只是用虚拟机和虚拟化网络连接取代了机架式服务器。但与本地数据中心相比，管理 IaaS 实例也带来了一些独特的挑战，因为云实例通常不像本地系统那样可以进行全面定制。
- 云环境中代理的初始化 ：
- 手动初始化 ：最直接的方法是手动操作，将新的 IaaS 虚拟机视为新安装的 Linux 主机，通过 SSH 连接，逐步安装 Puppet、连接到主服务器并请求证书。
- 自动初始化 ：为了减少手动干预，可以创建一个预安装 Puppet 包的镜像。为了进一步简化初始化过程，可以添加一个启动脚本，使用 --waitforcert 选项让 Puppet 代理尽快获取证书。示例脚本如下：

#!/bin/bash
export PATH=/bin:/usr/bin
CERT=`puppet agent --configprint certname`
DIR=`puppet agent --configprint certdir`
[ -f "${DIR}/${CERT}.pem" ] && exit 0
puppet agent --onetime --no - daemonize --waitforcert 300

将该脚本添加到 /etc/cron.d/ 目录下的文件中，使其在实例启动时运行：

@reboot /usr/local/bin/receive - puppet - cert

需要注意的是，仍然需要在主服务器上使用 puppet cert 命令手动签署证书，这是出于安全考虑。如果希望通过 Web 表单签署证书，可以在主服务器上安装 Puppet Dashboard（不过该工具已停止维护，仅由社区提供支持，更官方的版本可通过 Puppet Enterprise 获得）。
- 使用 Puppet 的云配置模块 ：Puppet Enterprise 提供了一个 CLI 工具，可用于管理由 AWS、GCE 或 VMware 驱动的云实例。在社区版中，可以通过安装 puppetlabs - cloud_provisioner 模块添加类似的功能（该模块不支持 VMware）。该模块为 Puppet 添加了新的子命令（Puppet 称为 Faces），如 puppet node_aws 和 puppet node_gce 下的命令。配置完成后，可以使用 puppet node_aws list 命令列出 EC2 实例。

4. 为云环境构建清单

云环境与本地硬件在操作上的一个显著区别是无法为节点命名。在本地数据中心，服务器名称通常具有一定的含义，用于传达机器的功能；而在云环境中，网络由一系列匿名的工作节点组成。
- 功能映射到节点 ：
- 传统方法的局限性 ：在云环境中，传统的为节点分配清单的方法并不适用。定义单个节点块或在单个 Hiera 数据源中定义角色映射都很麻烦，尤其是在云实例的删除和重新部署过程中，需要不断更新清单以匹配新的节点名称。
- 使用 Facter 事实 ：在云环境中，更合适的方法是让 Puppet 代理通过 Facter 事实声明其目标状态。例如，可以添加一个自定义事实 my_cloud_app_role 来选择代理的角色。可以通过定义环境变量或添加外部事实文件的方式来设置该事实。示例如下：

FACTER_my_cloud_app_role=appserver puppet agent --test
# 或者
export FACTER_my_cloud_app_role=appserver
puppet agent --test

外部事实文件示例：

# /etc/facter/facts.d/my_cloud_app_role.txt
my_cloud_app_role=appserver

主服务器根据该事实值从角色模块中选择相应的角色：

node default {
    include "role::${my_cloud_app_role}"
}

使用初始化脚本创建外部事实文件的示例：

gcloud compute instances create instance1502 \
    --image debian - 7 \
    --metadata startup - script='#!/bin/bash
        echo my_cloud_app_role=appserver \
                >/etc/facter/facts.d/role.txt'

不过，允许代理自行选择清单可能会带来一些问题，例如机器可能会意外选择不适合的角色，导致配置不一致。
- 使用可信事实（Trusted Facts） ：为了避免上述问题，可以使用可信事实。代理在生成证书时可以向主服务器注册一些值，这些值会包含在证书的扩展字段中，一旦证书签署，代理就无法更改这些值，主服务器可以信任这些值的真实性。启用可信事实需要在 puppet.conf 文件中设置 trusted_node_data=true 。需要使用版本高于 3.5 的 Puppet。每个可信事实值通过 OID 进行索引，例如可以选择自定义 OID 1.3.6.1.4.1.34380.1.2.42 来定义节点角色。在 /etc/puppet/csr_attributes.yaml 文件中添加如下内容：

---
extension_requests:
   1.3.6.1.4.1.34380.1.2.42: appserver

主服务器可以从可信事实中安全地推导代理节点的角色：

$role = $trusted['extensions']['1.3.6.1.4.1.34380.1.2.42']
node default {
    include "role::$role"
}

需要注意的是，这种模式下的值是不可变的，如果需要更改角色，需要签署新的证书。但在云环境中，重新部署受影响的实例是比较常见的操作。

5. 选择证书名称

在云环境中，证书名称与每个云实例所承担的角色无关，因此证书的通用名称可以任意选择。使用云实例的 DNS 名称作为证书名称是一种可行的方法，但存在一个问题：当实例被停用和重新启用时，其 IP 地址和 DNS 名称可能会重复。由于主服务器会记录已签署的证书，当新的代理请求一个之前已为其他代理签署过的证书时，主服务器会拒绝接受该请求，尤其是在使用自动扩展功能时，这种情况会更加危险。

使用 Puppet 配置云应用

6. 为自动扩展做准备

在云环境中，自动扩展是一项重要的功能，它允许系统根据负载情况自动调整资源。使用 Puppet 进行自动扩展时，需要确保新的实例能够自动初始化并加入到系统中。
- 自动化初始化 ：如前面所述，创建预安装 Puppet 包的镜像并结合启动脚本来自动获取证书是关键。可以使用 --waitforcert 选项让 Puppet 代理在启动时等待证书，确保实例在获取到有效证书后能够正常工作。以下是之前提到的启动脚本示例，确保在实例启动时运行：

#!/bin/bash
export PATH=/bin:/usr/bin
CERT=`puppet agent --configprint certname`
DIR=`puppet agent --configprint certdir`
[ -f "${DIR}/${CERT}.pem" ] && exit 0
puppet agent --onetime --no - daemonize --waitforcert 300

• 动态角色分配 ：在自动扩展过程中，新实例需要能够动态地分配角色。可以使用前面介绍的 Facter 事实或可信事实来实现。例如，使用可信事实时，在创建新实例时通过设置 csr_attributes.yaml 文件来指定角色：

---
extension_requests:
   1.3.6.1.4.1.34380.1.2.42: appserver

主服务器根据可信事实为实例分配相应的角色：

$role = $trusted['extensions']['1.3.6.1.4.1.34380.1.2.42']
node default {
    include "role::$role"
}

• 集成云服务 API ：为了实现自动扩展，还需要集成云服务提供商的 API。例如，在 AWS 中，可以使用 Auto Scaling 组结合 Puppet 来实现自动扩展。当 Auto Scaling 组根据负载创建新实例时，通过启动脚本初始化 Puppet 代理并分配角色。

7. 确保成功的资源调配

在云环境中使用 Puppet 进行资源调配时，需要确保整个过程的成功和可靠性。
- 错误处理和监控 ：在 Puppet 脚本中添加适当的错误处理机制，确保在出现问题时能够及时发现和解决。可以使用 Puppet 的报告功能，将执行结果发送到监控系统，如 Nagios 或 Zabbix。例如，可以在 Puppet 配置文件中设置报告处理器：

reports = store, http
reporturl = http://your - monitoring - server/report

• 测试和验证 ：在部署到生产环境之前，对 Puppet 清单和模块进行充分的测试和验证。可以使用测试框架如 Beaker 来模拟不同的环境和场景，确保配置的正确性。以下是一个简单的 Beaker 测试示例：

require 'beaker - spec_helper'

describe 'my_module' do
  hosts.each do |host|
    it 'should install the package' do
      on(host, puppet('apply', '-e', 'include my_module'))
      expect(package('my_package')).to be_installed
    end
  end
end

• 版本控制和回滚 ：使用版本控制系统（如 Git）来管理 Puppet 代码，确保代码的可追溯性和可维护性。在出现问题时，可以轻松地回滚到之前的版本。例如，在 Git 中创建分支进行开发和测试，然后将稳定版本合并到主分支。

总结

本文详细介绍了如何使用 Puppet 配置云应用，涵盖了 Puppet 的典型应用范围、数据中心常见用法、将 Puppet 引入云环境、为云环境构建清单、选择证书名称、为自动扩展做准备以及确保成功的资源调配等方面。通过合理使用 Puppet 的各种功能和技术，可以在云环境中高效、可靠地管理和配置资源。

流程图：云环境中 Puppet 实例初始化流程

graph TD;
    A[创建云实例] --> B[使用预安装 Puppet 的镜像];
    B --> C[启动实例];
    C --> D[运行启动脚本];
    D --> E[使用 --waitforcert 选项请求证书];
    E --> F[主服务器签署证书];
    F --> G[实例获取证书并开始工作];

表格：Puppet 不同功能在云环境中的应用对比

功能	优点	缺点
Facter 事实	配置简单，可动态设置	安全性较低，可能导致配置不一致
可信事实	安全性高，主服务器可信任	值不可变，更改角色需重新签署证书
Puppet 云配置模块	统一管理云实例	社区版不支持 VMware