前言
隨着系統愈來愈大，開發人員、站點、服務器愈來愈多，微服務化推動，......等等緣由，實現自動化的devops愈來愈有必要。 固然，真實的緣由是，在團隊組建之初就預見到了這些問題，因此從一開始就決定這一塊要自動化。 帶來的實質好處也是顯而易見的，人力成本的節省、規範化的流程、可追溯的發佈歷史、解脫雙手（重複性勞動）、避免人爲操做產生的錯誤等等。前端
##感概一下 1.目前市面上的成套的產品要麼貴的要死，要麼不支持本地部署，要麼就仍是一個demo級別的東西，最重要的仍是每一個公司或者產品都有本身的一些特殊環境或者業務再裏面。不必定都適合。反正是比較難找到好用的，並且是成套的產品來。期待一個devops界的SAP，並且還要便宜！ 2.幾個老大哥產品仍是作得很牛逼！好比jira，confluence，jenkins，sonar。官方文檔很是完善，網上教程多。接口完備。不像某些產品，看上去高大上，一用起來就是各類坑 3.懂開發的運維覺逼是牛逼的程序員！（^_^） 4.人真的很是重要，否則流程什麼的，呵呵，都是個屁......node
##大概的樣子 
固然，目前這套工具還有不少不完善的地方，隨着不停的使用，或者變化的需求來進一步變化。linux
gitlab
開源的git倉庫，主要有幾個用途 1.源代碼管理 分支管理規則能夠參考gitflow，或者規定一個合適本身的就好，微服務化後，一個站點或者說一個項目參與的開發人員只有有限的幾我的。用了簡單的方法，master做爲發佈用分支，每次迭代開發使用新分支，上線前合併到master；線上簡單的fix則直接在master分支上提交。 2.配置文件管理 放在gitlab上，主要是爲了方便管理，以及追溯修改歷史。固然，咱們有本身的配置中心，能走配置中心的都儘可能走配置中心，只有必須是文件配置管理的才放在gitlab上。 3.發佈腳本管理 jenkins須要使用到的發佈腳本。根據環境、源代碼語言、部署方式等有所不一樣 nginx
jira
jira敏捷開發管理工具，管理需求、研發迭代等。在加上他們家公司的wiki作知識庫管理基本穩了。 jira用下來發現仍是至關強大！各類自定義可配置。頁面、字段、流程等等全可配置。有http open api能夠直接調用修改信息、觸發流程等git
使用的發佈流程也比較簡單。開發建立發佈任務，而後提交給測試，測試在jira上操做發佈到測試環境，準線上環境，線上環境進行測試等。準線上環境測試完後要發佈到線上須要讓具備leader權限的人進行一次審覈，一方面是讓leader知道有什麼東西上線了，另外一方面也是安全控制的一些緣由（好比說節假日前夕最好是不在作更新等，要作更新就得報備，否則出問題節假日就得嗝屁）。 程序員
截圖是比較歷史的版本了，最近在jira裏面找了一個進度條插件，而後把構建發佈的實時進度直接反饋到jira的頁面上。這樣就不用再打開發布系統查看發佈進度了，進一步提升使用體驗。docker
發佈流程工做流，根據自身的狀況設計的 shell
發佈系統
這一塊，是咱們本身開發的一個簡單系統。主要做用是銜接各個開源工具的使用。做爲一個粘合劑系統使之分散的各個子工具能連接爲一個總體。 雖然，jira裏面有jenkins插件，jenkins裏面有jira的插件，可是組件對各個系統都有版本要求，而後組件使用上也蠻不方便的，最後也有一些需求要解決起來至關麻煩，因此纔有了本身的發佈系統。 功能仍是比較簡單，一個前端小夥弄弄頁面什麼的1個禮拜就完事了，關鍵仍是把當下的各類新技術都秀了一波，雖然頁面挺醜的。幾個系統的接口調用本身研究寫一寫也就幾天就完事了。 主要完成的幾個功能 1.發佈配置管理 站點或者系統的開發語言，部署的目標系統，要部署那些主機，是否是docker容器方式，docker要部署幾個示例，部署方式併發、串行發佈，要走那一個nginx，綁定的域名，綁定的端口等等信息。 在新的系統或者站點發布的時候由運維和研發協調填寫，後期則由運維來維護，好比擴縮容等 windows
2.接收jira的發佈任務操做通知，並通知到某一個Jenkins去執行，sonar進行靜態代碼檢查等 3.接收jenkins構建部署反饋過來的進度 4.展現構建部署進度 api
5.一部分CMDB系統的功能，主機管理（ip，名稱，用戶名）之類的。原本打算是直接調用CMDB工具的接口的，奈何目前運維在用的CMDB工具很差對接，因此簡單的作了一部分管理工做，加之機器數量還不是太多，人工也仍是能管理過來。
由於涉及到主機的帳號密碼之類的，因此密碼都是公鑰加密存儲在系統上。 而密碼的使用方有2個，一個是jenkins在部署的時候新機器在建立SSH免密登陸的時候要用一次，還有就是遠程管理工具要用，因此對密碼的使用單獨寫了個小組件用私鑰解密得到密碼，而後把發佈系統和小組件單獨管理
jenkins
jenkins絕對能夠說是這套工具裏面的大佬了，能夠說一切都是圍着他在轉。 接收發布系統發過來的構建請求，拉取代碼，編譯，拉取配置文件，打包成部署包，上傳ftp，發佈到私有docker倉庫，部署等等。 還要區分系統環境，開發語言(windows、linux、nodejs、.net core)單獨處理等。 1.參數化構建過程。好比要構建的分支名稱之類的 2.源代碼配置。git源代碼地址，gitlab固定的代碼只讀帳號，經過SSH進行代碼的拉取。 3.調用構建腳本。jenkins內的執行命令大約以下面所示
#!/bin/bash -l
cd /opt/deployscript # 進入構建腳本目錄
git pull #拉取最新的構建腳本
#調用構建腳本
#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的構建腳本
重中之重了，全部的驅動都在這個腳本里面了。分環境、分開發語言單獨編寫的構建或部署腳本。 爲何每個站點都有一個腳本的緣由則是總有那麼一些站點是那麼的特殊和優秀，固然以爲多數系統均可以走一個公共的構建腳本。 腳本有很多要調用其餘系統接口的，我則直接用.net core 寫了一個控制檯應用，專門負責這個事情，畢竟寫shell不是專業的。 具體的構建腳本就不貼上來了。 腳本執行步驟（net core 測試環境腳本）：在每個部署完成或者出錯的時候都把進度反饋到發佈系統上。 1.源代碼在jenkins配置裏面已經幫忙拉取好了。因此腳本不用拉代碼了。 2.編譯。好比dotnet publish -c Release -r linux-x64 -o 「輸出路徑」 3.編譯輸出內容打包 4.上傳到ftp。 5.拉取配置文件。 6.將輸入內容和配置文件，等打成壓縮包 6.拉取部署配置。要部署到那些機器，部署要併發仍是要串行等 7.檢查機器是否已經完成SSH免密配置了，沒有配置則拉取密碼配置好。 8.並行或者串行進行發佈操做 9.SSH到目標機器，上傳壓縮包，部署腳本 10.執行部署腳本（解壓，停掉原來的服務，啓動新的服務，檢查是否啓動成功等）
sonar靜態代碼檢查
在發佈系統中接收到jira的發佈請求後，拉取站點的配置，若是是須要進行sonar檢查則把請求發送給sonar的jenkins。 目前咱們配置的是發佈到產線的時候才作sonar的靜態代碼檢查，而後再sonar系統裏面配置了。 後面看須要，是否要對sonar的結果進行郵件。打算這樣作。每週出一份代碼質量報告，統計一週內已上線的項目和上一週相比錯誤，漏洞，壞味道，覆蓋了等數據的變化。弄個定時任務，sonar 2個接口獲取一下數據，存儲對比結果，發個郵件就完事了。
##簡單總結一下 文章隨便寫寫，不少東西交代的不清楚，還有不少東西壓根就沒有說。好比說堡壘機集成，日誌、host監控集成等等等。我不會說實在是我太懶了，打字好累啊！ 總之，歡迎交流！！雖然實現的不完整，可是仍是適合目前自身的需求的。合適的纔是最好的嘛
感謝開源界大佬的貢獻，雖然我還沒錢捐款。讓社區有那麼多那麼多好用的產品。 感謝前人已經種好的大樹，很涼快！
整套工具搭建完成，若是真的算時間估計也就不到一個月，固然真實狀況是零零散散的，東戳戳，西戳戳。好在作這個事情以前有一個簡單的規劃，沒有走彎路，雖然再找國產產品的路上耗費了一些時間
從開始使用開始，3個月不到就發了不下2000次，這仍是在剛起步階段。可想而知，確實是生產力工具