摘要:这两类密钥文件需要配置在中,在里进行的操作。在找到想要重新部署的版本,点击,在新页面中选择为。其他若是想要进入交互,可以通过以下命令
背景
公司的前端项目部署方式比较简单,整个过程基本上是手动的;
目标通过工具实现以下几个任务:
编译、部署自动化;
选择指定版本进行回滚;
区分不同的分支(环境);
技术方案选用 jenkins 作为部署工具;也便于后续 CI 的接入;
使用 docker 进行编译,确保每次编译的环境的稳定;
步骤 步骤一:搭建 Jenkins搭建 Jenkins 有很多方案,这里选择使用 docker 搭建。
docker-compose.yml 的内容如下:
version: "3" services: fejenkins: user: root image: jenkinsci/blueocean ports: - "8080:8080" - "50000:50000" volumes: - /data/jenkins_home:/var/jenkins_home - /data/nm_cache:/var/nm_cache - /var/run/docker.sock:/var/run/docker.sock
通过 docker-compose up 命令启动;启动后通过初始密码进行第一个用户的创建和 Jenkins 初始化的一些列操作,初始密码会打印在 jenkins docker 启动命令行的输出中,注意查看。
当然也可以不使用 docker-compose:
docker run --rm -u root -v /data/jenkins_home:/var/jenkins_home -v /data/nm_cache:/var/nm_cache -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 -p 50000:50000 jenkinsci/blueocean
稍做解释:
/data/jenkins_home:/var/jenkins_home /var/jenkins_home 是 jenkinsci image 的默认数据存放路径,这里将路径映射到宿主机的指定文件夹;
/data/nm_cache:/var/nm_cache nm_cache 涵义是 node_modules cache,顾名思义,这里是想对编译所需的 node_modules 做缓存,将缓存文件夹也映射到宿主机;
/var/run/docker.sock:/var/run/docker.sock 这里是将宿主机运行 docker 后产生的 sock 文件映射到了 jenkins container 中。这样,jenkins 中使用 docker 进行编译时,其实是使用宿主机的 docker 来运行的,而不是在 docker container 中又启动了 docker。这里稍微有点绕,若是暂时看不明白,需要找一些深入介绍 docker 的文章阅读;
步骤二:配置 Jenkins通过 Jenkins 进行 git 操作需要对应 git repo 的权限,这里需要用到有 git repo 权限的密钥文件。同样,通过 Jenkins 将编译产物 scp 到服务器上的时候,也需要服务器的密钥文件。
这两类密钥文件需要配置在 Jenkins 中,在:Jenkins > Credentials > System > Global credentials (unrestricted) 里进行 Add Credentials 的操作。
Jenkins > New Item,然后选择 Pipeline,在下面的 Pipeline 配置区域的 Definition 中选择 Pipeline script,Script 如下:
pipeline { environment { SERVER_IP_1 = "11.22.33.44" SERVER_CREDENTIALSID = "abcd1234-abcd-abcd-abcd-abcd1234abcd" SERVER_DEPLOY_DIR = "/your/www/path/" CACHE_DIR = "/var/nm_cache/your_project_name/" GIT_URL = "git@github.com:example/example.git" GIT_BRANCH = "master" GIT_CREDENTIALSID = "abcd1234-abcd-abcd-abcd-abcd1234abcd" } agent none stages { stage("Checkout code") { agent any steps { git ( branch: "${GIT_BRANCH}", credentialsId: "${GIT_CREDENTIALSID}", url: "${GIT_URL}", changelog: true ) sh """ ls -al cache_dir="${CACHE_DIR}" cache_nm="${CACHE_DIR}node_modules" cache_lock="${CACHE_DIR}yarn.lock" if [ ! -d "$cache_dir" ]; then mkdir ${cache_dir}; fi if [ ! -d "$cache_nm" ]; then mkdir ${cache_nm}; fi if [ -d "$cache_nm" ]; then ln -sf ${cache_nm} ./; fi if [ -f "$cache_lock" ]; then mv -n ${cache_lock} .; fi ls -al """ } } stage("Build") { agent { docker { image "node:8-alpine" args "" } } steps { sh """ npm config set registry https://registry.npm.taobao.org yarn install yarn build tar -cvf build.tar build ls -al mv ./yarn.lock ${CACHE_DIR} rm -rf ./node_modules ls -al """ archiveArtifacts artifacts: "build.tar", fingerprint: true } } stage("Deploy") { agent any steps { unarchive mapping: ["build.tar": "build.tar"] echo "--- Deploy ---" sshagent(["${SERVER_CREDENTIALSID}"]) { sh "scp -o StrictHostKeyChecking=no build.tar root@${SERVER_IP_1}:${SERVER_DEPLOY_DIR}" sh "ssh -o StrictHostKeyChecking=no root@${SERVER_IP_1} "rm -rf ${SERVER_DEPLOY_DIR}build; tar -xvf ${SERVER_DEPLOY_DIR}build.tar -C ${SERVER_DEPLOY_DIR}"" } } } } }
稍做解释:
这个部署脚本分为三个步骤:
Checkout code(在指定 git 仓库通过指定证书文件获取代码)
Build(通过指定命令进行编译,将编译后的产物存档)
Deploy(通过指定命令部署)
在 Build 阶段前后,我们各做了一些工作,以求每次部署可以复用 node_modules,因为下载 node_modules 的时间可能很长,而并不是每次都会修改 package.json,所以其实 node_modules 大概率可以复用;
编译前:
看指定 node_modules 缓存文件夹是否存在,不存在则新建该文件夹;
看缓存文件夹中是否有 node_modules 文件夹,如果没有则新建该文件夹;并且将该文件夹软连接到当前目录;
看缓存文件夹中是否有 yarn.lock 文件,如果有则移动到当前文件夹;
编译后:
移除 node_modules 文件夹的软连接;
将 yarn.lock 文件移动到缓存文件夹中;
这里使用了 yarn install 的某些特性:
没有 node_modules 或者 yarn.lock 时会安装全量依赖;
有 node_modules 和 yarn.lock 但是 yarn.lock 和 package.json 不匹配时,会安装所需依赖;
有 node_modules 和 yarn.lock,且 yarn.lock 和 packge.json 配置时,跳过安装依赖;
使用编译和部署直接点击 Build Now 即可;
回滚的本质其实是:重新部署某个历史版本。在 Build History 找到想要重新部署的版本,点击 Restart from Stage,在新页面中选择 Stage Name 为 Deploy。
其他若是想要进入 docker container 交互,可以通过以下命令
docker exec -i -t [dockername] /bin/bash
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/27718.html
摘要:原博客地址实现前端项目自动化集成打包部署掘金地址前言以前写前端项目打包部署,都是手动运行命令,打包完,然后压缩,再上传到服务器解压。验证提交代码,成功自动打包部署提交代码,观察界面,出现构建任务,构建完成之后收到邮件通知。 原博客地址:https://yezihaohao.github.io/2017/09/09/Jenkins实现前端项目自动化集成打包部署/掘金地址:https://...
摘要:为了看起来清晰,我写了一个文件,将这个文件和之前的放在同一个目录中,可以用以下命令快速启动,启动之后新构建的镜像和容器都名为。 showImg(https://segmentfault.com/img/remote/1460000014924499?w=883&h=515); 在软件开发过程中,如果我们每一次提交的代码都能够进行一次完整的编译、测试、打包、发布,就能及早发现问题、及早修...
摘要:是什么阿里云是一款提供持续集成持续交付能力,并完全兼容的能力和使用习惯的化产品。后续遇到的坑如果发生构建失败,记得要删除当前构建,否则触发器不会工作 1、codepipeline是什么 阿里云CodePipeline是一款提供持续集成/持续交付能力,并完全兼容Jenkins的能力和使用习惯的SAAS化产品。通过使用阿里云CodePipeline,您可以方便的在云端实现从代码到应用的持续...
摘要:从到再到搭建编写构建一个前端项目选择现成的项目模板还是自己搭建项目骨架搭建一个前端项目的方式有两种选择现成的项目模板自己搭建项目骨架。使用版本控制系统管理源代码项目搭建好后,需要一个版本控制系统来管理源代码。 从 0 到 1 再到 100, 搭建、编写、构建一个前端项目 1. 选择现成的项目模板还是自己搭建项目骨架 搭建一个前端项目的方式有两种:选择现成的项目模板、自己搭建项目骨架。 ...
摘要:从到再到搭建编写构建一个前端项目选择现成的项目模板还是自己搭建项目骨架搭建一个前端项目的方式有两种选择现成的项目模板自己搭建项目骨架。使用版本控制系统管理源代码项目搭建好后,需要一个版本控制系统来管理源代码。 从 0 到 1 再到 100, 搭建、编写、构建一个前端项目 1. 选择现成的项目模板还是自己搭建项目骨架 搭建一个前端项目的方式有两种:选择现成的项目模板、自己搭建项目骨架。 ...
阅读 2238·2021-11-16 11:44
阅读 643·2019-08-30 15:55
阅读 3275·2019-08-30 15:52
阅读 3596·2019-08-30 15:43
阅读 2198·2019-08-30 11:21
阅读 437·2019-08-29 12:18
阅读 1946·2019-08-26 18:15
阅读 469·2019-08-26 10:32