前端静态服务踩坑实践

前言

随着前端项目的增大，越来越多时候会把动静态资源进行分离部署，对于分离部署时常常涉及到代理转发的问题，专网项目主要使用 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中的资源

总结

前端工程的稳定生产作为前端工程化的重要考量要素，我们不仅要考虑传统的前端部分工程化相关基建，同时也要对性能监控、日志收集等问题定位做到精准控制，链路追踪，当然这些也需要前端懂得更多后端、云及容器化相关的内容，未来前端发展可能会朝着”端+云“的模式发展，做好全方位的学习才是未来大前端的必由之路，共勉！！！

参考

• IPVS从入门到精通kube-proxy实现原理
• KubeDNS 和 CoreDNS
• 使用 CoreDNS 来应对 DNS 污染
• 我花了10个小时，写出了这篇K8S架构解析
• 四层、七层负载均衡的区别