关于nginx:前端静态服务踩坑实践

随着前端我的项目的增大，越来越多时候会把动动态资源进行拆散部署，对于拆散部署时经常波及到代理转发的问题，专网我的项目次要应用 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 的地址上，尽管俊俏然而能够解决问题

在部署过程中，因为 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 作为一个优雅的分布式资源调度框架，其优良的架构设计能够对不同的外围对象（例如：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 架构解析
四层、七层负载平衡的区别

关于nginx:前端静态服务踩坑实践

前言

背景

案例

环境一致性问题

k8s 域名问题

k8s 端口映射问题

总结

参考