摘要:一切看似妥當,但是頻繁的調整以及部署自然成了頭疼的問題。叫作部署的大問題由于我比較菜,所以沒有寫測試模塊。為什么因為絕大多數都是黨用來部署的啊。。。經過思考,原來在這里我們需要將部署工序做一個調整,同時增加步。。。
前言
在自己的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
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/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...
閱讀 2891·2021-10-14 09:42
閱讀 1244·2021-09-24 10:32
閱讀 2951·2021-09-23 11:21
閱讀 2839·2021-08-27 13:10
閱讀 3327·2019-08-29 18:41
閱讀 2194·2019-08-29 15:16
閱讀 1193·2019-08-29 13:17
閱讀 892·2019-08-29 11:22