容器並不能解決一切問題

我們的行業在過去十年中取得了令人難以置信的進步，這在一定程度上要歸功於 Docker、Docker Compose 和 Kubernetes 等技術。然而，我們仍在研究如何在我們所處的多樣化環境中進行開發。

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

進入 Docker

 使用 Docker 打包和部署

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

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

 使用 Docker Compose 進行開發

 使用 Docker Compose 管理開發環境

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

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

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

現代開發：雲和微服務

 雲原生開發的複雜性

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

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

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

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

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

除了雲服務，微服務還具有它們自身的複雜性，這些複雜性是 “僅僅使用 Docker” 無法解決的。任何採用了微服務策略的大型組織都會迅速發展到任何開發人員都可以在其筆記本電腦上運行該組織所有服務的地步。像 Telepresence 這樣的工具有助於將本地容器連接到遠程 Kubernetes 集羣中運行的容器，但我們仍然缺乏能夠跨本地和遠程環境透明地處理服務發現、代理和身份驗證等問題的高級工具。而且，現有的工具大多是以 kubernetes 爲中心的，這給很多開發人員增加了使用難度。

下一步是什麼？

我們的行業在過去十年中取得了令人難以置信的進步，這在一定程度上要歸功於 Docker、Docker Compose 和 Kubernetes 等技術。然而，我們仍在研究如何在我們所處的多樣化環境中進行開發。下一代開發工具必須能夠處理本地進程、Docker 容器、雲服務，甚至其他團隊的微服務的構建和運行。針對所有這些問題，我們還沒有答案，但我們正在構建 exo，以幫助像我們這樣的開發者克服本地開發的複雜性。

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/HKnW50EfxBnKtNyz5OfW3Q