約定Service構建方式

　　對於DevOps中，將開發好的軟件交付給運維人員去部署與維護，過程當中參雜着諸多不可控制的變量，如環境問題、版本問題等等，而Docker容器極大程度上解決了這些問題，同時對於服務的持續交付，也變得方便和簡潔，本次講講個人整個生成流水線中服務部署方面的一些想法和執行方式，或許不是很中意的想法，而且還可能被認爲存在漏洞和錯誤，可是，至少是這個環節是通了的。最完美的前提至少是運行完成，在設計過程當中，考慮到了幾種狀況，主要是針對服務器中鏡像生產者和服務承載者之間的關係，也有不一樣的實現方式。 

 

1、無需交付

　　鏡像生產和服務部署共用服務器集羣，服務器之間經過Docker Swarm完成集羣，同時Docker Swarm中的Manager與鏡像生產者在同一臺服務器上，管理整個服務集羣。

　　

　　注意：仍然須要將生產完畢的鏡像推送到鏡像倉庫中，由於在同一個集羣中的其餘Worker節點須要指定鏡像下載，鏡像生產結束後，推送到倉庫，此時發起一個建立服務或是更新服務的命令，指定本服務器上的集羣完成相應工做。在交付服務時，能夠有兩種方式進行交付，採用單個服務的建立腳本docker service create或是採用多個服務的批量建立腳本docker stack deploy指定.yaml文件，將.yaml文件中的服務進行批量建立或更新。

　　對於多個服務的建立腳本，我沒有去嘗試，有興趣的能夠查看Docker官網相關資料，對於單個服務的建立或更新腳本能夠採用命令行方式或是使用UI工具去完成建立和更新，如使用Portainer工具，在Portainer中操做是很方便的。

 

2、手動交付

　　當鏡像生產者和服務部署分離時，一般也是這種情形，鏡像生產者只做爲鏡像的生產，職責即是生產鏡像，而做爲部署服務器，職責即是承載服務，對外提供服務。這個過程當中就存在着，服務由誰建立，何時更新，由誰更新的一些問題，對於這些問題，也在一步一步設計中解答，本次先使用手動交付的形式，使用命令行來完成服務建立和更新，當鏡像生產完畢後，即是交付環節，手動交付是最爲基本的交付方式了。

　　經過命令行方式完成手動交付：

　　一、在Jenkins中使用命令行完成交付，當鏡像生產完畢，執行建立服務或是更新服務，這有點隨着鏡像的變動而變動，無需人爲操做，可是也是有問題的，就單個來說，鏡像的變動每每是由開發人員將代碼合併到主幹中，才觸動鏡像更新，這也在必定程度上受限於合併到主幹的時機，若是合併太過頻繁，則鏡像生產者須要連續生產，而且中間的鏡像生產過程變得毫無心義了。

　　二、在Swarm Cluster內使用命令行建立服務完成交付，在Swarm集羣中的Manager節點上單個操做，是可行的，若是集羣數量少，且沒有安裝圖形管理工具之類的，可使用這種方式，只是若是Swarm Cluster數量過多，須要一個一個切換\登陸，也是比較繁瑣的。

　　三、在其餘主機上操控Swarm Cluster使用命令行完成交付，這個過程同直接操做Swarm Cluster也是差很少的，只是可使用額外的管理主機管理多個Swarm Cluster的Manager節點，這樣一來，也較爲方便，直接在一臺非Swarm Cluster內的主機上便可完成全部Swarm Cluster的建立和更新過程。

　　

　　圖例：直接在Jenkins所在主機上操控Swarm Cluster完成交付

 

3、藉助工具手動交付

　　對於命令行來說，多條複雜命令老是難記，有能夠直接操做的工具每每是更受歡迎的，而對於Docker來說，Portainer工具是極受歡迎的，快速安裝，簡單的操做界面，豐富的功能等，一樣還有其餘不錯的圖形化容器管理工具，如Seagull、Shipyard等。

　　一、利用Portainer工具完成手動交付，在Portainer界面中，配置好倉庫地址和用戶名密碼，便於私有鏡像的拉取，至於倉庫，能夠是本身搭建的鏡像倉庫，也可使用第三方提供的鏡像倉庫，如阿里雲、騰訊雲鏡像倉庫。

　　

　　二、利用其餘Docker及Docker Swarm集羣管理工具完成手動交付，至於使用其餘的工具，我也沒有使用過，可是工具只不過是將命令行進行了分裝，所以，其餘圖形化管理工具也是應該存在這些功能。

　　

　　圖例：利用Portainer工具操控Swarm Cluster完成交付

 

4、藉助工具自動交付

　　對於自動交付，這個功能，只是見到過其餘人這麼玩過，猜測了一下工做方式，至於實際嘗試，並無去作，由於思考了一些操做過程，感受我對這個自動交付的環節並不太感冒，由於按照生產來說，追求穩定纔是重要的，若是存在測試人員，測試相應服務完畢後，推送測試好的鏡像，這是運維人員將鏡像交付到生產環境中，可以保證不出差錯，雖然失去了效率，可是也在是問心無愧。至此，我只能簡單描述下藉助工具完成自動交付過程，在Docker Swarm集羣中的Manager節點或單獨弄一臺服務器做爲鏡像更新後的交付服務器，在服務器中加入Jenkins工具，指定鏡像版本更新，則拉取最新鏡像完成服務更新，鏡像首次推送，則完成服務建立，對於使用批量建立/更新服務的腳本文件，沒有使用的太深，可是那個是很是有價值的。

　　

 

 　　至此，幾種我用過的方式也講完了，在其中對於docker stack deploy使用的較少，由於docker stack deploy使用場景是爲了批量服務的建立和更新而存在的，若是對於單個服務我都使用這個命令，有點殺雞用牛刀的感受，而對於之後的k8s學習，使用批量服務建立更新腳本文件，將會是常態。目前我如今採用的是「藉助工具手動交付「這種方式，緣由有幾點，主要是，思考了下，服務交付的意義，主要是爲了穩定，少出問題，必須在確保穩定後才能交付部署，經測試人員測試完畢後完成交付到生產環境，這應該是咱們所但願可以見到的，不管開發人員天天或每週有多少個版本更新，經測試人員測試後的穩定版本，才能交付到生產環境中，而不是說開發人員一將分支代碼合併到主幹中，有新的鏡像生成了，就直接將新的鏡像推送到生產環境中，而作到所謂的持續交付的目的，實際的持續交付應該是保證測試完畢到生產部署這個環節具備連續性，穩定性，每一次交付都經得起推敲，具體其中發生了什麼，穩定性如何等，雖然這種方式效率較低，但對於持續交付來說，這個效率也算是能夠接受的。

 

　本文地址：http://www.javashuo.com/article/p-xegmhjlg-ew.html

　歡迎關注微信訂閱號，有新的文章將同步到訂閱號中

　

2018-12-10,望技術有成後能回來看見本身的腳步