約定Service構建方式
對於DevOps中，將開發好的軟體交付給運維人員去部署與維護，過程中參雜著諸多不可控制的變數，如環境問題、版本問題等等，而Docker容器極大程度上解決了這些問題，同時對於服務的持續交付，也變得方便和簡潔，本次講講我的整個生成流水線中服務部署方面的一些想法和執行方式，或許不是很中意的想法，並且還可能被認為存在漏洞和錯誤，但是，至少是這個環節是通了的。最完美的前提至少是執行完成，在設計過程中，考慮到了幾種情況，主要是針對伺服器中映象生產者和服務承載者之間的關係，也有不同的實現方式。
一、無需交付
映象生產和服務部署共用伺服器叢集，伺服器之間通過Docker Swarm完成叢集，同時Docker Swarm中的Manager與映象生產者在同一臺伺服器上，管理整個服務叢集。
注意：仍然需要將生產完畢的映象推送到映象倉庫中，因為在同一個叢集中的其他Worker節點需要指定映象下載，映象生產結束後，推送到倉庫，此時發起一個建立服務或是更新服務的命令，指定本伺服器上的叢集完成相應工作。在交付服務時，可以有兩種方式進行交付，採用單個服務的建立指令碼docker service create或是採用多個服務的批量建立指令碼docker stack deploy指定.yaml檔案，將.yaml檔案中的服務進行批量建立或更新。
對於多個服務的建立指令碼，我沒有去嘗試，有興趣的可以檢視 ofollow,noindex">Docker官網 相關資料，對於單個服務的建立或更新指令碼可以採用命令列方式或是使用UI工具去完成建立和更新，如使用Portainer工具，在Portainer中操作是很方便的。
二、手動交付
當映象生產者和服務部署分離時，通常也是這種情形，映象生產者只作為映象的生產，職責便是生產映象，而作為部署伺服器，職責便是承載服務，對外提供服務。這個過程中就存在著，服務由誰建立，什麼時候更新，由誰更新的一些問題，對於這些問題，也在一步一步設計中解答，本次先使用手動交付的形式，使用命令列來完成服務建立和更新，當映象生產完畢後，便是交付環節，手動交付是最為基本的交付方式了。
通過 命令列方式 完成手動交付：
1、在Jenkins中使用命令列完成交付，當映象生產完畢，執行建立服務或是更新服務，這有點隨著映象的變更而變更，無需人為操作，但是也是有問題的，就單個來講，映象的變更往往是由開發人員將程式碼合併到主幹中，才觸動映象更新，這也在一定程度上受限於合併到主幹的時機，如果合併太過頻繁，則映象生產者需要連續生產，並且中間的映象生產過程變得毫無意義了。
2、在Swarm Cluster內使用命令列建立服務完成交付，在Swarm叢集中的Manager節點上單個操作，是可行的，如果叢集數量少，且沒有安裝圖形管理工具之類的，可以使用這種方式，只是如果Swarm Cluster數量過多，需要一個一個切換\登入，也是比較繁瑣的。
3、在其他主機上操控Swarm Cluster使用命令列完成交付，這個過程同直接操作Swarm Cluster也是差不多的，只是可以使用額外的管理主機管理多個Swarm Cluster的Manager節點，這樣一來，也較為方便，直接在一臺非Swarm Cluster內的主機上即可完成所有Swarm Cluster的建立和更新過程。
圖例：直接在Jenkins所在主機上操控Swarm Cluster完成交付
三、藉助工具手動交付
對於命令列來講，多條複雜命令總是難記，有可以直接操作的工具往往是更受歡迎的，而對於Docker來講，Portainer工具是極受歡迎的，快速安裝，簡單的操作介面，豐富的功能等，同樣還有其他不錯的圖形化容器管理工具，如DockerUI、Shipyard等。
1、利用Portainer工具完成手動交付，在Portainer介面中，配置好倉庫地址和使用者名稱密碼，便於私有映象的拉取，至於倉庫，可以是自己搭建的映象倉庫，也可以使用第三方提供的映象倉庫，如阿里雲、騰訊雲映象倉庫。
2、利用其他Docker及Docker Swarm叢集管理工具完成手動交付，至於使用其他的工具，我也沒有使用過，但是工具只不過是將命令列進行了分裝，因此，其他圖形化管理工具也是應該存在這些功能。
圖例：利用Portainer工具操控Swarm Cluster完成交付
四、藉助工具自動交付
對於自動交付，這個功能，只是見到過其他人這麼玩過，猜想了一下工作方式，至於實際嘗試，並沒有去做，因為思考了一些操作過程，感覺我對這個自動交付的環節並不太感冒，因為按照生產來講，追求穩定才是重要的，如果存在測試人員，測試相應服務完畢後，推送測試好的映象，這是運維人員將映象交付到生產環境中，能夠保證不出差錯，雖然失去了效率，但是也在是心安理得。至此，我只能簡單描述下藉助工具完成自動交付過程，在Docker Swarm叢集中的Manager節點或單獨弄一臺伺服器作為映象更新後的交付伺服器，在伺服器中加入Jenkins工具，指定映象版本更新，則拉取最新映象完成服務更新，映象首次推送，則完成服務建立，對於使用批量建立/更新服務的指令碼檔案，沒有使用的太深，但是那個是非常有價值的。
至此，幾種我用過的方式也講完了，在其中對於docker stack deploy使用的較少，因為docker stack deploy使用場景是為了批量服務的建立和更新而存在的，如果對於單個服務我都使用這個命令，有點殺雞用牛刀的感覺，而對於以後的k8s學習，使用批量服務建立更新指令碼檔案，將會是常態。目前 我現在採用的是“藉助工具手動交付“這種方式，原因有幾點，主要是，思考了下，服務交付的意義，主要是為了穩定，少出問題，必須在確保穩定後才能交付部署，經測試人員測試完畢後完成交付到生產環境，這應該是我們所希望能夠見到的，無論開發人員每天或每週有多少個版本更新，經測試人員測試後的穩定版本，才能交付到生產環境中，而不是說開發人員一將分支程式碼合併到主幹中，有新的映象生成了，就直接將新的映象推送到生產環境中，而做到所謂的持續交付的目的，實際的持續交付應該是保證測試完畢到生產部署這個環節具有連續性，穩定性，每一次交付都經得起推敲，具體其中發生了什麼，穩定性如何等，雖然這種方式效率較低，但對於持續交付來講，這個效率也算是可以接受的。
本文地址： https://www.cnblogs.com/CKExp/p/9940469.html
歡迎關注微信訂閱號，有新的文章將同步到訂閱號中
2018-12-10,望技術有成後能回來看見自己的腳步