Skywalking在9.0+版本后重做了前端UI,叫做“Booster UI”,以前的“Rocketbot UI”被弃用。默认情况下,新版本的UI在官方提供的“SkyWalking APM”下载包中,默认以jar包的形式进行部署。下载后通过查看其官方文档关于UI的配置文件和说明,会发现该UI项目的前端外部又被包裹了一层Spring Boot/Spring Cloud Gateway网关。当我们需要将该UI项目部署到自定义的网关(如nginx)后,并且增加映射访问路径时,会发现无论如何请求都无法正常路由到正确的前端资源地址,因为在Booster UI中,前端路径都写死到了根路径下,于是就没有办法在中间增加映射路径了。
首先,考虑到官方使用Spring Boot/Spring Cloud Gateway对前端项目进行了又一层的封装,这对于自定义网关和前端路径来说都增加了不少难度,因此就开始寻找有没有前端原本的项目源码,便找到了Github上的skywalking-booster-ui。clone下来源码之后,修改vue.config.js,在module.exports
中增加一行publicPath: "/skywalking"
,这个就是你前端部署在服务器上之后需要配置的子路径。如果只修改这一行,部署之后会发现,前端要去请求一个graphql地址,这个地址没有被publicPath所影响,因此其请求的路径还是域名根路径,随后在代码中全局搜索"/graphql",发现有三个地方配置了graphql请求路径,即vue.config.js的29,8,fetch.ts的25,6和index.ts的53,10,三个地方都改成/skywalking/graphql,然后使用npm编译(此处省略npm的安装过程),并且npm版本必须是LTS 16+,不能是Current 18+,否则会报编译错误。编译命令是npm run build
。然后将生成的dist文件夹上传部署到服务器的既定目录下。
现在,就可以使用nginx对该前端资源进行代理了。这里先贴出nginx的相关配置:
location /skywalking/graphql {
proxy_method POST;
proxy_pass http://127.0.0.1:12800/graphql;
}
location /skywalking {
alias /opt/skywalking/skywalking-front/dist/;
try_files $uri $uri/ /skywalking/index.html;
}
首先,当location有重叠部分时,nginx是按照先后顺序匹配的,因此将具有子路径的location /skywalking/graphql
写在location /skywalking/
前面。然后,根据官方提供的webapp.yml
配置文件的以下内容:
spring:
cloud:
gateway:
routes:
- id: oap-route
uri: lb://oap-service
predicates:
- Path=/graphql/**
discovery:
client:
simple:
instances:
oap-service:
- uri: http://localhost:12800
我们可以推测,当请求本机的/graphql/**
接口时,请求被重定向到http://localhost:12800/graphql
,并且该请求经过测试为post请求,因此我们将其请求代理转发到对应的Skywalking server的rest端口上,并且接口为/graphql
,方法为post,因此有了location /skywalking/graphql
的两行配置。至于location /skywalking/
的两行配置,首先alias和try_files的作用可以看nginx官方文档,另外,当前端项目为vue时,vue+nginx的配置,vue路由必须先加载index.html或者XX.js才能识别到路由,因此可以理解成最后一行为针对vue项目history路由模式的固定配置,hash路由据悉无此问题。关于hash和history路由模式的在nginx下的区别,可以参考history路由模式下的nginx配置。
至此,skywalking-ui已经能够被nginx所正常代理了。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。