3. 环境准备

ThingsBoard边缘版（ThingsBoard Edge）作为工业物联网场景中的核心边缘计算节点，其部署环境的稳定性直接决定了后续设备接入、数据流转与规则引擎执行的可靠性。与云端版不同，边缘版通常运行在靠近生产网络的网关或工控机上，面临的环境更为复杂：可能是老旧Windows主机、ARM架构的工业盒子，也可能是虚拟化环境中的Linux虚拟机。本章将围绕服务器硬件选型、操作系统准备、容器运行时安装、网络规划与防火墙放行五个维度展开，帮助读者构建一个既满足当前部署需求、又具备横向扩展能力的运行底座。在动手安装之前，我们需要先明确一个核心原则：边缘版不是简单的“缩小版云端”，它对资源占用、网络抖动和存储写入的要求更为敏感，因此环境准备阶段必须做到“一次做对”。

上图清晰地展示了环境准备阶段的四个核心模块及其依赖关系。硬件与操作系统是基础底座，容器运行时是ThingsBoard Edge的运行载体，网络与端口规划决定了外部系统如何访问边缘服务，而防火墙配置则是保障安全的第一道防线。在实际部署中，这四个模块并非孤立存在，例如端口规划会直接影响防火墙规则的编写，而操作系统的内核参数（如文件句柄数）又会制约Docker容器的并发连接能力。因此，我们建议按照“先硬件、再软件、后网络”的顺序逐步推进，并在每一步完成后进行验证。

3.1 服务器硬件要求与操作系统选型

核心原理：边缘节点的资源边界

ThingsBoard Edge在启动时会同时运行多个容器：PostgreSQL数据库、ThingsBoard核心服务、以及可选的消息队列（如Kafka或内置的InMemory）。这些服务共享宿主机的CPU、内存和磁盘I/O。与云端版可以依赖分布式存储不同，边缘版通常采用单机部署，因此资源规划必须预留20%-30%的余量，用于应对设备连接数突增或规则引擎执行复杂逻辑时的峰值负载。此外，边缘节点往往部署在无人值守的现场，硬件故障的恢复成本远高于云端，所以磁盘建议使用SSD（固态硬盘）而非机械硬盘，以避免数据库写入延迟导致的数据丢失风险。

判断方法：根据设备规模选择配置

我们可以通过一个简单的公式估算所需内存：基础内存（2GB）+ 设备数 × 0.01GB + 规则引擎复杂度系数。例如，接入500台设备且规则逻辑较复杂时，建议内存不低于2 + 5 + 2 = 9GB，实际选择16GB内存较为稳妥。CPU方面，ThingsBoard Edge的规则引擎和REST API是CPU密集型任务，建议至少4核。下表给出了不同场景下的推荐配置：

对于Windows环境，虽然ThingsBoard官方提供了Docker Desktop支持，但生产环境不推荐使用Windows作为宿主机，主要原因是Windows的容器隔离机制（Hyper-V）性能损耗较大，且系统更新可能重启导致服务中断。如果必须使用Windows，建议采用Windows Server 2022并开启WSL2（Windows Subsystem for Linux 2）后端，但需要接受更高的运维复杂度。

实战场景：工控机上的ARM架构部署

某新能源工厂需要在产线边缘部署ThingsBoard Edge，用于采集PLC数据并执行本地告警。现场工控机为ARM架构（瑞芯微RK3588），8GB内存，64GB eMMC存储。我们首先确认了ThingsBoard Edge官方Docker镜像支持linux/arm64架构，然后选择Ubuntu 22.04 ARM版作为操作系统。在部署过程中发现，由于eMMC的随机写入性能较弱，PostgreSQL容器频繁出现“checkpoint not complete”警告。解决方案是将PostgreSQL的shared_buffers从默认的128MB降低到64MB，并设置synchronous_commit = off，同时将Docker的数据目录挂载到外接SSD硬盘上。这一调整使数据库写入延迟从平均15ms降低到3ms，设备数据上报成功率提升至99.9%。

3.2 Docker与Docker Compose安装

核心原理：容器运行时与编排工具的分工

Docker Engine负责容器的生命周期管理（创建、启动、停止），而Docker Compose则通过一个YAML文件定义多容器应用的配置，实现“一键启动”。ThingsBoard Edge的官方部署方式就是通过docker-compose.yml文件同时启动PostgreSQL和ThingsBoard Edge两个容器。需要特别注意的是，Docker Compose v2已经作为Docker CLI的插件集成，不再需要单独安装docker-compose二进制文件，但部分旧教程仍在使用v1命令，容易造成混淆。

操作流程：Linux环境下的标准安装步骤

以下以Ubuntu 22.04为例，展示完整的安装与验证流程。首先卸载可能存在的旧版本，然后安装依赖包并添加Docker官方GPG密钥：

# 1. 卸载旧版本
sudo apt-get remove docker docker-engine docker.io containerd runc

# 2. 安装依赖
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 3. 添加Docker官方GPG密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# 4. 设置稳定版仓库
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 5. 安装Docker Engine和Compose插件
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

# 6. 验证安装
sudo docker --version
sudo docker compose version

安装完成后，建议将当前用户加入docker组，避免每次执行命令都需要sudo：

sudo usermod -aG docker $USER
newgrp docker
# 验证免sudo执行
docker ps

案例拆解：国内网络环境下的镜像加速配置

由于ThingsBoard镜像存储在Docker Hub上，国内服务器直接拉取时经常出现超时或速度极慢的问题。某制造企业在部署时，docker pull thingsboard/tb-edge命令耗时超过30分钟仍未完成。我们通过配置镜像加速器解决了该问题。编辑/etc/docker/daemon.json文件：

{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://dockerproxy.com",
    "https://docker.nju.edu.cn"
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "data-root": "/data/docker"
}

配置完成后执行sudo systemctl restart docker，再次拉取镜像，耗时缩短至3分钟。同时，我们将Docker的数据目录从系统盘迁移到独立数据盘（/data/docker），避免系统盘空间不足导致容器启动失败。这里需要特别提醒：data-root的修改必须在Docker服务停止状态下进行，否则会导致数据损坏。

3.3 网络与端口规划

核心原理：端口映射与容器网络模式

ThingsBoard Edge默认使用host网络模式还是bridge模式，取决于docker-compose文件中的配置。官方默认使用bridge模式，通过端口映射将容器端口暴露到宿主机。这种模式下，我们需要明确哪些端口需要对外暴露，哪些端口仅限内部通信。例如，PostgreSQL的5432端口通常只允许宿主机访问，不应映射到外部网卡。而8080端口（Edge UI）和1883端口（MQTT）需要根据业务需求决定是否对外开放。

端口清单与规划建议

下表列出了ThingsBoard Edge涉及的主要端口及其用途，读者应根据实际网络环境进行规划：

在规划网络时，还需要考虑边缘节点与云端ThingsBoard的通信方式。如果边缘节点通过4G/5G网络连接云端，需要确保7070端口能够主动访问云端的443端口（HTTPS），且网络具备稳定的上行带宽。对于设备接入侧，如果现场存在多个网段（如PLC网段、传感器网段），建议在交换机层面做好VLAN隔离，仅放行必要的IP段访问1883端口。

实战场景：多网卡服务器的端口绑定

某智慧园区部署边缘版，服务器拥有双网卡：eth0连接办公网（192.168.1.0/24），eth1连接设备网（10.10.0.0/16）。需求是：办公网用户只能访问8080端口，设备网设备只能访问1883端口。我们通过修改docker-compose.yml中的端口映射实现：

ports:
  - "192.168.1.10:8080:8080"
  - "10.10.0.10:1883:1883"

这种绑定方式比直接使用0.0.0.0更安全，避免了端口暴露到所有网卡。同时，在防火墙上仅放行对应IP段的访问规则。部署完成后，使用ss -tlnp | grep -E '8080|1883'验证监听地址，确认端口只绑定在预期的IP上。

3.4 防火墙配置

核心原理：防火墙与容器端口的关系

Docker的端口映射（-p参数）本质上是iptables的DNAT规则，它会在宿主机防火墙之前生效。这意味着，即使宿主机防火墙没有放行某个端口，Docker的映射规则也可能绕过防火墙直接暴露端口。因此，正确的防火墙配置策略是：在Docker层面限制端口绑定IP，在系统防火墙层面限制源IP和访问控制，两者配合才能形成有效防护。

操作流程：Ubuntu UFW与CentOS Firewalld配置

对于Ubuntu系统，使用UFW（Uncomplicated Firewall）进行配置。以下命令演示如何仅允许特定网段访问8080端口：

# 启用UFW
sudo ufw enable

# 默认拒绝所有入站流量
sudo ufw default deny incoming

# 允许SSH（防止锁死）
sudo ufw allow 22/tcp

# 允许办公网访问8080
sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp

# 允许设备网访问1883
sudo ufw allow from 10.10.0.0/16 to any port 1883 proto tcp

# 查看规则
sudo ufw status numbered

对于CentOS/RHEL系统，使用Firewalld：

# 启动并启用firewalld
sudo systemctl start firewalld
sudo systemctl enable firewalld

# 添加富规则，限制源IP
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="8080" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.0.0/16" port protocol="tcp" port="1883" accept'

# 重新加载
sudo firewall-cmd --reload

配置完成后，务必进行验证。可以从外部机器使用telnet或nc命令测试端口连通性，同时检查Docker的iptables规则是否与防火墙规则冲突：

# 查看Docker的iptables规则
sudo iptables -L DOCKER -n -v --line-numbers

# 测试端口连通性（从办公网机器执行）
nc -zv 192.168.1.10 8080

案例拆解：防火墙误配置导致设备离线

某水处理项目在部署完成后，所有MQTT设备无法连接边缘节点。排查过程如下：首先检查Docker容器状态，发现容器正常运行；然后使用docker logs查看ThingsBoard日志，发现大量“Connection refused”错误；接着在宿主机上执行ss -tlnp | grep 1883，确认端口正在监听；最后检查防火墙规则，发现UFW默认策略为deny incoming，且未放行1883端口。由于Docker的DNAT规则在UFW之前生效，理论上端口应该可达，但UFW的deny规则会拦截所有未显式允许的入站流量，包括Docker的转发流量。解决方案是添加UFW放行规则后，设备立即恢复连接。复盘经验：在启用UFW或Firewalld时，必须同时考虑Docker容器端口和宿主机端口的关系，建议在防火墙配置完成后，使用docker-compose restart重启容器，确保iptables规则重新加载。

环境准备阶段是整个ThingsBoard Edge部署过程中最容易被忽视、但影响最大的环节。硬件选型不当会导致性能瓶颈，Docker安装错误会引发容器启动失败，端口规划混乱会造成安全漏洞，防火墙配置失误则直接导致设备无法接入。建议读者在完成本章内容后，按照“硬件检查→Docker安装→端口验证→防火墙配置”的顺序进行一次完整的演练，并记录每一步的输出结果。只有基础环境稳固，后续的ThingsBoard Edge配置、设备接入和数据流转才能顺利进行。