第3章 安装部署:DSPM组件介绍、安装包获取、安装步骤详解

3.1 DSPM组件概览

说实话,DSPM的组件架构并不复杂,但每个组件都有自己的脾气。我刚开始接触时,光区分几个微服务就花了一整天。现在先带你认认门。

组件名称一句话职责部署形态
DSPM-Core策略引擎 + 决策中心Java服务(Spring Boot)
DSPM-Agent数据采集 & 执行代理Go守护进程
DSPM-Web管理控制台(UI)Nginx + Vue 前端
DSPM-Store脱敏/加密存储层独立进程(C++)
DSPM-Broker消息总线(内部通信)基于Redis Streams
记住:Core 是大脑,Agent 是手脚,Store 是保险柜。剩下两个是血管和仪表盘。

3.2 安装包获取

你可能会问,安装包从哪下?官方渠道就两个:

  1. 企业版:联系销售获取授权码,然后在 portal.dspm.com/download 下载。
  2. 社区版:GitHub Release 页面,搜 dspm-community。

我个人习惯用社区版做测试,毕竟不需要申请License。不过注意,社区版不支持高可用和集群。嗯,小规模验证完全够用。

下载后先校验 sha256sum。我第一次没校验,结果解压报错,白白浪费半小时排查。你想想看,要是生产环境出这事可不得了。

3.3 安装步骤详解

下面的步骤我按最小部署来走,适合单机验证。如果你手头是CentOS 7.9+,基本不会卡壳。

3.3.1 环境准备

# 系统依赖
yum install -y java-11-openjdk redis nginx
# 创建运行用户
useradd -m -s /bin/bash dspm
echo "dspm  ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

我记得有个坑——Redis版本必须 ≥6.2。老版本缺少Stream特性,Broker组件启动会直接挂掉。

3.3.2 解压与配置

tar xzf dspm-community-2.5.0.tar.gz -C /opt/dspm
cd /opt/dspm
# 快速初始化目录结构
bash scripts/init-dirs.sh
# 编辑核心配置文件
vim conf/core.yml

核心配置文件里需要改三个地方:

  • redis.host:改成你的Redis地址(默认localhost)
  • store.path:脱敏存储路径(建议分配独立磁盘)
  • agent.enroll_key:随便写一串,Agent注册时要用
千万别用默认的enroll_key。我在一个测试环境里忘了改,结果被隔壁项目组的Agent无意中连进来,拉走了一批测试数据。虽然不是机密,但复盘起来脸都绿了。

3.3.3 启动各组件

启动顺序有讲究:先Broker,再Store,然后Core,最后Web和Agent。否则Core启动时会因为连不上Broker而反复重试。

# 启动顺序(每个窗口单独跑)
systemctl start redis          # 已有则跳过
/opt/dspm/bin/start-broker.sh
/opt/dspm/bin/start-store.sh
/opt/dspm/bin/start-core.sh
/opt/dspm/bin/start-web.sh
/opt/dspm/bin/start-agent.sh   # Agent最后启动

检查进程是否都活着:

ps aux | grep dspm
# 应该看到 broker, store, core, web, agent 共5个进程

我有个小技巧:写个简单的健康检查脚本,每10秒curl Core的 /actuator/health。一旦状态变为UP,就自动拉起剩余服务。省得你一个个窗口盯着。

3.3.4 验证部署

打开浏览器访问 http://你的IP:8080,看到登录页就成功了一多半。然后用默认admin账号登进去,在“Agent管理”里看看已注册的Agent状态。

关键验证动作:在Agent所在机器上执行 dspmcli policy apply demo_policy.json,观察Web端实时策略下发日志。如果5秒内日志显示“policy applied to agent”,部署闭环就通了。

3.4 避坑指南

  • 端口被占:Core默认8080,Web默认80。如果环境中已有Nginx,记得调Web的端口。
  • Java版本不匹配:我遇到过一次,JDK 17跑Core直接抛 UnsupportedClassVersionError。强制用JDK 11。
  • 磁盘空间:Store路径至少留10GB,否则Agent写入脱敏数据时会悄悄失败,日志里只写一句 disk full。
  • 其实大部分问题都能从 /opt/dspm/logs/ 下的日志找到线索。我习惯先看 core.log,再查 agent.log,80%的坑都能定位出来。

    3.5 组件关系一览

    下面这张图帮你理清部署后的通信路径。你看一眼就能明白“谁依赖谁”。

    DSPM 最小部署组件关系图 DSPM-Core DSPM-Agent DSPM-Store DSPM-Web DSPM-Broker 通信枢纽(Redis Streams) 所有内部消息都经过它

    箭头方向表示数据流或控制流。Core通过Broker向Agent下发策略,Agent采集数据后写入Store。Web通过Core读取状态。你按这个图检查进程间连通性,基本不会漏项。

    3.6 小结

    安装部署这步,说白了就是“架桥铺路”。组件虽多,但只要抓住Core、Agent、Store三个屁股,再通过Broker这根电线连起来,整套系统就能跑起来。我个人还保留了一个习惯:每次装完后,在Web端手动执行一次“全部Agent策略同步”,看看有没有组件报超时。如果一切顺利,部署验证就算通过了。接下来你就可以放心做策略配置和脱敏测试了。