前言

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

感概一下

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

大概的樣子

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

gitlab

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

jira

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

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

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

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

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

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

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

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

因為涉及到主機(jī)的賬號密碼之類的，所以密碼都是公鑰加密存儲在系統(tǒng)上。
而密碼的使用方有2個，一個是jenkins在部署的時候新機(jī)器在創(chuàng)建SSH免密登錄的時候要用一次，還有就是遠(yuǎn)程管理工具要用，所以對密碼的使用單獨(dú)寫了個小組件用私鑰解密獲得密碼，然后把發(fā)布系統(tǒng)和小組件單獨(dú)管理

jenkins

jenkins絕對可以說是這套工具里面的大佬了，可以說一切都是圍著他在轉(zhuǎn)。
接收發(fā)布系統(tǒng)發(fā)過來的構(gòu)建請求，拉取代碼，編譯，拉取配置文件，打包成部署包，上傳ftp，發(fā)布到私有docker倉庫，部署等等。
還要區(qū)分系統(tǒng)環(huán)境，開發(fā)語言(windows、linux、nodejs、.net core)單獨(dú)處理等。
1.參數(shù)化構(gòu)建過程。比如要構(gòu)建的分支名稱之類的
2.源代碼配置。git源代碼地址，gitlab固定的代碼只讀賬號，通過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ū)動都在這個腳本里面了。分環(huán)境、分開發(fā)語言單獨(dú)編寫的構(gòu)建或部署腳本。
為什么每一個站點(diǎn)都有一個腳本的原因則是總有那么一些站點(diǎn)是那么的特殊和優(yōu)秀，當(dāng)然覺得多數(shù)系統(tǒng)都可以走一個公共的構(gòu)建腳本。
腳本有不少要調(diào)用其他系統(tǒng)接口的，我則直接用.net core 寫了一個控制臺應(yīng)用，專門負(fù)責(zé)這個事情，畢竟寫shell不是專業(yè)的。
具體的構(gòu)建腳本就不貼上來了。
腳本執(zhí)行步驟（net core 測試環(huán)境腳本）：在每一個部署完成或者出錯的時候都把進(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免密配置了，沒有配置則拉取密碼配置好。
8.并行或者串行進(jìn)行發(fā)布操作
9.SSH到目標(biāo)機(jī)器，上傳壓縮包，部署腳本
10.執(zhí)行部署腳本（解壓，停掉原來的服務(wù)，啟動新的服務(wù)，檢查是否啟動成功等）

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

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

簡單總結(jié)一下

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

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

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

從開始使用開始，3個月不到就發(fā)了不下2000次，這還是在剛起步階段。可想而知，確實是生產(chǎn)力工具