歡迎光臨
每天分享高質量文章

智慧工廠的容器雲實踐

隨著國家對智慧製造的大力推進,傳統工業領域也在加快資訊化轉型。中鋁視拓致力於有色金屬領域的工業網際網路平臺的研發。本文和大家一起討論在傳統工業領域中,基於Kubernetes的容器雲如何幫助企業提高資訊化效率。
現狀

 

中鋁是一家從事有色金屬領域相關的企業,主要從事礦產資源開發、有色金屬冶煉加工、相關貿易及工程技術服務等。除了本身工業領域的相關技術以外,也需要資訊化系統的輔助。典型的場景就是工廠的生產管控系統和計量系統。
不同的工廠規模不一樣,導致在資訊化投入的力度上也不一樣,所以現場的IT 資產的情況也不一樣。有的工廠盈利不錯,資訊化水平會相對高一些,有獨立的機房,有IaaS相關的基礎設施,有較為完善的IT系統,有的工廠盈利不行,資訊化水平就低一些,可能就只有老舊的幾臺低配伺服器來執行所有的IT系統,系統也是比較傳統的C/S的.NET 應用。
一般工廠基於安全考慮,機房不會直接和網際網路通訊,因此主流的線上安裝的形式不適合現場的情況。針對這種情況,我們基於Ansible開發了一整套的全容器化離線安裝工具,並以此為基礎,提供了版本的概念,規範部署和升級。Kubernetes的基礎概念之前的很多分享都已經提到了,我就不再贅述。我更多的是分享一下,我們在易用性上所作的一些工作。

 

Ansible 部署

 

基於Ansible的部署這個本身沒有太多別的東西,就是按照Ansible的規範,把Kubernetes相應的元件分門別類的放好。在技術選型上,我們也基本是跟著主流走,這個看Ansible的role就能看出來。網路元件採用的是Calico,日誌體系採用的是典型的ELK,監控體系採用的是Prometheus,分散式儲存採用的是Gluster。

在Kubernetes的版本上,我們經歷了1.8、1.10、1.14三個大版本,目前是使用的1.14.0版本。主要看中CSI 1.0和Windows節點的能力。
在整體的部署上,採用全容器化的離線部署方式,這樣能極大的降低部署過程中的複雜度,也方便日後的升級。對於一個典型的組網結構來說,我們採用3個管理節點和3個儲存節點,計算節點則根據實際需求去進行分配。當然也有一些極端場景下,只提供3臺甚至是隻有1臺虛擬機器,指令碼本身也是適配的,不需要做額外的改動。

 

面向業務人員的開發運維平臺

 

這裡主要介紹一下gpass這個模組。
  • cs-cloud,開發運維平臺

  • ELK,日誌體系,採集平臺所有的日誌,包括業務容器、平臺容器、節點產生的日誌

  • Monitor,監控體系,根據Prometheus採集的度量資料,進行監控和告警

cs-cloud是我們封裝的面向開發人員和工廠資訊科工作人員的開發運維平臺,主要分三個模組:
  • auth,使用者體系模組

  • ccapi,後端服務模組

  • dashboard,前端服務模組

我們主要做了這些工作:
  • 封裝了Kubernetes的Java SDK,方便開發

  • 整合了平臺所使用的各種元件,提供統一的訪問UI

  • 遮蔽了部分Kubernetes的底層概念,方便開發人員理解

透過使用我們提供的平臺,開發人員可以很方便的部署出自己開發的服務,不需要瞭解底層的技術細節。

左上方是環境選擇選單,使用者登入之後,只會看到和自己相關的環境,這個就是對標的namespace。
右上方是當前環境下的一些公共內容,這裡比Kubernetes多出來的就是應用商店。
對於使用者來說,他主要關心自己部署的服務。平臺中的服務是Kubernetes中多個概念的綜合體,包含了deployment、service等概念。我們增加了一個服務組的邏輯概念,來方便用於對關聯度較高的服務進行分組,方便展示和檢視。
在部署一個新的服務的時候,我們提供了一個綜合性的標簽頁,在大部分情況下,能夠滿足部署一個新服務所需的功能。這樣使用者不需要去關心Kubernetes底層的那些概念,更多的是關心服務本身,降低了上手難度。
 

對於之前提到的應用商店,是我們對一些使用頻率較高的公共服務做的一些封裝,尤其是一些配置項較多,或者有相互關聯的服務,方便部署。主要涉及的是Spring Cloud相關的服務。
因為一些遺留原因,部分服務會使用到Spring Cloud作為微服務框架進行開發。所以我們提供了一個全套的Spring Cloud應用,包括Config、Zuul、Oauth2、Eureka、Hystrix Dashboard,一鍵部署出整套環境。

 

DevOps 實踐

 

為了方便管理程式碼到部署的整個生命週期,我們基於Jenkins構建了整個DevOps流水線。
在構建方式上,沒有採用傳統的每個專案單獨構建的形式,而是根據專案型別的不同,透過一個公共專案進行構建。
以Java 型別為例:

專案根據實際情況填寫引數就可以了,當然為了簡化,也可以直接克隆一份,把引數固化。

質量分析目前是採用的SonarQube,除了對每次的構建進行分析,我們還專門對每次程式碼提交進行了自動觸發質量分析,只要專案提交了程式碼,GitLab就會透過webhook通知Jenkins,對專案進行程式碼質量分析,並將分析結果通知給專案開發人員。
 

截止到目前是已經分析了8108次,質量部門會根據這個分析結果,對專案質量提出一些要求,從一定程度上提高專案程式碼質量。
最後,看一下我們最新上線的一個智慧工廠案例,採用的是3個管理節點,3個儲存節點,10個計算節點的配置。
這是節點的情況。
 

這是其中部分服務的部署情況。

Q&A;

 

Q:您認為未來工業PaaS雲平臺的發展前景和發展樣式有哪些?
A:工業場景本身是千差萬別的,石油、金屬、製造業等等,都有自己各自的需求,目前來看的話,主要還是要先完成資訊化改造,然後才能以此為基礎去做後續的比如工藝最佳化等等。後續應該會公有雲、私有雲並存,大集團型公司走私有雲樣式,中小型公司走公有雲樣式。
Q:Kubernetes的線上熱升級容易做嗎,請問是不是踩過很多坑呢?
A:目前對於Kubernetes的熱升級,主要是大版本變動會帶來一些配置上的改動,因為全部容器化,所以升級本身不複雜。
Q:現在生產服務的規模多大,服務數量,流水線是每個專案型別一個公共構建專案嗎?針對多分支構建如何快速持續整合?針對服務的特殊化需求比如Pipeline的某個stage要跳過怎麼辦,每個專案一個標準的Jenkinsfile嗎?
A:服務數量根據不同的專案規模,各有不同,智慧工廠專案本身是一個很龐大的專案,下麵會分很多的子專案,目前來看,一般的子專案服務數量是在50個以內。目前我們還沒考慮多分支情況,因為專案不像自己運維的產品,不會存在頻繁的更新,我們是按版本形式去走,所有的提交最後都要彙總到主幹分支後,再打包發到現場。目前還沒有跳過stage的需求。
Q:請問Jenkins webhook那些構建引數如何傳入GitLab觸發?
A:webhook的觸發和介面引數會有一些區別,我們在指令碼裡面做了處理。
Q:離線部署,是不是透過打出映象壓縮包,然後帶著映象包到現場部署的容器雲平臺上,上傳部署的方式?
A:是在家裡打出映象壓縮包,然後到現場解壓出來,根據映象型別進行處理,比如一些基礎映象,會直接上傳到節點,業務的映象會在部署完成後上傳到Harbor,然後節點從Harbor去拉取。
已同步到看一看
贊(0)

分享創造快樂