在專案實踐中，如何進行容器化改造和DevOps建設？

縱觀虛擬化技術的發展在歷史，虛擬化技術跨越IT架構，實現包括資源、應用、網路、桌面在內的全系統虛擬化的發展階段。許多金融、保險等行業早已完成從物理機到虛擬化的轉換。使用虛擬化技術一定程度上降低了運維複雜性，提升了資源的使用率，但這種虛擬化技術可視作雲端計算中IaaS的發展。當前移動多媒體APP和互聯金融、大資料等行業的業務面臨如下問題期待解決：

1. 應用系統基礎元件多：由於使用的基礎軟體多為複雜商業軟體，功能繁多，真正經常使用的功能一般都有少數。這些基礎軟體系統架構複雜、安裝部署複雜度呈曲線上升

2. 應用部署與升級複雜：應用系統規模越來越複雜，龐大的部署架構樣式使得應用的安裝、部署和更新也相對比較複雜，部署訓運維成本都成倍增加

3. 敏捷與高效管理困難：在移動APP和網際網路金融等多種行業的激烈市場競爭時，應用業務的需求變化越發頻繁，同時也希望研發部門的軟體交付週期越來越短，要高效、敏捷開發、Devops 、增強應用感知

4. 面臨硬體使用率低、資源分配排程緩慢的問題，無法滿足應用快速上線、彈性伸縮、智慧決策的需求

為瞭解決上述問題從而更好的提升研發和運維團隊的生產力，而更加靈活、高效、快速的滿足業務系統需求，更好提升業務價值。這就需要引入容器技術，使用容器雲它可以從本質上更好的解決面臨的問題。

過去一年美國超過 40% 的公司嘗試過Docker，並且四分之一的公司使用了編排系統。一些大型企業的資料庫、大資料等應用都在逐步採用容器技術。

容器的價值

容器的優勢

1. 標準化應用的部署和交付：由於容器映象的方式實現執行環境的標準化，遮蔽應用部署過程中針對不同環境需要的環境配置、安裝步驟等複雜過程。類似“沙箱”技術，每臺主機上可執行幾百到上千容器，提供服務

2. 加速Devops的落地實施：容器的理念及其技術特點，能夠更好的與CI/CD技術進行融合，促進CI/CD理念的落地，可從技術手段上保證專案管理方式和管理理念的真正有效落地

3. 有效整合現有資源：容器可執行在多種雲平臺環境中，物理、虛擬機器、阿裡雲、AWS、OpenStack、Azure等，可實現對企業不同的基礎資源的統一化管理，降低系統運維難度

4. 提升資源利用率：容器是基於作業系統的輕量級虛擬化技術，共享作業系統的核心行程和核心資源，從而有效節省作業系統級資源開銷， 容器啟動速度快，佔用資源少，透過容器密度的提升更好的利用資源

5. 管理更加簡單： 使用容器技術，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分發和更新，從而實現自動化並且高效的管理

6. 生態系統完善：使用容器元件，組建企業級映象倉庫，實現企業級應用商店功能，應用系統日誌監控等，幾乎是應有盡有

一、專案標的

1、專案描述

規模：50臺業務節點機

專案標的：容器管理平臺

提供高可用佈署，異構環境管理，應用叢集化佈署/升級/回滾、服務發現、健康檢查、排程、彈性伸縮、負載均衡、日誌/監控等功能

2、映象管理倉庫

提供高可用映象倉庫佈署、映象安全、映象管理、訪問控制等

3、應用容器化

營銷平臺應用系統的容器化改造及上線

4、持續整合/部署

實現營銷系統持續整合/部署的全自動化流程

1、容器平臺設計要求

由於實施部署環境是在某企業內部阿裡雲（私有雲）中進行搭建容器管理平臺。具體環境描述與要求如下：

1. 使用阿裡雲私有雲平臺統一管理，有多處機房，要求開發、測試環境與生產環境隔離

2. 需要共用一個高可用的映象倉庫，用於儲存企業內部的應用映象

3. 使用VPC專用網路，網路環境複雜；沒有硬體負載均衡器，只有阿裡雲的SLB

4. 目的是透過容器管理平臺可以提高虛擬主機的利用率

5. 平臺需要高可用部署，提供穩定可靠的執行環境

6. 要有針對部署的業務系統的統一日誌收集和檢視以及篩選功能

7. 有兩套業務系統需要容器化，而且業務系統操作要隔離

8. 每套業務系統容器化模組需要實現CICD

9. 建立企業級的應用商店，為企業提供一鍵式部署應用的功能

2、基礎框架概覽

3、容器管理平臺搭建標的

容器管理平臺的基礎環境：

三、應用微服務化

1、應用微服務化的好處

四個方面的優點，分別如下：

1. 透過分解巨大單體式應用為多個服務的方法解決了複雜性問題。每個微服務元件都是簡單靈活的，能夠獨立部署

2. 可以使得每個服務都有專門的開發團隊負責，更專註、更高效 、更可靠

3. 微服架構樣式每個微服務之間是低耦合的，微服務內部是高內聚的，每個微服務很容易按需擴充套件

4. 微服務架構與語言工具無關，自由選擇合適的語言和工具，高效的完成業務標的

2、應用微服務化的原則

四個原則如下：

1. AKF拆分原則

2. 前後端分離

3. 無狀態服務

4. Restful通訊風格

3、營銷平臺服務架構

應用微服務化，需要根據微服務應用的設計原則和企業內部應用實際情況進行部署情況進行合理選擇。

1. Nginx：做為反向代理和負載均衡的配置，進行容器化配置

2. 前端：靜態stN和應用層中介軟體Tomcat

3. 基礎元件層：ActiveMQ、Kafka、Redis叢集和單機以及MongoDB叢集容器化

4. 服務層：由zookeeper、CSF提供主站app與公共服務、連線資料庫、後臺業務處理建立通訊

4、營銷平臺服務關係圖

5、微服務化思路

網際網路和移動多媒體應用的發展，在敏捷快速迭代、高可用、高效能、高併發等方面要求越所以，我們採用微服務化是把應用拆解為多個應用服務，組合，每個服務自治，以達到更加靈活，維護方便的效果。下麵是根據客戶業務系統進行拆分的方式。

1. 基礎服務元件：像ActiveMQ叢集、Kafka叢集、Redis主從叢集、MongoDB叢集以及Redis單點，這些相對容易進行容器化改造，只要按照業務應用的部署方式需求，進行容器化

2. ZooKeeper和ZKWeb：服務間通訊和註冊端（ZooKeeper叢集）和管理端（ZKWeb），分開進行應用容器化設計

3. Csf_server和csf_web：主要是提供服務，所有的公共服務，連線資料庫、後臺業務處理等服務和管理

4. 業務端：stN是靜態資源主要是從專案工程中將靜態檔案（html、js、css、img、images等），單獨拆分出來，進行獨立部署，從而達到動靜分離的目的。

5. Rmdp：是後臺管理端，產品釋出，訂單管理、優惠策略、審核等一系列的管理操作

6. Nginx負載：入口nginx主要配置主機分發，透過URL字尾來訪問那此業務主機

7. CSF和airmdp資料庫：阿裡雲RDS資料庫服務服務，不需要容器化

6、容器化展示

透過容器化管理平臺把營銷平臺執行容器化元件，上架到容器平臺的應用棧中。對接資料庫，進行業務連續性的功能測試，確保業務的流程正常。

7、營銷平臺聯調

8、應用商店

構建企業應用商店和一鍵部署應用能力。

9、新增雲主機

新增主機驅動，對Machine的管理更加精進了一步，管理Catalog應用市場一樣管理Machine Driver，部署和管理方式更加直觀。新增完成Driver後，就可以在Plugin中使用了。

10、擴容、縮容

透過建立Webhook，獲取擴容或縮容的HTTP API網址，然後透過curl工具傳送HTTP POST請求，實現擴容或縮容。

1. 根據CPU、記憶體等自定義觸發條件閾值和擴充套件條件設定

2. 智慧監測應用環境，並自動橫向擴充套件容器

3. 支援除主機CPU、記憶體的資源監控外，可對會話等自定義的系統或應用資源監控，根據指定負載範圍進行基於容器的彈性伸縮

1、什麼是CI/CD？

1. 持續整合——Continuous Integration簡稱CI，是指頻繁地（一天多次）將程式碼整合到主幹。標的是讓產品快速迭代，同時保持高質量。核心措施：程式碼整合到主幹前必須透過自動化測試，測試零失敗的程式碼才能合併。

2. 持續交付——Continuous Delivery 簡稱CD，指的是頻繁地更新版本軟體，交付給QA團隊或者使用者，讓他們評審。如果評審透過了，程式碼就進入生產階段。比如，我們完成測試後，可以把程式碼部署到連線資料庫的Staging 環境中進行更多的自動化測試。如果程式碼沒有問題，可以繼續手動部署到生產環境中。

3. 持續部署——Continuous Deployment 也簡稱CD，它是持續交付的下一步，指的是程式碼透過評審以後，自動部署到生產環境。持續部署是持續交付的最高階段。

據調查顯示，2016年，38%的企業已經在使用DevOps, 2017年超過70%的IT市場會將目光聚焦在DevOps技術及功能上。

2、CI/CD流程概覽

基於Jenkins，實現從開發者提交程式碼、編譯構建、環境部署，關鍵環節郵件通知相關人員。

3、CI/CD流程

1. 提交申請：開發人員提交開發程式碼到SVN、Git伺服器

2. 人工定時確發：如果發現程式碼有更新可進行人工或定時觸發程式碼的編輯操作

3. 自動構建：Jenkins會根據構建指令碼把編譯打包檔案和Dockerfile進行自動生成映象，並上傳至映象倉庫；根據需求可發出郵件通知

4. 自動部署：Jenkins根據部署的Compose檔案和容器管理平臺對接

5. 獲取部署環境資訊： 獲取需要部署環境ENV:id，訪問和存取key以及操作（部署、更新）

6. 部署成功： 如果映象編譯正常，Compose檔案和管理平臺對接正常，獲取部署環境資訊正常，那麼，就會根據需求進行平臺應用棧部署。如果部署失敗，也可以正常釋出郵件通知

7. 自動測試：如果部署成功以後，可根據自動化測試指令碼，進行專案的單元測試和檢查檢查測試。測試最終的結果，可透過郵件通知開發或運維人員

4、CI/CD展示

5、解決方案價值

1. 快速釋出，能夠應對業務需求，並更快地實現軟體價值

2. 編碼->測試->上線->交付的頻繁迭代週期縮短，同時獲得迅速反饋

3. 高質量的軟體釋出標準，整個交付過程標準化、可重覆、可靠

4. 整個交付過程進度視覺化，方便團隊人員瞭解專案成熟度

5. 更先進的團隊協作方式。從需求分析、產品的使用者體驗到互動設計、開發、測試、運維等角色密切協作，相比於傳統的瀑布式軟體團隊，更少浪費

1、日誌管理

2、ELK日誌系統資料流圖

ELK stack支援元件間的靈活組合，提供強大的開箱即用的日誌收集和檢索功能。

從上圖中看到ELK系統進行日誌收集的過程，可以分為三個環節：

1. 日誌收集和匯入ElasticSearch

2. ElasticSearch進行索引等處理

3. 視覺化操作，查詢等

Logstash可以結合Redis或者Kafka等收集應用伺服器產生的日誌，經過簡單的過濾等操作後傳送到ElasticSearch，ElasticSearch進行相關的索引處理，最後在Kibana進行相關的視覺化操作。

3、容器管理平臺中具備：

1. 日誌收集

2. 容器系統日誌

3. 應用日誌

4. 平臺日誌審計

5. 集成了ELK

4、App Stack & Link

5、Kibana展示

在企業內部進行應用微服務化改造，說起來簡單，但真正做起來需要考慮很多方面的因素。根據實際的服務架構進行考慮與解決：

1. 應用架構微服務化，從功能的角度去拆分，如不同的功能拆成不同的微服務，微服務的標的在於充分分解應用程式以方便應用敏捷開發和部署。

2. 微服務是一個分散式系統，使得整體變得複雜。開發者需要選擇和實現基於訊息或者RPC的行程間通訊機制，服務呼叫者應有一些應對策略。

3. 使用服務註冊中心做服務可用性檢測，如果發現某個服務節點不可用，就會將其從註冊中心中刪除。為了保證生產者、zk、消費者之間的服務同步 。只依託ZK做狀態檢測還不夠，需要服務提供者和消費者的鏈路層做雙向心跳檢測。

4. 在企業做推廣和營銷宣傳時，stN靜態容器需要，需要獲取到FTP伺服器中獲取網站做推廣時的靜態資源圖片。這就需要同步機制，來監控FTP伺服器圖片庫目錄是否有改變，如果改變，就需要把靜態資源同步到容器的指定目錄中，實現靜態資源的同步更新。

透過應用微服務化，已經完成兩個業務系統的微服務化改造，並且已經成功上架到容器管理平臺中，對外提供服務。

在DevOps 2.0時代，我們註意到作為成功的軟體交付的關鍵因素，自適應特性交付正在興起。

Q：用Jenkins測試完了以後如何釋出到生產環境的？

Q：請問，日誌的話，是不是每個服務都有規定格式？

Q：這個環境支援應用一鍵部署到公有雲嘛？

Q：AKF原則可以詳細介紹嘛？

Q：如何切換開發、測試、生產環境的引數配置？

A： 如果您有三個Environment環境，開發、測試、生產環境需求；我們可以建立三個環境分別如下：DEV（開發環境）、TEST（測試環境）、PRO（生產環境），每個環境下麵的應用棧與其它環境想到隔離，互不影響；如果需要切換管理，只需要在管理平臺中進行ENV環境的切換，即可對相應的環境與應用棧進行管理。

Q：請問目前監控使用的是什麼方案？

Q：程式碼怎麼部署到容器中，是透過外部硬碟掛載嗎，是不是每次都重新生成新的映象？

Q：對於資料庫叢集，現階段是怎麼運維的，有案例？同時對於資料安全是怎麼保證的？資料的備份採用什麼方式？