摘要:一切看似妥当,但是频繁的调整以及部署自然成了头疼的问题。叫作部署的大问题由于我比较菜,所以没有写测试模块。为什么因为绝大多数都是党用来部署的啊。。。经过思考,原来在这里我们需要将部署工序做一个调整,同时增加步。。。
前言
在自己的vps上做博客系统已经有一段时间了,期间也是磕磕碰碰遇到不少问题,如今也算是有个基础版本能用。可是vps上只放一个博客有点浪费了,而且博客系统也不光是用来写文章的,所以自然就开始放一些其他的自己开发的应用。
正好老婆到了要数胎动的日子了,于是就做了一个数胎动的应用,可是到部署的时候却遇到了不少问题。
原本博客系统用的是vue+loopback的前后端搭配,用forever支撑应用。但是新应用尝试了一下django rest framework,不同的后端应用服务器的存在,自然地要求引入一个web服务器做请求转发,所以就在前面放了一个nginx。关于nginx的配置就放到另一篇文章里吧,也是一个愉(keng)悦(die)的过程。
一切看似妥当,但是频繁的调整以及部署自然成了头疼的问题。
由于我比较菜,所以没有写测试模块。但是我还是有(yao)追(zhuang)求(bi)啊!!所以我坚持要做没有测试持续集成(污误)!换言之,一键部署
我们只看前端部分,那部署要做的工作是什么呢?
本地开发完成 -> git push到github -> 登录到vps -> git pull -> build -> copy到nginx静态文件对应目录
首先,通过常用的工具链,把能做的事情先做掉点。由于我用的是vue作为前端部分,构建用了webpack,包管理和流程控制都是npm,所以第一步,在prod用的webpack部分设定了一下部署目录
webpack.config.js var PRD_BUILD_PATH = path.resolve(ROOT_PATH, "../../deploy/babyMoveCounter"); .... if (process.env.NODE_ENV === "production") { module.exports.output = { path: PRD_BUILD_PATH, publicPath: "", filename: "[name].js" }; }
之后,在package的script部分里,加上deploy的这句,就算准备好了
package.json "scripts": { "deploy": "NODE_ENV=production webpack" }
于是,上面的这个工序就减少了一点,现在变成了
本地开发完成 -> git push到github -> 登录到vps -> git pull -> npm run deploy
还是很烦啊!!!
开始正式搞一键部署,引入git hook网上看一键部署有好多文章,然后会发现很多都是讲jenkins的,但是并没有什么X用。为什么?因为绝大多数都是java党用来部署java的啊。。。
况且在自己的vps上放个jenkins,貌似有点太笨重了。于是在不断的google中,找到了git hooks这个神奇的东西。
git hooks和其他hooks差不多,也就是在各个阶段加个钩子干点别的呗,所以我们就可以用到post-receive这个钩子。
到这里就出现了第一个坑。如果有人去看参考文档里讲git hooks的文章,或者去git官网看,一定会有不明觉厉的感觉。而且是看似有操作步骤,但是总感觉不太对。
因为他们说的都是往github push的时候干点啥,可是我的应用是在自己的服务器上,跟github没半毛钱关系。。
经过思考,原来在这里我们需要将部署工序做一个调整,同时增加N步。。。又要多事情了= =
本地开发完成 -> git push到github
本地开发完成 -> git push到vps上私有仓库 -> 登录到vps -> cd到vps上的代码目录(并不是私有仓库目录) -> git pull -> npm run deploy
没错,建一个私有仓库,那么post-receive就可以有用武之地了,怎么建私有仓库就很方便的google一下好了
可能遇到的问题是关于git用户的权限问题
在我自己的vps上,我在根目录下设了3个文件夹
/opt/git/ # 用来放所有的私有仓库
/projects/ # 用来放服务器上pull的代码
/deploy/ # 用来放build之后的代码,为什么要和projects分开呢?你去问nginx呀(摔!)
然后,让我们加入post-receive
post-receive的代码可以放在/opt/git/xxxxproject.git/hooks里面
我的代码是这样的
#!/bin/sh LOGFILE=./post-receive.log # The deployed directory (the running site) DEPLOYDIR=/projects/babyMoveCounter ## Record the fact that the push has been received echo -e "Received Push Request at $( date +%F )" >> $LOGFILE echo " - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE ## Update the deployed copy echo "Starting Deploy" >> $LOGFILE echo " - Starting code update" GIT_WORK_TREE="$DEPLOYDIR" git checkout -f echo " - Finished code update" echo " - Starting npm install" cd "$DEPLOYDIR"; npm install; echo " - Finished npm install" echo " - Staring build" cd "$DEPLOYDIR"; npm run deploy; echo " - Finished build" echo "Finished Deploy" >> $LOGFILE
最关键的主要是3步,拉代码,npm install,npm run deploy
于是乎,我们的部署流程就大大的简化了,现在是2键部署
本地开发完成 -> git push到github
本地开发完成 -> git push到vps上私有仓库
离一键部署越来越近了,如果你喜欢2一点,那就不要看下去了
一键部署达成,引入travis-ci其实做到上面这部,如果不想开源的话,一键部署也已经达成了。但是,一般自己项目都是开源放到github的,为了分(炫)享(技)嘛
既然放到了github,那么travis-ci作为一个优秀的工具就可以被引入到流程中,同时,它也能作为链接2个仓库的桥梁
引入travis-ci后,部署流程就会是这样的
集成travis-ci本地开发完成 -> git push到github -> 通知travis-ci -> 跑测试 -> git push到vps上私有仓库
参考文档中hexo作者的博客里已经写的挺清楚了,但是仍然会让我觉得云里雾里,为什么呢?还是那个原因,他们是放到github.io上去的啊!!我要集成到我的vps呀!!
让我们继续。。。
首先,我们了解一下travis官方说的如何用git集成(注意,非github)
其中的样例代码是这样的
after_success: - eval "$(ssh-agent -s)" #start the ssh agent - chmod 600 .travis/deploy_key.pem # this key should have push access - ssh-add .travis/deploy_key.pem - git remote add deploy DEPLOY_REPO_URI_GOES_HERE - git push deploy
从中我们发现
这又是一个hook
这货能替我们ssh
到这一步,再回想一下之前的博客,我们可以推断出,github到travis再到我们私有仓库的业务流程应该是这样的
git push到github -> 通知travis-ci -> 跑测试 -> 测试跑成功 -> travis开启ssh -> git push到vps上私有仓库
所以我们需要给travis一个部署用的rsa密钥才行。所以就有了以下这几步(这些命令都在项目根目录中执行)
首先,我们生成一个密钥
$ ssh-keygen -t rsa -C "your_email@example.com" #就像hexo作者的博客里说的,别加密码,除非你想自虐
生成的文件我们叫它们travis_deploy & travis_deploy.pub (记得在gitignore里面把它们加进去)
由于我们是让travis agent通过ssh上传代码,所以我们把travis_deploy加密传到travis上,然后,把travis_deploy.pub放到我们的私有仓库里
之前的博客中是在github的项目里放一个deploy的key,原理其实是一样的,因为他的after success是在github上面执行,而我是在自己的vps上执行
让我们一步步来
先写一个基本的.travis.ymllanguage: node_js node_js: - "4" script: - npm run test branches: only: - master加密travis_deploy
$ gem install travis # 你需要ruby的gem $ travis login --auto $ travis encrypt-file travis_deploy --add
之后travis会自动修改项目中的.travis.yml
.travis.yml最终配置language: node_js node_js: - "4" script: - npm run test branches: only: - master before_install: - openssl aes-256-cbc -K $encrypted_cb1b65bfda52_key -iv $encrypted_cb1b65bfda52_iv -in travis_deploy.enc -out travis_deploy -d - chmod 600 travis_deploy - cp travis_deploy ~/.ssh/travis_deploy - cp travis_config ~/.ssh/config after_success: - eval "$(ssh-agent -s)" - ssh-add ~/.ssh/travis_deploy - git remote add deploy git@xx.xx.xx.xx:/opt/git/yourPrivateRepo.git - git push deploytravis_deploy.pub
# sftp上传到vps上,然后在server上执行 cat travis_deploy.pub >> /home/git/.ssh/authorized_keysssh config
到这一步,travis是能够做git push了,但是自己的vps并不是travis agent的认证服务器,所以我们需要增加一点ssh config,不然会出现Are you sure you want to continue connecting (yes/no)?
Host xx.xx.xx.xx User git StrictHostKeyChecking no IdentityFile ~/.ssh/travis_deploy IdentitiesOnly yes
到此,一切大功告成!我们的部署流程变成了
本地开发完成 -> git push到github
好high~ 好high~
补充一些过程中的坑 npm共享问题一般在vps上安装node都是用nvm来控制的,但是给git用户用的npm总不能也用nvm来装,所以需要跑一些指令让root用的当前版本的node,同步给其他用户
n=$(which node);n=${n%/bin/node}; chmod -R 755 $n/bin/*; sudo cp -r $n/{bin,lib,share} /usr/local
每次切换node版本如果git用户也需要换的话,必须再执行一次
总结没啥总结的,一键部署,好high~~~
参考文档 travis & githttps://zespia.tw/blog/2015/01/21/continuous-deployment-to-github-with-travis/
http://davidsiaw.github.io/blog/2014/10/30/using-travis-to-deploy-my-blog/
https://docs.travis-ci.com/user/deployment/custom/
git post-receive hookhttps://www.sitepoint.com/one-click-app-deployment-server-side-git-hooks/
travis unauthed host issuehttp://stackoverflow.com/questions/16638573/auto-authorize-ssh-auth-requests-on-travis-ci
install nvm & share node to other userhttps://www.digitalocean.com/community/tutorials/how-to-install-node-js-with-nvm-node-version-manager-on-a-vps
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/79770.html
原文链接 随着Vateral主题的开发接近了尾声,在对主题速度优化的时候发现之前用的githubpage问题多多:首先就是因为在国内的原因,访问速度本身就很慢,曾经有次加载一张16kb的图标时间耗费了26s!!?其次,在对资源做CDN托管加速时,域名是需要备案的,显然githubpage也是做不了的;所以果断舍弃了这个把hexo搭建到了我的阿里云服务器上 总体来说还是比把hexo搭建到github...
摘要:持续集成,持续交付当然也有叫通常会采用一些软件如等来辅助我们。这时可以通过仓库自带的来触发。这里的最好是可以支持,关于,大家可以理解为类似的功能。关于如何取出服务地址并自动添加记录的原理,可以参考我之前的一篇文章文中第三部分有详细描述。 CI(Continuous Integration)持续集成,CD(Continuous Delivery) 持续交付(当然也有叫 Continuou...
摘要:是目前新兴的开源持续集成构建项目,采用格式,简洁清新独树一帜。目前大多数的项目都已经移入到的构建队列中。测试提交代码到中查看部署情况至此,整个部署完成,赶快自己尝试一下吧 Travis CI是目前新兴的开源持续集成构建项目,采用yaml格式,简洁清新独树一帜。目前大多数的github项目都已经移入到Travis CI的构建队列中。Travis-CI会同步你在GitHub上托管的项目,...
摘要:博客的架构先搞明白博客从搭建到自动发布的架构,才能更好的理解我们每一步进行的操作。整个搭建流程第一部分服务器环境搭建,包括安装配置创建用户。在裸库的文件夹中,新建文件。 1. 博客的架构 先搞明白Hexo博客从搭建到自动发布的架构,才能更好的理解我们每一步进行的操作。不然只跟着步骤过了一遍,却不知道为什么这么做。 首先看这张架构图:showImg(https://segmentfaul...
阅读 2840·2021-10-14 09:42
阅读 1189·2021-09-24 10:32
阅读 2928·2021-09-23 11:21
阅读 2816·2021-08-27 13:10
阅读 3311·2019-08-29 18:41
阅读 2181·2019-08-29 15:16
阅读 1173·2019-08-29 13:17
阅读 878·2019-08-29 11:22