自動化部署--shell腳本--1

傳統部署方式
一、純手工scp
二、純手工登陸git pull 、svn update
三、純手工xftp往上拉
四、開發給打一個壓縮包，rz上去。解壓

 

傳統部署缺點：
一、全程運維參與，佔用大量時間
二、上線速度慢。
三、認爲失誤多。管理混亂
四、回滾慢，不及時

 

新項目上線，規劃排在第一位
通常銀行都不提供測試接口。好比一些電商公司測試的話，常常把商品調節成1分，只能特定帳號能看到。

環境的規劃
一、開發環境-開發者本地有本身的環境，而後運維須要設置的開發環境，放的是你們共用的服務。如開發數據庫mysql，其它：redis、Memcached。
二、測試環境：功能測試環境和性能測試環境
三、預生產環境：通常能夠用生產環境中的某個節點擔任
四、生產環境：直接對用戶提供服務的環境

預生產環境產生的緣由：
一、數據庫不一致：測試環境和生產環境數據庫確定不同的。
二、使用生產環境的聯調接口。例如，支付接口

 

預生產環境--生產環境--灰度發佈

 

灰度發佈：

阿里雲產品上線，都是一個區一個區上的。確定不是一會兒都上的

qq彈窗：恭喜你得到某某版本資格，請下載新版本享用，你就是小白鼠，這個也是一種灰度發佈

 

規劃

已經有一個能夠上線的代碼在代碼倉庫。咱們如何設計一套生產自動化部署系統。

一、規劃

二、實現

三、總結和擴展。PDCA

四、在生產環境應用

 

自動化部署系統的規劃

 

需求： 

1個集羣有10個節點。一鍵部署這10個節點。

二、一鍵回滾到任意版本

三、一鍵回滾到上個版本

 

部署：

一、代碼放在哪裏：svn，git
二、獲取什麼版本代碼？
svn+git直接拉去某個分支
svn:指定版本號
git:指定tag
三、差別解決：
（1）、各個節點直接差別：
（2）、代碼倉庫和實際的差別。配置文件是否在代碼倉庫中
（3）、配置文件未必同樣：crontab.xml預生產節點
四、如何更新。java tomcat。須要重啓。
五、測試。
六、串行和並行 分組部署
7如何執行。（1）shell執行。（2）web界面

 

關於配置文件存放：

配置文件放代碼倉庫裏，豈不是全部開發都能連數據庫了。

所以配置文件不能放git裏。

有的人把配置文件放某個分支裏。讓一些人無法看到

我以爲能夠單獨有個放配置文件的git

 

騰訊藍鯨:我幫你作個平臺，你寫個腳本，我幫你發佈到某個機器上，你經過平臺幫你執行

一些公司如今的運維，無論任何發佈，都是作好界面，讓項目負責人去經過界面管理

 

關於差別文件：

可能有些節點有特殊的差別性文件

 

 

自動化部署流程設計