前言

隨著系統(tǒng)越來(lái)越大，開(kāi)發(fā)人員、站點(diǎn)、服務(wù)器越來(lái)越多，微服務(wù)化推進(jìn)，......等等原因，實(shí)現(xiàn)自動(dòng)化的devops越來(lái)越有必要。
當(dāng)然，真實(shí)的原因是，在團(tuán)隊(duì)組建之初就預(yù)見(jiàn)到了這些問(wèn)題，所以從一開(kāi)始就決定這一塊要自動(dòng)化。
帶來(lái)的實(shí)質(zhì)好處也是顯而易見(jiàn)的，人力成本的節(jié)省、規(guī)范化的流程、可追溯的發(fā)布?xì)v史、解脫雙手（重復(fù)性勞動(dòng)）、避免人為操作產(chǎn)生的錯(cuò)誤等等。

感概一下

1.目前市面上的成套的產(chǎn)品要么貴的要死，要么不支持本地部署，要么就還是一個(gè)demo級(jí)別的東西，最重要的還是每個(gè)公司或者產(chǎn)品都有自己的一些特殊環(huán)境或者業(yè)務(wù)再里面。不一定都適合。反正是比較難找到好用的，而且是成套的產(chǎn)品來(lái)。期待一個(gè)devops界的SAP，而且還要便宜！
2.幾個(gè)老大哥產(chǎn)品還是做得很牛逼！比如jira，confluence，jenkins，sonar。官方文檔非常完善，網(wǎng)上教程多。接口完備。不像某些產(chǎn)品，看上去高大上，一用起來(lái)就是各種坑
3.懂開(kāi)發(fā)的運(yùn)維覺(jué)逼是牛逼的程序員！（^_）
4.人真的非常重要，不然流程什么的，呵呵，都是個(gè)屁......

大概的樣子

當(dāng)然，目前這套工具還有很多不完善的地方，隨著不停的使用，或者變化的需求來(lái)進(jìn)一步變化。

gitlab

開(kāi)源的git倉(cāng)庫(kù)，主要有幾個(gè)用途
1.源代碼管理
分支管理規(guī)則可以參考gitflow，或者規(guī)定一個(gè)合適自己的就好，微服務(wù)化后，一個(gè)站點(diǎn)或者說(shuō)一個(gè)項(xiàng)目參與的開(kāi)發(fā)人員只有有限的幾個(gè)人。用了簡(jiǎn)單的方法，master作為發(fā)布用分支，每次迭代開(kāi)發(fā)使用新分支，上線前合并到master；線上簡(jiǎn)單的fix則直接在master分支上提交。
2.配置文件管理
放在gitlab上，主要是為了方便管理，以及追溯修改歷史。當(dāng)然，我們有自己的配置中心，能走配置中心的都盡量走配置中心，只有必須是文件配置管理的才放在gitlab上。
3.發(fā)布腳本管理
jenkins需要使用到的發(fā)布腳本。根據(jù)環(huán)境、源代碼語(yǔ)言、部署方式等有所不同

jira

jira敏捷開(kāi)發(fā)管理工具，管理需求、研發(fā)迭代等。在加上他們家公司的wiki做知識(shí)庫(kù)管理基本穩(wěn)了。
jira用下來(lái)發(fā)現(xiàn)還是相當(dāng)強(qiáng)大！各種自定義可配置。頁(yè)面、字段、流程等等全可配置。有http open api可以直接調(diào)用修改信息、觸發(fā)流程等

使用的發(fā)布流程也比較簡(jiǎn)單。開(kāi)發(fā)創(chuàng)建發(fā)布任務(wù)，然后提交給測(cè)試，測(cè)試在jira上操作發(fā)布到測(cè)試環(huán)境，準(zhǔn)線上環(huán)境，線上環(huán)境進(jìn)行測(cè)試等。準(zhǔn)線上環(huán)境測(cè)試完后要發(fā)布到線上需要讓具有l(wèi)eader權(quán)限的人進(jìn)行一次審核，一方面是讓leader知道有什么東西上線了，另一方面也是安全控制的一些原因（比如說(shuō)節(jié)假日前夕最好是不在做更新等，要做更新就得報(bào)備，不然出問(wèn)題節(jié)假日就得嗝屁）。

截圖是比較歷史的版本了，最近在jira里面找了一個(gè)進(jìn)度條插件，然后把構(gòu)建發(fā)布的實(shí)時(shí)進(jìn)度直接反饋到j(luò)ira的頁(yè)面上。這樣就不用再打開(kāi)發(fā)布系統(tǒng)查看發(fā)布進(jìn)度了，進(jìn)一步提高使用體驗(yàn)。

發(fā)布流程工作流，根據(jù)自身的情況設(shè)計(jì)的

發(fā)布系統(tǒng)

這一塊，是我們自己開(kāi)發(fā)的一個(gè)簡(jiǎn)單系統(tǒng)。主要作用是銜接各個(gè)開(kāi)源工具的使用。作為一個(gè)粘合劑系統(tǒng)使之分散的各個(gè)子工具能鏈接為一個(gè)整體。
雖然，jira里面有jenkins插件，jenkins里面有jira的插件，但是組件對(duì)各個(gè)系統(tǒng)都有版本要求，然后組件使用上也蠻不方便的，最后也有一些需求要解決起來(lái)相當(dāng)麻煩，所以才有了自己的發(fā)布系統(tǒng)。
功能還是比較簡(jiǎn)單，一個(gè)前端小伙弄弄頁(yè)面什么的1個(gè)禮拜就完事了，關(guān)鍵還是把當(dāng)下的各種新技術(shù)都秀了一波，雖然頁(yè)面挺丑的。幾個(gè)系統(tǒng)的接口調(diào)用自己研究寫一寫也就幾天就完事了。
主要完成的幾個(gè)功能
1.發(fā)布配置管理
站點(diǎn)或者系統(tǒng)的開(kāi)發(fā)語(yǔ)言，部署的目標(biāo)系統(tǒng)，要部署那些主機(jī)，是不是docker容器方式，docker要部署幾個(gè)示例，部署方式并發(fā)、串行發(fā)布，要走那一個(gè)nginx，綁定的域名，綁定的端口等等信息。
在新的系統(tǒng)或者站點(diǎn)發(fā)布的時(shí)候由運(yùn)維和研發(fā)協(xié)調(diào)填寫，后期則由運(yùn)維來(lái)維護(hù)，比如擴(kuò)縮容等

2.接收jira的發(fā)布任務(wù)操作通知，并通知到某一個(gè)Jenkins去執(zhí)行，sonar進(jìn)行靜態(tài)代碼檢查等
3.接收jenkins構(gòu)建部署反饋過(guò)來(lái)的進(jìn)度
4.展示構(gòu)建部署進(jìn)度

5.一部分CMDB系統(tǒng)的功能，主機(jī)管理（ip，名稱，用戶名）之類的。本來(lái)打算是直接調(diào)用CMDB工具的接口的，奈何目前運(yùn)維在用的CMDB工具不好對(duì)接，所以簡(jiǎn)單的做了一部分管理工作，加之機(jī)器數(shù)量還不是太多，人工也還是能管理過(guò)來(lái)。

因?yàn)樯婕暗街鳈C(jī)的賬號(hào)密碼之類的，所以密碼都是公鑰加密存儲(chǔ)在系統(tǒng)上。
而密碼的使用方有2個(gè)，一個(gè)是jenkins在部署的時(shí)候新機(jī)器在創(chuàng)建SSH免密登錄的時(shí)候要用一次，還有就是遠(yuǎn)程管理工具要用，所以對(duì)密碼的使用單獨(dú)寫了個(gè)小組件用私鑰解密獲得密碼，然后把發(fā)布系統(tǒng)和小組件單獨(dú)管理

jenkins

jenkins絕對(duì)可以說(shuō)是這套工具里面的大佬了，可以說(shuō)一切都是圍著他在轉(zhuǎn)。
接收發(fā)布系統(tǒng)發(fā)過(guò)來(lái)的構(gòu)建請(qǐng)求，拉取代碼，編譯，拉取配置文件，打包成部署包，上傳ftp，發(fā)布到私有docker倉(cāng)庫(kù)，部署等等。
還要區(qū)分系統(tǒng)環(huán)境，開(kāi)發(fā)語(yǔ)言(windows、linux、nodejs、.net core)單獨(dú)處理等。
1.參數(shù)化構(gòu)建過(guò)程。比如要構(gòu)建的分支名稱之類的
2.源代碼配置。git源代碼地址，gitlab固定的代碼只讀賬號(hào)，通過(guò)SSH進(jìn)行代碼的拉取。
3.調(diào)用構(gòu)建腳本。jenkins內(nèi)的執(zhí)行命令大約如下面所示

#!/bin/bash -l
cd /opt/deployscript # 進(jìn)入構(gòu)建腳本目錄
git pull #拉取最新的構(gòu)建腳本
#調(diào)用構(gòu)建腳本
#workspace,build_number,jobname,project_name,git_commit,git_branch,env,jira_id,userid
sh /opt/deployscript/${JOB_NAME}/${env}/deploy.sh "${WORKSPACE}" "${BUILD_NUMBER}" "${JOB_NAME}" "${PROJECT_NAME}" "${GIT_COMMIT}" "${selected_branch}" "${env}" "${JIRA_ISSUE_ID}" "${BUILD_USER_ID}"

jenkins的構(gòu)建腳本

重中之重了，所有的驅(qū)動(dòng)都在這個(gè)腳本里面了。分環(huán)境、分開(kāi)發(fā)語(yǔ)言單獨(dú)編寫的構(gòu)建或部署腳本。
為什么每一個(gè)站點(diǎn)都有一個(gè)腳本的原因則是總有那么一些站點(diǎn)是那么的特殊和優(yōu)秀，當(dāng)然覺(jué)得多數(shù)系統(tǒng)都可以走一個(gè)公共的構(gòu)建腳本。
腳本有不少要調(diào)用其他系統(tǒng)接口的，我則直接用.net core 寫了一個(gè)控制臺(tái)應(yīng)用，專門負(fù)責(zé)這個(gè)事情，畢竟寫shell不是專業(yè)的。
具體的構(gòu)建腳本就不貼上來(lái)了。
腳本執(zhí)行步驟（net core 測(cè)試環(huán)境腳本）：在每一個(gè)部署完成或者出錯(cuò)的時(shí)候都把進(jìn)度反饋到發(fā)布系統(tǒng)上。
1.源代碼在jenkins配置里面已經(jīng)幫忙拉取好了。所以腳本不用拉代碼了。
2.編譯。比如dotnet publish -c Release -r linux-x64 -o “輸出路徑”
3.編譯輸出內(nèi)容打包
4.上傳到ftp。
5.拉取配置文件。
6.將輸入內(nèi)容和配置文件，等打成壓縮包
6.拉取部署配置。要部署到那些機(jī)器，部署要并發(fā)還是要串行等
7.檢查機(jī)器是否已經(jīng)完成SSH免密配置了，沒(méi)有配置則拉取密碼配置好。
8.并行或者串行進(jìn)行發(fā)布操作
9.SSH到目標(biāo)機(jī)器，上傳壓縮包，部署腳本
10.執(zhí)行部署腳本（解壓，停掉原來(lái)的服務(wù)，啟動(dòng)新的服務(wù)，檢查是否啟動(dòng)成功等）

sonar靜態(tài)代碼檢查

在發(fā)布系統(tǒng)中接收到j(luò)ira的發(fā)布請(qǐng)求后，拉取站點(diǎn)的配置，如果是需要進(jìn)行sonar檢查則把請(qǐng)求發(fā)送給sonar的jenkins。
目前我們配置的是發(fā)布到產(chǎn)線的時(shí)候才做sonar的靜態(tài)代碼檢查，然后再sonar系統(tǒng)里面配置了。
后面看需要，是否要對(duì)sonar的結(jié)果進(jìn)行郵件。打算這樣做。每周出一份代碼質(zhì)量報(bào)告，統(tǒng)計(jì)一周內(nèi)已上線的項(xiàng)目和上一周相比錯(cuò)誤，漏洞，壞味道，覆蓋了等數(shù)據(jù)的變化。弄個(gè)定時(shí)任務(wù)，sonar 2個(gè)接口獲取一下數(shù)據(jù)，存儲(chǔ)對(duì)比結(jié)果，發(fā)個(gè)郵件就完事了。

簡(jiǎn)單總結(jié)一下

文章隨便寫寫，很多東西交代的不清楚，還有很多東西壓根就沒(méi)有說(shuō)。比如說(shuō)堡壘機(jī)集成，日志、host監(jiān)控集成等等等。我不會(huì)說(shuō)實(shí)在是我太懶了，打字好累??！
總之，歡迎交流！！雖然實(shí)現(xiàn)的不完整，但是還是適合目前自身的需求的。合適的才是最好的嘛

感謝開(kāi)源界大佬的貢獻(xiàn)，雖然我還沒(méi)錢捐款。讓社區(qū)有那么多那么多好用的產(chǎn)品。
感謝前人已經(jīng)種好的大樹(shù)，很涼快！

整套工具搭建完成，如果真的算時(shí)間估計(jì)也就不到一個(gè)月，當(dāng)然真實(shí)情況是零零散散的，東戳戳，西戳戳。好在做這個(gè)事情之前有一個(gè)簡(jiǎn)單的規(guī)劃，沒(méi)有走彎路，雖然再找國(guó)產(chǎn)產(chǎn)品的路上耗費(fèi)了一些時(shí)間

從開(kāi)始使用開(kāi)始，3個(gè)月不到就發(fā)了不下2000次，這還是在剛起步階段?？上攵?，確實(shí)是生產(chǎn)力工具