一、准備環境
！docker-ce---17.06.2-ce
！k8s集群----1.11.1
！helm部署工具---helm-v2.10.0
！spinnaker-charts---spinnaker-0.5.0
環境准備參考我的其他兩篇博文：
https://www.cnblogs.com/cuishuai/p/9485939.html
https://www.cnblogs.com/cuishuai/p/9525656.html
二、示例說明
由於本次只是驗證spinnaker工作流程，所以采用GitHub、dockerhub兩者結合做代碼和鏡像管理。主要使用的是dockerhub的自動構建功能，當然生產環境這一步我們直接放到私有倉庫上去做，代碼的話直接放到gitlab上面管理。
結合spinnaker強大的pipeline和rosco（構建 beta 鏡像的組件，需要配置 Packer 組件使用）實現這個同樣功能的發布流程，這個后續會在更博中寫道。大致的發布流程：
如果生產應用的時候就將圖中的github換成gitlab，dockerhub建議使用企業級的私有倉庫harbor。這個具體會在后面進行講解，本次只是spinnaker的一個發布流程和spinnaker的工作流程的理解。
三、部署
1、Github准備
首先需要創建一個github、dockerhub賬號，這里就不詳細介紹創建過程了。需要利用dockerhub的create automated build與github結合實現代碼更新自動提交構建，本次構建過程參考的是https://www.spinnaker.io/guides/tutorials/codelabs/kubernetes-source-to-prod/ ，代碼放在我的github上面https://github.com/cuishuaigit/spin-kub-demo.git。fork一份代碼到自己的GitHub上面。然后進行一些簡單的配置：
進入剛剛fork的spin-kub-demo項目，點擊右上方的"Settings"---點擊左側欄上的"Integrations & services"---點擊"Add service"在下拉菜單中選擇"Docker"---選擇Add service就完事了。結果如下圖：
2、dockerhub准備
上面准備好github，接下來准備dockerhub。使用dockerhub自動構建鏡像的過程之前已經寫過一篇博文了：https://www.cnblogs.com/cuishuai/p/8483496.html，這里為了完整性，我在詳細介紹一下dockerhub的"Create Automated
Build"的使用流程，首先登陸dockerhub，然后在"Create"的下拉菜單中選擇"Creta Automated Build"---使用Github那個選項：
接下來選擇github上剛剛fork創建的那個spin-kub-demo項目，選擇后進入下面的配置頁面:
master下面的那個branch表示排除master的任意分支, Docker Tag的位置留空表示與branch的name相同。branch name以服務版本號命名。當然為了演示方便直接使用master、latest。上面操作完成，點擊Create，然后進入另外的配置頁面，選擇"Build Settings"----"Trigger"---"Ssave Changes".這樣整個任務的准備工作就結束了。
3、spinnaker創建構建流程
3.1、前面部署的博文中介紹了詳細的搭建及訪問，這就不在詳細介紹了。出於安全考慮，沒有將ui暴漏在外網。我們使用的openvpn進行訪問的，openvpn的搭建參考我的其他博文：https://www.cnblogs.com/cuishuai/p/7992477.html
輸入訪問地址進入ui，點擊"Applications":
當然你的那個可能顯示的和我這里不一樣，那也沒有關系。大致相同就好了，因為我這里還部署了其他的東西比如istio、nfs、prometheus等。
接下來開始創建一個Application。點擊右側的"Actions"在下拉菜單上選擇"Create Application"進入New Application頁面填寫相關信息，Name處自己定義，我用的"skrdemo"，由於我已經創建過了skrdemo不能重復創建，所以圖中使用skrDemo代替skrdemo。Owner Email處填寫自己的郵箱就好了，Repo Type處選擇github，Repo Project處填寫GitHub上剛剛fork的spin-kub-demo，Repo Name處填寫自己的github，我這里是"cuishuaigit"，Instance Port處寫80.：
后點擊Create完成創建。
3.2、創建負載均衡策略（Load Balancer）
skrdemo創建完畢，創建一個 Dev Load Balancer 負載均衡策略，進行 Dev 環境的部署。進入該應用詳情頁面，點擊頂部導航欄 “LOAD BALANCERS”，進入負載均衡列表頁面，默認是沒有任何記錄的。點擊頁面 “Create Load Balancer” 按鈕，在創建負載均衡彈框頁面填寫信息，點擊 “Create” 完成負載均衡策略的創建。這里 “Stack” 處填 dev，可以理解為作為測試環境使用標示，在 “Ports” 欄下邊 “Target Port” 處填 8000，作為對外轉發目標端口。“Advanced Settings” 欄下邊 “Type” 處選擇 ClusterIP，這里可選項有 ClusterIP、LoadBalancer、NodeType，針對不同的應用類型和平台，選擇所支持的類型，這里我選擇默認值 ClusterIP。
Dev Load Balancer 創建完畢后，接下來我們創建一下 Prod Load Balancer 用來進行 Prod 環境的部署。創建過程同上操作，主要修改 “Stack” 為 prod，並且在 “Advanced Settings” 欄下邊 “Type” 處選擇 NodeType，其他保持一致。
3.3創建服務組（Server Group）
skrdemo應用的 Load Balancers 創建完畢，接下來我們創建一個 Dev Service Group 服務組，點擊導航欄 “CLUSTERS”，進入集群列表頁面，默認也是沒有任何記錄的。點擊 “Create Service Group” 按鈕，在創建服務組彈框頁面填寫信息，點擊 “Create” 完成服務組的創建。這里 “Stack” 處依填 dev，“Containers” 處填寫容器 Docker 鏡像地址，這里我們直接使用上邊配置的個人 DockerHub 倉庫鏡像，Spinnaker 會自動拉取所有版本鏡像列表供選擇，這里我選擇 index.docker.io/fastop/spin-kub-demo:latest 作為測試鏡像。“Load Balancers” 處選擇上邊創建的 skrdemo-dev 負載均衡策略。“Replicas” 欄下方 “Capacity” 處填 1，意味着該服務組將啟動 1 個由該容器鏡像啟動的 Pod 實例。“Port” 欄 “Container Port” 處填寫為 8000，保持跟 Load Balancers Target 端口一致，“Container” 欄下方 “name” 修改為 skrdemo。點擊 “Probes” 欄，點擊 “Enable Readiness Probe” 按鈕來添加探測，修改 “Port” 為 8000，這里 “Readiness Probe” 為服務是否准備就緒的探測。
注意：這里如果在 Containers 欄下拉選擇 image 時沒有自己項目的鏡像列表，只有 library 的話，需要修改 values.yaml 配置自己的 DockerHub 倉庫，當然也可以使用其他私有倉庫配置。
服務組創建完成就會自動拉去鏡像，並創建服務，訪問方式和deck的訪問方式相同，找到相應服務的pod名稱，端口為8000，使用kubectl port-forward pod名稱 8888:8000,在配置nginx服務：
server{
listen 82;
server_name 0.0.0.0;
location / {
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
就可以通過內網代理訪問服務，：
這個頁面是github上項目的content目錄下面的index.html展示的內容：
四、spinnaker自動部署（pipeline）
1、創建dev環境的自動deploy
點擊 skrdmo 應用頁的導航欄 “PIPELINES”，點擊頁面右上角 “Create” 按鈕，彈框中 “Type” 選擇 Pipeline，“Pipeline Name” 處填寫 Deploy to Dev，點擊 “Create” 按鈕完成創建。
進入到 Deploy to Dev 流程設置頁面，在 “Automated Triggers” 欄下點擊 “Add Trigger”，“Type” 欄選擇 Docker Registry，“Registry Name” 欄會加載 values.yaml 文件中倉庫配置的賬戶名稱，這里我選擇 dockerhub，“Organization” 欄會加載選擇的 Registry 下配置的所屬組織列表，這里我選擇自己的賬戶 fastop，“Image” 欄選擇要觸發的鏡像，這里我選擇 fastop/spin-kube-demo 鏡像，“Tag” 欄這里不填，意思就是匹配任何新的 Tag。以上配置的作用就是，當我們的 DockerHub 倉庫中fastop/spin-kube-demo 有新的鏡像生成時，會自動觸發該流程啟動。
接下來點擊 “Add Stage” 按鈕，增加一個節點，該節點執行部署鏡像到 Dev 環境。“Type” 欄選擇 Deploy，“Stage Name” 欄填寫 Deploy to Dev，如下圖所示。
“Deploy Configuration” 欄下點擊 “Add Server Group” 在彈框中 “Copy configuration from” 可以選擇之前我們創建的服務組 demo-dev，點擊 “Use This Template” 按鈕，進入到配置部署集群彈框頁面。
配置部署集群彈框頁面跟之前創建的服務組 skrdemo-dev 一樣，不過有一個地方需要修改一下，在 “Container” 欄下邊 “Image” 選擇 Image from Trigger(s) 這一項，意思是跟 “Automated Triggers” 那里鏡像保持一致，頁面其他配置保持不變，最后點擊"Add",完成添加
最后，添加一個節點，目的是為了銷毀之前的 demo-dev 服務組（上邊已經啟動的 demo-dev 服務組）。點擊 “Add Stage” 按鈕，“Type” 欄選擇 Destory Server Group，“Destroy Server Group Configuration” 欄下 “Namespaces” 選擇 default，“Cluster” 選擇 demo-dev，“Target” 選擇 Previous Server Group。選擇 default Namespaces，因為之前的 demo-dev 服務組就是使用的 default 命名空間，如果我們不太清楚選擇哪個，可以點擊下方 “Toggle for list of existing clusters” 鏈接，就會過濾掉其他 Namespaces。Target 處一定要選擇 Previous Server Group，意思是銷毀掉之前的服務組，這里別選錯了，最后點擊"Save Changes"保存pipeline。
此時可以試驗一下配置是否生效，直接修改github上的代碼，做一個提交指定docker tag，這樣就會自動觸發pipeline構建：
如圖所示，紅框標記出的結果，表示可以自動觸發更新。
2、創建驗證流程
接下來，我們創建一個新的流程，為了驗證 deploy to dev 流程是否部署成功。點擊 “Create” 按鈕，彈框中 “Pipeline Name” 欄填 Verity deploy dev，進入到 Verity deploy dev 流程設置頁面，在 “Automated Triggers” 欄下點擊 “Add Trigger”，“Type” 欄選擇 Pipeline，“Pipeline” 欄選擇 deploy to dev 流程，“Pipeline Status” 欄勾選 successful，意思是當 deploy to dev 流程成功執行后，將自動觸發該流程。
然后添加一個stage，目的是讓流程暫停，等待人工驗證本次部署實例是否成功。點擊 “Add Stage” 按鈕，“Type” 欄選擇 Manual Judgment，“Instructions” 欄輸入 <b>Manual Judgment Verity if “skrdemo-dev” server run ok</b> 對該流程做一下簡要的說明信息（支持 Html ），"Judgement Inputs"可以自己定義一個操作來繼續后面的stage或者停止本次有問題的構建，我這里定義了輸入"ok"繼續后面的操作。
這里只是模擬了簡單的人工決策，具體需要結合測試反饋、和一些服務狀態來判斷是否進行下一步構建。
3、創建prod的自動deploy
創建一個新的流程，目的是當 Verity Deploy-Dev 流程人工驗證通過后，執行自動化部署到 Prod 環境中去。點擊 “Create” 按鈕，彈框中 “Pipeline Name” 欄填 deploy to prod，進入到 deploy to prod 流程設置頁面，在 “Automated Triggers” 欄下點擊 “Add Trigger”，“Type” 欄選擇 Pipeline，“Pipeline” 欄選擇 Verity deploy dev 流程，“Pipeline Status” 欄勾選 successful，意思是當 Verity deploy dev 流程成功執行后，將自動觸發該流程。
然后添加一個stage，目的是從集群中找到最新的鏡像，既然是自動化部署，dev 環境 Image 已經測試完畢，那么就不需要再指定部署哪一個鏡像了，直接從集群中查找最新的哪個鏡像就是本次要部署的鏡像了。點擊 “Add Stage” 按鈕，“Type” 欄選擇 Find Image from Cluster，“Find Image from Cluster Configuration” 欄下 “Namespace” 選擇 default，“Cluster” 欄選擇鏡像所在集群 skrdemo-dev，“Server Group Selection” 欄選擇 Newest，表示最新的服務組。“Image Name Pattern” 欄填 .*，這里說明一下，此處用來過濾鏡像名稱匹配，當單個 Pod 中部署多個不同鏡像時使用，這里我們只有一個鏡像，所以可以使用 .* 匹配所有，點擊"Add"保存。
接着添加一個stage用於將查找到的鏡像部署到 Prod 環境中去。點擊 “Add Stage” 按鈕，“Type” 欄選擇 Deploy，“Stage Name” 欄輸入 deploy to prod，“Deploy Configuration” 欄下點擊 “Add Server Group” 按鈕，彈出選擇服務組對話框,點擊"Add"保存。
配置部署集群彈框頁面跟之前創建的服務組 skrdemo-dev 一樣，不過這次要修改三個地方，第一個地方 “Stack” 欄修改為 prod；第二個地方 “Load Balancers” 欄刪除原 demo-dev 並選擇 skrdemo-prod；第三個地方 “Container” 欄下邊 “Image” 選擇 Find Image Result(s) skrdemo-dev.* 這一項，意思是跟上一節點中查找 Image 結果保持一致，頁面其他配置保持不變，點擊"Add"保存
最后我們添加一個stage，目的是當新的部署完成后，Prod 環境中老版本的該實例將廢棄掉不再接入流量。點擊 “Add Stage” 按鈕，“Type” 欄選擇 Disable Cluster，“Disable Cluster Configuration” 欄下 “Namespaces” 處繼續選擇 default，“Cluster” 處填寫 skrdemo-prod，注意：這里沒法使用點擊 “Toggle for list of existing clusters” 鏈接方式過濾 namespace，因為暫時只有 skrdemo-dev 集群運行中，skrdemo-prod 服務組還未創建，沒法選擇，這里只能手動填寫，填寫完成記得點擊"Save Changes"保存。
4、運行驗證流程
通過上面的操作我們創建了delay to dev-->Verity deploy dev-->deploy to prod整個流程，代碼提交后自動構建。
由於前面驗證自動發布觸發構建dev的時候使用了，test為tag，現在在github上新建一個branch，名為sndz：
觸發構建后，中間有個人工決策，選中"ok"點擊"Continue"繼續后面的構建。
完全發布完成后顯示如下圖：
五、訪問測試
dev和prod環境結果都是如下圖：
看一下github上的代碼：
證明部署成功！