部署進化論

05-06

最近一段時間在自己的個人項目裡面研究部署的各種方式，然後總結了一些經驗。

使用 git post-receive hooks

從最開始的講起。我在阿里雲 ESC 上搭建了，git 伺服器，然後修改對應代碼倉庫的 post receive hook，收到 git 推送後，post-receive 裡面的腳本會被執行。

腳本大概長這樣：

#!/bin/bashGIT_DIR=/path/to/repo.gitWORK_TREE=/path/to/destwhile read oldrev newrev refdo if [[ $ref =~ .*/master$ ]]; then echo "Master ref received. Deploying master branch to production..." mkdir -p $WORK_TREE git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f else echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server." fidone

這種方法很直接。但卻很繁瑣，需要在伺服器上搭建 git（我當時用的是 gitosis），每次新增一個項目必須到服務端修改對應 repo 的 hooks。

不過作為個人項目使用的話這種也還湊合，所以很長一段時間裡面，我在阿里雲上都用的這種方式來發布項目。

使用 jenkins

後來，其實也就是前不久，我的 ubuntu 伺服器出問題了，陰差陽錯裝了 centOS，想想之前 ubuntu 裡面的部署需要的環境都要在 centOS 裡面重新裝一遍，而且對於把代碼添加多個 origin 推送到自己伺服器這種事也是覺得麻煩。於是就找到了 jenkins。一個用 java 寫的，專門來執行這種構建任務的工具，有一個界面陳舊的管理後台。

然後工作流程就變成了這樣：在 jenkins 裡面新建一個任務，任務里指定代碼 git 地址，以及拉取代碼後的構建腳本。然後每次提交代碼後，登錄 jenkins，選擇構建對應的項目就可以了。

缺點是，每次需要手動登錄，然後跑構建任務，如果構建任務需要的內存比較大還會影響當前在伺服器上的其他應用（之前我在阿里雲上買的 ECS 實例只有 1G 內存，直接就卡死了，後來升級到 2G 才可以了）。

當然，以上兩種方式都有一個缺點，對於平台的依賴性很強，如果現在你有兩個應用，一個依賴 nodejs 5.x 一個依賴 6.x 那麼這個時候在同一個伺服器上用以上的方法就存在問題了。

使用 docker 技術

其實在實施這些的時候也不是沒聽說過 docker，只是當時一直沒時間去研究，但考慮到面臨的那些問題，還是去仔細看了 docker 的一些文檔。基本上我理解的流程就是這樣，在代碼裡面添加 Dockerfile。Dockerfile 裡面定義了一個基礎環境比如 nodejs 6.x，然後還有定義工作目錄，以及構建腳本，最後是 docker 的啟動腳本。可以在 docker cloud 的網站上添加代碼倉庫，每次提交後，它會自動構建 docker image，然後配合 docker 官方對第三方服務商的集成，可以方便的將構建好的 image 發布到 AWS 之類的雲服務商上面，不過遺憾的是阿里雲不在此列。後來發現阿里雲自身是對 docker 有很好的支持的。在阿里雲上可以選擇新建 Docker 鏡像倉庫，然後代碼源支持阿里雲 Code，GitHUb，GitLab，BitBucket 以及本地倉庫。最方便的是，可以選擇使用海外伺服器構建（好處你懂的）。

然後流程變成，合併代碼到 master 分支，阿里雲鏡像倉庫自動拉取代碼，開始構建鏡像。完成之後，在 docker 應用界面選擇變更配置，修改應用版本號後就可以讓新的 docker 實例跑起來了。

整個過程需要一定的學習成本，但都走通了之後，會發現效率提升了很多，部署上去的應用的可用性有更好的保障。

寫在最後

這篇文章主要是記錄下自己在部署上的一些實踐，中間省略了很多細節。其實如果要在阿里雲上使用 docker，需要配置集群伺服器，負載均衡，以及簡單路由。另外，mongodb，nginx 之類的工具在 docker 的環境下如何相互通信去配合使用其實都是需要不少的鑽研的。我相信這是一個很好的開始，docker 方面的技術實踐還有很多值得研究的，有時間再寫寫關於 docker 的使用實踐。