武进做网站,外贸简单网站建设,网站怎么做来流量吗,网站建设规模将你的前端应用打包成docker镜像并部署到服务器#xff1f;仅需一个脚本搞定1.前言前段时间#xff0c;自己搞了个阿里云的服务器。想自己在上面折腾#xff0c;但是不想因为自己瞎折腾而污染了现有的环境。毕竟#xff0c;现在的阿里云已经没有免费的快照服务了。要想还原… 将你的前端应用打包成docker镜像并部署到服务器仅需一个脚本搞定1.前言前段时间自己搞了个阿里云的服务器。想自己在上面折腾但是不想因为自己瞎折腾而污染了现有的环境。毕竟现在的阿里云已经没有免费的快照服务了。要想还原的话最简单的办法就是重新装系统。而一旦重装之前的搭建的所有环境就都白搭了。 再加上之前本身就想引入docker所以就打算利用docker容器来部署这次的前端应用。 2.构建前端应用在打包之前首先需要一个可正常运行的前端应用。这个可以使用umi或者create-react-app来构建。 3.nginx的默认配置文件然后需要在项目中加上默认nginx配置文件。 server { listen 80;
server_name localhost;location / {root /usr/share/nginx/html;index index.html index.htm;try_files $uri $uri/ /index.html;
} }4.编写本地构建脚本4.1. 移除上次的目录和Dockerfile !/bin/bash if [ -d ./dist ]; then rm -rf ./dist fi if [ -f ./Dockerfile ]; then rm -f ./Dockerfile fi因为每次更改后dist中的内容肯定与之前不同其实这一步显得不是那么必要。运行npm的打包命令也会自动清楚该目录。 而清除Dockerfile则是为了防止更新了Dockerfile而这次却不能得到最新的配置。 4.2. 打包前端应用执行前端的打包命令生成静态文件目录。 yarn build4.3. 生成Dockerfileecho FROM nginx:latest ./Dockerfileecho COPY ./dist /usr/share/nginx/html/ ./Dockerfileecho COPY ./default.conf /etc/nginx/conf.d/ ./Dockerfileecho EXPOSE 80 ./DockerfileFROM制定了该定制容器的基础镜像为nginx:latest;COPY命里将打包好的静态文件目录复制到容器内的/usr/share/nginx/html/目录下然后将nginx的配置写入容器中对应的位置; EXPOSE则是设置对外暴露容器的80端口。 4.4. 生成并推送定制imagedocker build -t detectivehlh/mine .docker login -u detectivehlh -p docker push detectivehlh/mine这里是在开发本地使用docker命令来打包所以该脚本对docker有强依赖。build命令表示打包docker应用的-t选项则制定了docker镜像的名字和tagtag会默认为latest。 然后登录dockerHub将定制好的镜像推送到dockerHub中。detectivehlh就是dockerHub的用户名mine是image的名字。 4.5. 删除tag为none的无用image第一次构建不会生成tag为none的image但是后面每次再次执行该命令就会出现这样的情况。所以每次构建了一个新的image后需要清除调不需要的image。 docker images | grep none | awk {print $3} | xargs docker rmi使用grep命令匹配到tag为none的imageawk是一个强大的文本分析工具{print $3}表示打印出匹配到的每一行的第三个字段也就是docker的image id。如果是$0的话表示当前整行的数据。 xargs是一个给其他命令也就是后面的docker rmi传递参数的一个过滤器将标准输入转换成命令行参数。 总结来说上述命令就是找到tag为none的image的ID然后使用docker rmi命令移除该image。 4.6. 执行部署cmdcd ~ sh deploy.sh minessh -t USER_NAMEIP_ADDRESS bash -c ${cmd}通过ssh命令登录远程服务器并且执行参数中的脚本。 deploy.sh是放在服务端的构建脚本。放在默认的登录用户下。我们发现后面还跟了个mine这是在服务器上运行的docker镜像的名字。这里暂时没有对container的名字加上hash因为自己的小项目暂时没有必要。 在项目中的完整构建脚本如下。 !/bin/bash if [ -d ./dist ]; then rm -rf ./dist fiif [ -f ./Dockerfile ]; then rm -f ./Dockerfile fi yarn build echo FROM nginx:latest ./Dockerfileecho COPY ./dist /usr/share/nginx/html/ ./Dockerfileecho COPY ./default.conf /etc/nginx/conf.d/ ./Dockerfileecho EXPOSE 80 ./Dockerfile docker build -t detectivehlh/mine .docker login -u detectivehlh -p docker push detectivehlh/mine docker images | grep none | awk {print $3} | xargs docker rmi cmdcd ~ sh deploy.sh minessh -t USER_NAMEIP_ADDRESS bash -c ${cmd} 编写服务器部署脚本从上面步骤来看我们还需要一个服务器端的部署脚本。大家可能会说标题不是说一个脚本搞定吗em。。。服务器一个本地一个...简称只需一个脚本。5.1 接收参数在本地的构建脚本中我们传入了docker运行的container的名字。在服务器构建脚本中需要来接收它。然后更新刚刚推送的docker image。 !/bin/bash name$1docker pull detectivehlh/$name5.2. 启动container在启动container时我们会面对两种情况名字为传入参数的container已经在运行了。而在此时如果再次运行docker run命令就会报错而导致我们无法使用最新的container也无法达到更新应用的目的。 if docker ps | grep $name | awk {print $(NF)} | grep -Fx $name; then echo Container mine is already start
docker stop $name
docker rm $name
docker run -d --name $name -p 3000:80 detectivehlh/$name else echo Container mine is not start!, starting
docker run -d --name $name -p 3000:80 detectivehlh/$name
echo Finish starting fidocker images | grep none | awk {print $3} | xargs docker rmi所以在这里做一个判断第一个if判断如果存在名字为传入参数的container正在运行就停止当前容器再重新启动。如果不存在则直接启动容器。 run命令就不过多解释了。-d表示后台运行容器并返回容器ID--name表示设置容器的名字-p表示设置端口将阿里云服务器的3000端口映射到容器的80端口最后一句表示要启动哪个image好像还是解释了一遍。 最后一句就是移除多次更新后出现的tag为none的无用镜像。完整的脚本如下。 !/bin/bash name$1docker pull detectivehlh/$nameif docker ps | grep $name | awk {print $(NF)} | grep -Fx $name; then echo Container mine is already start
docker stop $name
docker rm $name
docker run -d --name $name -p 3000:80 detectivehlh/$name else echo Container mine is not start!, starting
docker run -d --name $name -p 3000:80 detectivehlh/$name
echo Finish starting fidocker images | grep none | awk {print $3} | xargs docker rmi 如果你只是想打个包看到标题进来的兄dei如果只是想打包一个docker镜像那么你只需要Dockerfile文件和docker build命令就OK了。总结最初写这个脚本主要目的是为了方便。所以脚本中为了达到这个目的做了一些调整。最终我达成了满足我需求的一个方便的部署脚本。它的方便体现在当我完成了项目代码的更新只需要跑一下这个脚本然后等待一会儿项目就会自动打包成docker image并且自动的在我的服务器上运行该container。 但是这种方式会给实际的生产环境带来一些不可控的问题。比如脚本必须不能上传因为涉及一些服务器的敏感信息。但是如果你不小心上传了那你的服务器就相当于裸奔了再比如你对你的代码必须要十分自信没有经过测试的代码就直接部署会带来一些风险。 如果是自己用的那完全不用担心想怎么搞怎么搞。但是如果是开放给所有人用的并且有一定的访问量比如博客那么对于其他用户来说这种方式就不怎么友好。 所以我的观点是分情况来。目前来说我的项目只有少数几个人在用也还在处于迭代阶段。并且代码仓库是私有的所以我完全不用担心隐私的问题。服务未经测试就直接上线对于我来说其实问题也不大。首先我会在本地测试确认无误后才会执行部署操作。所以在不同的阶段找到最适合自己的方案就OK。原文地址https://www.cnblogs.com/detectiveHLH/p/10756702.html
