乐趣区

关于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 的地址上,尽管俊俏然而能够解决问题

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 架构解析
  • 四层、七层负载平衡的区别
退出移动版