對於devops中，將開發好的軟體交付給運維人員去部署與維護，過程中參雜著諸多不可控制的變數，如環境問題、版本問題等等，而docker容器極大程度上解決了這些問題，同時對於服務的持續交付，也變得方便和簡潔，本次講講我的整個生成流水線中服務部署方面的一些想法和執行方式，或許不是很中意的想法，並且還可能被認為存在漏洞和錯誤，但是，至少是這個環節是通了的。最完美的前提至少是執行完成，在設計過程中，考慮到了幾種情況，主要是針對伺服器中映象生產者和服務承載者之間的關係，也有不同的實現方式。
映象生產和服務部署共用伺服器集群，伺服器之間通過docker swarm完成集群，同時docker swarm中的manager與映象生產者在同一臺伺服器上，管理整個服務集群。
對於多個服務的建立指令碼，我沒有去嘗試，有興趣的可以檢視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等。
2、利用其他docker及docker swarm集群管理工具完成手動交付，至於使用其他的工具，我也沒有使用過，但是工具只不過是將命令列進行了分裝，因此，其他圖形化管理工具也是應該存在這些功能。
圖例：利用portainer工具操控swarm cluster完成交付
對於自動交付，這個功能，只是見到過其他人這麼玩過，猜想了一下工作方式，至於實際嘗試，並沒有去做，因為思考了一些操作過程，感覺我對這個自動交付的環節並不太感冒，因為按照生產來講，追求穩定才是重要的，如果存在測試人員，測試相應服務完畢後，推送測試好的映象，這是運維人員將映象交付到生產環境中，能夠保證不出差錯，雖然失去了效率，但是也在是心安理得。至此，我只能簡單描述下借助工具完成自動交付過程，在docker swarm集群中的manager節點或單獨弄一台伺服器作為映象更新後的交付伺服器，在伺服器中加入jenkins工具，指定映象版本更新，則拉取最新映象完成服務更新，映象首次推送，則完成服務建立，對於使用批量建立/更新服務的指令碼檔案，沒有使用的太深，但是那個是非常有價值的。
至此，幾種我用過的方式也講完了，在其中對於docker stack deploy使用的較少，因為docker stack deploy使用場景是為了批量服務的建立和更新而存在的，如果對於單個服務我都使用這個命令，有點殺雞用牛刀的感覺，而對於以後的k8s學習，使用批量服務建立更新指令碼檔案，將會是常態。目前我現在採用的是「借助工具手動交付「這種方式，原因有幾點，主要是，思考了下，服務交付的意義，主要是為了穩定，少出問題，必須在確保穩定後才能交付部署，經測試人員測試完畢後完成交付到生產環境，這應該是我們所希望能夠見到的，無論開發人員每天或每週有多少個版本更新，經測試人員測試後的穩定版本，才能交付到生產環境中，而不是說開發人員一將分支**合併到主幹中，有新的映象生成了，就直接將新的映象推送到生產環境中，而做到所謂的持續交付的目的，實際的持續交付應該是保證測試完畢到生產部署這個環節具有連續性，穩定性，每一次交付都經得起推敲，具體其中發生了什麼，穩定性如何等，雖然這種方式效率較低，但對於持續交付來講，這個效率也算是可以接受的。
2018-12-10,望技術有成後能回來看見自己的腳步
Service使用方式
使用service的場合 1.乙個或多個activity需要向同一應用中的service發出執行某一操作的命令。ps 不需要繫結 2.某個activity需要同一應用中的service為其單獨服務，當此activity消毀時，也將為其服務的service一併消毀。ps 需要繫結 3.多個activi...
Service的啟動方式
service的啟動方式 兩種啟動模式，一種是非繫結啟動模式，另一種是繫結啟動模式。一 startservice方式啟動 1 intent intent new intent this,firstservice.class 2 開啟服務 3 startservice intent 二 繫結啟動模式 ...
Service 兩種啟動方式
service的生命週期service的生命週期方法比activity少一些，只有oncreate,onstart,ondestroy 我們有兩種方式啟動乙個service,他們對service生命週期的影響是不一樣的。1通過startservice service會經歷oncreate onsta...