1.容器提供標(biāo)準(zhǔn)化開發(fā)
當(dāng)解決方案提供商專注于提供價(jià)值而不是目標(biāo)環(huán)境的復(fù)雜性時(shí),每個(gè)人都會(huì)贏。這就是容器大放異 彩的地方。
隨著容器技術(shù)產(chǎn)品(如 Docker)的廣泛采用和標(biāo)準(zhǔn)容器運(yùn)行時(shí)平臺(tái)(如 Kubernetes)的持續(xù)普及 ,開發(fā)人員需要考慮的兼容性問題越來越少。雖然熟悉目標(biāo)環(huán)境仍然很重要,但只要我們?cè)陂_發(fā)過程中可以使用相同的平臺(tái),具體的
操作系統(tǒng)、安裝的實(shí)用程序和服務(wù)就不是那么重要了。我們認(rèn)為這是越來越多的新容器運(yùn)行時(shí)選項(xiàng)的原因之一。
對(duì)于針對(duì)本地環(huán)境的工作負(fù)載,可以根據(jù)所需的編排級(jí)別選擇運(yùn)行時(shí)平臺(tái)。一些團(tuán)隊(duì)決定通過Docker-Compose 運(yùn)行他們的少數(shù)服務(wù),這對(duì)于開發(fā)和測(cè)試環(huán)境來說是典型的,對(duì)于生產(chǎn)安裝來說并非聞所未聞。對(duì)于需要成熟的容器編排器的用例,Kubernetes(以及 OpenShift 等衍生產(chǎn)品)仍然??占主導(dǎo)地位。
那些為云開發(fā)的人可以從眾多選項(xiàng)中進(jìn)行選擇。Kubernetes 存在于所有主要的云平臺(tái)中,但也有針對(duì)那些具有整體工作負(fù)載的選項(xiàng),從半托管服務(wù)到完全托管服務(wù),以獲取那些簡(jiǎn)單的 Web 應(yīng)用程序(如 Azure App Services 或 Google Cloud Platform 的 App Engine)。
對(duì)于那些冒險(xiǎn)進(jìn)入無服務(wù)器的人來說,部署單元通常是容器鏡像或源代碼,然后平臺(tái)變成容器。
通過所有這些選項(xiàng),關(guān)注我們的客戶如何采用容器技術(shù)是一件很有趣的事情。較小公司的 IT 戰(zhàn)略似乎對(duì)使用像我們這樣的解決方案提供商反應(yīng)更快。
但更大的公司也在迎頭趕上。我們歡迎企業(yè)客戶認(rèn)識(shí)到使用容器和其他云原生技術(shù)構(gòu)建和交付軟件的好處的趨勢(shì)。
總的來說,我們可以說作為集裝箱的運(yùn)輸解決方案正在成為常態(tài)。我們?cè)?Adnovum 使用 Docker,
我們已經(jīng)看到了對(duì)開發(fā)人員的具體好處。讓我們更多地看看這些好處。
2. 有限的曝光意味著更多的安全
針對(duì)容器平臺(tái)(與傳統(tǒng)操作系統(tǒng)包相對(duì))也會(huì)帶來安全后果。例如,假設(shè)我們有一個(gè)完全托管的 Kubernetes 平臺(tái)。這意味著客戶的 IT 團(tuán)隊(duì)負(fù)責(zé)以安全的方式配置和操作集群。在這些情況下,我們的開發(fā)人員可以將注意力集中在我們交付的應(yīng)用程序上。得益于容器技術(shù),我們可以進(jìn)一步限制對(duì)各種攻擊和漏洞的暴露。
這與容器的基本理念相關(guān):通過僅打包應(yīng)用程序絕對(duì)必要的內(nèi)容,您還可以減少可能的攻擊面。這可以通過從頭構(gòu)建鏡像或選擇安全基礎(chǔ)鏡像來封裝您的可交付成果來實(shí)現(xiàn)。在Docker Hub上選擇安全基礎(chǔ)鏡像時(shí),我們建議過濾由經(jīng)過驗(yàn)證的各方生成的容器鏡像:
也有完整的打包過程由您的開發(fā)工具處理的情況。我們?cè)谠S多 Web 應(yīng)用程序項(xiàng)目中使用 Spring Boot。Spring Boot 包含buildpacks,它可以以高效可靠的方式從您的 Web 應(yīng)用程序構(gòu)建 Docker OCI 映像。這減輕了開發(fā)人員尋找基本圖像的負(fù)擔(dān),并減少了(但并未完全消除)進(jìn)行各種優(yōu)化的需要。
3. 容器支持多樣化的開發(fā)者環(huán)境
雖然 Adnovum 專門從事網(wǎng)絡(luò)和移動(dòng)應(yīng)用程序開發(fā),但在這些范圍內(nèi),我們利用了廣泛的技術(shù)。支持此類異構(gòu)環(huán)境可能很棘手。
想象一下,我們有一個(gè)在 Linux 上工作的 spring boot 開發(fā)人員,另一個(gè)在 Mac 上開發(fā) Angular 前端。他們都依賴一組工具和依賴項(xiàng)在他們的機(jī)器上開發(fā)項(xiàng)目:
本地?cái)?shù)據(jù)庫(kù)實(shí)例
第三方服務(wù)的測(cè)試替身(模擬等)
瀏覽器——有時(shí)有多個(gè)版本
開發(fā)人員工具,包括運(yùn)行時(shí)和構(gòu)建工具
根據(jù)我們的經(jīng)驗(yàn),如果這些工具是本機(jī)安裝的,則很難跨多個(gè)操作系統(tǒng)支持這些工具。相反,我們嘗試將盡可能多的這些推送到容器中。這有助于我們調(diào)整開發(fā)人員的體驗(yàn)并降低跨平臺(tái)的維護(hù)成本。
我們?cè)?Windows 或 Mac 上工作的開發(fā)人員可以使用Docker Desktop,這不僅允許他們運(yùn)行容器,還帶來了一些額外的功能(Docker Desktop 在 Linux 上也可用,或者您可以選擇直接使用 docker-engine)。例如,我們可以開箱即用地使用docker-compose,這意味著我們無需擔(dān)心確保人們可以在各種操作系統(tǒng)上安裝它。在許多此類工具上執(zhí)行此操作可以為您的支持團(tuán)隊(duì)顯著降低認(rèn)知和成本。
如果您的開發(fā)人員需要同時(shí)跨多個(gè)項(xiàng)目工作,以這種方式外包您的依賴項(xiàng)也很有用。畢竟,沒有人喜歡安裝多個(gè)版本的數(shù)據(jù)庫(kù)、瀏覽器和工具。
我們通常可以將此技術(shù)應(yīng)用于我們最近的項(xiàng)目,而對(duì)于技術(shù)早于 Docker 大規(guī)模采用的舊項(xiàng)目,我們?nèi)杂泄φn要做。
4. 容器有助于再現(xiàn)性
作為專業(yè)的軟件制造商,我們希望確保我們不僅為客戶提供出色的解決方案,而且如果有任何問題(功能或安全性),我們可以將問題追溯到產(chǎn)生工件的確切代碼更改——通常Web 應(yīng)用程序的容器映像。最終,我們可能還需要重建所述工件的固定版本,這被證明是具有挑戰(zhàn)性的。這是因?yàn)闃?gòu)建環(huán)境也會(huì)隨著時(shí)間的推移而發(fā)展,不斷改變它們提供的兼容性窗口。
根據(jù)我們的經(jīng)驗(yàn),自動(dòng)化(特別是基礎(chǔ)架構(gòu)即代碼)是為開發(fā)人員提供可靠且可擴(kuò)展的構(gòu)建基礎(chǔ)架構(gòu)的關(guān)鍵。我們希望能夠在軟件或硬件出現(xiàn)故障時(shí)迅速重建環(huán)境,或者根據(jù)舊的配置參數(shù)提供基礎(chǔ)設(shè)施組件以進(jìn)行調(diào)查。我們的策略是通過 Ansible 或 Terraform 等工具管理所有基礎(chǔ)設(shè)施,我們強(qiáng)烈建議工程師避免手動(dòng)管理服務(wù)。我們的數(shù)據(jù)中心和云環(huán)境也是如此。
只要有可能,我們也更喜歡將服務(wù)作為容器運(yùn)行,而不是將它們安裝為傳統(tǒng)的包。您會(huì)在Docker Hub上找到許多流行的基礎(chǔ)設(shè)施服務(wù),例如NGINX和PostgreSQL。
我們嘗試推動(dòng)密封構(gòu)建,因?yàn)樗鼈兛梢砸龑?dǎo)自己的依賴項(xiàng),這大大減少了它們對(duì)特定 CI/CD 平臺(tái)提供的構(gòu)建上下文中安裝的內(nèi)容的依賴。從歷史上看,我們?cè)谥С忠蕾囉跈C(jī)器上安裝的瀏覽器的自動(dòng)化 UI 測(cè)試方面遇到了挑戰(zhàn)。隨著我們項(xiàng)目數(shù)量的增加,他們對(duì)瀏覽器版本的期望也有所不同。即使我們致力于自動(dòng)化,這很快就變得難以支持。后來,我們?cè)谑褂?Node.js 和 Java JDK 等工具時(shí)遇到了類似的挑戰(zhàn),幾乎無法滿足需求。
最終,我們決定在我們的自動(dòng)化構(gòu)建中采用引導(dǎo)和容器,允許團(tuán)隊(duì)定義他們的項(xiàng)目需要的 Chrome 或 Java 版本。在 CI/CD 管道期間,將在構(gòu)建之前下載所需的版本依賴項(xiàng),以防它尚未緩存。
不變性意味著我們的依賴關(guān)系和我們的產(chǎn)品,就此而言,在構(gòu)建之后永遠(yuǎn)不會(huì)改變。不幸的是,這并不是 Docker 標(biāo)簽的工作方式。事實(shí)上,Docker 標(biāo)簽在設(shè)計(jì)上是可變的,如果您習(xí)慣了SemVer ,一開始可能會(huì)感到困惑。
合乎邏輯的假設(shè)是,每當(dāng)您(重新)構(gòu)建自己的圖像時(shí),都會(huì)使用相同的基礎(chǔ)圖像。實(shí)際上,標(biāo)簽可以指向不同的圖像,以防有人決定在同一標(biāo)簽下發(fā)布新圖像。他們這樣做可能出于多種原因:有時(shí)是出于必要,但也可能是出于惡意。
如果您想確保您將使用與以前完全相同的圖像,您可以開始通過它們的摘要來引用圖像。這同時(shí)是可用性和安全性的權(quán)衡。雖然使用摘要使您更接近真正可重現(xiàn)的構(gòu)建,但這也意味著如果基礎(chǔ)鏡像的作者在同一標(biāo)簽下發(fā)布新的鏡像版本,那么您的構(gòu)建將不會(huì)使用最新版本。無論您傾向于哪一方,您都應(yīng)該使用來自可信來源的基礎(chǔ)圖像,并將漏洞掃描引入您的管道。
結(jié)合不變性(及其所有挑戰(zhàn))、自動(dòng)化和密封構(gòu)建,我們將能夠重建我們代碼的舊版本。您可能需要這樣做來重現(xiàn)錯(cuò)誤——或者在發(fā)布修復(fù)的工件之前解決漏洞。
雖然我們?nèi)匀豢吹阶约涸趯?shí)現(xiàn)可重復(fù)性的過程中有改進(jìn)的機(jī)會(huì),但在此過程中使用容器是我們將再次做出的決定。