我的devops實踐經驗分享一二

前言

隨著系統越來越大，開發人員、網站、伺服器越來越多，微服務化推進，......等等原因，實現自動化的devops越來越有必要。
當然，真實的原因是，在團隊組建之初就預見到了這些問題，所以從一開始就決定這一塊要自動化。
帶來的實質好處也是顯而易見的，人力成本的節省、正常化的流程、可追溯的發布曆史、解脫雙手（重複性勞動）、避免人為操作產生的錯誤等等。

感概一下

1.目前市面上的成套的產品要麼貴的要死，要麼不支援本地部署，要麼就還是一個demo層級的東西，最重要的還是每個公司或者產品都有自己的一些特殊環境或者業務再裡面。不一定都適合。反正是比較難找到好用的，而且是成套的產品來。期待一個devops界的SAP，而且還要便宜！
2.幾個老大哥產品還是做得很牛逼！比如jira，confluence，jenkins，sonar。官方文檔非常完善，網上教程多。介面完備。不像某些產品，看上去高大上，一用起來就是各種坑
3.懂開發的營運覺逼是牛逼的程式員！（^_^）
4.人真的非常重要，不然流程什麼的，呵呵，都是個屁......

大概的樣子

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

gitlab

開源的git倉庫，主要有幾個用途
1.原始程式碼控制
分支管理規則可以參考gitflow，或者規定一個合適自己的就好，微服務化後，一個網站或者說一個項目參與的開發人員只有有限的幾個人。用了簡單的方法，master作為發布用分支，每次反覆式開發法使用新分支，上線前合并到master；線上簡單的fix則直接在master分支上提交。
2.設定檔管理
放在gitlab上，主要是為了方便管理，以及追溯修改曆史。當然，我們有自己的配置中心，能走配置中心的都盡量走配置中心，只有必須是檔案組態管理的才放在gitlab上。
3.發布指令碼管理
jenkins需要使用到的發布指令碼。根據環境、原始碼語言、部署方式等有所不同

jira

jira敏捷開發管理工具，管理需求、研發迭代等。在加上他們家公司的wiki做知識庫管理員基本穩了。
jira用下來發現還是相當強大！各種自訂可配置。頁面、欄位、流程等等全可配置。有http open api可以直接調用修改資訊、觸發流程等

使用的發布流程也比較簡單。開發建立發布任務，然後提交給測試，測試在jira上操作發布到測試環境，準線上環境，線上環境進行測試等。準線上環境測試完後要發布到線上需要讓具有leader許可權的人進行一次審核，一方面是讓leader知道有什麼東西上線了，另一方面也是安全控制的一些原因（比如說節假日前夕最好是不在做更新等，要做更新就得報備，不然出問題節假日就得嗝屁）。

是比較曆史的版本了，最近在jira裡面找了一個進度條外掛程式，然後把構建發布的即時進度直接反饋到jira的頁面上。這樣就不用再開啟發布系統查看發布進度了，進一步提高使用體驗。

發布流程工作流程，根據自身的情況設計的

發布系統

這一塊，是我們自己開發的一個簡單系統。主要作用是銜接各個開源工具的使用。作為一個粘合劑系統使之分散的各個子工具能連結為一個整體。
雖然，jira裡面有jenkins外掛程式，jenkins裡面有jira的外掛程式，但是組件對各個系統都有版本要求，然後組件使用上也蠻不方便的，最後也有一些需求要解決起來相當麻煩，所以才有了自己的發布系統。
功能還是比較簡單，一個前端小夥弄弄頁面什麼的1個禮拜就完事了，關鍵還是把當下的各種新技術都秀了一波，雖然頁面挺醜的。幾個系統的介面調用自己研究寫一寫也就幾天就完事了。
主要完成的幾個功能
1.發布組態管理
網站或者系統的開發語言，部署的目標系統，要部署那些主機，是不是docker容器方式，docker要部署幾個樣本，部署方式並發、串列發布，要走那一個nginx，綁定的網域名稱，綁定的連接埠等等資訊。
在新的系統或者網站發布的時候由營運和研發協調填寫，後期則由營運來維護，比如擴縮容等

2.接收jira的發布任務操作通知，並通知到某一個Jenkins去執行，sonar進行靜態代碼檢查等
3.接收jenkins構建部署反饋過來的進度
4.展示構建部署進度

5.一部分CMDB系統的功能，主機管理（ip，名稱，使用者名稱，密碼）之類的。方便。
至於為什麼不用世面上已有的CMDB系統，也實屬無賴，要麼要錢，要麼好麻煩、要麼沒介面。索行自己簡單做一個。能滿足功能即可。
因為涉及到主機的帳號密碼之類的，所以密碼都是公開金鑰加密儲存在系統上。
而密碼的使用方有2個，一個是jenkins在部署的時候新機器在建立SSH免密登入的時候要用一次，還有就是遠端管理工具要用，所以對密碼的使用單獨寫了個小工具用私密金鑰解密獲得密碼，然後把發布系統和小工具單獨管理

jenkins

jenkins絕對可以說是這套工具裡面的大佬了，可以說一切都是圍著他在轉。
接收發布系統發過來的構建請求，拉取代碼，編譯，拉取設定檔，打包成部署套件，上傳ftp，發布到私人docker倉庫，部署等等。
還要區分系統內容，開發語言(windows、linux、nodejs、.net core)單獨處理等。
1.參數化構建過程。比如要構建的分支名稱之類的
2.原始碼配置。git原始碼地址，gitlab固定的代碼唯讀帳號，通過SSH進行代碼的拉取。
3.調用構建指令碼。jenkins內的執行命令大約如下面所示

#!/bin/bash -lcd /opt/deployscript # 進入構建指令碼目錄git pull #拉取最新的構建指令碼#調用構建指令碼#workspace,build_number,jobname,project_name,git_commit,git_branch,env,jira_id,useridsh /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個介面擷取一下資料，儲存對比結果，發個郵件就完事了。

簡單總結一下

文章隨便寫寫，很多東西交代的不清楚，還有很多東西壓根就沒有說。比如說Bastion Host整合，日誌、host監控整合等等等。我不會說實在是我太懶了，打字好累啊！
總之，歡迎交流！！雖然實現的不完整，但是還是適合目前自身的需求的。合適的才是最好的嘛

感謝開源界大佬的貢獻，雖然我還沒錢捐款。讓社區有那麼多那麼多好用的產品。
感謝前人已經種好的大樹，很涼快！

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

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