SaltStack基础设施：为HAProxy负载均衡器创建Salt状态

介绍

SaltStack 或 Salt 是一个功能强大的远程执行和配置管理系统，可用于以结构化、可重复的方式轻松管理基础架构。在本系列中，我们将演示一种从 Salt 部署管理开发、登台和生产环境的方法。我们将使用 Salt 状态系统来编写和应用可重复的操作。这将使我们能够安全地破坏我们的任何环境，因为我们知道我们可以在以后轻松地将它们以相同的状态重新上线。

在我们的上一篇指南中，我们为安装和配置 Nginx 的 Web 服务器创建了 Salt 状态。在本指南中，我们将为负载均衡器配置状态，该负载均衡器将位于我们的暂存和生产环境中的 Web 服务器前面。我们的负载均衡器需要配置 Web 服务器地址才能正确传递流量。

让我们开始吧。

创建主 HAProxy 状态文件

我们的负载均衡器将使用 HAProxy 在环境中所有可用的 Web 服务器之间分配我们应用程序的流量。与 Nginx 状态文件一样，我们将在 /srv/salt 目录中为此状态创建一个目录：

sudo mkdir /srv/salt/haproxy

我们将使用名称 init.sls 作为此目录中的主状态文件，以便我们可以通过目录名称引用状态：

sudo nano /srv/salt/haproxy/init.sls

在内部，我们可以使用与 Nginx 相同的模式来安装 haproxy 包并确保它正在运行。我们将确保在包发生更改或 /etc/default/haproxy 文件或 /etc/haproxy/haproxy.cfg 文件发生更改时重新加载服务。同样，要非常小心间距以避免 YAML 错误：

/srv/salt/haproxy/init.sls

haproxy:
  pkg:
    - installed
  service.running:
    - watch:
      - pkg: haproxy
      - file: /etc/haproxy/haproxy.cfg
      - file: /etc/default/haproxy

我们需要管理 haproxy 服务正在监视的两个文件。我们可以为每个创建状态。

/etc/haproxy/haproxy.cfg 文件将是一个模板。该文件将需要提取有关环境的信息，以填充其要向其传递流量的 Web 服务器列表。我们的网络服务器在每次创建时都不会拥有相同的 IP。每次应用此状态时，我们都需要动态创建列表。

/etc/default/haproxy 文件只是一个普通文件。我们正在管理它，因为我们希望确保 HAProxy 在启动时启动。不过，这不是动态信息，因此我们不需要将其设为模板：

/srv/salt/haproxy/init.sls

haproxy:
  pkg:
    - installed
  service.running:
    - watch:
      - pkg: haproxy
      - file: /etc/haproxy/haproxy.cfg
      - file: /etc/default/haproxy

/etc/haproxy/haproxy.cfg:
  file.managed:
    - source: salt://haproxy/files/etc/haproxy/haproxy.cfg.jinja
    - template: jinja
    - user: root
    - group: root
    - mode: 644

/etc/default/haproxy:
  file.managed:
    - source: salt://haproxy/files/etc/default/haproxy
    - user: root
    - group: root
    - mode: 644

这实际上是我们需要的状态文件本身。完成后保存并关闭文件。

安装 HAProxy 并将包文件传输到 Salt Master

我们将使用与 Nginx 相同的技术来获取我们需要的基本 HAProxy 文件。我们将在 minion 上安装包，然后告诉服务器将文件推送回 master。

让我们使用 stage-lb 服务器，因为无论如何这将是这个包的最终目标。如果您尚未启动并运行暂存机器，请键入：

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map

一旦您的服务器可用，您可以通过键入以下命令在 stage-lb 服务器上安装 haproxy 软件包：

sudo salt stage-lb pkg.install haproxy

安装完成后，我们可以告诉 minion 将我们需要的两个文件推送到主服务器：

sudo salt stage-lb cp.push /etc/default/haproxy
sudo salt stage-lb cp.push /etc/haproxy/haproxy.cfg

minion 文件系统的相关部分将在 /var/cache/salt/master/minions/minion_id/files 目录中重新创建。在这种情况下，minion ID 为 stage-lb。将整个 minion 文件结构复制到我们的 HAProxy 状态目录：

sudo cp -r /var/cache/salt/master/minions/stage-lb/files /srv/salt/haproxy

我们可以通过键入以下内容来查看文件结构：

find /srv/salt/haproxy -printf "%P\n"

Outputfiles
files/etc
files/etc/default
files/etc/default/haproxy
files/etc/haproxy
files/etc/haproxy/haproxy.cfg
init.sls

现在我们已经有了 Minion 的文件，我们可以销毁负载平衡服务器：

sudo salt-cloud -d stage-lb

然后，我们可以在后台重新创建服务器，以便我们稍后可以进行最终测试和确认。使用此命令定位您的 Salt 主服务器，因为它可以访问相关的云文件：

sudo salt --async sm cloud.profile stage-lb stage-lb

当服务器正在重建时，我们可以继续对我们正在管理的 HAProxy 文件进行必要的修改。

配置 /etc/default/haproxy 文件

我们可以从 /etc/default/haproxy 文件开始。在 Salt Master 上的 HAProxy 状态目录中，移动到包含默认文件的目录：

cd /srv/salt/haproxy/files/etc/default

将文件复制到 haproxy.orig 以便我们可以将文件保留为最初打包时的样子：

sudo cp haproxy haproxy.orig

现在，打开文件进行编辑：

sudo nano haproxy

将 ENABLED 更改为“1”。这将告诉 Ubuntu 的初始化系统 Upstart 在服务器启动时启动 HAProxy 服务：

/srv/salt/haproxy/文件/etc/default/haproxy

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

这是我们唯一需要做的改变。保存并关闭文件。

配置 /etc/haproxy/haproxy.cfg 模板文件

接下来，让我们处理主 HAProxy 配置文件。移动到 Salt Master 服务器上的相应目录：

cd /srv/salt/haproxy/files/etc/haproxy

同样，让我们复制配置以保存其原始状态：

sudo cp haproxy.cfg haproxy.cfg.orig

然后，重命名文件以反映这是一个 Jinja 模板文件：

sudo mv haproxy.cfg haproxy.cfg.jinja

在文本编辑器中打开模板文件：

sudo nano haproxy.cfg.jinja

在文件的顶部，我们可以从设置 Jinja 变量开始。我们需要使用 network.interface_ip 执行函数来获取负载均衡器运行的环境。稍后我们将使用它来使用来自同一环境的 Web 服务器填充服务器列表：

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

{%- set env = salt['grains.get']('env') -%}
global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        . . .

跳到文件的“默认”部分。我们需要将 mode 更改为“tcp”，将第一个 option 更改为“tcplog”：

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

defaults
    . . .
    mode    tcp
    option  tcplog
    . . .

在文件的底部，我们需要创建我们的实际配置。我们需要创建一个“前端”部分，它将描述 HAProxy 如何接受连接。我们将此部分标记为“www”。

我们想将此绑定到服务器的公共 IP 地址。我们可以使用带有 eth0 参数的 network.interface_ip 执行模块函数来获取它。 Web 请求将从端口 80 进入。我们可以使用 default_backend 选项指定要传递给的默认后端。我们将调用我们的后端 nginx_pool：

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

frontend www
    bind {{ salt['network.interface_ip']('eth0') }}:80
    default_backend nginx_pool

接下来，我们需要添加 nginx_pool 后端。我们将使用传统的循环平衡模型并再次将模式设置为“tcp”。

之后，我们需要从我们的环境中填充后端 Web 服务器列表。我们可以在 Jinja 中使用“for”循环来做到这一点。我们可以使用mine.get执行模块函数来获取internal_ip挖矿函数的值。我们将匹配 Web 服务器角色和环境。 ~ env 会将我们之前设置的 env 变量的值连接到它之前的匹配字符串。

对于循环的每次迭代，此查找的结果将存储在 server 和 addr 变量中。在循环中，我们将使用这些循环变量添加服务器的详细信息。最终结果如下所示：

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

. . .

frontend www
    bind {{ salt['network.interface_ip']('eth0') }}:80
    default_backend nginx_pool

backend nginx_pool
    balance roundrobin
    mode tcp
    {% for server, addr in salt['mine.get']('G@role:webserver and G@env:' ~ env, 'internal_ip', expr_form='compound').items() -%}
    server {{ server }} {{ addr }}:80 check
    {% endfor -%}

完成后保存并关闭文件。

测试 HAProxy 状态文件

我们的负载平衡状态是相当基本的，但很完整。我们现在可以继续测试它。

首先，让我们使用 state.show_sls 来显示文件排序：

sudo salt stage-lb state.show_sls haproxy

我们可以通过输出中各种“order”值的顺序来判断包将被安装，服务将被启动，然后两个文件将被应用。这是我们所期望的。由于我们配置的“监视”设置，文件更改将触发服务重新加载。

接下来，我们可以对状态应用程序进行试运行。这将捕获一些（但不是全部）会导致状态在运行时失败的错误：

sudo salt stage-lb state.apply haproxy test=True

检查所有状态是否都已通过。无论底部的故障计数或输出如何，向上滚动并查看每个状态的“注释”行。有时，这将包括有关潜在问题的额外信息，即使测试被标记为成功。

修复测试命令期间出现的任何问题后，您可以将您的状态应用到负载均衡器服务器。确保在应用状态之前运行并配置了后端 Nginx Web 服务器：

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map
sudo salt -G 'role:webserver' state.apply nginx

当您的 Web 服务器正在运行时，应用 haproxy 状态：

sudo salt -G 'role:lbserver' state.apply haproxy

您现在应该能够通过负载均衡器的公共 IP 地址访问您的两个后端 Web 服务器之一。您可以使用以下命令显示负载均衡器的公共 IP 地址：

sudo salt -G 'role:lbserver' network.interface_ip eth0

如果你使用浏览器，它看起来像这样：

使用 curl 更容易看到负载均衡器在后端服务器之间传递流量：

curl load_balancer_public_IP

Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from stage-www2</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello!  This is being served from:</p>

<h2>stage-www2</h2>

</body>
</html>

如果您再次键入该命令几次，它应该在您的两台服务器之间交换：

curl load_balancer_public_IP

Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from stage-www1</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello!  This is being served from:</p>

<h2>stage-www1</h2>

</body>
</html>

如您所见，服务请求的服务器发生了变化，这意味着我们的负载均衡器运行正常。

结论

在这一点上，我们有一个正常工作的 HAProxy 状态，可以应用于我们的负载均衡器机器。这可用于在所有后端 Nginx 服务器之间拆分我们应用程序的传入流量。我们可以轻松地销毁负载均衡器，然后根据可用的 Web 服务器重建它们。

在下一个指南中，我们将专注于让 MySQL 启动并作为我们的后端数据库系统运行。这将用于在我们的各种环境中存储应用程序数据。