如何在Chef中使用角色和环境来控制服务器配置

介绍

在构建基础架构时，管理多服务器，服务，用户和应用程序可能会很快变得很难。配置管理系统可用于帮助您管理这种混乱。

Chef是一个出色的配置管理系统，可以让您轻松配置整个系统的不同组件。关于Chef的基本概念和怎么使用详情参考腾讯云+社区。

在本指南中，我们将继续探索如何使用Chef管理您的环境。这一次，我们将讨论如何使用角色和环境来区分您的服务器和服务，具体取决于它们应该展示的功能类型。

我们假设您已经安装了服务器，工作站和客户端。

角色和环境

什么是角色？

在您的组织中，如果您的基础架构在持续增长以满足更高流量的需求，则这种情况下可能存在多个冗余服务器，它们都执行相同的基本任务。例如，可能是负载均衡器将请求传递给Web服务器。它们都具有相同的基本配置，可以说每个都差不多是相似的角色。

Chef的角色视图几乎与常规定义完全相同。Chef中的角色是一种描述特定机器应该执行的操作的分类。它有什么责任，应该给它什么样的软件和设置。

在不同的情况下，您可能有一些机器处理多个角色。例如，如果您正在测试您的软件，则一台服务器可能包含数据库和Web服务器组件，而在生产中，您计划在不同的服务器上安装这些组件。

使用Chef，这可以像将第一台服务器分配给两个角色一样简单，然后将每个角色分配给不同计算机。每个角色都将包含使计算机进入完全运行状态以履行其特定角色所需的配置详细信息。这意味着您可以收集将处理包安装，服务配置，特殊属性等的信息。

什么是环境？

环境只是一个名称，旨在帮助管理员了解服务器所属的生产过程的哪个阶段。每个服务器都可以是一个环境的一部分。

默认情况下，会创建一个名为“_default”的环境。除非指定了其他环境，否则每个节点都将置于此环境中。可以创建环境以将服务器标记为进程组的一部分。

例如，一个环境可以称为“测试”，另一个环境可以称为“生产”。由于您不希望任何仍在测试的计算机成为生产计算机，因此每台计算机只能位于一个环境中。然后，您可以在测试环境中为计算机建立一个配置，为生产中的计算机建立完全不同的配置。

在角色中给出的上述示例中，您可以指定在测试环境中，Web和数据库服务器角色将位于单个计算机上。在生产环境中，这些角色应由各个服务器处理。

环境也有助于测试过程本身。在生产过程中，其应该是稳定版本。但是，您可以指定如果计算机是测试环境的一部分，它可以接收更新版本的信息。

如何使用角色

使用Ruby DSL创建角色

我们可以使用工作站上roles目录中的chef-repo目录创建角色。

登录您的工作站并立即进入此目录：

cd ~/chef-repo/roles

在此目录中，我们可以创建不同的文件来定义组织中我们想要的角色。每个角色文件都可以用Chef的Ruby DSL或JSON编写。

让我们为我们的Web服务器创建一个角色：

nano web_server.rb

在这个文件的内部，我们可以从指定角色的一些基本数据开始：

name "web_server"
description "A role to configure our front-line web servers"

这些应该是相当直接的。我们提供的名称不能包含空格，并且通常应与我们为此角色选择的文件名相匹配，减去扩展名。该描述只是一个可读消息，关于该角色应该管理什么。

接下来，我们可以指定我们希望用于此特定角色的运行列表。角色的运行列表可以包含cookbook（将运行的默认配置），cookbook中的配置（使用cookbook::recipe语法指定）和其他角色。请记住，run_list总是按顺序执行，因此将依赖项放在其他项之前。

如果我们想要指定run_list，这应该与我们在上一个指南中配置的完全一样，那么我们会看到如下所示的内容：

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"

我们还可以使用特定于环境的run_lists来根据服务器所属的环境指定变量配置更改。

例如，如果节点处于“生产”环境中，您可能希望在“nginx”cookbook中运行特殊配置，以使该服务器达到生产策略要求。你也可以在nginx cookbook中生成一个配置，用于配置测试服务器的特殊更改。

假设这两个配置分别称为“config prod”和“config test”，我们可以创建一些环境特定的运行列表，如下所示：

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]

在上面的例子中，我们已经指定如果节点是生产环境的一部分，它应该在“nginx”cookbook中运行“config prod”配置。但是，如果节点在测试环境中，它将运行“配置测试”配置。如果节点位于不同的环境中，则将应用默认的run_list。

同样，我们可以指定default和override属性。此时您应该熟悉默认属性。在我们的角色中，我们可以设置默认属性，这些属性可以覆盖其他任何地方设置的任何默认属性

我们还可以设置覆盖属性，其优先级高于许多其他属性声明。我们可以使用它来尝试强制分配了此角色的节点以某种方式运行。

在我们的文件中，可以像这样添加：

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]
default_attributes "nginx" => { "log_location" => "/var/log/nginx.log" }
override_attributes "nginx" => { "gzip" => "on" }

这里我们为节点中的任何服务器设置了默认日志位置。我们还指出，尽管在其他位置声明了其他一些属性声明，但此角色中的节点应将gzip属性设置为“on”。这可以在更多的地方被覆盖，但通常是高优先级声明。

使用JSON创建角色

可用于配置角色的另一种格式是JSON。事实上，我们可以通过使用knife来自动创建这种格式的角色。让我们创建一个测试角色：

knife role create test

将使用预加载的模板打开角色文件。它应该看起来像这样：

{
  "name": "test",
  "description": "",
  "json_class": "Chef::Role",
  "default_attributes": {
  },
  "override_attributes": {
  },
  "chef_type": "role",
  "run_list": [

  ],
  "env_run_lists": {
  }
}

这基本上与我们输入Ruby DSL格式文件的信息相同。唯一的区别是格式化和添加两个名为json_class和chef_type的新键。除此之外，我们可以使用以下内容轻松地在JSON中重新创建我们的其他文件：

{
  "name": "web_server",
  "description": "A role to configure our front-line web servers",
  "json_class": "Chef::Role",
  "default_attributes": {
    "nginx": {
      "log_location": "/var/log/nginx.log"
    }
  },
  "override_attributes": {
    "nginx": {
      "gzip": "on"
    }
  },
  "chef_type": "role",
  "run_list": [
    "recipe[apt]",
    "recipe[nginx]"
  ],
  "env_run_lists": {
    "production": [
      "recipe[nginx::config_prod]"
    ],
    "testing": [
      "recipe[nginx::config_test]"
    ]
  }
}

这应该与上面的Ruby版本具有几乎相同的功能。

在工作站和服务器之间传输角色

保存使用knife命令创建的JSON文件时，将在Chef服务器上创建角色。我们在本地创建的Ruby文件不会上传到服务器。

我们可以通过运行如下所示的命令将ruby文件上传到服务器：

knife role from file path/to/role/file

这会将我们文件中指定的角色信息上传到服务器。这适用于Ruby DSL格式的文件或JSON文件。

类似地，如果我们想从服务器获取我们的JSON文件，我们可以告诉knife命令在JSON中显示该角色文件，然后将其传递到如下文件中：

knife role show web_server -Fjson> path/to/save/to

将角色分配给节点

所以现在，无论我们使用何种格式，我们都在Chef服务器上担任角色。

我们将节点的角色分配给节点，就像节点的run_list中的配置一样。

因此，要将我们的角色添加到节点，我们将通过发出以下命令找到该节点：

knife node list

然后我们会发出如下命令：

knife node edit node_name

这将打开节点的定义文件，这将允许我们在其run_list中添加一个角色：

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "recipe[nginx]"
  ]
}

例如，我们可以用我们在此文件中的角色替换我们的配置：

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "role[web_server]"
  ]
}

这将执行与我们之前的配置相同的步骤，但它只是简单地说明服务器应具有的角色。

这允许您通过搜索访问特定角色中的所有服务器。例如，您可以通过搜索角色和环境来搜索生产环境中的所有数据库服务器：

knife search "role:database_server AND chef_environment:prod" -a name

这将为您提供配置为数据库服务器的节点列表。您可以在您的cookbook内部使用它来配置Web服务器，以自动将所有生产数据库服务器添加到其中以发出读取请求。

如何使用环境

创造一个环境

在某些方面，环境与角色非常相似。它们还用于区分不同的服务器，但不是通过服务器的功能区分，而是通过机器所属的开发阶段来区分。

我们之前讨论过角色的一些问题。与您的实际产品生命周期相符的环境更有用一些。如果您通过测试，登台和生产这样的步骤运行代码，则您应该具有与其相匹配的环境。

与角色一样，我们可以在Ruby DSL或JSON中设置定义文件。

在我们工作站的“chef-repo”目录中，我们应该有一个环境目录。这是我们应该放置环境文件的地方。

cd ~/chef-repo/environments

在这个目录中，如果我们要定义开发环境，我们可以创建一个这样的文件：

nano development.rb

name "development"
description "The master development branch"
cookbook_versions({
    "nginx" => "<= 1.1.0",
    "apt" => "= 0.0.1"
})
override_attributes ({
    "nginx" => {
        "listen" => [ "80", "443" ]
    },
    "mysql" => {
        "root_pass" => "root"
    }
})

如您所见，将环境合并到系统中的一个主要优点是，您可以指定cookbook的版本以及部署的配置。

我们也可以使用JSON格式。knife工具可以通过键入以下内容生成环境文件的模板：

knife environment create development

这将打开我们的编辑器（同样，您可以设置您的编辑器export EDITOR=nano），其中包含一个已填充名称的预加载环境文件。

我们可以输入以下内容创建相同的文件：

{
  "name": "development",
  "description": "The master development branch",
  "cookbook_versions": {
    "nginx": "<= 1.1.0",
    "apt": "= 0.0.1"
  },
  "json_class": "Cheff:Environment",
  "chef_type": "environment",
  "default_attributes": {
  },
  "override_attributes": {
    "nginx": {
      "listen": [
        "80",
        "443"
      ]
    },
    "mysql": {
      "root_pass": "root"
    }
  }
}

该文件在功能上应与我们上面演示的Ruby文件相同。与JSON角色文件一样，环境JSON文件还有两条额外的信息（json_class和chef_type），我们应该保留这些信息。

将环境文件移入和移出服务器

此时，如果您使用Ruby DSL，则您的文件位于工作站上，如果您使用JSON，则您的文件仅在服务器上。我们可以通过knife轻松地来回移动文件。

我们可以通过键入以下内容将我们的Ruby文件上传到Chef服务器：

knife environment from file ~/chef-repo/environments/development.rb

对于我们的JSON文件，我们可以通过键入以下内容来获取服务器的环境文件：

knife environment show development -Fjson > ~/chef-repo/environments/development.json

这将显示来自服务器的JSON文件，并将结果传递到ENVIRONMENT子目录中的本地文件中。

在节点中设置环境

每个节点可以只在一个环境中。我们可以通过编辑节点信息来指定节点所属的环境。

例如，要编辑一个被调用的节点client1，我们可以输入：

knife node edit client1

这将打开一个带有当前节点参数的JSON格式文件：

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "role[web_server]"
  ]
}

如您所见，chef_environment设置为_default。我们可以简单地修改该值以将节点置于新环境中。

完成后，保存并关闭文件。在节点运行的下一个chef-client上，它将获取新属性和版本约束并修改自身以与新策略保持一致。

结论

到目前为止，您应该很好地理解如何使用角色和环境来巩固机器应该处于何种状态。使用这些分类策略，您可以开始管理Chef在不同环境中处理服务器的方式。更多管理服务器的教程请前往腾讯云+社区学习更多知识。

参考文献：《How To Use Roles and Environments in Chef to Control Server Configurations》