為什麼Docker容器将占領世界
我加入了bieryun,主持了一個關于Docker的網絡研讨會,以及您可以使用容器将傳統Windows應用程式遷移到雲端以及運作開源無伺服器平台。
我分享了Docker容器啟用的最常用的用例。這些是公司目前在生産中所做的事情。以下是前五個場景,以及我在現場網絡研讨會上對問答的所有答案。
将應用遷移到雲端
将現有工作負載遷移到雲曾經是IaaS和PaaS之間的選擇。PaaS選項意味着将您的應用程式的要求與您選擇的雲的産品目錄相比對,并采用包含所有托管服務的元件的新架構:
這有利于營運成本和效率,但需要一個項目才能實作 - 您需要更改代碼并運作完整的回歸測試套件。當你上線時,你隻能在一個雲上運作,是以如果你想要多雲或混合雲,它将需要另一個項目。
另一種選擇是IaaS,這意味着在雲中租用虛拟機。由于您隻需要啟動一組VM并使用現有的部署工件和工具來部署應用程式,是以初始工作量較少:
但是,将VM環境從資料中心複制到雲隻意味着要複制所有營運和基礎架構的低效率。你仍然需要管理你的所有虛拟機,而且它們仍然大量未充分利用,但現在你有一個月度賬單顯示它的效率是多麼低效。
新方法是首先将應用程式移動到容器,然後在雲中運作它們。您可以使用現有的部署工件來建構Docker容器映像,是以您無需更改代碼。如果您可以将部署腳本編寫到Dockerfile中,那麼您可以容納幾乎任何東西 - 它可能是一個已有15年曆史的.NET 2.0應用程式或去年的Node.js應用程式:
Docker化應用程式在任何地方都以相同的方式運作,是以開發人員可以使用Docker Desktop在本地運作整個堆棧。您可以使用Docker Enterprise在資料中心或雲中運作它們,也可以選擇雲提供商的容器服務。這些應用程式現在可以移植,運作速度遠遠超過虛拟機,并使用最新的作業系統,是以這是擺脫Windows Server 2003和2008的好方法,很快就會失去支援。
提供雲原生應用程式
從初創企業到大型企業,人們都看到了新型應用程式架構帶來的好處。所述雲本地計算基礎(CNCF)定義了這些類型的應用程式作為具有微服務的設計,在容器中運作,并且由容器平台動态管理。
雲原生應用程式可高效運作并輕松擴充。它們是自我修複的,是以應用程式和基礎架構問題不會導緻停機。它們旨在支援快速,增量更新。在容器中運作的微服務可以獨立更新,是以可以推出對産品目錄服務的更改,而無需測試支付服務,因為支付服務不會更改:
這個架構來自GitHub上的微服務 - 示範示例,它都打包在容器中運作,是以您可以在筆記本電腦上啟動整個堆棧。它使用一系列程式設計語言和資料庫作為每個元件的最佳選擇。
現代化傳統應用程式
您可以在同一群集上的Docker容器中運作現有應用程式和新的雲原生應用程式。它也是一個發展遺留應用程式的絕佳平台,是以它們的外觀和感覺更像是雲原生應用程式,而且您可以在沒有2年重新架構項目的情況下完成。首先将應用程式遷移到Docker。此示例适用于單個ASP.NET Web應用程式和SQL Server資料庫:
現在,您可以開始從整體中斷出功能并在單獨的容器中運作它們。版本2可以使用反向代理來引導現有monolith與在單獨容器中運作的新應用程式首頁之間的流量:
這是一個簡單的模式,用于分解Web UI而無需更改原始整體中的代碼。對于下一個版本,您可以打破應用程式的内部功能,并将其作為在另一個容器中運作的REST API公開:
這些新元件完全獨立于原始元件。你可以使用你喜歡的任何技術堆棧。每個功能都可以有自己的釋出節奏,您可以按需要的比例運作每個元件。
技術創新:無伺服器
到目前為止,您已經在同一群集上的Docker容器中運作了遺留應用程式,雲原生應用程式和不斷發展的單塊。您以相同的方式建構,打包,分發,運作和管理所有應用程式的所有元件。您的整個應用程式環境都在一個安全,現代和開放的平台上運作。
它并沒有就此結束。可以使用相同的平台來探索技術創新。無伺服器是一種很有前途的新部署模型,它由容器驅動。AWS Lambda和Azure功能是專有實作,但是有許多開源無伺服器架構可以在資料中心或雲中與Docker一起部署:
所述CNCF無伺服器工作組定義的目前選擇的通用架構和管道的過程。如果您對無伺服器模型感興趣,但是您在本地或跨多個雲運作,那麼開放架構是一個很好的選擇。Nuclio很容易上手,它在與其他應用程式相同的平台上的Docker容器中運作。
流程創新:DevOps
下一個重大創新是DevOps,它旨在打破建構軟體的團隊和運作軟體的團隊之間的障礙,目标是更快地将更好的軟體推向市場。DevOps更多的是關于文化和流程,而不是軟體,但如果你仍在使用相同的技術和工具,很難做出有影響力的改變。
CALMS是一個很好的架構,用于了解DevOps轉換中要關注的領域。它是關于文化,自動化,精益,名額和共享的關鍵部分。如果您通過技術變革為其提供支援,那麼在這些領域取得進展并量化成功要容易得多。采用容器支撐該架構:
當團隊使用相同的工具并使用相同的語言時,将團隊整合在一起要容易得多 - Dockerfiles和Docker Compose檔案與應用程式源代碼一起使用,并由Dev和Ops共同擁有。它們提供了共同合作的共同點。
自動化是Docker的核心。手動制作容器要比使用Dockerfile自動化容器要困難得多。将應用程式分解為小型單元支援精簡,您可以将名額烘焙到所有這些元件中,以便為您提供一緻的方法來監控不同類型的應用程式。Docker Hub可以輕松共享,其中有數十萬個應用程式打包為Docker鏡像。
網絡研讨會問答
我們在會議結束時提出了很多問題,沒有足夠的時間來回答這些問題。以下是錯過的問題。
問:你說你可以在你的筆記本電腦上運作你的投票應用程式,但它是Linux和Windows容器的混合體。這不會有用嗎?
答:不,你不能在一台機器上運作Linux和Windows容器的混合體。您需要有一個運作Docker Swarm的叢集,其中包含Linux和Windows伺服器的混合體。示例投票應用程式具有不同的版本,是以它可以在所有Linux,全Windows或混合環境中運作。
問:使用Docker容器從源代碼編譯[你的應用程式]是什麼?在這種情況下MSBuild?
答:是的,您編寫了一個多階段Dockerfile,其中第一階段編譯您的應用程式。該階段使用已部署工具集的Docker鏡像。Microsoft擁有.NET Framework SDK映像和.NET Core映像,還有其他平台(如Go和Maven for Java)的官方Docker映像。您可以建構自己的SDK映像并打包所需的任何工具。
問:如果群集中安裝了遺留應用程式,我們如何使用Docker swarm或Kubernetes維護粘性會話?
答:您的群集節點上将有一個負載平衡器,是以流量可以進入任何伺服器,然後您可以在該伺服器上運作多個容器。Docker Swarm或Kubernetes都沒有為開箱即用的容器提供會話親和性,但你可以通過運作像Traefik這樣的反向代理或者像Nginx這樣的Kubernetes的會話感覺入口控制器來實作。
問:在桌面上進行測試時,不同的作業系統要求如何工作?(例如,某些容器需要Linux,有些需要Windows,而Mac則用于開發)
答:容器非常有效,因為它們使用運作它們的主機的底層作業系統。這意味着Linux容器需要在Windows主機上的Linux主機和Windows容器上運作。Docker Desktop使這一切變得簡單 - 它為您提供和管理Linux VM。Docker Desktop for Mac隻允許您運作Linux容器,但Docker Desktop for Windows支援Windows和Linux。
問:IDE如何适應Docker(例如,確定所有開發團隊成員都使用相容的IDE配置)?
答:使用Docker從源代碼編譯和打包應用程式的好處在于人們使用的IDE無關緊要。當開發人員在本地測試應用程式時,他們将使用具有CI使用的相同建構腳本的Docker容器來建構和運作它。是以建構是一緻的,團隊不需要使用相同的IDE - 人們可以在同一個項目中使用Visual Studio,VS Code或Rider。
問:如何協調Windows容器的最佳方法?
答:現在隻有Docker Swarm支援生産中的Windows節點。您可以将多個Windows伺服器與Docker Swarm一起加入,或者使用Docker Enterprise配置混合的Linux-Windows群集。預計到2018年底,Kubernetes将支援Windows節點。
問:我是否需要管理程式來管理我的Docker環境運作的底層硬體?更好的是,使用Docker是否可以滿足對VMware的需求?
答:Docker可以在裸機或VM上運作。生産Docker伺服器隻安裝了最小的作業系統(比如Ubuntu Server或Windows Server Core)和Docker。
問:在容器中運作的SQL Server可以使用Windows身份驗證嗎?
答:是的。預設情況下,容器不是域加入的,但您可以使用憑據規範運作它們,這意味着它們可以使用組管理的服務帳戶的憑據通路AD。
問:對于舊的Eclipse IDE依賴,在容器内建構/編譯Java的任何建議嗎?
答:您需要在沒有任何IDE的情況下通過腳本建構應用程式。如果您可以遷移建構以使用Maven(例如),那麼您可以在Dockerfile中使用Maven設定建構和打包。
問:那麼,伺服器必須擁有容器所需的所有應用程式?如果伺服器沒有容器需要的應用程式,會發生什麼?
A.不,恰恰相反!Docker鏡像是包含容器所需内容的包。是以,Docker鏡像中的ASP.NET應用程式将安裝.NET Framework,IIS和ASP.NET,并且您不需要在運作容器的伺服器上安裝任何這些元件。
問:如果您需要多種技術來運作應用程式,如何在單個包中建立支援它們的Docker鏡像?如果您需要一個不易獲得的特定技術堆棧呢?
答:您的應用程式映像需要安裝應用程式的所有先決條件。您可以使用現有圖像,如果它可以為您提供所需的一切或建構自己的圖像。隻要您可以編寫腳本,就可以将其放在Dockerfile中 - 是以Windows Dockerfile可以使用Chocolatey來安裝依賴項。
問:Docker如何決定哪些庫/運作時将成為容器的一部分?它如何劃分OS和其他運作時?
A. Docker沒有決定。這取決于建構應用程式映像的人。目标是使您的應用程式實際需要的依賴項盡可能地使您的運作時映像盡可能小。這為您提供了更小的攻擊表面區域,并縮短了建構和部署的時間。