怎样运用docker部署前端利用的要领步骤-百分百源码网

怎样运用docker部署前端利用的要领步骤

发布时间：05/13 来源：未知浏览：关键词：

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

此刻很强调 devops 的理念，我把 devops 五个大字放在电脑桌面上，格物致知了一天。恍然大悟，devops 的意思就是写一个 Dockerfile 去跑利用(开玩笑。

这里介绍怎样运用 Docker 部署前端利用。千里之行，始于足下，足下的意思就是，先让它能够跑起来。

先让它跑起来

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

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

介绍完部署流程后，简略写一个 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 装包。

对于两者的区别可以参考文档 https://docs.npmjs.com/files/package.json.html#dependencies

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 <repo> 的缓存此类

参考官方文档 https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache

多阶段构建

得益于缓存，此刻镜像构建工夫已经快了不少。但是，镜像的体积照旧过于巨大，也会添加每次的部署工夫
考虑下每次 CI 部署的流程

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

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

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

对于镜像体积的过大，很大一局部是由于node_modules 污名昭著的体积

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

参考官方文档 https://docs.docker.com/develop/develop-images/multistage-build/

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

以上就是本文的全部内容，但愿对大家的学习有所帮忙，也但愿大家多多支撑脚本之家。

打赏