對於DevOps中，將開發好的軟件交付給運維人員去部署與維護，過程中參雜着諸多不可控制的變量，如環境問題、版本問題等等，而Docker容器極大程度上解決了這些問題，同時對於服務的持續交付，也變得方便和簡潔，本次講講我的整個生成流水線中服務部署方面的一些想法和執行方式，或許不是很中意的想法，並且還可能被認為存在漏洞和錯誤，但是，至少是這個環節是通了的。最完美的前提至少是運行完成，在設計過程中，考慮到了幾種情況，主要是針對服務器中鏡像生產者和服務承載者之間的關系，也有不同的實現方式。
一、無需交付
鏡像生產和服務部署共用服務器集群，服務器之間通過Docker Swarm完成集群，同時Docker Swarm中的Manager與鏡像生產者在同一台服務器上，管理整個服務集群。
注意：仍然需要將生產完畢的鏡像推送到鏡像倉庫中，因為在同一個集群中的其他Worker節點需要指定鏡像下載，鏡像生產結束后，推送到倉庫，此時發起一個創建服務或是更新服務的命令，指定本服務器上的集群完成相應工作。在交付服務時，可以有兩種方式進行交付，采用單個服務的創建腳本docker service create或是采用多個服務的批量創建腳本docker stack deploy指定.yaml文件，將.yaml文件中的服務進行批量創建或更新。
對於多個服務的創建腳本，我沒有去嘗試，有興趣的可以查看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工具是極受歡迎的，快速安裝，簡單的操作界面，豐富的功能等，同樣還有其他不錯的圖形化容器管理工具，如Seagull、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,望技術有成后能回來看見自己的腳步