現在戴姆勒旗下的汽車都仰賴容器技術,以物聯網的規模來遞送程式更新。

現在戴姆勒旗下的汽車都仰賴容器技術,以物聯網的規模來遞送程式更新。

全球汽車大廠戴姆勒(Daimler AG)研發主力Mercedes-Benz Research and Development(Mercedes-Benz  R&D)的連網汽車平台團隊都戲稱該公司所打造的汽車為容器驅動汽車(Container-driven cars),因為現在戴姆勒旗下的汽車都仰賴容器技術,以物聯網的規模來遞送程式更新。

汽車儀表板上的主機電腦主要執行車載資訊娛樂系統,它內含導航系統、數位廣播收音機,以及包括停車或搜尋等各種應用程式,過去它是以單體(monolith)軟體的形式隨著汽車出廠。

因此,當要變更車載資訊娛樂系統時,通常需要重新驗證整個單體,它涉及嚴格的品質保證與實際的試駕,因而曠日廢時,有時軟體更新可透過行動網路進行,但會損耗大量頻寬,有時候的更新必須重刷主機,而且由於檔案太大,只能在取得Mercedes-Benz授權的地點進行更新。

此一開發模式帶來了其它挑戰,傳輸上的限制侷限了它所能供應的程式型態,除了車載資訊娛樂系統之外,還有其它程式透過受控介面與汽車的感應器及系統互動,以監視諸如油量、速度與GPS位置等功能,這些應用程式是由不同的開發團隊所建置,且它們必須密切協調。

程式發布的時間表亦受到由外部專家所建立的程式之間的相依性所影響,包括主機生產商的各個團隊,以及公司內部各領域的團隊所建立的程式。

在上述的限制下,連網汽車團隊更新軟體的頻率並不高,一年約莫只有一、兩次,Mercedes-Benz  R&D首席軟體工程師Rodrigo Nunes表示,他們希望能讓開發者的工作流程脫離基礎系統與汽車的發布管理周期。

於是,由北美及德國Mercedes-Benz  R&D團隊共同推動的連網汽車平台(Connected Cars Platform)專案,決定選擇微軟的Azure作為現代化汽車軟體開發的雲端平台,除了採用Azure Container Registry及Azure Kubernetes Service(AKS)等容器服務,Azure Cosmos DB分散式多模型資料庫服務,流量管理服務Azure Traffic Manager之外,也藉由API管理平台Azure API Management來改善團隊之間的協調。

如今,連網汽車團隊已可隨心所欲地快速建立新版本,遞送新解決方案的周期也已大幅縮短至3個月。

在車聯網架構中,API透過AKS路由串接後端服務。

在車聯網架構中,API透過AKS路由串接後端服務。

 

容器技術改變了開發生態

容器技術具備許多優點,在一個基於雲端的容器平台上,開發團隊能夠打造個別的程式,並透過無線網路進行遞送,此外,容器還代表著純軟體解決方案,程式碼將能以具備特定功能的獨立微服務進行設計與測試,讓軟體開發時程不必再受到硬體團隊的牽絆。

容器技術也簡化了開發者的測試,過去開發者必須先遞送一個新的軟體構件,把它整合到主機映像檔上,再把映像檔刷新至硬體裝置上,假使測試程序發現了一個Bug,那麼就得重新執行整個流程,又是幾周的時間。

現在開發者則可在筆電或Azure的虛擬機器上執行模擬器,不必再存取硬體測試台就能測試應用程式,當所有的自動化測試都在雲端的模擬汽車上執行後,開發者可將程式映射到測試汽車,啟動時測試車的主機就可連結至雲端,找到新程式並啟動它。

此外,連網汽車團隊亦發現,Azure在全球部署了資料中心,得以降低程式部署或下載時的延遲。

流量管理服務Azure Traffic Manager把更新需求導至最近的資料中心,研發團隊也利用Azure Container Registry與Azure Cosmos DB的跨區域複製能力來確保映像檔的存放位置與順暢的部署。

 

在不同平台與眾多區域供應DevOps能力
以往連網汽車團隊的持續整合 (CI) 與持續部署(CD)作法是奠基在開源工具上,包含一個Atlassian Bitbucket版本的控制存放庫,一個Jenkins自動化伺服器,與一個JFrog Artifactory存放庫管理工具,但整體程序並不真的是CI,每一個車用程式都有自己的客製化管線,需要某些手動操作,且軟體的二進位檔案來自四面八方,亦需長時間的整合周期進行整合與測試。

如今,該團隊使用基於Azure Pipelines的CI/CD管線。Nunes透露,他們在Azure上幾乎一開始就採用DevOps,Azure現在已是所有車用程式開發者的首選平台,其管線是以一個YAML檔案所設定的範例,開發者不必深入了解DevOps於Azure上的運作原理就能立即著手運用。

 

以Azure API Management串連內部開發者

應用程式介面(Application Programming Interface,API)已然成為連結程式、資料、服務與裝置的標準,同時也推動了組織內的數位轉型。Mercedes-Benz  R&D的連網汽車平台團隊也使用不同的API來連結歐洲團隊及負責後端架構的北美辦公室,並順理成章地使用了微軟所提供的API集中管理服務--Azure API Management。

在Gartner於今年9月發布的《魔力象限:完整生命周期API管理》研究報告中,微軟的Azure API Management被列為該領域的領導者之一。Gartner所定義的完整生命周期API管理必須具備五項功能,包括API目錄的開發者入口網站、API閘道、政策管理及分析、API設計與API測試,Azure API Management即滿足了上述功能。

Azure API Management主要在Azure上運作,但其API閘道及入口網站等元件也能透過Azure Arc安裝至混合式雲端或直接安裝至Kubernetes。

根據Gartner的分析,Azure API Management的強項在於它提供了一個相對簡單與直覺的管理介面,而且客戶對該服務的滿意度很高。其次是該服務展現了微軟強大的全球策略,因為它現身於所有的Azure區域,且支援18種語言,亦有50種語言的說明文件。

Mercedes-Benz  R&D連網汽車平台團隊對Azure API Management的評價與Gartner的說法不謀而合。該團隊指出,API閘道接受各種API呼叫並將它們導回後端,有效地把後端的API與微服務拆開,也能妥善驗證憑證與API金鑰。

連網汽車平台團隊認為,介面合約應能引導汽車與後端系統之間的所有通訊,後端系統存放了許多重要資訊,包括汽車能力與應用程式的所有權,它以Swagger描述語言來起草這些合約API的正式定義,再於支援OpenAPI 規格的Azure API Management中匯入相關檔案。

這使得後端團隊可透過此一程序於Azure API Management中設定模擬政策。開發者得以針對某個API設定政策,以讓它回覆一個模擬回應,讓其它團隊也能在後端無法傳送真實回應時,繼續實施與測試Azure API Management實例。

Nunes說,該團隊只要簡單地上傳Swagger介面,其它的供應商團隊就能立即透過其模擬政策進行開發,並測試其安全性、連結能力、延遲或系統其它部份,將更容易於正式實施之前發現潛在的問題。

當後端團隊已準備好整合微服務與API Management時,它便會以真實的回應取代模擬回應。Nunes表示,此一功能賦予了具備不同能力、輸送量及處於不同開發階段的各個團隊,即便分隔幾千英里也能透過Swagger共享不同的API描述,一起打造產品。

受到該團隊重用的Azure API Management功能還包括憑證、節流、SSL卸載,以及與虛擬網路、Azure Load Balancer及Kubernetes Ingress的無縫整合。

Nunes說,在Azure的協助下,該團隊的軟體開發程序大有改善,現在車載軟體的更新與新功能的釋出只需要幾周就能完成,不再是冗長的幾個月,還能兼顧汽車與車主資料的品質及安全性。

 

各種作業的X-ray

為了持續監視基於容器的汽車服務,團隊以Azure Monitor打造了一個作業儀表板,Nunes說,它替團隊帶來了完全透視的作業,自Kubernetes平面到每一個運作中的個別服務。先前,該團隊使用Elasticsearch進行記錄、監視與警示,並由一專門供應商處理大多數的DevOps任務及資料中心的支援。

Nunes非常感謝Azure Monitor的容器功能,因為它監視了部署於AKS的各種容器任務的效能,以及自控制器、節點與容器蒐集記憶體及處理器的數據,而且當開發者於叢集中啟用監視功能時,AKS監視器的附加功能即會自動啟動,替作業系統代理人部署DaemonSet。

 


點擊 Banner 免費試用 Azure API Management,運用跨所有環境的混合式多重雲端管理平台、串接內部開發者。

Microsoft

熱門新聞

Advertisement