SkyWalking 二进制与 Docker 部署

SkyWalking 的基础部署由存储后端、OAP 和 UI 组成。你提供的实操记录使用 SkyWalking 8.6、Elasticsearch 7 和单机 Docker Compose，适合学习和功能验证。生产部署前必须重新确认 SkyWalking、存储后端和 Agent 的兼容矩阵，不应直接把旧版本镜像或单节点 Elasticsearch 用于生产。

1. 组件与端口

组件	默认端口	职责	网络建议
Java Agent	无固定监听端口	向 OAP 上报 Trace 和指标	仅需访问 OAP gRPC 端口
OAP gRPC	11800	接收 Agent 数据	只向受信应用网络开放
OAP HTTP	12800	供 UI 查询 OAP 数据	只向 UI 或内部网络开放
SkyWalking UI	8080	查询、拓扑和 Trace 展示	经网关、SSO 或访问控制暴露
Elasticsearch	9200 / 9300	保存追踪、指标和元数据	不对公网开放

先确认四段链路：应用能访问 OAP 11800，UI 能访问 OAP 12800，OAP 能读写存储，运维人员能通过受控入口访问 UI。

2. 二进制部署

2.1 准备 Elasticsearch

以下示例是单节点实验配置。生产环境需要独立节点规划、分片和副本策略、快照仓库、TLS、认证以及索引生命周期管理。

# /etc/elasticsearch/elasticsearch.yml
cluster.name: skywalking-es-cluster
node.name: elasticsearch-1

# 单节点实验使用本机私网地址；生产使用受控的服务发现和网络策略。
network.host: 172.16.41.28
http.port: 9200

# 数据与日志应位于独立的持久化磁盘。
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# 仅用于单节点实验；多节点必须按真实集群规划配置。
discovery.type: single-node

# 启动服务并设置开机自启。
sudo systemctl enable --now elasticsearch

# 验证 HTTP 健康和节点信息；不要通过公网暴露该端口。
curl -fsS http://172.16.41.28:9200/
curl -fsS 'http://172.16.41.28:9200/_cat/nodes?v'

如果 OAP 无法创建索引，优先检查存储地址、认证权限、集群健康、磁盘水位和版本兼容性，而不是反复重启 OAP。

2.2 配置并启动 OAP 与 UI

解压与安装目录可按团队标准安排，下面以 /apps/skywalking 为例。下载文件应从 Apache 官方下载页或受控镜像仓库获取，并对校验和、签名和版本兼容性进行确认。

# 解压 SkyWalking 二进制包并建立稳定软链接，方便后续版本切换和回滚。
sudo tar -xzf apache-skywalking-apm-es7-8.6.0.tar.gz -C /apps
sudo ln -sfn /apps/apache-skywalking-apm-bin-es7 /apps/skywalking

# OAP 和 UI 共用启动脚本；启动前先完成存储配置。
cd /apps/skywalking
./bin/startup.sh

在 config/application.yml 中设置存储实现和节点地址。你提供的记录使用 elasticsearch7 选择器；实际名称应与下载包内支持的 storage selector 一致。

storage:
  # 使用与发行包兼容的 Elasticsearch 存储实现。
  selector: ${SW_STORAGE:elasticsearch7}

elasticsearch7:
  # 为空表示默认命名空间；多环境应使用受控命名空间或独立集群。
  nameSpace: ${SW_NAMESPACE:""}
  # 写入集群内地址或负载均衡地址，不要写单个临时 Pod IP。
  clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:172.16.41.28:9200}

# 核对 OAP、UI 及其监听端口是否启动。
ss -lntp | rg '8080|11800|12800'

# 检查 OAP 和 UI 进程日志，重点关注存储连接与索引初始化错误。
tail -n 200 logs/oap-server.log
tail -n 200 logs/webapp.log

通过 Elasticsearch Head 等管理工具可以确认索引是否持续创建和写入；这类工具只应在受控的运维网络使用，不能代替快照、容量和权限检查。

3. Docker Compose 实验部署

下面的 Compose 文件保留了原始实操中的 Elasticsearch 7、SkyWalking 8.6 和 3 个容器结构。版本被固定是为了让实验可重现；生产请换成已验证的受支持版本，并增加资源限制、健康检查、备份、认证、TLS 和网络策略。

services:
  es7:
    image: elasticsearch:7.10.1
    environment:
      # 单机实验必须显式声明；生产 Elasticsearch 不应使用此模式。
      - discovery.type=single-node
      # 堆大小要与主机内存和其他容器一起评估。
      - ES_JAVA_OPTS=-Xms1g -Xmx1g
      - TZ=Asia/Shanghai
    volumes:
      # 挂载持久卷，且宿主机目录应对容器内 Elasticsearch 用户可写。
      - /data/elasticsearch/data:/usr/share/elasticsearch/data
    ports:
      - "127.0.0.1:9200:9200"

  skywalking-oap:
    image: apache/skywalking-oap-server:8.6.0-es7
    depends_on:
      - es7
    environment:
      - TZ=Asia/Shanghai
      - SW_STORAGE=elasticsearch7
      # Compose 服务名会由内部 DNS 解析，无需写固定 IP。
      - SW_STORAGE_ES_CLUSTER_NODES=es7:9200
    ports:
      - "11800:11800"
      - "127.0.0.1:12800:12800"

  skywalking-ui:
    image: apache/skywalking-ui:8.6.0
    depends_on:
      - skywalking-oap
    environment:
      - TZ=Asia/Shanghai
      # UI 通过 OAP HTTP 端口查询，不直接查询 Elasticsearch。
      - SW_OAP_ADDRESS=skywalking-oap:12800
    ports:
      - "8080:8080"

# 启动前确认主机有足够内存和磁盘，并让数据目录拥有正确权限。
free -h
sudo mkdir -p /data/elasticsearch/data

# 使用 Compose V2 启动并检查三个容器是否全部就绪。
docker compose up -d
docker compose ps
docker compose logs --tail=200 skywalking-oap

在单机实验中，至少预留 4 GiB 主机内存；真实需求取决于 Elasticsearch 堆、OAP 分析负载、追踪采样率和保留期。UI 可通过 http://<host>:8080 访问，但生产应经反向代理和身份认证暴露。

4. 部署验收

• Elasticsearch 节点健康，OAP 具备写入所需索引权限。
• OAP 的 11800 对 Agent 可达，UI 能访问 OAP 12800。
• UI 正常打开且能加载服务列表；空列表不等同于 UI 故障，应继续检查 Agent 上报。
• 数据目录、备份策略、保留期、访问控制和升级回滚方案已记录。