容器并不能解決一切問題

容器化在開發(fā)和運維領域掀起了一場風暴。在過去，部署是高度依賴于特定技術的，通常需要對每個項目進行大量不可重復的工程工作。你是否部署到 VPS？你是否在分發(fā)虛擬機鏡像？靜態(tài)可執(zhí)行文件？需要特定解釋器的腳本? 根據(jù)你對這些問題的回答，你可能已經(jīng)使用了 Capistrano、Puppet、shell 腳本、Ansible、deb 或 rpm 包、cloud-init 腳本、專有云技術、upstart、systemd、init 等很多技術。在部署階段，系統(tǒng)管理和開發(fā)之間的界限就變得模糊了，DevOps 的原則就誕生了。隨著 DevOps 開始成熟，業(yè)界發(fā)展出了應用開發(fā)的最佳實踐，比如 12 因素應用程序方法論，但許多實現(xiàn)細節(jié)仍然是依賴于特定技術的。

然后 Docker 出現(xiàn)了，并通過如下簡單的規(guī)則使應用程序的部署產(chǎn)品化：如果你的應用程序可以打包成一個容器，那么它就可以部署在任何地方。容器并不是什么新鮮事——畢竟，谷歌已經(jīng)使用它們很多年了。Unix 黑客也曾出于類似目的使用 Solaris Zones 和 FreeBSD jail。然而，在 Docker 出現(xiàn)之前，還沒有一個很好的方式可以輕松地將應用程序打包到一個可移植的容器中。Docker 徹底改變了我們部署應用程序的方式。

Docker 解決了許多重要的部署問題，所以接下來要問的問題是 Docker 是否為開發(fā)提供了任何優(yōu)勢。擁有一個看起來（至少大體看起來）像生產(chǎn)環(huán)境的開發(fā)環(huán)境有很多好處。如果你在生產(chǎn)環(huán)境中部署 Docker 容器，那么在開發(fā)過程中在容器中運行代碼也是合理的。此外，Docker 還解決了版本依賴關系的問題。例如，如果你有一個應用程序需要 MySQL 5.3，而另一個應用程序需要 MySQL 5.7，那么你就不需要在本地運行兩個版本，也不需要在各自的虛擬機中運行每個版本。你可以為每個版本使用一個容器，它們可以在幾秒鐘內(nèi)啟動和停止。

2013 年底，Docker Compose（當時稱為 fig）進入了這個領域。Docker Compose 有一個簡單的前提：與使用一次性腳本啟動和停止應用程序及其在開發(fā)中的依賴不同，你把它們描述為 YAML 文件中的 Docker 容器，并讓 Docker Compose 管理它們的生命周期。它提供了一些額外的細節(jié)，如為 12 因素應用程序提供日志采集、環(huán)境變量以及基本容器網(wǎng)絡。簡而言之，Docker Compose 對那些想要使用容器化的方法開發(fā) 12 因素應用程序的開發(fā)人員來說是一種完美工具。

乍一看，Docker Compose 似乎是本地開發(fā)的理想解決方案——在許多情況下，它確實是。然而，就像它的名字一樣，它只關注那些一切都在 Docker 內(nèi)部運行的開發(fā)工作流。在某些情況下，這樣做很好。例如，如果你在 Node.JS 中編寫一個依賴于 Postgres 的 API，那么你可以在 nodejs 容器中運行代碼（可能在它前面有一個文件監(jiān)視器），在 Postgres 容器中運行 Postgres。然而，并不是所有的開發(fā)工作流都可以被容器化。無論是為了性能、易于與主機操作系統(tǒng)特性集成，還是其他許多原因，有時最好將開發(fā)環(huán)境的某些部分作為本地進程運行，而將其他部分作為容器運行。你仍然需要拼湊一個解決方案，以將非 Docker 部分與一些 Docker 容器進行集成。

此外，考慮到 Docker 依賴于 Linux 內(nèi)核特定的特性來實現(xiàn)容器，macOS、Windows、FreeBSD 和其他操作系統(tǒng)的用戶仍然需要虛擬化層。我們想要通過使用容器來擺脫的一系列復雜的網(wǎng)絡、文件同步和虛擬機管理等問題仍然存在。當然，它們通常是可以工作的——直到出現(xiàn)問題，這時我們就只剩下谷歌、Stack Overflow 和 GitHub 來幫助我們找到解決方案。

快進到 2021 年，大多數(shù)生產(chǎn)級應用也依賴于云基礎設施，這些基礎設施不能作為本地 Docker 容器運行，因此我們面臨一系列新的問題，每個問題都需要權衡：

• 我們是否將云服務存根？這種方法成本低、性能好，但除了非常簡單的服務外，維護本地存根所需工程量很高。

• 每個開發(fā)人員是否都有自己的每個云資源實例？這通常代價高昂，公司必須支付很高的成本來保留很少使用的基礎設施。無服務器產(chǎn)品通常比預留產(chǎn)品有更好的成本模型，但仍然必須考慮成本。

• 開發(fā)人員是否共享共同的開發(fā)基礎設施？在此選項中，基礎設施成本降低了，但通常需要額外的工程量，以便多個應用程序可以共享相同的數(shù)據(jù)庫和其他有狀態(tài)服務而不會發(fā)生沖突。換句話說，每個應用程序都必須支持多租戶。

以上選項在不同的場景中都是可行的，但這里要說的是采用 Docker 或者 Docker Compose 并不能解決問題——甚至不能指出哪個選項是最好的！現(xiàn)代開發(fā)環(huán)境編排器必須具有云感知能力并支持不同的運行時架構(gòu)。目前，基礎設施即代碼工具最接近解決這個問題，但由于它們專注于生產(chǎn)部署，因此無法與本地開發(fā)環(huán)境順利集成。

除了云服務，微服務還具有它們自身的復雜性，這些復雜性是“僅僅使用 Docker”無法解決的。任何采用了微服務策略的大型組織都會迅速發(fā)展到任何開發(fā)人員都可以在其筆記本電腦上運行該組織所有服務的地步。像 Telepresence 這樣的工具有助于將本地容器連接到遠程 Kubernetes 集群中運行的容器，但我們?nèi)匀蝗狈δ軌蚩绫镜睾瓦h程環(huán)境透明地處理服務發(fā)現(xiàn)、代理和身份驗證等問題的高級工具。而且，現(xiàn)有的工具大多是以 kubernetes 為中心的，這給很多開發(fā)人員增加了使用難度。

我們的行業(yè)在過去十年中取得了令人難以置信的進步，這在一定程度上要歸功于 Docker、Docker Compose 和 Kubernetes 等技術。然而，我們?nèi)栽谘芯咳绾卧谖覀兯幍亩鄻踊h(huán)境中進行開發(fā)。下一代開發(fā)工具必須能夠處理本地進程、Docker 容器、云服務，甚至其他團隊的微服務的構(gòu)建和運行。針對所有這些問題，我們還沒有答案，但我們正在構(gòu)建 exo，以幫助像我們這樣的開發(fā)者克服本地開發(fā)的復雜性。

原文鏈接：https://blog.deref.io/containers-dont-solve-everything/

歡迎關注“Java引導者”，我們分享最有價值的Java的干貨文章，助力您成為有思想的Java開發(fā)工程師！