怎么使用docker部署前端应用

这篇“怎么使用docker部署前端应用”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“怎么使用docker部署前端应用”文章吧。

成都创新互联公司专业为企业提供临桂网站建设、临桂做网站、临桂网站设计、临桂网站制作等企业网站建设、网页设计与制作、临桂企业网站模板建站服务，10年临桂做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

docker 变得越来越流行，它可以轻便灵活地隔离环境，进行扩容，方便运维管理。对开发者也更方便开发，测试与部署。
最重要的是， 当你面对一个陌生的项目，你可以照着 dockerfile，甚至不看文档(文档也不一定全，全也不一定对)就可以很快让它在本地跑起来。

先让它跑起来

首先，简单介绍一下一个典型的前端应用部署流程

1. npm install, 安装依赖

2. npm run build，编译，打包，生成静态资源

3. 服务化静态资源

介绍完部署流程后，简单写一个 dockerfile

from node:alpine

# 代表生产环境
env project_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

现在这个前端服务已经跑起来了。接下来你可以完成部署的其它阶段了。一般情况下，以下就成了运维的工作了，不过，拓展自己的知识边界总是没错的。

• 使用 nginx 或者 traefik 做反向代理

• 使用 kubernetes 或者 compose 等做编排。

• 使用 gitlab ci 或者 drone ci 等做 ci/cd

这时镜像存在有两个问题，导致每次部署时间过长，不利于产品的快速交付

• 构建镜像时间过长

• 构建镜像大小过大，1g+

从 dependencies 和 devdependencies 下手

陆小凤说过，一个前端程序员若是每天工作八个小时，至少有两个小时是白白浪费了的。一个小时用来 npm install，另一个小时用来 npm run build。

对于每次部署，如果能够减少无用包的下载，便能够节省很多镜像构建时间。eslint，mocha，chai 等代码风格测试模块可以放到 devdependencies 中。在生产环境中使用 npm install --production 装包。

关于两者的区别可以参考文档

from node:alpine

env project_env production
workdir /code
add . /code
run npm install --production && npm run build && npm install -g http-server
expose 80

cmd http-server ./public -p 80

好像是快了那么一点点。

我们注意到，相对于项目的源文件来讲，package.json 是相对稳定的。如果没有新的安装包需要下载，则再次构建镜像时，无需重新装包。则可以在 npm install 上节省一半的时间。

利用镜像缓存

对于 add 来讲，如果需要添加的内容没有发生变化，则可以利用缓存。把 package.json 与源文件分隔开写入镜像是一个很好的选择。目前，如果没有新的安装包更新的话，可以节省一半时间

from node:alpine

env project_env production

# http-server 不变动也可以利用缓存
run npm install -g http-server

workdir /code

add package.json /code
run npm install --production

add . /code
run npm run build
expose 80

cmd http-server ./public -p 80

关于利用缓存有更多细节，需要特别注意一下，如 run git clone 的缓存此类

参考官方文档

多阶段构建

得益于缓存，现在镜像构建时间已经快了不少。但是，镜像的体积依旧过于庞大，也会增加每次的部署时间
考虑下每次 ci 部署的流程

1. 在构建服务器构建镜像

2. 把镜像推至镜像仓库服务器，

3. 在生产服务器拉取镜像，启动容器

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

即使，构建服务器与生产服务器在同一节点下，没有延时的问题。减少镜像体积也能够节省磁盘空间

关于镜像体积的过大，很大一部分是因为node_modules 臭名昭著的体积

但最后我们只需要 public 文件夹下的内容，对于源文件以及node_modules下文件，占用体积过大且不必要，造成浪费。
此时可以利用 docker 的多阶段构建，仅来提取编译后文件

参考官方文档

from node:alpine as builder

env project_env production

# http-server 不变动也可以利用缓存
workdir /code

add package.json /code
run npm install --production

add . /code
run npm run build

# 选择更小体积的基础镜像
from nginx:alpine
copy --from=builder /code/public /usr/share/nginx/html

此时，镜像体积从 1g+ 变成了 50m+

使用 cdn

分析一下 50m+ 的镜像体积，nginx:alpine 的镜像是16m，剩下的40m是静态资源。

如果把静态资源给上传到 cdn，则没有必要打入镜像了，此时镜像大小会控制在 20m 以下

关于静态资源，可以分类成两部分

• /static，此类文件在项目中直接引用根路径，打包时复制进 /public 下，需要被打入镜像

• /build，此类文件需要 require 使用，会被 webpack 打包并加 hash 值，并可以通过 publicpath 修改资源地址。可以把此类文件上传至 cdn，并加上永久缓存，不需要打入镜像

from node:alpine as builder

env project_env production

# http-server 不变动也可以利用缓存
workdir /code

add package.json /code
run npm install --production

add . /code
# npm run uploadcdn 是把静态资源上传至 cdn 上的脚本文件
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

以上就是关于“怎么使用docker部署前端应用”这篇文章的内容，相信大家都有了一定的了解，希望小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注创新互联行业资讯频道。