前端部署发展史

带着两个问题去思考:

1 缓存: 前端中的http的response header是由谁来配置?

2 跨域: /api的代理配置由谁来配置?在开发环境前端可以开个小服务,启用webpack-dev-server配置跨域,那在生产环境呢?

几个概念

跳板机:跳板机属于内控堡垒机范畴,是一种用于单点登陆的主机应用系统。2000年左右,高端行业用户为了对运维人员的远程登录进行集中管理,会在机房里部署跳板机。跳板机就是一台服务器,维护人员在维护过程中,首先要统一登录到这台服务器上,然后从这台服务器再登录到目标设备进行维护。但跳板机并没有实现对运维人员操作行为的控制和审计,使用跳板机过程中还是会有误操作、违规操作导致的操作事故,一旦出现操作事故很难快速定位原因和责任人。此外,跳板机存在严重的安全风险,一旦跳板机系统被攻入,则将后端资源风险完全暴露无遗。同时,对于个别资源(如telnet)可以通过跳板机来完成一定的内控,但是对于更多更特殊的资源(ftp、rdp等)来讲就显得力不从心了。

运维堡垒机: 人们逐渐认识到跳板机的不足,需要更新、更好的安全技术理念来实现运维操作管理,需要一种能满足角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制要求,并生成一些统计报表配合管理规范来不断提升IT内控的合规性的产品。在这些理念的指导下,2005年前后,运维堡垒机开始以一个独立的产品形态被广泛部署,有效地降低了运维操作风险,使得运维操作管理变得更简单、更安全。

现在堡垒机产品已成熟,各家产品功能基本一致。早几年这还是个比较有前景的行业,但后来越来越多的人看到了这个机会,很多优秀的工程师也出来创业做类似的堡垒机产品。但主流的总是那么几家,如:思福迪、帕拉迪、尚思卓越、科友、齐治(微医线上用的就是齐治)、极地等,这些都是目前行业里做的专业且受到企业用户好评的厂商,但每家厂商的产品所关注的侧重又有所差别。各企业在选购的时候,除了仔细研究产品技术指标是否可以满足自己的需求外,还应该着重考虑产品的交互性、易用性、性价比、维护成本低、产品自身安全性等等。堡垒机作为单点故障点,自身安全性很重要。对于大数据量的企业,还应该考虑产品可扩展性,毕竟大数据中心的信息系统会越来越复杂。

server {
    listen 80;
    server_name xiaoyu.work;
}
# 避免非root路径404
location / {
    try_files $uri $uri/ /index.html;
}
# 解决跨域
location /api {
    proxy_pass http://api.xiaoyu.work;
}
# 为带有hash值的文件配置永久缓存(js/css静态资源)
location ~* \.(?:css|js)$ {
    try_files $uri = 404;
    expires 1y;
    add_header Cache-Control "public";
}

location ~ ^.+\..+$ {
    try_files &uri =404;
}

问题: 脚本经常跑不起来 运维抱怨着前端的部署脚本没有标好 node 版本,前端嚷嚷着测试环境没问题。 but why? 为什么会跑不起来?

使用docker构建镜像(引入docker)

https://juejin.im/book/5b7ba116e51d4556f30b476c/section/5b83817ae51d4538b406d852#heading-5

docker知识待整理…

dockerfile就是部署脚本,部署脚本就是dockfile 很大程度上缓解了前端运维的摩擦,至少部署脚本没问题了( 为什么?)

这时候,前端不再是提供静态资源了,而是提供一个http服务。 (服务?)

此时: 缓存开始交由前端控制(但是镜像中的http-server不太适合做这件事情)

跨域: 仍然在运维nginx中配置

CI/CD 与gitlab

解放运维的ci/cd

ci: Continuous Integration: 持续集成

cd: Continuous Delivery: 持续交付

重要的不是ci/cd是什么,重要的是现在运维不用跟着业务上线走了,不需要一直盯着前端部署了,这些都是ci/cd的事情了。

.gitlab-ci.yml是gitlab的ci配置文件。

deploy: 
    stage: deploy
    only:
        - master
    script:
        - docker-compose up --build -d

    tags: 
        -shell

ci/cd不仅仅更加解放了业务项目的部署,也在交付之前大大加强了业务代码的质量,它可以用来lint test package 安全检查,甚至

多特性多环境部署。

如果你有一台个人服务器的话,如果希望结合github做ci cd 可以试一试github + github action,或者drone.ci

使用k8s

k8s 知识待整理…

随着业务越来越大,镜像越来越多,docker-compose已经不太能应付,kubernetes应时而出,此时一台服务器从一台变成了多台,多台

服务器就会有多台服务器的分布式问题。

一个重要的角色

SRE: site reliability engineer 网站可靠性工程师,是软件工程师和系统管理员的结合,一个sre工程师基本上需要掌握很多知识

算法、数据结构、编程能力、网络编程、分布式系统、可扩展架构、故障排除。

SRE起源于国外大型互联网公司,直接掌管着互联网公司的机器和服务,保证网站不宕机是他们的使命。SRE基本是从软件研发工程师转型,有很强

的编程算法能力,同时具备系统管理员的技能,熟悉网络架构等,是一个要求非常高的职业。 [1]

大部分人理解SRE等于传统运维工程师(OP)或者系统管理员(SA),实则不然,这两类角色离一名合格的SRE还有太大的差距,完全无法匹配得上这

个称号。

在国内,只有少数几家顶尖互联网公司才会出现真正的SRE。

nginx: 作为http服务器接受来自internet的请求,并将请求按配置的规则转发给对应的端口

nodejs: 在云主机上提供js的运行环境

pm2: node应用进程管理器

git: 将git仓库的代码拉取到云主机上

发布

前后端分离中的一个要点就是发布分离,如果你的前端发布还在依赖后端发布,那就没法聊了。

先让它跑起来

  • npm install 安装依赖
  • npm run build 编译、打包、生成静态资源
  • 服务化静态资源

(需要学习docker)

每次ci部署的流程

  • 在构建服务器构建镜像
  • 把镜像推至镜像仓库服务器
  • 在生产服务器拉取镜像,启动容器

显而易见,镜像体积过大造成传输效率低下,增加了每次部署的延时。

堡垒机为访问集群限定一个入口,方便了权限的控制和监控

在传统的it环境中,安全边界是非常明确的,我们可以利用传统的堡垒机、防火墙来对服务等应用系统进行严格的

访问控制,在业务迁入云环境之后,传统堡垒机已经不再适用。

在分布式部署中使用容器技术是一个方向,Docker是这个方向上跑得最快也最完美的运动员。