標籤:

數人云|微軟Azure Container Service的容器化應用

8月19日的數人云線下Meetup,微軟中國有限公司創新技術合作事業部技術顧問趙文婧,從容器、虛擬機、微服務等方面為大家分享了Azure雲平台容器技術服務,以下是本次分享的實錄。

容器VS虛擬機

容器和虛擬機作為虛擬化技術,為我們提供了一個隔離的、獨立的運行環境,但兩者最大的不同之處是容量具有輕量級的優勢,上圖可以看到,每個虛擬機內部都有完整的操作系統,但一個主機上運行的多個容器是共享Linux內核的,容器和虛擬機的不同之處可以分為以下幾點:

  • 操作系統:虛擬機有完整的操作系統,容器共享內核。
  • 體積:虛擬機包含完整的操作系統,才創建過程中要給其分配一定量的內存去支持運轉,所以虛擬機比容器的體積更大,消耗資源更多。
  • 啟動:在啟動虛擬機的過程當中要從操作系統去啟動,因此啟動較慢,而容器的啟動時間是秒級的。

Docker是容器技術發展過程的重要變革,其ICON實鯨魚馱著非常多的集裝箱,這些集裝箱即容器,它帶來的主要變革有:提供了一套標準化的流程,可以用這個標準化的借口去將自己的應用進行鏡像打包,然後在不同的平台上部署和運行,Docker的寓意是碼頭工人,而它在我們部署運行的過程中起到的是綠色遷移作用。

若把容器遷移過程想像為以集裝箱為核心的運輸體系,那概念之間可以這樣對應:容器是集裝箱,雲服務提供商是裝載集裝箱的港口,雲服務商提供一些IaaS的服務可以理解為裝載集裝箱的拖船,同時在進行部署運行的過程中有一套標準化的流程,可以將其看做裝運流程。

隨著容器的不斷發展,可以看到可以看到容器在雲平台和物理機平台會形成一個綠色遷移發展,總結了容器的這兩個非常重要特點之後,接下來看一下Azure都提供了哪些容器服務。

Azure Container Service

Azure提供最重要的容器服務名為:Azure Container Service,首先,對於雲平台來說,它提供的很重要的資源是Infrastructure,無需購買虛擬機配置分散式集群,雲平台提供了基礎的框架如Azure上提供的虛擬機,它也會有其自己的Scale Sets,這些虛擬機會根據需求擴展VM的Sets,也會提供一些Availability Sts,幫助實現高可用。

有了基礎設施的架構,即可方便地在雲平台索取自己的一些計算機資源,在Infrastructure上,Azure Container Service提供了多種不同的編排工具,因為業務所用的容器是跨主機的,此時容器和容器之間需要進行通信、數據管理、網路管理等,編排工具可以幫助實現跨主機容器應用管理,Azure Container Service提供了三種主流的編排工具:Kuberntes、Swarm、DC/OS,可按需求自行選擇。

眾所周知,Kubernetes內部具有一些非常複雜的資源類型,雖然它提供了很多重要的功能,但在使用時也會非常繁瑣,這裡有一些工具可以幫助更好地使用Kuberentes,如DEIS這家公司的Helm和Draft。

  • Helm相當於軟體包的管理器,類似於Linux上的Apt-Get或Yum,通過Helm可以自動獲取一些名為Helm Chart的軟體包去快速構建部署Kuberentes集群上的應用。
  • Draft能夠自動識別應用的語言,幫助去寫Dockerfile和Helm Charts以及快速的構建部署引用,同時,Kuberntes是谷歌根據多年的系統經驗做的編排工具,Kuberentes的創始人後來也加入了微軟支持Azure。

之前說到的Infrastructure和以上編排工具都通過Azure的ARM模型進行構建,大家知道AWS有Cloud Formation,阿里雲上有Resource Orchestration,類似於這種模板文件,Azure上有自己的ARM文件,可以用一些很簡單的輸入,通過ARM模板在Azure進行部署,除了可以在Azure的Portal上或Azure CLI上去創建Azure Container Service,也可以通過ACS的Engine去創建,使用一些簡單輸入的定義文件用ACS Engine轉化為ARM模板,從而快速去創建部署,ACS Engine現在是開源在GitHub上的,用戶可以在其中快速更改自己的部署,從而進行一些自定義的容器服務,我們也希望這些開源的代碼能夠對社區做出貢獻,也幫助我們ACS的服務更快更好地發展。

微服務+容器化

之前了解了Azure Container Service提供的一些服務,下面再分享下微服務和容器化如何更好的結合,在集群部署的情況下,Azure Container Service在哪些方面起到相關作用。

首先,單體的應用。在集群部署的過程中和容器化的應用在集群部署的過程中有什麼區別,提到微服務,簡單地說即應用程序有多少獨立的組件,希望它們能夠獨立的進行開發測試以及運行,但假設一些單體的應用向把它部署到集群上時,為了實現高可用,將它在集群上的每個節點都進行部署,但對於容器化的應用,可以把這些應用拆分成多個獨立的組件,每個獨立的組件都能放在容器之中,為它提供一個獨立的運行環境,此時,當應用的模塊組件放在分散式集群這些節點上時,即可自動地去根據分散式節點的計算資源調整模塊分布的位置,假如在ACS部署了一個集群,ACS會幫助做一些負載均衡及網路管理的設置,可以在容器集群上更好地部署容器化應用。

DevOps

說到DevOps,目前很難給它做一個具體的定義,但其主要目的是在應用開發測試以及運行過程中做一個更好地銜接,使應用更新能夠快速地進行發布,從而提升提升效率,所以DevOps和容器的特性不謀而合。

通過容器技術可以達到一次編寫部署,在這個基礎上構建敏捷的DevOps開發若把應用構建在雲上,使用Azure上的容器服務,有一些工具可以使用如:Azure Container Registry,可以在它上面構建私有的鏡像倉庫,其中存儲著Docker格式的鏡像,此倉庫可以與Azure Container Service提供的編排引擎進行集成,如果想在Kubernetes集群上進行應用部署,可直接從這個鏡像倉庫中Push一個鏡像在上面運行,這個Push下來的過程即可直接寫在Kubernetes相關的部署文件當中。

鏡像倉庫是可以和Docker的鏡像倉庫兼容的,所以如果使用的是Docker工具,也可以進行無縫遷移,同時在Azure上使用容器化服務以及一系列持續集成工具鏈包括Visual Studio Visual Studio Team Service以及Visual Studio Code,通過一系列的集成工具鏈即可構建版本代碼庫,同時進行人員分配的管理調度,達到更好的持續集成、持續交付概念。

Demo:用ACS服務運行應用

接下來會為大家用比較多的時間演示Demo:在ACS上創建一個服務,並運行應用。

第一步:創建ACS的服務

點擊觀看Demo

有兩種方式:1、在Portal裡面進行創建,2、在Azure的CLI裡面進行創建。首先,這是Azure的Portal,進到裡面創建Azure Container Service,可以自定義服務名稱,因要使用Kubernetes,我定義這樣一個名字,選擇資源組,接下來定義Master節點的屬性,可以看到很多編排工具可以選擇,選擇Kubernetes,重新再來看下,最上面可以選擇三種不同的編排引擎,接下來我們會定義Master節點的用戶名,然後用SSH的Key去登錄我們的Portal。

將SSH的Key生成完畢後,直接粘進去,下面是在創建服務時需要一個服務主體,之前已經創建好了,使用它的ID和密碼,這裡可以設置Agent節點的數量以及設置VM的Size,我們確認信息,然後即可創建Kuberentes的集群了,同樣還有另外一種方法可以進行Azure的CLI里,用Az Acs Create 這樣的命令來創建自己的集群,那麼在這裡我們可以指定我們的編排引擎,接著指定我們要將集群放在哪個資源組裡面。

在Azure平台里,其實都是通過資源組去管理服務,比如服務需要什麼樣的計算資源,都會統一放在某個資源組裡,此時,讓不需要這項服務即可刪除整個資源組,然後去刪除這些服務,下面定義節點的VM Size以及SSH Key的這些選項,進入Portal里看下之前創建好的Kuberntes集群,可以看到這已經定義了Agent Master這樣一些節點,還包括一些負載均衡以及網路的組件,進到Cluster裡面看下它的組成:一個Agent Pool,VM Size VM Count顯示等,其實只要一些很簡單的輸入,即可快速地在Azure上創建一個ACS服務。

第二步:測試例子應用程序的本地鏡像部署和運行

點擊觀看Demo

接下來將一個WEB的應用部署在集群中,首先將WEB的應用在本機上進行鏡像的打包和運行,從這個地址Clone一個應用,確認Dockers是正在運行著的,查看本機上有哪些Docker鏡像,可以看到目前還沒有,接下來用Docker Compose這個命令去創建有關應用的所有進項,它會讀取Docker Compose文件,進到Docker-Compose文件里查看,定義了兩個服務,包括Azure-Vote-Back和Azure-Vote-Front,Redis是資料庫的服務,Azure-Vote-Front是前端的投票應用服務。

在創建的過程中,會Push一些基礎鏡像擴,包括Nginx這個正在Pull下來的WEB Server鏡像,還有資料庫的鏡像,生成應用自身的鏡像,完畢後,可以看到本地現在有三個鏡像,此時有兩個容器正在運行,包括資料庫和應用,再來確認下Docker Compose的文件中所確定的應用,本機和容器之間的埠映射,可以看到,進到本機8080埠可以運行WEB應用,這是一個投票軟體,會在這個WEB上面進行投票,而後資料庫會對這些投票進行記錄,此應用現在已經在機器上運行成功,下面會將這個應用部署到剛才創建的集群上面。

第三步:創建Azure Registry並將應用鏡像Push進去

點擊觀看Demo

在將應用Push到集成之前,首先需要創建一個Azure上的容器註冊表,即創建屬於自己的鏡像倉庫,可以看到鏡像倉庫已經創建完成,可以使用其中的Login Server和Password進行登錄,現在需要獲取此進項倉庫的密碼,成功後在本地登錄到鏡像倉庫中,將之前創建的鏡像Push到進項倉庫中,在此之前,需要用Docker Tag命令為鏡像打一個標籤,之後用Docker Images確認,這是為了下次在進行應用更新時的版本控制。

現在把鏡像Push到剛才創建的鏡像倉庫中,在Push的過程里會不斷地顯示Push的階段,成功後進到Azure的CLI中查看已經Push成功鏡像的List,此時顯示了剛才大號標籤的鏡像已經Push到鏡像倉庫中。

第四步:用Kubectl連接到Kubernetes集群並在集群上運行應用

點擊觀看Demo

可以看到在這個應用下載的例子中,有一個定義Kubernetes部署的文件,那麼在這個文件中定義了不同的Deployment和不同的Service,可以在這個文件中寫清自己的部署,然後利用此文件創建Kubernetes的部署。

將這裡使用的鏡像更換成之前在鏡像倉庫中Push進去的鏡像,更換鏡像倉庫的Loginserver,然後會用Kubectl Create的命令根據剛才所看到的的部署文件去創建部署和服務。

現在創建了WEB應用的部署和一些Service,接下來即可Get剛才創建的Service,然後同時用Watch參數進行監控,獲得IP後,即可將Watch關掉,進入External的IP里查看應用的運行情況。

第五步:為集群做擴展

點擊觀看Demo

進入此IP後,即可看到UI界面,部署完應用後,如何給集群做擴展?有兩個方面:包括Kubernetes的單元Pod擴展,也包括集群節點的擴展,依次來看一下:

Kubernetes裡面的Pods的情況,現在給Azure-Vote-Front進行擴展,用Kubectl Scale的這個命令擴展副本數是5個,擴展完成後再用Kubectl Get Pods這個命令進行查看,此時Azure-Vote-Front就變成了需要的5個量,可以在更多的量上去做自己的應用計算資源的應用,接下來看一下剛才部署文件中它其實是設置了有關請求的CUP的量,M其實指的是一千分之一核這樣的一個單位,請求CPU量為250M現在在500M之內,可以根據CPU的使用率去進行後面的擴展。

定義CPU的Pescent是50,即當CPU的使用率超過50%時,可以給它達到10個Azure-Vote-Front Pods的情況,可以通過這樣一個命令來查看已經設置過的自動擴展狀態,除了在Kubernetes的Pods做這樣一個擴展,還可以在VM的Count這個層面上去做一個擴展,可以設置New-Agent-Count這個數字為4,此時會從剛才的3個Count編程4個Count。

第六步:應用更新後的快速發布

點擊觀看Demo

最後一步會為大家分享如何進行應用更新後的快速部署和運行,進到剛才下載下來的應用,進入UI定義文件,將剛才的Cats和Dogs更改成其他的單詞,讓它可以顯示在UI上,以表示更新。完成後仍之前提過的Count應用重新給應用進行打包鏡像,成功後此時將應用以一個新的標籤來傳到剛才的Registry里,顯示剛才的Count結果,定義Count為4,此時編程了新的VMcount,相當於在Cluster理有4個可用的VM。

把剛才更新好的應用重新打一個標籤:V2,發現已經定義成功,接下來把打好標籤的鏡像Push到之前創建好的鏡像倉庫中,可以看到其實有一些內容已經存在了,這是剛才擴展後的情況,對這個更新好的鏡像進行重新部署,它提示這個鏡像已經更新成功,重新看到Pods的情況是有一些已經進行更新了,從最右邊的Age來看Pods的存在時間,下面重新Get Service來去查看這個應用的運行結果,登錄到這個響應的IP里去查看一下。

可以看到現在選項已經編程了White和Black,從進行應用更新到快速在集群上部署運行,只需要很短的時間即可進行。

今天給大家介紹的內容主要是有關Azure Container Service上面的容器化應用。謝謝大家。


推薦閱讀:

少年,你的告警量可以更少些!
玩轉NetDevOps
怎麼把SQL server放到docker里運行?
閑聊我心中的運維

TAG:DevOps | 容器 |