前言
随着前端项目的增大，越来越多时候会把动静态资源进行分离部署，对于分离部署时常常涉及到代理转发的问题，专网项目主要使用 nginx + docker + k8s 的部署方式，本文主要分享一些相关项目的实践过程的踩坑历程及回顾思考。
背景
公司云环境提供了对象存储服务（ps：类似于腾讯云的对象存储COS），但出于安全考虑，整个环境都是基于内网的系统，其https的证书并未进行相关的CA机构认证，但专网自服务项目会涉及到在公网让客户访问的问题，浏览器对于没有CA认证的https会给出警告，需要用户进行点击确认，用户体验极差，出于此考虑，在部署时候决定对静态服务进行代理转发，整个方案就变成了 nginx1(纯前端应用) 和 nginx2(静态服务转发) 的负载代理问题
案例
环境一致性问题
在开发过程中，经常会出现环境的问题，当测试小姐姐来向我们提bug时候，我们经常的回复是：”在我这儿是好的啊，你在刷新（重启）一下试试“[手动狗头]，这其实本质就是环境一致性的问题，对前端工程化来说，解决环境一致性问题其实是运维中一个比较常见的问题，常见的有云端IDE及统一配置文件等来解决，这里我们在构建脚手架的时候借鉴了dll的思想，通过一个config.json将配置每次从服务端请求下来解析后对url进行相应的配置，生产环境下走nginx，开发环境下走dev.proxy.js
- config.json
{
"IS_NGINX": 1,
"API" : {
"TGCOS": {
"alias": "/tgcos/",
"url": "http://bfftest.default.service.local:8148/tgcos/"
}
}
}
- dev.proxy.js
module.exports = {
'/tgcos/': {
target: 'http://172.24.131.166:8148'
}
}
- nginx1.conf (纯前端应用)
server {
location /tgcos/ {
proxy_pass http://bfftest.default.service.local:8148/tgcos/;
}
}
- nginx2.conf (静态服务代理转发)
server {
location / {
proxy_pass http://cos.zz-hqc.cos.tg.ncmp.unicom.local/
}
location /tgcos/ {
proxy_pass http://cos.zz-hqc.cos.tg.ncmp.unicom.local/
}
}
问题：这里配置了代理之后，在webpack中由于转发的服务又重新传了一层，因而在代理的时候发现会少一层转发，这时就会找不到代理的地址，解决办法是将根目录也代理到同一个cos的地址上，虽然丑陋但是可以解决问题
k8s域名问题
在部署过程中，由于k8内部的ip漂移问题，因而希望能够使用k8内部的dns域名将代理转发的域名固定住。k8s中的dns有两个常用的插件，即：KubeDNS和CoreDNS，在Kubernetes 1.12之后，CoreDNS成为其默认的DNS服务器，其配置在/etc/resolv.conf可以进行修改，主要有三个配置的关键字
-
nameserver 定义DNS服务器的IP地址
-
search 定义域名的搜索列表，当查询域名中包含.的数量少于options.ndots的值时，会依次匹配列表中的每个值
-
options 定义域名查找时的配置信息
我们进入启动的Pod中看一下它的resolv.conf
nameserver 11.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options nodts:5
这里我没有做其他的操作，因而正常来说应该是可以使用的是默认的k8s的dns策略，即使用默认的ClusterFirst的策略
问题：正常来说应该能够找到对应的域名，结果却没有找到，因而思考是不是端口的映射问题
k8s端口映射问题
k8s作为一个优雅的分布式资源调度框架，其优秀的架构设计可以对不同的核心对象（例如：Pod，Service，RC）进行调度和操作，整个k8s架构，通过命令行kubectl操作API Server，利用其包装的api去操作访问权限控制、注册、etcd等行为，其下层通过Scheduler和Controller Manager来实现调度和管理资源的能力，这里整个service的代理能力是通过kube proxy来实现的，从而实现反向代理和负载均衡
这里在前端写的yaml里配置了service和deployment
apiVersion: v1
kind: Service
metadata:
name: bff
spec:
ports:
- port: 80
selector:
app: bff
---
apiVersion: app/v1
kind: Deployment
metadata:
name: bff
labels:
app: bff
spec:
replicas: 1
selector:
matchLabels:
app: bff
template:
metadata:
labels:
app: bff
spec:
containers:
- name: bff
image: harbor.dcos.ncmp.unicom.local/fe/bff:1.0
imagePullPolicy: Always
ports:
- containerPort: 80
问题：这里在创建clb的时候会重新再简历一个service，配置的新的8148端口和之前yaml里写的80端口是不一样的，如果单纯的只是通过ip进行查找是不存在找不到的问题，但是由于是通过dns进行查找，在上一部分中k8s内部默认的dns策略是ClusterFirst的策略，因而这里会出现两个名称和端口恰好没有对上的状况，本质上是两个service同时调度了同一个pod中的资源
总结
前端工程的稳定生产作为前端工程化的重要考量要素，我们不仅要考虑传统的前端部分工程化相关基建，同时也要对性能监控、日志收集等问题定位做到精准控制，链路追踪，当然这些也需要前端懂得更多后端、云及容器化相关的内容，未来前端发展可能会朝着”端+云“的模式发展，做好全方位的学习才是未来大前端的必由之路，共勉！！！
