一種開發運維方法、裝置及云計算PaaS平臺與流程

本發明涉及通信及計算機技術領域，特別是指一種開發運維方法、裝置及云計算paas平臺。

背景技術：

互聯網技術尤其是移動互聯網技術的發展極大地推動了整個電信行業的發展。然而，隨著用戶數量的增長，電信相關支撐服務激增以及彼此之間的依賴關系變得更加復雜，應用服務的部署以及運行面臨更大挑戰。

傳統的應用部署方式主要包括專屬物理機、虛擬機和分布式集群三種方式。專屬物理機就是把應用直接部署在一臺物理機上，這種方式可以獲得較高的應用性能，但是不利于應用之間的資源隔離；虛擬機是隨著虛擬化技術的發展而產生的，將一臺物理機虛擬出多臺虛擬機、每臺虛擬機上部署一個應用，這種方式的優勢在于在較充分利用物理機資源的同時實現了應用之間的資源隔離,但是如果虛機上同時部署多個應用，無法實現多個應用之間的資源隔離，且分配虛機資源時需要消耗分鐘級時間，運維效率較低；分布式集群的出現誕生于互聯網技術的蓬勃發展，當應用訪問量激增，專屬物理機和虛擬機的部署方式受限于單臺物理機的性能，因而出現了分布式集群的部署方式。然而，受限于自動化水平，分布式集群中多節點多實例的運維難度高、運維工作量大、人為誤操作風險高。

云計算paas平臺的出現使大規模應用的部署自動化水平得到極大提高，然而現有的公有云paas平臺雖然符合大部分互聯網產品的需求，但是電信領域諸如話費清算、統一支付等有其自身業務特點，不適合使用公有云。

綜上可知，現有符合電信領域業務特點的paas平臺，存在如下問題：

1、運維的簡便性得不到滿足，在大規模部署、啟停、故障檢查和處理時，仍需要借助輔助工具來處理；

2、應用的可靠性得不到保障，應用實例出現故障時，無法及時高效的進行故障遷移，同時各應用實例的資源無法真正實現隔離；

3、開發、運維的效率低，開發提交的代碼到運維人員部署時需要修改配置、搭建環境后才能部署，開發、運維低效，且之間存在壁壘。

技術實現要素：

本發明的目的在于提供一種開發運維方法、裝置及云計算paas平臺，解決現有技術中paas平臺運維效率低的問題。

為了解決上述技術問題，本發明實施例提供一種開發運維方法，包括：

設定基礎鏡像為初始環境；

接收預設環境變量的配置信息；

根據所述初始環境和所述配置信息生成目標環境；

根據程序包和所述目標環境生成目標鏡像；

其中，所述基礎鏡像包括程序所需基礎配置和依賴庫。

可選地，所述預設環境變量包括測試環境變量和運維環境變量。

可選地，在所述設定基礎鏡像為初始環境之前，所述開發運維方法還包括：

獲取用戶輸入的環境配置信息；

根據所述環境配置信息生成所述基礎鏡像。

可選地，所述開發運維方法還包括：

在運行的實施例數減少時，獲取減少原因；

根據所述減少原因執行對應的副本維持操作。

可選地，所述根據所述減少原因執行對應的副本維持操作包括：

在所述減少原因為進程級別的原因時，利用本地鏡像重新啟動一個容器。

可選地，所述根據所述減少原因執行對應的副本維持操作包括：

在所述減少原因為應用級別的原因時，重新建立對應的副本。

可選地，所述開發運維方法還包括：

實時維護各個宿主機的運行狀態；

若有一個宿主機的運行狀態指示該宿主機出現問題，則將該宿主機上的所有實施例轉移至其他沒有出現問題的宿主機上。

可選地，所述開發運維方法還包括：

接收應用一鍵式部署、啟停或重起的觸發信息；

根據所述觸發信息執行對應操作。

可選地，若所述觸發信息為一鍵式啟動或重啟的觸發信息，則在所述根據所述觸發信息執行對應操作之后，所述開發運維方法還包括：

實時獲取啟動的應用下的各個實施例的啟停狀態；

將所述啟停狀態告知用戶。

本發明還提供了一種開發運維裝置，包括：

設定模塊，用于設定基礎鏡像為初始環境；

第一接收模塊，用于接收預設環境變量的配置信息；

第一生成模塊，用于根據所述初始環境和所述配置信息生成目標環境；

第二生成模塊，用于根據程序包和所述目標環境生成目標鏡像；

其中，所述基礎鏡像包括程序所需基礎配置和依賴庫。

本發明還提供了一種云計算paas平臺，包括：上述的開發運維裝置。

本發明的上述技術方案的有益效果如下：

上述方案中，所述開發運維方法通過把基礎鏡像作為程序的運行環境(把基礎鏡像設定為初始環境)，程序所需基礎配置和依賴庫放入基礎鏡像中；(使用不可變的基礎鏡像)保證了運行環境在開發、測試和運維中的一致性，并且把測試和運維需要的配置信息提取成環境變量進行配置，從而開發人員提交的代碼，測試和運維人員不須要經過任何修改即可進行部署，大大提高了開發、運維效率。

附圖說明

圖1為本發明實施例一的開發運維方法流程示意圖；

圖2為本發明實施例二的開發運維裝置結構示意圖；

圖3為本發明實施例三的paas平臺整體結構示意圖；

圖4為本發明實施例三的控制中心功能結構示意圖；

圖5為本發明實施例三的資源管理中心功能結構示意圖；

圖6為本發明實施例三的服務器發現原理示意圖；

圖7為本發明實施例三的paas平臺操作前臺界面示意圖；

圖8為本發明實施例三的基于docker自動化部署示意圖；

圖9為本發明實施例三的一鍵式啟停界面示意圖；

圖10為本發明實施例三的日志管理界面示意圖；

圖11為本發明實施例三的devops方案流程示意圖；

圖12為本發明實施例三的paas平臺使用流程示意圖。

具體實施方式

為使本發明要解決的技術問題、技術方案和優點更加清楚，下面將結合附圖及具體實施例進行詳細描述。

本發明針對現有的技術中paas平臺運維效率低的問題，提供了多種解決方案，具體如下：

實施例一

如圖1所示，本發明實施例一提供的開發運維方法包括：

步驟11：設定基礎鏡像為初始環境；

步驟12：接收預設環境變量的配置信息；

步驟13：根據所述初始環境和所述配置信息生成目標環境；

步驟14：根據程序包和所述目標環境生成目標鏡像；

其中，所述基礎鏡像包括程序所需基礎配置和依賴庫。

本發明實施例一提供的所述開發運維方法通過把基礎鏡像作為程序的運行環境(把基礎鏡像設定為初始環境)，程序所需基礎配置和依賴庫放入基礎鏡像中；(使用不可變的基礎鏡像)保證了運行環境在開發、測試和運維中的一致性，并且把測試和運維需要的配置信息提取成環境變量進行配置，從而開發人員提交的代碼，測試和運維人員不須要經過任何修改即可進行部署，大大提高了開發、運維效率。

其中，所述預設環境變量可包括測試環境變量和運維環境變量。

為了保證信息的安全性和使用方便性，可將基礎鏡像和目標鏡像放置于鏡像倉庫。

具體的，在所述設定基礎鏡像為初始環境之前，所述開發運維方法還包括： 獲取用戶輸入的環境配置信息；根據所述環境配置信息生成所述基礎鏡像。

另，本發明中可利用容器技術生成基礎鏡像，也就是，采用容器技術，在開發階段就將所有環境的依賴包制作在一個容器鏡像文件內；這個鏡像文件在測試、運維階段都可以使用，它屏蔽了各種環境的差異，使得各個環境能夠做到統一管理，簡化應用因環境差異導致的各種工作，大大提升的開發、測試和運維人員的工作效率。

為了保證副本維持，所述開發運維方法還包括：在運行的實施例數減少時，獲取減少原因；根據所述減少原因執行對應的副本維持操作。

具體的，所述根據所述減少原因執行對應的副本維持操作包括：在所述減少原因為進程級別的原因時，利用本地鏡像重新啟動一個容器；

在所述減少原因為應用級別的原因時，重新建立對應的副本。

也可以說是，副本維持分為進程級別和應用級別兩個層次。進程是指程序進程，應用是指與程序對應的應用。

其中，進程級別是指由于程序原因，或外界原因導致進程退出時，該應用的容器也會自動退出。當node發現容器不在時，又用鏡像重新起一個容器。

應用級別是指由于系統故障或人為操作刪除了某個應用的實例，master很快會掃描到，并重建副本。為了保障故障遷移的及時性，所述開發運維方法還包括：實時維護各個宿主機的運行狀態；若有一個宿主機的運行狀態指示該宿主機出現問題，則將該宿主機上的所有實例轉移至其他沒有出現問題的宿主機上。

也就是，當節點發生宕機或其它異常導致無法工作時，系統為應用重新分配資源。具體為：主節點master對從節點node進行實時健康檢查，master每隔5秒向node發送查詢請求，正常情況下，node會返回ok。master將node的狀態設為ready。如果沒有收到某個node的返回，master將該node記為unready。

接下來的5分鐘master會重復上面的過程，如果5分鐘內收到了該node返回的ok。master則將此node設為ready，并開始恢復該node上的應用。如果5分鐘后依然沒有收到該node的返回，master開始執行遷移，將該node上的應用分配至其它node，分配的策略同創建應用時的調度策略。

為了滿足運維的簡便性需求，所述開發運維方法還包括：接收應用一鍵式部署、啟停或重起的觸發信息；根據所述觸發信息執行對應操作。

為了方便用戶及時準確地處理故障，本實施例中，若所述觸發信息為一鍵式啟動或重啟的觸發信息，則在所述根據所述觸發信息執行對應操作之后，所述開發運維方法還包括：實時獲取啟動的應用下的各個實施例的啟停狀態；將所述啟停狀態告知用戶。

實施例二

如圖2所示，本發明實施例二提供的開發運維裝置包括：

設定模塊21，用于設定基礎鏡像為初始環境；

第一接收模塊22，用于接收預設環境變量的配置信息；

第一生成模塊23，用于根據所述初始環境和所述配置信息生成目標環境；

第二生成模塊24，用于根據程序包和所述目標環境生成目標鏡像；

其中，所述基礎鏡像包括程序所需基礎配置和依賴庫。

本發明實施例二提供的所述開發運維裝置通過把基礎鏡像作為程序的運行環境(把基礎鏡像設定為初始環境)，程序所需基礎配置和依賴庫放入基礎鏡像中；(使用不可變的基礎鏡像)保證了運行環境在開發、測試和運維中的一致性，并且把測試和運維需要的配置信息提取成環境變量進行配置，從而開發人員提交的代碼，測試和運維人員不須要經過任何修改即可進行部署，大大提高了開發、運維效率。

其中，所述預設環境變量可包括測試環境變量和運維環境變量。

具體的所述開發運維裝置還包括：第一獲取模塊，用于所述設定模塊執行操作之前，獲取用戶輸入的環境配置信息；第三生成模塊，用于根據所述環境配置信息生成所述基礎鏡像。

為了保證副本維持，所述開發運維裝置還包括：第二獲取模塊，用于在運行的實施例數減少時，獲取減少原因；第一執行模塊，用于根據所述減少原因執行對應的副本維持操作。

具體的，所述執行模塊包括：處理子模塊，用于在所述減少原因為進程級別的原因時，利用本地鏡像重新啟動一個容器；

重建子模塊，用于在所述減少原因為應用級別的原因時，重新建立對應的副本。

為了保障故障遷移的及時性，所述開發運維裝置還包括：

處理模塊，用于實時維護各個宿主機的運行狀態；

轉移模塊，用于若有一個宿主機的運行狀態指示該宿主機出現問題，則將該宿主機上的所有實施例轉移至其他沒有出現問題的宿主機上。

為了滿足運維的簡便性需求，所述開發運維裝置還包括：

第二接收模塊，用于接收應用一鍵式部署、啟停或重起的觸發信息；

第二執行模塊，用于根據所述觸發信息執行對應操作。

為了方便用戶及時準確地處理故障，本實施例中，所述開發運維裝置還包括：第三獲取模塊，用于若所述觸發信息為一鍵式啟動或重啟的觸發信息，在所述第二執行模塊執行操作之后，實時獲取啟動的應用下的各個實施例的啟停狀態；告知模塊，用于將所述啟停狀態告知用戶。

其中，上述開發運維方法的所述實現實施例均適用于該開發運維裝置的實施例中，也能達到相同的技術效果。

實施例三

為了解決上述技術問題，本發明實施例三還提供了一種云計算paas平臺，包括：上述的開發運維裝置。

下面對本發明實施例三提供的云計算paas平臺進行舉例說明。

本發明實施例三可提供一種基于容器技術docker(開源的應用容器引擎)的paas平臺。

paas平臺主要由四部分組成：前臺、控制中心、資源管理中心和容器節點組成。

前臺：作為人機交互界面，提供系統管理、應用管理、鏡像管理、版本管理和日志管理等功能。

控制中心：命令樞紐中心，負責版本控制、鏡像管理和運行控制等功能。

資源管理中心：負責資源的生命周期管理、應用副本管理、應用的負載均衡和故障轉移failover等功能。

容器節點：以資源隔離的方式部署在docker容器中的每個應用為一個節點，負責實現具體應用的業務功能。

具體如圖3所示，下面對其中的每個模塊做詳細介紹：

一、前臺

實現的功能包括：

系統管理：提供用戶的注冊、注銷和授權管理等功能。

應用管理：提供應用和應用實例的增刪改查、啟停、信號發送、配置管理和應用日志的查看和下載等功能；

版本管理：提供應用的版本維護、新舊版本切換等功能。

鏡像管理：提供基礎鏡像的錄入、修改、刪除和查詢功能。

日志管理：管理所有用戶的操作日志記錄和查詢。

二、控制中心

控制中心是整個系統的命令樞紐，對上接收前臺發送的用戶請求，對下向資源管理中心的發送操作命令。它的主要功能包括版本控制、鏡像管理和應用的運行控制。

如圖4所示的控制中心功能結構，其中：

1、版本控制

paas平臺接收用戶的原始程序包，并且對每次上傳的程序包進行版本控制。在系統中，有程序包倉庫和鏡像倉庫，且程序包版本和應用鏡像是一一對應的。

版本控制流程如下：

用戶上傳程序包，版本管理接收并生成一個唯一的版本號，對應一個唯一的程序包倉庫目錄；

鏡像管理對該程序包打鏡像操作完成后，鏡像倉庫中該應用鏡像名字唯一對應該程序包版本；

對程序版本的操作同步該應用鏡像。

2、鏡像管理

鏡像管理包括基礎鏡像管理和應用鏡像管理，基礎鏡像管理對用戶常用的基礎鏡像進行增刪改查；應用鏡像管理則負責對應用程序打鏡像，打鏡像處理如下：

鏡像管理接收到打應用鏡像的請求，請求信息包括程序包目錄和基礎鏡像，驗證信息的有效性，檢查目標程序包是否存在，基礎鏡像是否合法；

在本地創建臨時目錄，目標程序包移至該目錄；

自動生成dockerfile文件；

使用dockerfile文件打應用鏡像；

將應用鏡像push到鏡像倉庫。

3、運行控制

運行控制管理應用的啟動、停止、發送信號操作：

(1)啟動應用

應用管理接收到啟動應用的請求，調用模板管理；

模板管理從數據庫讀取應用數據，生成應用模板，該模板中存儲應用的運行控制信息，包括期望運行的副本數、運行需要的資源、容器環境變量等信息，模板是控制中心和資源管理中心的通信協議；

模板生成后，應用管理模塊調用資源管理中心，啟動應用，資源管理中心根據模板信息調度資源。

(2)停止應用

應用管理接收到停止應用的請求，直接調用資源管理中心刪除運行模板和所有運行實例。

(3)發送信號

應用管理中心接收到發送信號的請求，會首先獲取該應用的所有運行實例，對所有運行實例批量發送運行信號。

三、資源管理中心

資源管理中心是整個系統的資源管理中心，它負責管理所有的容器節點，提供rest接口供控制中心使用。其主要功能包括：資源調度、部署運行、服務發現、擴容縮容。

如圖5所示的資源管理中心，其在部署上分為兩個角色，分別為主節點master和從節點node。其中master為管理模塊，整個系統只有一個。node即為容器節點，是應用具體運行的地方，一個master對應多個node。

實現的功能包括：

資源調度

資源調度是資源管理中心的核心內容，其涉及到兩方面的調度：

1.創建應用時為應用分配資源。

下面是創建應用的過程：

master收到創建應用的請求。這些請求可能來自命令行，也可能來自rest接口。但最終都會由api接口服務組件apiserver來處理。

master開始創建副本，這是一個邏輯的過程，僅在內部處理。

為每一個副本選擇一個node。這里由編排schedule模塊來處理，其策略是空閑的節點優先，如果兩個節點的空閑值一樣，就按node列表的順序來分派。

選擇node后，開始創建應用控制模塊，然后向node發送創建應用請求。

2.當節點發生宕機或其它異常導致無法工作時，系統為應用重新分配資源。

master對node進行實時健康檢查。其工作過程描述如下：

master每隔5秒向node發送查詢請求，正常情況下，node會返回ok。master將node的狀態設為ready。

如果沒有收到某個node的返回，master將該node記為unready。

接下來的5分鐘master會重復上面的過程，如果5分鐘內收到了該node返回的ok。master則將此node設為ready，并開始恢復該node上的應用。

如果5分鐘后依然沒有收到該node的返回，master開始執行遷移，將該node上的應用分配至其它node，分配的策略同創建應用時的調度策略。

副本維持

副本維持功能是一個很重要的運維功能，在傳統的運維場景里，為了保證應用以固定的實例數來運行，必須額外部署一個監控程序，每隔幾秒掃描一次進程，將退出的進程重新啟動。

采用paas平臺后，完全不用擔心這個問題，平臺天然具備這樣的功能。

副本維持分為兩個層次：

(1)進程級別

進程級別是指由于程序原因，或外界原因導致進程退出時，該應用的容器也會自動退出。當node發現容器不在時，又用鏡像重新起一個容器。

(2)應用級別

應用級別是指由于系統故障或人為操作刪除了某個應用的實例，master很快會掃描到，并重建副本。

部署運行

分配資源后，資源管理中心負責將應用部署至容器中心，其負責調用容器 節點的rest接口。

服務發現

在容器節點里運行的服務，其ip是由系統隨機分配的，并且通過資源調度，其ip是可能隨時變化的。如果服務是類似web服務tomcat的服務，需要提供ip地址供外部訪問，就會面臨許多麻煩。

為了解決這個問題，本發明引入了service機制，即服務發現。服務發現的原理可以用圖6描述：

1.容器里的ip屬于內部ip，外面是無法直接訪問的。

2.首先選取某一臺node的ip作為service的ip。例如我們選取node1的ip，而應用部署在node2上。

3.當用戶訪問tomcat時，代理服務器proxy將訪問請求發送給tomcat。

4.在默認情況下，node1也是無法訪問node2上的內部ip的，此時需要做以下事情：

給node1和node2上的ip分段，例如node1的內部ip為172.16.1.0/24，node2的內部ip為172.16.2.0/24。

在node1上設置路由，將所有172.16.2.0/24的訪問請求發送給node2。

在node2上設置路由，將所有172.16.1.0/24的訪問請求發送給node1。

5.通過設置路由，proxy成功將tomcat的訪問請求發送給node2上的tomcat。

6.service與應用一一對應，這樣即使應用遷移至其它node，proxy同樣能找到。應用也可以是多實例，當tomcat有多實例時，proxy通過輪詢的方式來訪問。

擴容縮容

所有的節點都無狀態，能夠支持在線擴容，縮容。

擴容時，master將一個新的node加入系統，此時并不會因為負載均衡將其它node的應用遷移至新加入的node。只有運維人員通過前臺界面新建應用或增加應用實例時，需要進行資源調度，此時應用會優先選擇新建的node。

縮容時，可以直接將節點從系統中移除，此時會觸發資源調度的重分配功能，等遷移完成，將該node從master的node列表中刪除即可。

四、容器節點

容器節點的主要功能是使用了容器技術，其上運行的應用由資源管理中心來調度。在調度前，控制中心將應用及運行環境打包成容器。其后的所有操作都基于容器，容器具有輕量，快速等特點。

其主要功能包括：

資源隔離

容器采用的是基于cgroup(controlgroups，linux內核提供的一種可以限制、記錄、隔離進程組所使用的物理資源的機制，如：cpu、memory、io等等)的輕量級的虛擬化技術。通過lxc(linuxcontainer)我們可以對容器的資源進行以下的限制：

cpu:cgroup不能像其它虛擬化方案一樣提供定義cpu的能力，它能定義cpu的優先級，可以對應用設置一個相對的權重。

cpu設置cpusets：定義哪幾個cpu可以被容器使用，這是限制cpu的一種很好的方式。

內存memery：可以限制內存的大小。

采用資源隔離后，用戶可以很好的對應用的資源進行限制，防止因部分應用消耗資源過大而對其它應用造成影響。

標準化容器

采用容器技術的另一大優勢就是能制作標準化的容器。在日常開發過程中，環境問題一直是困擾開發人員和測試人員的一大難題。后臺服務，特別是c++程序，往往會依賴一大堆組件，這些組件都有各自的版本。當應用從開發人員提交到測試人員手中時，測試人員需要重新搭建這些環境，并且經常會因為版本或配置的問題造成應用運行異常。

采用容器技術后，這些問題得到了很好的解決。容器技術是一個輕量化的虛擬化技術，想讓應用在容器里運行起來，需要通過以下幾個步驟：

1)準備一個基礎鏡像，可以是任意linux發行版，一般可以通過社區去下載。

2)通過基礎鏡像啟動一個容器。容器運行起來與linux無異，可以在上面進行linux相關的所有操作。

3)在容器里安裝應用依賴的組件，包括修改配置文件。

4)將應用也安裝在容器里，確保應用能正常運行。

5)將此容器重新提交為一個新的鏡像。

新的鏡像可以在集群的任意主機上運行，用戶無需再擔心環境，配置等問題。

其實，paas平臺四個模塊設計，不僅實現了分布式環境中應用實例的資源隔離和副本維持，還實現了對應用的一鍵式智能運維、故障遷移及高效devops(英文development和operations的組合，是一組過程、方法與系統的統稱，用于促進開發應用程序/軟件工程、技術運營和質量保障qa部門之間的溝通、協作與整合)機制，詳細介紹如下：

提供可視的paas操作前臺界面，在分布式環境中實現應用的一鍵式智能運維。其中，簡潔清晰的可視paas操作界面，如圖7所示。

主要分三部分介紹：

1.基于docker鏡像技術，實現集群環境應用的自動化部署，如圖8所示。

當用戶在paas前臺觸發一鍵部署，控制中心從svn(是subversion的簡稱，是一個開放源代碼的版本控制系統)下載程序包(用戶也可以在前臺頁面上傳程序包)，并且從基礎鏡像庫拉取基礎鏡像進行目標鏡像制作，制作以后的應用鏡像會寫入鏡像倉庫，控制中心根據前臺頁面用戶配置的配置信息進行資源調度，集群節點會從應用鏡像庫拉取鏡像、啟動，從而完成一鍵部署。

因此用戶只需在前臺進行一鍵式應用部署操作，paas平臺即可實現應用的全程自動化部署，從而簡化運維操作，提升運維效率。

2.支持應用和應用集群的一鍵啟停、一鍵重啟，且支持對單個實例的重啟，如圖9所示。

當用戶在paas前臺觸發應用的一鍵式啟動、停止和重啟操作，前臺即刻與控制中心建立長連接，控制中心將以watch的機制監控資源管理中心，實時獲取該應用下各個應用實例的啟停狀態，例如正在調度應用資源，正在啟動應用，啟動的應用實例個數、啟動成功或者失敗等等；使得用戶能夠實時獲知應用的啟動情況，對出現的錯誤能夠實時獲知原因并進行處理，提升運維和管理能力。

3.對應用日志進行歸集，支持應用運行日志的在線查看,包括標準輸出和日志文件，如圖10所示。

應用啟動后，會生成應用日志文件和標準輸出，應用日志在paas平臺會通過flume進行實時歸集，統一歸集到日志服務器，供用戶通過paas前臺進行在線查看和下載。而標準輸出日志可以通過paas平臺進行實時的獲取和查閱。用戶通過這些日志可以定位問題、統計分析和運維管理，從而精準的獲取整個系統各個應用的運行情況，提升運維效率。

基于容器技術的資源隔離與副本維持

paas平臺提供了資源隔離和副本維持等特性，能大大的提升開發和運維的效率。主要從下面三個方面來闡述：

1.資源隔離

傳統的虛擬化采用的威睿虛擬機軟件vmware或類似vmware的技術，在宿主主機上安裝虛擬機，然后在虛擬機上安裝操作系統。這樣，每安裝一臺虛擬機都會占用一臺虛擬機的資源，雖然現在能把cpu和內存都進行虛擬化，但每臺虛擬機都實實在在安裝了完整的操作系統。占用資源的同時，還需要一套復雜的系統對其進行維護。

而容器技術是輕量級的技術，它與虛擬機的差別是虛擬機管理程序對整個設備進行抽象處理，而容器只是對操作系統內核進行抽象處理。因此能夠實現類似虛擬機的資源隔離，同時容器運行不需要模擬層和管理層，而是使用操作系統的系統調用接口，因此降低了運行容器所需的開銷，不僅使得容器啟動時間能夠做到秒級，也使得宿主機上可以運行更多的容器。

基于容器的資源隔離技術，是paas平臺的基石，是paas平臺實現一鍵式便捷運維操作以及副本維持和故障遷移功能的基礎。

2.標準化容器機制

標準化容器也是容器技術的一大特色，在傳統開發測試和運維中，不同的開發和測試環境問題無法做到統一管理。運行一個程序需要開發，測試和運維同時準備環境，安裝各種依賴包，而且極易因為版本問題造成程序出錯。采用容器技術后，我們在開發階段就將所有環境的依賴包制作一個容器鏡像文件，這個鏡像文件在測試、運維階段都可以使用，它屏蔽了各種環境的差異，使得各個環境能夠做到統一管理，簡化應用因環境差異導致的各種工作，大大提升的開發、測試和運維人員的工作效率，同時也是devops機制實現的基石。

3.副本維持

paas平臺能實現應用的副本維持功能，可根據業務的需要隨時調整應用實例數。例如可以在過年過節業務量較大的時候增大實例數以應對業務量瞬間增大的壓力。

這個機制只需要在創建應用的時候在paas前臺對資源進行設置即可，如設置該應用運行所需的cpu和內存大小。大部分情況下，用戶不需要關注這些配置，只有在業務量激增的情況下，才需要進行修改以滿足要求。

paas平臺的監控系統能實時監控應用的所有變化，包括應用退出，應用重啟等健康檢測功能，當檢測到某個應用實例的狀態不正常或進程退出時，可以秒級啟動一個正常實例進行替代，也即自動選擇一臺合適的主機重新部署，并告警給用戶。如果一個宿主機出現問題，運行其上的所有實例都可以快速轉移至其它健康的宿主機上。基于容器技術使得應用故障轉移非常快速，并且可以在集群中任意宿主機上運行。通過基于容器的副本數維持和故障遷移，保障了paas平臺的高可靠性。

devops機制，提升運維開發效率

傳統方式開發和運維是割裂開的，不符合現代產品和服務開發的需求。paas平臺提供了一種devops機制的有效解決方案，以鏡像貫穿開發、測試、運維的整個生命周期，有效提升開發運維協同工作效率。

devops方案如下：

把基礎鏡像作為程序的運行環境，程序所依賴的配置和庫放入基礎鏡像中；使用不可變的基礎鏡像保證運行環境在開發、測試和運維中的一致性，并且把測試和運維需要的配置信息提取成環境變量在paas前臺進行配置，從而開發人員提交的代碼，測試和運維人員不須要經過任何修改即可以在paas平臺部署。

devops方案下開發運維流程如圖11所示：

1.開發人員在發布版本前，需要打基礎鏡像，并完成應用的調試，基礎鏡像中包含應用所需基礎配置、依賴庫等，制作好的基礎鏡像放入到paas平臺鏡像倉庫中；

2.開發人員提交源代碼、發布應用程序包版本；

3.運維人員拿到應用程序包版本，通過直接在paas平臺上傳或者定制svn 庫地址的方式向paas平臺提交可執行代碼；

4.運維人員在paas平臺選擇相應的基礎鏡像，并填寫運維配置；

5.paas平臺根據程序包和基礎鏡像，自動生成應用運行的目標鏡像。

paas平臺devops方案打破了開發、運維的壁壘，做到開發、運維的高效協同工作，使用基于容器的paas平臺，可以非常簡單的實現電信漫游清算業務服務的安裝、部署和運行。

以網間漫游b文件的校驗、查重、結果發布服務為例進行說明：

在測試環境，其安裝、部署和運行流程如圖12所示，包括：

1.開發人員會根據網間漫游b文件的校驗、查重和結果發布服務所用到的特定軟件，如jdk，oracle客戶端等打一個合適的基礎鏡像，并將該基礎鏡像上傳到鏡像倉庫；

2.開發人員同時登陸paas前臺，錄入該基礎鏡像信息；

3.運維人員根據接入paas規范進行網間漫游b文件校驗、查重和結果發布服務的zip包制作；

4.運維人員登陸paas前臺，創建校驗、查重和結果發布服務這些應用，以校驗服務為例，運維人員錄入校驗服務的相關信息(如名稱、應用實例個數、cpu、內存設置)后保存，paas前臺會將請求發給控制中心，控制中心將這些信息入到mysql數據庫；

5.paas前臺收到應用創建成功的結果后，再提示運維人員是否立即創建版本，如果是則開始創建版本，如果不是，則運維人員后續可以在版本面板那里下次再創建。

6.運維人員上傳校驗的zip包，選擇基礎鏡像，設置環境變量，保存之后，paas前臺將校驗zip包傳送到控制中心服務器，同時發起創建版本的請求，控制中心收到請求后立即獲取校驗zip包，并在基礎鏡像的基礎上打應用的鏡像并存入鏡像倉庫。同時將版本信息入到數據庫并返回給paas前臺。

7.paas前臺收到版本創建成功的請求后，提示運維人員是否立即啟動應用，如果是，則立即啟動，如果不是，運維人員后續可以在版本面板那里啟動該應用的這個版本。

8.運維人員啟動應用，paas前臺會將請求發給控制中心，控制中心創建應 用模板，并將請求發送給資源管理中心，資源管理中心根據測試集群中各個節點的負載情況進行實例的啟動，啟動成功后返回。paas前臺會將消息告知運維人員。

至此一個應用從鏡像制作、上傳到服務器、部署、啟動至運行就完成了。

綜上所述，本發明提供了一種基于容器的paas平臺，由前臺，控制中心，資源管理中心和容器節點4部分組成，能夠實現基于容器技術的資源隔離與副本維持；分布式環境中應用的一鍵式智能運維；devops機制，進而提升運維開發效率。

也就是說，本發明提供的基于容器技術的paas平臺，通過提供友好的前臺操作界面，使運維更加的簡便；引入docker容器技術很好的實現了資源的隔離；通過資源管理中心實現了軟負載均衡。

其中，上述開發運維裝置的所述實現實施例均適用于該云計算paas平臺的實施例中，也能達到相同的技術效果。

同樣，上述開發運維方法和裝置也能夠實現該云計算paas平臺所能夠實現的各種功能。

需要說明的是，此說明書中所描述的許多功能部件都被稱為模塊/子模塊，以便更加特別地強調其實現方式的獨立性。

本發明實施例中，模塊/子模塊可以用軟件實現，以便由各種類型的處理器執行。舉例來說，一個標識的可執行代碼模塊可以包括計算機指令的一個或多個物理或者邏輯塊，舉例來說，其可以被構建為對象、過程或函數。盡管如此，所標識模塊的可執行代碼無需物理地位于一起，而是可以包括存儲在不同位里上的不同的指令，當這些指令邏輯上結合在一起時，其構成模塊并且實現該模塊的規定目的。

實際上，可執行代碼模塊可以是單條指令或者是許多條指令，并且甚至可以分布在多個不同的代碼段上，分布在不同程序當中，以及跨越多個存儲器設備分布。同樣地，操作數據可以在模塊內被識別，并且可以依照任何適當的形式實現并且被組織在任何適當類型的數據結構內。所述操作數據可以作為單個數據集被收集，或者可以分布在不同位置上(包括在不同存儲設備上)，并且至少部分地可以僅作為電子信號存在于系統或網絡上。

在模塊可以利用軟件實現時，考慮到現有硬件工藝的水平，所以可以以軟件實現的模塊，在不考慮成本的情況下，本領域技術人員都可以搭建對應的硬件電路來實現對應的功能，所述硬件電路包括常規的超大規模集成(vlsi)電路或者門陣列以及諸如邏輯芯片、晶體管之類的現有半導體或者是其它分立的元件。模塊還可以用可編程硬件設備，諸如現場可編程門陣列、可編程陣列邏輯、可編程邏輯設備等實現。

以上所述的是本發明的優選實施方式，應當指出對于本技術領域的普通人員來說，在不脫離本發明所述原理前提下，還可以作出若干改進和潤飾，這些改進和潤飾也應視為本發明的保護范圍。