技术标签: kubernetes java 运维 devops docker
关注公众号 前端开发博客,领27本电子书
回复加群,自助秒进前端群
前端一说起刀耕火种,那肯定紧随着前端工程化这一话题。随着 react
/vue
/angular
,es6+
,webpack
,babel
,typescript
以及 node
的发展,前端已经在逐渐替代过去 script
引 cdn
开发的方式了,掀起了工程化这一大浪潮。得益于工程化的发展与开源社区的良好生态,前端应用的可用性与效率得到了很大提高。
前端以前是刀耕火种,那前端应用部署在以前也是刀耕火种。那前端应用部署的发展得益于什么,随前端工程化带来的副产品?
这只是一部分,而更重要的原因是 devops
的崛起。
为了更清晰地理解前端部署的发展史,了解部署时运维和前端(或者更广泛地说,业务开发人员)的职责划分,当每次前端部署发生改变时,可以思考两个问题
缓存,前端应用中 http 的 response header
由谁来配?得益于工程化发展,可以对打包后得到带有 hash 值的文件可以做永久缓存
跨域,/api
的代理配置由谁来配?在开发环境前端可以开个小服务,启用 webpack-dev-server
配置跨域,那生产环境呢
这两个问题都是前端面试时的高频问题,但话语权是否掌握在前端手里
时间来到 React
刚刚发展起来的这一年,这时已经使用 React
开发应用,使用 webpack
来打包。但是前端部署,仍是刀耕火种
本篇文章要求你有一定的 Docker,DevOps 以及前端工程化的知识储备。如果没有的话,本系列文章以及 个人服务器运维指南[1] 中的 Docker 部分会对你有所帮助。
一台跳板机
一台生产环境服务器
一份部署脚本
前端调着他的 webpack
,开心地给运维发了部署邮件并附了一份部署脚本,想着第一次不用套后端的模板,第一次前端可以独立部署。想着自己基础盘进一步扩大,前端不禁开心地笑了
运维照着着前端发过来的部署邮件,一遍又一遍地拉着代码,改着配置,写着 try_files
, 配着 proxy_pass
。
这时候,前端静态文件由 nginx
托管,nginx
配置文件大致长这个样子
server {
listen 80;
server_name shanyue.tech;
location / {
# 避免非root路径404
try_files $uri $uri/ /index.html;
}
# 解决跨域
location /api {
proxy_pass http://api.shanyue.tech;
}
# 为带 hash 值的文件配置永久缓存
location ~* \.(?:css|js)$ {
try_files $uri =404;
expires 1y;
add_header Cache-Control "public";
}
location ~ ^.+\..+$ {
try_files $uri =404;
}
}
不过...经常有时候跑不起来
运维抱怨着前端的部署脚本没有标好 node
版本,前端嚷嚷着测试环境没问题
这个时候运维需要费很多心力放在部署上,甚至测试环境的部署上,前端也要费很多心力放在运维如何部署上。这个时候由于怕影响线上环境,上线往往选择在深夜,前端和运维身心俱疲
不过向来如此
鲁迅说,向来如此,那便对么。
这个时候,无论跨域的配置还是缓存的配置,都是运维来管理,运维不懂前端。但配置方式却是前端在提供,而前端并不熟悉 nginx
docker
的引进,很大程度地解决了部署脚本跑不了这个大 BUG。dockerfile
即部署脚本,部署脚本即 dockerfile
。这也很大程度缓解了前端与运维的摩擦,毕竟前端越来越靠谱了,至少部署脚本没有问题了 (笑
这时候,前端不再提供静态资源,而是提供服务,一个 http
服务
前端写的 dockerfile
大致长这个样子
FROM node:alpine
# 代表生产环境
ENV PROJECT_ENV production
# 许多 package 会根据此环境变量,做出不同的行为
# 另外,在 webpack 中打包也会根据此环境变量做出优化,但是 create-react-app 在打包时会写死该环境变量
ENV NODE_ENV production
WORKDIR /code
ADD . /code
RUN npm install && npm run build && npm install -g http-server
EXPOSE 80
CMD http-server ./public -p 80
单单有 dockerfile
也跑不起来,另外前端也开始维护一个 docker-compose.yaml
,交给运维执行命令 docker-compose up -d
启动前端应用。前端第一次写 dockerfile
与 docker-compose.yaml
,在部署流程中扮演的角色越来越重要。想着自己基础盘进一步扩大,前端又不禁开心地笑了
version: "3"
services:
shici:
build: .
expose:
- 80
运维的 nginx
配置文件大致长这个样子
server {
listen 80;
server_name shanyue.tech;
location / {
proxy_pass http://static.shanyue.tech;
}
location /api {
proxy_pass http://api.shanyue.tech;
}
}
运维除了配置 nginx
之外,还要执行一个命令: docker-compose up -d
这时候再思考文章最前面两个问题
缓存,由于从静态文件转换为服务,缓存开始交由前端控制 (但是镜像中的 http-server
不太适合做这件事情)
跨域,跨域仍由运维在 nginx
中配置
前端可以做他应该做的事情中的一部分了,这是一件令人开心的事情
当然,前端对于 dockerfile
的改进也是一个慢慢演进的过程,那这个时候镜像有什么问题呢?
构建镜像体积过大
构建镜像时间过长
这中间其实经历了不少坎坷,其中过程如何,详见我的另一篇文章: 如何使用 docker 部署前端应用[2]。
其中主要的优化也是在上述所提到的两个方面
构建镜像体积由 1G+ 变为 10M+
构建镜像时间由 5min+ 变为 1min (视项目复杂程度,大部分时间在构建时间与上传静态资源时间)
FROM node:alpine as builder
ENV PROJECT_ENV production
ENV NODE_ENV production
WORKDIR /code
ADD package.json /code
RUN npm install --production
ADD . /code
# npm run uploadCdn 是把静态资源上传至 oss 上的脚本文件,将来会使用 cdn 对 oss 加速
RUN npm run build && npm run uploadCdn
# 选择更小体积的基础镜像
FROM nginx:alpine
COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
COPY --from=builder code/public/static /usr/share/nginx/html/static
那它怎么做的
先 ADD package.json /code
, 再 npm install --production
之后 Add
所有文件。充分利用镜像缓存,减少构建时间
多阶段构建,大大减小镜像体积
另外还可以有一些小优化,如
npm cache
的基础镜像或者 npm
私有仓库,减少 npm install
时间,减小构建时间
npm install --production
只装必要的包
前端看着自己优化的 dockerfile
,想着前几天还被运维吵,说什么磁盘一半的空间都被前端的镜像给占了,想着自己节省了前端镜像几个数量级的体积,为公司好像省了不少服务器的开销,想着自己的基础盘进一步扩大,又不禁开心的笑了
这时候再思考文章最前面两个问题
缓存,缓存由前端控制,缓存在 oss 上设置,将会使用 cdn 对 oss 加速。此时缓存由前端写脚本控制
跨域,跨域仍由运维在 nginx
中配置
此时前端成就感爆棚,运维呢?运维还在一遍一遍地上线,重复着一遍又一遍的三个动作用来部署
拉代码
docker-compose up -d
重启 nginx
运维觉得再也不能这么下去了,于是他引进了 CI
: 与现有代码仓库 gitlab
配套的 gitlab ci
CI
,Continuous Integration
,持续集成
CD
,Continuous Delivery
,持续交付
重要的不是 CI/CD
是什么,重要的是现在运维不用跟着业务上线走了,不需要一直盯着前端部署了。这些都是 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
安全检查,甚至多特性多环境部署,我将会在我以后的文章写这部分事情
我的一个服务器渲染项目 shfshanyue/shici[3] 以前在我的服务器中就是以 docker
/docker-compose/gitlab-ci
的方式部署,有兴趣的可以看看它的配置文件
shfshanyue/shici:Dockerfile[4]
shfshanyue/shici:docker-compose.yml[5]
shfshanyue/shici:gitlab-ci.yml[6]
如果你有个人服务器的话,也建议你做一个自己感兴趣的前端应用和配套的后端接口服务,并且配套 CI/CD
把它部署在自己的自己服务器上
而你如果希望结合 github
做 CI/CD
,那可以试一试 github
+ github action
另外,也可以试试 drone.ci
,如何部署可以参考我以前的文章: github 上持续集成方案 drone 的简介及部署[7]
随着业务越来越大,镜像越来越多,docker-compose
已经不太能应付,kubernetes
应时而出。这时服务器也从 1 台变成了多台,多台服务器就会有分布式问题
一门新技术的出现,在解决以前问题的同时也会引进复杂性。
k8s 部署的好处很明显: 健康检查,滚动升级,弹性扩容,快速回滚,资源限制,完善的监控等等
那现在遇到的新问题是什么?
构建镜像的服务器,提供容器服务的服务器,做持续集成的服务器是一台!
需要一个私有的镜像仓库,这是运维的事情,harbor
很快就被运维搭建好了,但是对于前端部署来说,复杂性又提高了
先来看看以前的流程:
前端配置 dockerfile
与 docker-compose
生产环境服务器的 CI runner
拉代码(可以看做以前的运维),docker-compose up -d
启动服务。然后再重启 nginx
,做反向代理,对外提供服务
以前的流程有一个问题: 构建镜像的服务器,提供容器服务的服务器,做持续集成的服务器是一台!,所以需要一个私有的镜像仓库,一个能够访问 k8s
集群的持续集成服务器
流程改进之后结合 k8s
的流程如下
前端配置 dockerfile
,构建镜像,推到镜像仓库
运维为前端应用配置 k8s
的资源配置文件,kubectl apply -f
时会重新拉取镜像,部署资源
运维问前端,需不需要再扩大下你的基础盘,写一写前端的 k8s
资源配置文件,并且列了几篇文章
使用 k8s 部署你的第一个应用: Pod,Deployment 与 Service[8]
使用 k8s 为你的应用配置域名: Ingress[9]
使用 k8s 为你的域名加上 https[10]
前端看了看后端十几个 k8s 配置文件之后,摇摇头说算了算了
这个时候,gitlab-ci.yaml
差不多长这个样子,配置文件的权限由运维一人管理
deploy:
stage: deploy
only:
- master
script:
- docker build -t harbor.shanyue.tech/fe/shanyue
- docker push harbor.shanyue.tech/fe/shanyue
- kubectl apply -f https://k8s-config.default.svc.cluster.local/shanyue.yaml
tags:
- shell
这时候再思考文章最前面两个问题
缓存,缓存由前端控制
跨域,跨域仍由运维控制,在后端 k8s
资源的配置文件中控制 Ingress
这时前端与运维已不太往来,除了偶尔新起项目需要运维帮个忙以外
但好景不长,突然有一天,前端发现自己连个环境变量都没法传!于是经常找运维修改配置文件,运维也不胜其烦
于是有了 helm
,如果用一句话解释它,那它就是一个带有模板功能的 k8s
资源配置文件。作为前端,你只需要填参数。更多详细的内容可以参考我以前的文章 使用 helm 部署 k8s 资源[11]
假如我们使用 bitnami/nginx[12] 作为 helm chart
,前端可能写的配置文件长这个样子
image:
registry: harbor.shanyue.tech
repository: fe/shanyue
tag: 8a9ac0
ingress:
enabled: true
hosts:
- name: shanyue.tech
path: /
tls:
- hosts:
- shanyue.tech
secretName: shanyue-tls
# livenessProbe:
# httpGet:
# path: /
# port: http
# initialDelaySeconds: 30
# timeoutSeconds: 5
# failureThreshold: 6
#
# readinessProbe:
# httpGet:
# path: /
# port: http
# initialDelaySeconds: 5
# timeoutSeconds: 3
# periodSeconds: 5
这时候再思考文章最前面两个问题
缓存,缓存由前端控制
跨域,跨域由后端控制,配置在后端 Chart 的配置文件 values.yaml
中
到了这时前端和运维的职责所在呢?
前端需要做的事情有:
写前端构建的 dockerfile
,这只是一次性的工作,而且有了参考
使用 helm
部署时指定参数
那运维要做的事情呢
提供一个供所有前端项目使用的 helm chart
,甚至不用提供,如果运维比较懒那就就使用 bitnami/nginx[13] 吧。也是一次性工作
提供一个基于 helm
的工具,禁止业务过多的权限,甚至不用提供,如果运维比较懒那就直接使用 helm
这时前端可以关注于自己的业务,运维可以关注于自己的云原生,职责划分从未这般清楚
后来运维觉得前端应用的本质是一堆静态文件,较为单一,容易统一化,来避免各个前端镜像质量的参差不齐。于是运维准备了一个统一的 node
基础镜像,做了一个前端统一部署平台,而这个平台可以做什么呢
CI/CD
: 当你 push 代码到仓库的特定分支会自动部署
http headers
: 你可以定制资源的 http header
,从而可以做缓存优化等
http redirect/rewrite
: 如果一个 nginx
,这样可以配置 /api
,解决跨域问题
hostname
: 你可以设置域名
CDN
: 把你的静态资源推到 CDN
https
: 为你准备证书
Prerender
: 结合 SPA
,做预渲染
前端再也不需要构建镜像,上传 CDN 了,他只需要写一份配置文件就可以了,大致长这个样子
build:
command: npm run build
dist: /dist
hosts:
- name: shanyue.tech
path: /
headers:
- location: /*
values:
- cache-control: max-age=7200
- location: assets/*
values:
- cache-control: max-age=31536000
redirects:
- from : /api
to: https://api.shanyue.tech
status: 200
此时,前端只需要写一份配置文件,就可以配置缓存,配置 proxy
,做应该属于前端做的一切,而运维也再也不需要操心前端部署的事情了
前端看着自己刚刚写好的配置文件,怅然若失的样子...
不过一般只有大厂会有这么完善的前端部署平台,如果你对它有兴趣,你可以尝试下 netlify
,可以参考我的文章: 使用 netlify 部署你的前端应用[14]
大部分前端应用本质上是静态资源,剩下的少部分就是服务端渲染了,服务端渲染的本质上是一个后端服务,它的部署可以视为后端部署
后端部署的情况更为复杂,比如
配置服务,后端需要访问敏感数据,但又不能把敏感数据放在代码仓库。你可以在 environment variables
, consul
或者 k8s configmap
中维护
上下链路服务,你需要依赖数据库,上游服务
访问控制,限制 IP,黑白名单
RateLimit
等等
我将在以后的文章分享如何在 k8s 中部署一个后端
随着 devops
的发展,前端部署越来越简单,可控性也越来越高,建议所有人都稍微学习一下 devops
的东西。
[1]
个人服务器运维指南: https://github.com/shfshanyue/blog#%E4%B8%AA%E4%BA%BA%E6%9C%8D%E5%8A%A1%E5%99%A8%E8%BF%90%E7%BB%B4%E6%8C%87%E5%8D%97
[2]如何使用 docker 部署前端应用: https://juejin.im/post/5c83cbaa6fb9a04a0f65fdaa
[3]shfshanyue/shici: https://github.com/shfshanyue/shici
[4]shfshanyue/shici:Dockerfile: https://github.com/shfshanyue/shici/blob/master/Dockerfile
[5]shfshanyue/shici:docker-compose.yml: https://github.com/shfshanyue/shici/blob/master/docker-compose.yml
[6]shfshanyue/shici:gitlab-ci.yml: https://github.com/shfshanyue/shici/blob/master/.gitlab-ci.yml
[7]github 上持续集成方案 drone 的简介及部署: https://juejin.im/post/5dc0b563f265da4cef190b8a
[8]使用 k8s 部署你的第一个应用: Pod,Deployment 与 Service: https://juejin.im/post/5db8c2b46fb9a020256692dc
[9]使用 k8s 为你的应用配置域名: Ingress: https://juejin.im/post/5db8da4b6fb9a0204520b310
[10]使用 k8s 为你的域名加上 https: https://juejin.im/post/5db8d94be51d4529f73e2833
[11]使用 helm 部署 k8s 资源: https://juejin.im/post/5dbf7909f265da4d4b5fe7b4
[12]bitnami/nginx: https://hub.helm.sh/charts/bitnami/nginx
[13]bitnami/nginx: https://hub.helm.sh/charts/bitnami/nginx
[14]使用 netlify 部署你的前端应用: https://shanyue.tech/op/deploy-fe-with-netlify.html
往期推荐:
另外欢迎大家围观我的朋友圈,搞搞技术,吹吹牛逼。关注我,秒添加,回复加群,可以进入 500人前端群。
转发文章并关注公众号:前端开发博客,回复 1024,领取前端进阶资料
回复「电子书」领取27本精选电子书
回复「加群」加入前端大神交流群,一起学习进步
回复「面试」获取 面试 精选文章
分享和在看就是最大的支持️
文章浏览阅读167次。在jQuery中可以通过四个方法来实现元素的淡入淡出,这四个方法分别是fadeIn()、fadeOut()、fadeToggle()以及fadeTo(),本文通过实例来为你讲解如何在jQuery中使用这四个方法。_在jquery中,如果希望实现元素淡出效果应调用的方法是
文章浏览阅读498次,点赞2次,收藏2次。这是因为要在 ArcGIS Pro 中使用 Excel 文件,必须从Microsoft 下载中心 下载并安装 Microsoft Access Database Engine 2016 Redistributable。如果你使用的是 ArcGIS Pro 2.5 或更高版本,请选择与您当前安装的 Microsoft 应用程序匹配的下载。如果你使用的是 ArcGIS Pro 2.4,请选择 32 位驱动程序下载。在选择输入表时,可能会提示未安装所需的 Microsoft 驱动程序。_arcgispro未安装所需的microsoft驱动程度
文章浏览阅读1k次,点赞13次,收藏26次。CSRF,XSS,SQL注入,URL跳转漏洞,点击挟持等WEB安全问题_挑战url劫持
文章浏览阅读1.5k次。本文首发于http://www.abcdsxg.cn/free/net/562虚拟信用卡首先介绍一下虚拟信用卡(Virtual Credit Card),顾名思义,虚拟就是没有实体卡,一般都是在提供服务的网站上注册后由服务商生成提供卡号、有效期、安全码之类的信息,此类平台是由金融市场行为监管局授权及监管,并且有相关银行组织发的执照,所以在安全性上是有一定保障的!虚拟信用卡一般有VISA(4..._谷歌开发者没卡怎么办
文章浏览阅读110次。java毕业设计闸口社区管理系统Mybatis+系统+数据库+调试部署。springboot疫情期间中小学生作业线上管理系统设计与实现。springcloud基于微服务的家居体验平台的设计与实现。JSP物流仓储仓库管理系统的设计与实现sqlserver。ssm医疗机构药房管理系统软件开发-后台软件设计与实现。springboot基于web的学校工资管理系统。ssm基于Web的精品课程网站的设计与实现。_人闸口机读取信息 后台管理系统架构
文章浏览阅读533次。EasyUI为TreeGrid的已勾选节点,未勾选节点,只勾选部分子节点的父节点分别添加了三个不同的样式,如下:样式一:tree-checkbox2 有子节点被选中样式二:tree-checkbox1 节点被选中样式三:tree-checkbox0 节点未选中那么,我们就可以依据这三个样式分别取到所有已勾选的主键值了,为方便使用,我们写成TreeGrid的扩展方法,代码如下: $.exten..._treegrid checknode
文章浏览阅读1.3w次,点赞9次,收藏62次。可以同时显示相关性和显著性的热图我们最终绘制的是如下图所示首先配置的文件如下所示行为样本名,列为基因名的一个表达谱读取文件data = read.table("cor.txt",header=T,sep="\t")data1<-data[,-1]#计算相关性,默认用的是pearson相关性计算cor_matr = cor(data1)cor_matr#保存相关性..._chart.correlation
文章浏览阅读6.8k次。目录shell远程执行前提条件:对于简单的命令:对于脚本的方式:SSH命令格式主要参数说明ssh控制远程主机,远程执行命令步骤准备工作基于公私钥认证远程登录可能存在的不足ssh 执行远程命令格式打开远程shellssh的-t参数在多个节点上并行执行命令的三种方法使用bash执行命令∞(Execute commands using Bash∞)使用执行命令clustershell∞(Execute commands usingclust..._shell脚本远程执行shell指令
文章浏览阅读371次,点赞3次,收藏4次。探索DroidLord:一款强大的Android逆向工程工具项目地址:https://gitcode.com/likia/DroidLordDroidLord 是一个专为Android开发者和安全研究人员设计的开源逆向工程框架。它利用Java和Python的强大功能,帮助用户深入理解APK文件的内部工作机制,从而进行代码审计、漏洞发现或应用优化。项目简介DroidLord的核心在于其模块化...
文章浏览阅读670次。前言此为完整版随机图片API介绍,若仅需要随机背景图片,请点击:接口调用地址12345#https调用https://img.xjh.me/random_img.php#http调用http://img.xjh.me/random_img.php开发状态增加图片分类,背景->ACG,背景->环境背景,调用方法:GET参数:type=bg&ctype=acg/nature——更新..._随机图片api接口
文章浏览阅读3.2w次,点赞6次,收藏21次。在使用pvcreate, vgcreate,lvextend等命令拓展分区的时候,发现出现了找不到逻辑块的问题,最后问题是现在的文件格式是xfs,resize2fs命令是读取不了的,故而查找到了需要使用xfs_growfs lvextend之后显示lv空间已经增加 然后我需要同步文件系统,一开始使用resize2fs后来_xfs_growfs命令找不到
文章浏览阅读2.5w次,点赞10次,收藏45次。如果python想要操作串口,需要首先先安装pyserial,在不同的系统上安装python serial模块的方法不一样,在windowns系统上,你可以直接直接通过pip install pyserial去安装pyserial,但是在linux系统上你需要把pyserial的源码包下载下来,解压,然后执行安装命令。1,在windows系统上的操作:C:\Users\test>..._python安装serial模块