公司上線流程 pushonline_alpha
這是在公司將服務部署上線的一個記錄，只是部署很小的python腳本，各公司不同，參考性不是很大
開始吧（版本管理是git）
1.整理好代碼後：git add xxx.py
git commit -m "輸入這次提交的說明"
2.代碼review：git push origin HEAD:refs/for/master%r=username, r=XXX
在公司相應得review管理網頁中中找到相應的提交，review通過後submit就好
3.原來就在master分支上，就不用這步了，如果不在的提交到master分支上去
git push origin HEAD:master
4.開發機上 輸入Pushonline_alpha 我的理解是將代碼提交到遠程的機器上去。然後就等代碼部署好
關於pushonline_alpha命令是個什麽東西，看下面這個：
|
背景 由於業務規模擴大，pushonline的速度和穩定性已經不能滿足業務需求；所以基於nodekeeper，開發了新的上線系統；由於新的系統處於小流量階段，所以暫時取名pushonline_alpha。老的pushonline上線的流程是先由一個server打一個bundle，然後放到hdfs，再ssh到所有需要上線的機器，然後將bundle下載下來再apply完成上線。這個過程首先是受限與上線的單機能力，所以在處理一些上線機器眾多的情況效率會非常低。另外，由於上線以來ssh，所以上線會很不穩定，遇到一些負載高的節點會拖慢整個上線。HDFS作為離線存儲，實時性比較難保證，上傳下載bundle經常會hung住一段時間。最後，新增節點的庫應該上什麽版本並不知道，需要專門的初始化的過程。 實現pushonline_alpha摒棄了ssh的思路，采用基於nodekeeper的方案來實現。nodekeeper簡單來說是采用了Master-agent的框架，每個機器會有一個agent與Master保持心跳，Master通過心跳下發agent需要執行的命令，已經執行過的命令會定期檢查其狀態，保證機器的環境處於一致的狀態。因此新增機器也可以通過增加tag來完成節點初始化，詳細介紹可以參考nodekeeper。 另一方面，pushonline_alpha也廢棄了同步打bundle的方案，采用一個bundle service來訂閱gitlab和gerrit的push事件，收到新的push事件後，會馬上開始打bundle，上傳到一個maven庫，需要上線的時候，直接從maven庫下載就可以，節約了打bundle的時間。 用戶調用pushonline_alpha上線，實際上只是記錄一下當前的commit_id，然後向nodekeeper提交一個命令將XX庫更新到XX commit，然後交給agent去執行，並定期從nodekeeper獲取執行的進度。 |
5.切換管理員用戶（最高權限的用戶）。在開發機上ssh [email protected] 如果發現要輸入密碼的話，先退出來，輸入kinit命令，輸入你的郵箱密碼。然後在ssh就好了。 切換用戶後 用gg 命令就跳轉到想要把服務跑起來的機器上（gg 22.161這樣）
6.在機器上看下git的代碼是不是已經是修改完畢的代碼，然後:
（1）進入/home/tiger/.server 目錄 ，在這個目錄下建立要啟動服務的軟鏈，就是建立real_run所在的文件夾的軟鏈
軟鏈就相當於一個快捷方式的感覺，用命令： ln -s 目標文件夾 服務名稱 來建立
（2）有些機器沒找到.server目錄 ，在/home/tiger/.config/systemd/user/ 下執行相同的操作
7.建立連接後 服務就啟動了，svc命令來處理服務相關
svc -d 服務名稱 ：停止服務
svstat 服務名稱 ：查看服務狀態，如果啟動時間一直是0s,1s的就說明沒啟動起來
svc -u 服務名稱 ：啟動服務
svc -i 服務名稱 :重新啟動服務，查看狀態時，啟動時間會更新
8.註意，啟動的腳步需要有執行權限，遇到了服務怎麽都啟動不起來，就是real_run腳本沒有x權限，要chmod +x 添加下權限
9.關於腳本怎麽寫，可以在.server文件夾下隨便找個服務看看人家的怎麽寫，基本上格式都一樣，改個執行py文件的地址就好
公司上線流程 pushonline_alpha