10,037 讀數

如何将分布式客户端连接到私有 InfluxDB 数据库

经过 Ockam11m2023/04/15

太長; 讀書

Ockam 为开发人员提供了将分布式客户端连接到私有 InfluxDB 数据库的工具。只需几分钟即可实施，无需更改网络，并且您不必将私有数据库放到公共互联网上。

featured image - 如何将分布式客户端连接到私有 InfluxDB 数据库

InfluxDB 已成为传感器和服务存储时间序列数据的流行方式，而 InfluxData 借助 InfluxCloud 使这一过程变得快速而简单。不过，我们采访过的一些客户并未将所有内容都存储在托管云服务中。有时他们出于特定的业务、监管或合规原因将数据存储在自己的数据中心。其他时候，作为灾难恢复计划的一部分，他们在 Telegraf 中使用多个输出将数据发送到 InfluxDB Cloud 。

不管是什么原因，让单个客户端安全地连接到私有 InfluxDB 数据库可能涉及设置网络路由、打开防火墙、调整 NACL 和安全组。更不用说导航可能涉及的任何内部流程，以批准和部署所有这些更改。 InfluxDB 的价值不在于只有一个客户端偶尔写入数据，而在于能够支持数百个或更多。因此，为每台新设备重复网络管理开销，或者每当设备的网络配置发生变化时，您很快就会遇到无法维持这些严格网络控制的情况。然后，大多数人会在两个选项之间权衡：1）要求在远程客户端和 InfluxDB 数据库所在的网络之间建立 VPN。（可能）运行 InfluxDB 的网络管理员的持续管理员较少，但是管理客户端的人的设置负担更高。他们真的希望通过 VPN 将他们的网络连接到您的网络吗？或者 2) 将 InfluxDB 数据库直接暴露在公共互联网上，并相信认证系统足以保护它。

今天，我将带您进行第三种选择。只需几分钟即可实施，无需更改网络，并且您不必将私有数据库放到公共互联网上。在此过程中，我们还将获得一大堆其他好处，一旦我们开始工作，我将介绍这些好处。

初始设置

如果你想直接跳到一个工作示例，我们在 GitHub 上提供了一个用于 Docker 的 InfluxDB + Telegraf + Ockam 演示您可以使用 Docker Compose 在本地运行。它使用 InfluxDB 和 Telegraf 的官方 Docker 镜像，对启动脚本进行了更改，因此每个服务都使用 Ockam 建立连接。关于如何运行它的完整说明包含在README中。

为了模拟客户端将数据发送到 InfluxDB 的端到端示例，我们将启动一个 Telegraf 实例，让它向 InfluxDB 发出 CPU 事件，然后更改这两者的连接方式以显示我们如何连接它们跨不同的主机或网络。不过，为了这个示例，我们将在一台机器上运行所有内容。

奥卡姆

如果您之前设置过 Ockam，则可以跳过此部分并直接转到下面的 InfluxDB 设置。

 brew install build-trust/ockam/ockam

（如果您不使用 brew 进行包管理，我们有其他系统的安装说明在我们的文档中）

安装后，您需要使用 Ockam Orchestrator 注册您的本地身份，运行以下命令并按照提供的说明进行操作：

 ockam enroll

Influx数据库

如果你已经在你的本地机器上运行了 InfluxDB 并且有一个你可以用来写入它的身份验证令牌，你可以跳过这部分并直接继续安装下面的 Telegraf。

本节的先决条件是首先安装：

安装后，我们需要启动 InfluxDB，以便我们有地方存储我们将要生成的指标数据。在大多数像运行一样简单的系统上：

 influxd

然后你应该看到一些日志输出，最后一行确认 influxd 现在正在监听端口8086 ：

 2023-02-21T23:49:43.106268Z info Listening {"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086}

如果 influxd 启动成功，那么你可以打开一个新的终端会话并让它在后台运行。如果 influxd 没有成功启动，请检查一些常见问题的官方文档针对不同的操作系统。

现在我们将使用 influx CLI 命令完成初始数据库设置，以便 influxd 可以接收我们的数据。运行设置命令并完成所需的提示，记住您使用的组织和存储桶名称，因为我们稍后需要它们：

 influx setup

接下来，您需要为刚刚创建的用户复制令牌，您可以使用 auth 命令检索该令牌：

 influx auth list

电讯报

安装 Telegraf ，一旦设置完成，我们将需要一个配置文件来定义我们的输入源和输出目标。值得庆幸的是，Telegraf 包含一个生成此类文件的命令，我们可以指定将其预先配置为将主机的 CPU 利用率作为输入源，并将 InfluxDB 作为输出。

要生成基本配置运行：

 telegraf config \ --section-filter agent:inputs:outputs \ --input-filter cpu \ --output-filter influxdb_v2 > telegraf.conf

打开生成的 telegraf.conf 文件并找到[[outputs.influxdb_v2]]部分，它应该如下所示：

 [[outputs.influxdb_v2]] ## The URLs of the InfluxDB cluster nodes. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. ## ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"] urls = ["http://127.0.0.1:8086"] ## Token for authentication. token = "" ## Organization is the name of the organization you wish to write to. organization = "" ## Destination bucket to write into. bucket = ""

将令牌、组织和存储桶的空值替换为上一节中关于设置 InfluxDB并保存您的更改。您现在可以启动 Telegraf：

 telegraf --config telegraf.conf

检查一切正常

为了便于在未来的命令和测试中重复使用您的值，请将适当的值（即，将下面的占位符替换为您的实际值）存储到一系列环境变量中：

 export INFLUX_PORT=8086 \ INFLUX_TOKEN=your-token-here \ INFLUX_ORG=your-org \ INFLUX_BUCKET=your-bucket

现在我们可以检查 Telegraf 是否定期向 InfluxDB 发送数据。我们之前创建的配置将每 10 秒发出一次 CPU 统计数据，因此我们可以向 InfluxDB 发送一个查询，并返回过去 1 分钟的所有数据：

 curl \ --header "Authorization: Token $INFLUX_TOKEN" \ --header "Accept: application/csv" \ --header 'Content-type: application/vnd.flux' \ --data "from(bucket:\"$INFLUX_BUCKET\") |> range(start:-1m)" \ http://localhost:$INFLUX_PORT/api/v2/query?org=$INFLUX_ORG

将 Telegraf + 私有 InfluxDB 与 Ockam 安全连接

上面的示例通过使用默认的未加密 HTTP 传输连接这两个在同一主机上运行的服务。大多数重要的配置都会让 InfluxDB 在一台单独的主机上运行，一个或多个 Telegraf 节点发送数据。在生产中，未加密的传输不太可能被接受，将 InfluxDB 端口潜在地暴露给公共互联网也不总是可取的。

在本节中，我们将向您展示如何通过对任何现有服务进行极少的配置更改来解决这两个问题。

创建和注册您的节点

第一步是注册 Ockam，保存您的项目信息，并为您的 InfluxDB 和 Telegraf 节点创建注册令牌：

 ockam enroll ockam project information --output json > project.json export OCKAM_INFLUXDB_TOKEN=$( \ ockam project enroll --attribute component=influxdb) export OCKAM_TELEGRAF_TOKEN=$( \ ockam project enroll --attribute component=telegraf)

现在我们可以为我们的 InfluxDB 服务创建一个节点：

 ockam identity create influxdb ockam project authenticate --identity influxdb \ --token $OCKAM_INFLUXDB_TOKEN --project-path project.json ockam node create influxdb \ --project project.json \ --identity influxdb ockam policy set \ --at influxdb \ --resource tcp-outlet \ --expression '(= subject.component "telegraf")' ockam tcp-outlet create \ --at /node/influxdb \ --from /service/outlet \ --to 127.0.0.1:8086 ockam forwarder create influxdb \ --at /project/default \ --to /node/influxdb

这些命令中发生了一些事情，所以让我们快速解压缩它们：

我们创建了一个名为influxdb的新节点，并使用我们之前生成的令牌将其注册到 Ockam。如果您回顾生成令牌的命令，您会看到我们还使用component=influxdb属性标记了该令牌。
然后我们向influxdb节点添加了一个策略，该策略声明只有组件component值为telegraf的节点才能连接到 TCP 出口。
接下来我们创建一个 TCP 出口。这就像从我们刚刚创建的influxdb节点到127.0.0.1:8086的 TCP 端口（即我们的 InfluxDB 数据库正在侦听的端口）的管道。这个 Ockam 节点现在将从其他节点接收到的任何数据通过管道传输到该目的地。然而，唯一能够建立该连接的节点是那些通过了上一步中定义的策略的节点。
最后，我们在我们的项目上创建了一个转发器，它现在允许我们项目中的其他节点发现influxdb并将流量路由到它。

现在是时候通过为 Telegraf 创建相应的客户端节点来建立此连接的另一端了：

 ockam identity create telegraf ockam project authenticate --identity telegraf \ --token $OCKAM_TELEGRAF_TOKEN --project-path project.json ockam node create telegraf \ --project project.json \ --identity telegraf ockam policy set \ --at telegraf \ --resource tcp-inlet \ --expression '(= subject.component "influxdb")' ockam tcp-inlet create \ --at /node/telegraf \ --from 127.0.0.1:8087 \ --to /project/default/service/forward_to_influxdb/secure/api/service/outlet

现在我们可以解压这三个命令以及它们的作用：

和以前一样，我们使用生成的注册令牌创建一个新节点并将其注册到我们的项目中。这次是telegraf节点。
我们再次应用了一项政策来改善我们的安全状况。此策略允许创建 TCP 入口，但前提是另一端的节点具有值为influxdb的属性component 。
最后我们创建 TCP 入口。这是一种定义节点应在何处侦听连接（在本例中为 TCP 端口8087 ）以及应将流量转发到何处的方法。该节点会将数据转发到我们之前创建的转发器，转发器又会将其传递给我们的 influxdb 节点，然后再将其发送到 InfluxDB 数据库。

就是这样！本地主机端口8087上的侦听器现在将所有流量转发到 InfluxDB，无论它在何处运行。如果该数据库位于不同的主机上，在云中运行，或在私有数据中心中运行，注册和转发仍将确保我们与127.0.0.1:8087的通信将安全地连接到该数据库运行的任何地方。

更新现有配置以使用安全连接

此示例在端口8087上创建了 TCP 入口，主要是因为 influxd 服务在同一主机上运行并且已经绑定到端口8086 。在 Telegraf 和 InfluxDB 位于不同主机上的生产部署中，TCP 入口可以侦听端口8086 ，并且不需要更改此默认配置。

虽然这是在单个主机上运行的简化示例，但无论您的部署如何，以下说明都是相同的。 influxdb和telegraf节点注册并运行后，您需要做的唯一更改是更新 telegraf.conf 以指向本地侦听端口：

 [[outputs.influxdb_v2]] urls = ["http://127.0.0.1:8087"]

重新启动 Telegraf 服务，然后我们可以使用我们之前使用的相同命令检查它是否仍在存储数据。z

安全连接的客户端，以及更多...

此处的示例在不到 10 分钟的时间内解决了我们最紧迫的问题，同时添加了一些有价值的改进，这些改进并不立即显而易见，因为它们已被抽象掉：

私人数据库保持私密：您的 InfluxDB 尚未将其端口暴露给公共互联网，因此第三方无法访问
传输中加密：节点之间建立的安全通道是端到端加密的。每个节点生成自己的加密密钥，并获得自己唯一的凭证。然后他们使用这些在彼此之间建立相互信任的安全通道。通过消除对第三方服务存储或分发密钥的依赖，您可以减少漏洞表面积并消除单点故障。
基于身份和属性的访问控制：甚至建立到 InfluxDB 数据库的路由的授权都与请求访问的客户端的唯一身份相关联，这在支持现代和动态部署方法方面更加灵活，也更明确地符合我们围绕访问控制的意图。如果他们的客户能够建立信任，相信他们就是他们所说的那个人，那么他们就能够将他们的数据包路由到数据库。将其与基于远程网络假设的永久访问决策的历史方法进行对比（例如，此请求是否来自我们预先授权的 IP 地址？）。这是对 InfluxDB 数据库本身的身份验证和授权控制的补充，它们将继续像往常一样工作。
安全设计：以上所有因素的结合意味着访问 InfluxDB 数据库的唯一方法是通过安全通道，这意味着所有通信在传输过程中都是加密的，无论任何一端是否存在任何错误配置（例如 HTTP/TLS）未启用）。而且由于每个节点彼此交换凭据而不是共享公共证书或共享加密密钥，因此您还可以确保：
1. 供应链中的任何其他方都无法修改传输中的数据。您在消费者处收到的数据正是您的客户发送的数据。
2. 只有授权的客户端才能写入 InfluxDB，确保主题中的数据高度可信。如果您有更严格的要求，您可以控制您的凭证权限并执行精细的授权策略。
减少漏洞表面积： Ockam 通过将所有远程服务公开为本地服务来简化客户端访问问题。我们称之为虚拟邻接.当一个应用程序的所有远程组件几乎都与其他所有组件相邻时，整个网络、整个基础设施、整个互联网的安全和信任复杂性就被完全抽象掉了。所有第三方中介均已从应用程序的漏洞面中移除。